There is a temptation in agent tooling to make everything magical. The agent figures out what it needs. The agent discovers the codebase. The agent learns as it goes.
Enterprise teams do not want magic. They want control.
They want to specify which submodules get loaded for which task types. They want to define the skills and tools available. They want to see what context the agent used and override it when the agent is wrong. They want the agent's long-term memory — whatever form it takes — to be something they can inspect, edit, and version control.
Not because enterprise teams are conservative. Because they have been burned by black boxes before, and they know any tool they cannot control will eventually produce a mess they have to clean up.
The pattern that works is straightforward. Context in, background execution, reviewable output, human approval. The human sets up the context. The agent does the work. The human reviews. The context improves over time, because every correction becomes institutional knowledge the agent carries forward. I've argued elsewhere that the harness is the product — and controllability is the feature of the harness that enterprise buyers care about most, even when they cannot articulate it that way.
If you are designing an agent product for the enterprise, build the override before you build the autopilot. Inspectability before optimization. Edit-ability before learning. Version control before memory. Customers will pay you to give them the wheel back.
Sources
Related Essays
The Harness Is the Product. The Prompt Is Cheap
The interesting part of an agent stopped being the prompt years ago. Orchestration, persistence, tool integrations, and policy enforcement are where the complexity — and the value — lives now.
The Agent Made a New Type Instead of Finding the Real One
A scene from every engineering org operationalizing agents. The task was trivial. The PR was wrong in a way no human on the team would ever get wrong. It is not a model problem.
Inspectable Logic, Not Black Box Magic
Most agent projects die because nobody can explain why the agent did what it did. The fix is non-obvious — agent logic should be permanent, inspectable code, not a regenerated prompt.
Key takeaways
- Magic agents that "figure out what they need" are the pitch. Controllable agents that take direction are the product enterprises buy.
- Teams want to specify submodules per task, define available tools, see what context was used, and override when wrong.
- Memory must be inspectable, editable, and version-controllable. Anything else is a black box waiting to leak.
FAQ
Why do enterprises distrust magical agents?
Because they have been burned by black boxes before. Any tool they cannot inspect or override will eventually produce a mess they have to clean up — and at enterprise scale that mess is expensive, public, or both.
What is the working pattern for enterprise agent deployments?
Context in, background execution, reviewable output, human approval. The human sets up the context. The agent does the work. The human reviews. The context improves over time, because every correction becomes institutional knowledge the agent carries forward.