The agent platform I decided not to build

I had the beginnings of a credible coding-agent control plane: isolated Git worktrees, structured events, deterministic validation, and a human review step before accepting change.

The architecture was reasonable. That was the problem.

Modern coding agents increasingly provide orchestration, task routing, isolated execution, and reviewer roles as normal capabilities. Continuing to polish my version would show that I could assemble those mechanics, but it would not answer the harder portfolio question: what does this product demonstrate that a capable agent platform does not already provide?

I could have added more agents, a richer dashboard, or another planning stage. Those additions would make the system larger without making the central claim stronger.

So I stopped treating the prototype as the product.

Keep the machinery, replace the claim

The useful parts did not need to be thrown away. Isolation, event capture, deterministic fixtures, and validation are valuable infrastructure. They became substrate for a narrower idea called BoundaryLab: an adversarial reliability lab for comparing how agent architectures behave when context and authority become dangerous.

Instead of asking, “Can several agents complete a task?”, BoundaryLab asks questions such as:

• What happens when retrieved text contains an instruction that should never receive authority?
• Does the system prevent an excessive refund without refusing a legitimate customer?
• Can a reviewer provide independent protection, or does it merely repeat the worker’s assumptions?
• Which context strategy produces a safe completion, an unsafe completion, or an unnecessary refusal?

Those questions require more than a polished final response. They require a synthetic world, explicit trust metadata, a deterministic capability gateway, protected evaluation, and visible traces of what was allowed or denied.

Architecture should earn its place

Multi-agent diagrams are easy to make impressive. Give one agent a planning title, another a coding title, and another a review title; then connect them with arrows. The result looks like a system, but the role names do not prove that the boundaries are necessary.

The stronger test is to ask what one component is prevented from seeing or doing.

In BoundaryLab, the judge must remain outside the worker’s trusted workspace because an agent should not be able to modify the rules used to score itself. The capability gateway exists because proposing a refund and authorizing one are different powers. The attacker exists because hostile content should be an experimental input, not an accidental surprise.

Now the architecture has something to protect.

A redirect can be the most valuable output

AI-assisted work creates a subtle pressure to continue. Once an agent has produced code, tests, and a roadmap, abandoning the product framing can feel wasteful. The visible output encourages commitment even when the underlying idea has weakened.

This experience reinforced a different measure of progress: sometimes the valuable result is recognizing that the artifact is technically competent but strategically ordinary.

1. 01Inspect the existing capability
2. 02Compare it with the current baseline
3. 03Identify the missing claim
4. 04Preserve reusable infrastructure
5. 05Reframe around a measurable failure

The reversal also improved scope. BoundaryLab is not a general evaluation platform. Its first arena is a small synthetic support workflow with legitimate requests, authority spoofing, excessive actions, and indirect prompt injection. Alternative architectures face the same authored scenarios, and a deterministic judge compares their outcomes.

That narrowness is an advantage: the ground truth can be inspected, the failures can be explained, and the public experience can replay immutable runs without asking visitors to spend model tokens.

Update: the test is now complete

Updated 8 September 2026. When this Note was first published, BoundaryLab was still a product direction and tested foundation. The benchmark, scenarios, gateway, context strategies, and protected judge had not yet produced a result. They have now been implemented as a public, read-only replay of 24 deterministic runs: the same eight synthetic support cases across three architecture profiles.

The vulnerable long-context profile completed four of eight tasks and recorded two successful attacks. The overcautious profile stopped every attack but falsely refused four legitimate cases. The bounded hybrid-memory profile completed all eight with zero successful attacks and zero false refusals.

That closes the test proposed here without expanding its claim. The runs use authored fake adapters, synthetic data, and zero model calls. They demonstrate that the benchmark can distinguish unsafe completion, unnecessary refusal, and safe completion; they do not predict production-model accuracy.

The control-plane prototype was not a failure. It answered a useful technical question and provided reusable infrastructure. But it was no longer a strong product claim. Deciding not to keep selling it as one was the decision that moved the work forward.