20th July 2026
Having built a couple of coding agents, I’ve learnt the model is only one part of the product.
What determines whether an agent is useful is the harness around it: how it manages context, asks for permission, uses tools and protects the user’s environment. A strong model inside a weak harness is still a poor agent.
Three principles have mattered most in my experience.
An agent should remember what the user is trying to achieve without becoming slower as the conversation grows.
Prompt caching helps by reusing parts of the conversation that have already been processed. Context management is harder. Simply removing the oldest messages can discard the original brief or an important technical decision.
A good agent should:
Messages also need to be reliable. If a user sends a correction while the agent is working, it should be preserved and acted on, not lost because the task was interrupted.
The aim is not to pretend that context is infinite. It is to give users clear ways to retain decisions, summarise progress and start a fresh session when needed.
Agents become valuable when they can act, but trustworthy only when those actions are visible and controllable.
Permission requests should explain exactly what the agent wants to do and why. Users should be able to approve one action, create a narrow ongoing rule or block a category of action altogether.
Denying a request should not destroy the task. The agent should retain its progress and offer another route where possible.
This reduces permission fatigue. If users face a stream of vague approval requests, they will eventually accept them without reading. Secure defaults and clearly scoped choices are as much a UX concern as a security one.
The same principle applies elsewhere:
I’ve also found that more tools and subagents do not automatically produce better results. Overlapping tools confuse the model, while poorly divided subagents duplicate work or operate with conflicting context.
Each tool should have a clear purpose. Editing tools should favour precise, reviewable changes. Planning tools are useful only if the agent keeps the plan current. Narrow search tools can be safer and easier to approve than giving every task unrestricted shell access.
A coding agent may be able to read private code, edit files, run programs and access credentials. The model cannot be trusted to police those powers itself.
Filtering commands by reading their text is not a reliable security boundary. The same action can be hidden inside a script, encoded payload or chain of commands.
Restrictions should be enforced at the operating-system level, using mechanisms such as Landlock on Linux, Seatbelt on macOS or restricted tokens on Windows. These can control which files an agent may access, whether it can use the network and which programs it may run.
For example, an agent might be allowed to read a repository’s .git directory but not modify it. It can inspect the history without being able to rewrite it.
Exact defaults depend on the product. Denying everything can make an agent unusable, while allowing everything creates obvious risks. The important point is that permissions should be explicit, narrowly scoped and technically enforced outside the model.
Users should also know when their code or prompts may leave their machine and which service receives them. Local-first operation is useful, but remote models and web access have real benefits. The choice should simply be visible.
Containers can help, but they are not a complete security model. Their effectiveness depends on their configuration, mounted files and controlling services. They should sit alongside proper permissions and OS-level isolation.
Language models are capable, but fallible. They can misunderstand instructions, invent facts and produce convincing code that does not work.
The harness should compensate for this through review, testing, reversibility and clear reporting of what has/has not been checked.
After building several agents, my main conclusion is straightforward: the best agent is not necessarily the one using the cleverest model. It is the one that combines a capable model with disciplined context management, focused tools, clear user control and security boundaries the model cannot bypass.
The model provides the intelligence. The harness makes it dependable.