Most conversations about AI agents focus on capability. Can the agent draft emails? Can it qualify leads? Can it update the CRM? The assumption is that a more capable agent is a more useful agent, and that the path to value is adding more tools, more integrations, more autonomy. After twelve years of shipping AI in surgery, nuclear power, military defense, and enterprise operations, we can tell you that assumption is wrong. The most successful agent deployments we have seen share a counterintuitive trait: they got better by doing less.
The addition trap
The instinct when building an agent is to add. Add a Slack integration. Add browser access. Add a CRM write action. Add a memory file. Add exception handling for edge cases. Every addition feels like progress because each one solves a real problem in isolation. But in aggregate, they create something that is hard to trust, hard to debug, and hard to maintain.
One of the clearest illustrations of this comes from Vercel, which deployed a sales agent to handle inbound messages — filtering leads, researching companies, drafting responses, routing support questions. The agent worked. But it did not get meaningfully better until the team deleted 80% of its tools.
That sentence deserves a moment. The agent improved by having fewer capabilities, not more. The beginner instinct is to add. The maintenance instinct is to ask what should be removed.
This matches a pattern we see repeatedly in enterprise deployments. The organizations that succeed with agents are not the ones that build the most sophisticated wrapper on day one. They are the ones that treat the agent as a living system and maintain it with the same discipline they would apply to any critical production infrastructure.
Study the real workflow, not the paper workflow
Before Vercel built anything, they studied one of their best sales reps. Not the process documentation — the actual observed behavior. What did the rep ignore? What made a lead real? What research happened before a reply? When was a message actually a support issue? Where did the human still need to make a judgment call?
This distinction between the paper workflow and the observed workflow is one of the most important factors in agent deployment. Every organization has documented processes. Almost none of those documents accurately describe what people actually do. The gap between the two is where agent projects fail — and where the real automation opportunities live.
We run structured discovery engagements for exactly this reason. Fifteen to twenty AI-driven interviews across an organization, talking to the people who do the work, not just the managers who describe it. The output is a map of how work actually flows, which is almost always different from how leadership thinks it flows. Building an agent against the paper workflow produces an agent that nobody trusts, because it does not match reality.
The harness is the real product
There is a concept in agent engineering that deserves far more attention than it gets: the harness. If the agent is the worker, the harness is the workbench. It defines what the agent reads, what it remembers, what tools it can touch, what it is allowed to change, and what proof it has to bring back.
The agent is not the product. The harness — the system of constraints, permissions, sources, and verification loops around the agent — is the product. A capable model inside a poor harness is more dangerous than a mediocre model inside a well-maintained one.
This is a governance principle, not just an engineering one. In our work across regulated industries — healthcare, nuclear, defense — we have learned that the system around the AI matters more than the AI itself. A surgical navigation system does not succeed because the model is accurate. It succeeds because the harness ensures the model cannot act outside its verified domain, that every output is traceable, and that a human is in the loop at every critical decision point.
The same principle applies to an agent that qualifies sales leads. The stakes are lower, but the architecture is the same. What sources is the agent reading? Are those sources current? What can the agent change in your systems? What happens when it is wrong? Can a human inspect every step of its reasoning?
If you cannot answer those questions, you do not have a deployed agent. You have an unsupervised process.
Agents break in two directions
Here is something most teams do not anticipate: agents break in two directions, and only one of them is the one you expect.
The first direction is familiar. The world around the agent drifts. The wiki gets stale. The CRM fields change meaning. The dashboard still says “activation” but the team redefined what activation means three months ago. The process changed, the owner changed, the docs did not. With traditional software, this is annoying. With agents, it is dangerous — because agents do not sit idle. They produce work. They summarize, recommend, draft, route, and act based on whatever information they have access to. A stale wiki that is mildly inconvenient for a human becomes a source of confidently wrong output from an agent.
The second direction is the one that catches people off guard: the model inside the agent improves. A tool that helped a weaker model navigate ambiguity can confuse a stronger one. A constraint that protected you from an unreliable model’s mistakes can trap a better model. A workflow that forced rigid structure around a clumsy agent becomes unnecessary friction when the model can handle more nuance on its own.
We see this constantly. A team builds a careful, constrained harness around an early model. Six months later, the model has improved significantly, but the harness has not changed. The agent is either underperforming because the old constraints are holding it back, or — worse — the broad permissions that were safe when the model was too clumsy to act on them are now dangerous because the model is good enough to take twenty plausible actions in minutes.
This is why agent maintenance is not a one-time configuration task. It is an ongoing engineering discipline.
The compounding flywheel
There is a positive version of this dynamic as well. Better models can help build better harnesses, and better harnesses make agents more useful. This creates a compounding loop that the most effective teams are already exploiting.
The best agent deployments we work on follow this pattern. The initial harness is deliberately narrow — scoped permissions, limited tool access, mandatory human review. As the team observes the agent in production, they learn which constraints are necessary and which are vestigial. They prune what is no longer needed and expand where the model has demonstrated reliability. The harness evolves alongside the model, and each iteration makes the system more valuable.
This is the opposite of how most organizations approach agents. The typical pattern is to build a wrapper, launch it, and walk away — checking back only when something breaks. By then, the harness has drifted so far from reality that the agent is either useless or actively creating problems that humans have to unwind.
Five maintenance checks for any production agent
Based on what we have seen work in practice, here are five checks that every agent in production should go through regularly:
1. Check what it is reading
Are the sources current? Did the workflow change since the agent was last configured? Did a new data source become important? Did an old source become misleading? An agent that reads stale documentation will produce confident, well-formatted, completely wrong output.
2. Test its permissions
What can the agent touch? Can it only read, or can it create records, post messages, update fields, trigger workflows? A permission that was harmless for a weaker model may be too broad for a stronger one. Conversely, a restriction that made sense for an unreliable model may be holding back a better one. Permissions should be reviewed every time the underlying model is updated.
3. Verify its role
Is the agent still doing the right job? A summary agent might need to become a planning agent as the model improves. A routing agent might be capable of qualification. Do not let the role change silently because the model got smarter. Change the job deliberately, with updated constraints and verification, or do not change it at all.
4. Inspect the proof trail
The agent should not just produce conclusions — it should produce traceable evidence. Every recommendation should link to the source data. Every qualification should reference the signals it evaluated. Every routing decision should explain its reasoning. If a human cannot inspect the agent’s work and verify it independently, the agent is not trustworthy enough for production use.
5. Measure actual value
Does anyone read the output? Does it change the work? Does it save time after review, or does it create another pile of work that someone has to check? Has the model improved enough that the agent should be rebuilt from scratch? Has the business changed enough that the agent should be retired entirely? These are uncomfortable questions. They are also the questions that separate agents that deliver value from agents that consume resources.
Sailboats, not apps
Stewart Brand wrote in The Maintenance of Everything that the systems we depend on most are the ones that require the most sustained attention. Sailboats are not maintained because they were badly designed. They are maintained because they live in motion — the weather changes, the lines loosen, salt corrodes everything.
Agents live in motion too. The model changes inside them. The world changes around them. The harness has to keep up with both. The organizations that treat agents like apps — build once, deploy, move on — will join the 95% of AI projects that produce no measurable return. The organizations that treat agents like sailboats — inspecting, adjusting, pruning, rebuilding — will be the ones that compound value over time.
The question is not whether you can build an agent. Of course you can. The harder question is whether you can maintain the system around the agent as the model evolves and the work changes. That is where the real engineering happens, and it is where we spend most of our time with the organizations we work with.
If you are deploying agents or trying to figure out why the ones you built are not delivering, start with the harness. Map the real workflow. Scope the permissions. Build the proof trail. And plan to maintain it — not once, but continuously.