Everyone is building agents.
Custom orchestration layers. Proprietary graph frameworks. Bespoke tool-calling chains. Teams spend months wiring node-to-node workflows and hand-coding what the model should do at each step.
Here is what I have learned deploying agents in production at enterprise scale: most of that work is unnecessary. More important, it is the wrong abstraction.
The shift that most people missed
Two years ago, the conventional wisdom was reasonable. You could not trust a model to make good decisions on its own. So you defined the workflow. You mapped the graph. You told the agent: call tool A, then tool B, then route here if condition X, else go there.
That world is gone.
Modern frontier models are capable orchestrators. They can reason about which tool to call, when to call it, how to recover from failure, and when to stop. They do not need you to define the graph. They are the graph. The orchestration problem is largely solved by the model itself.
What has not changed is what the model needs to do its job well. That is where most teams still get it wrong.
The real problem: no one is building the right things
If the model can orchestrate, your job as an engineer shifts. You are no longer building the agent. You are building what the agent reaches for.
In Anthropic's framing, which matches what I have seen work in production, the move is: build skills, not agents.
A skill is not a prompt template. It is a proper primitive: a packaged unit of capability that an agent can discover, load, and use reliably. Done right, a skill contains the instructions, tools, context, and guardrails for a task. The agent decides when to use it. You decide what it is allowed to do.
The primitives that matter in production are skills (packaged, reusable task capabilities with their own instructions and tools), MCPs / Model Context Protocol (the plumbing for how the model connects to external systems and data), hooks (intercept points where you observe, validate, or modify agent behavior in flight), guardrails (constraints that keep the agent inside acceptable bounds without hardcoding the workflow), and memory (how the agent retains and retrieves context across sessions and tasks).
If you build these five well, you have something composable. Something that can extend a mature, battle-tested harness rather than replace it.
Why you should not build the harness
This is the part that took me time to say plainly: the harness is not your problem to solve.
Companies like Anthropic have run thousands of evaluations on tool-calling behavior. They know which failure modes appear and when. They know how model behavior shifts with context window size, instruction phrasing, and tool description quality. They have tested edge cases you have not imagined yet, because they have seen them in the wild at a scale you have not reached.
Claude Code is a good example. It is not only a wrapper. It is a harness tuned against real usage patterns, refined through evaluations, red-teaming, and production feedback. When you adopt it, you are not taking someone's first draft. You are inheriting years of iteration on what actually works.
Most teams do not think of it this way. They see an existing harness and want to fork it, replace it, or abstract over it. They spend six months building their own orchestration system. Then they spend the next twelve debugging it.
The alternative is to go with the harness and put your engineering effort into what it needs to be effective: better skills, tighter guardrails, sharper system prompts, and proper memory design.
What this means practically
If you are choosing whether to build a custom agent framework or adopt something like Claude Code, the question is not "does this harness do everything we need?" It probably does not, out of the box. The question is: can we build the primitives it needs to do our job, without touching the orchestration core?
In most enterprise contexts, the answer is yes. The specialization you need lives in the skills and the guardrails, not in the tool-calling loop.
The teams I have seen succeed with agents in production are not the ones with the most sophisticated orchestration code. They built clean, well-scoped primitives, plugged them into a harness that already worked, and spent their time on the hard problems: memory design, failure recovery, eval coverage, and context management.
The reframe
Agents are not products. They are configurations of primitives running on capable models.
The model handles the orchestration. The harness handles the infrastructure. Your job is to build what goes in between: the skills that define what the agent knows how to do, and the guardrails that define what it is allowed to do.
Stop rebuilding the stack. Build the primitive.