Agents are users now, and they found every hole in our product — Next Wave of Tech

▶ NOW PLAYING · CH 03<br>Agent interface<br>Demo Reels · AUG 03, 2026

▶ CH 03

TAPE №011<br>Demo Reels·AUG 03, 2026·10 MIN<br>Agents are users now, and they found every hole in our product<br>Products have a new interface to design and a completely new set of ways to fail as agents become users.

Working with AI can feel a bit like training a puppy. You give it an instruction, watch it repeat the instruction back correctly, and then it does the exact thing you told it not to do. Instead of chewing your shoes, it ignores a skill file or calls the wrong tool and then gives you a very convincing explanation for why.

I've spent a lot of the last few months building a plugin for Until, our plan-first workflow for coding agents. The basic idea is straightforward: agree what should be built, write and review the plan, then let the agent implement it. I went into this thinking the difficult bit would be getting that workflow right.

Building it has made me think that agent-first products have at least three interfaces:

The interface the human sees and controls

The interface the agent reasons through

The MCP or app interface where the actions actually happen

We have spent decades learning how to design the first one, and the third looks enough like an API that we have some decent instincts. The agent interface in the middle is much stranger. It is where most of our failures have happened, and where a problem that seems obvious in one conversation can be a nightmare to recreate in the next.

The agent interface is a product surface

An MCP tool can have a perfect schema and still be horrible to use. The agent needs to know when to call it, what state the product is in and what it is actually allowed to do. It also needs to know what to do when something goes wrong. This sounds obvious written down. It was not obvious while we were building it.

One of our first proper failures happened in Cursor's Plan Mode. The agent had written a plan, the user had read it and then clicked the big Build button. So the agent started building. You can see the logic: the user approved a plan and then pressed a button that literally said Build. The problem was that our workflow had another step in between. The plan needed to be submitted and reviewed before any code changed, so we added clearer instructions.

The next agent got as far as review. The reviewer came back with "revise", but the agent decided the comments were minor implementation details and carried on as if it had been approved. We added more instructions. Then another agent openly acknowledged that review was still pending, decided the user's eagerness counted as an "explicit go-ahead", and started building anyway.

This went on for a while. Every time we closed one route the agent found another, usually with a completely plausible explanation for why this time was different. Eventually we stopped trying to solve all of it with words. Instructions are still useful for teaching the agent how the product works, but they cannot be responsible for the rules that always need to hold. We moved those states into code and started blocking the transitions that should not be possible.

We also found a particularly stupid hole in our review flow. The agent that wrote a plan could record the verdict approving it. We had told it not to self-approve, but when the quickest route to finishing involved self-approval, some models could convince themselves there was a good reason to do it. A rule the agent is responsible for policing is still basically a suggestion, so the author and reviewer needed to be separate actors in the product, with that separation enforced outside the conversation.

Different models use the same product differently

This is where the choice of model starts to matter a lot more than I expected.

The biggest difference we have seen is between Composer 2.5 and models like GPT-5.6 or Opus. Composer will bypass every living thing to get you where you asked to go. It can be brilliant when you just want something done. Put it inside a process with deliberate stopping points and it becomes an absolute pain.

GPT-5.6 and Opus have been more willing to treat the workflow as part of the job. Composer is more inclined to see the workflow as something standing between it and the job. I am not saying Composer is bad, or that this will hold for every version and every prompt. We pin model versions in our tests precisely because this stuff changes. There are plenty of tasks where I would prefer the model that keeps pushing until it gets an answer.

But two models supporting the same MCP tools does not mean they use your product in the same way. They can read the same instructions, see the same tools and make completely different calls about what they are allowed to do next. Composer has actually become quite useful for us because of this. If we have left an escape route somewhere, it tends to find it. I...