Build
Agent development starts with the case that must be completed, not the model that sounds fluent.
Teams that start with prompts and frameworks end up with a demo. Teams that start with a workflow, tools, and a definition of done can build something an operator will use.
57%
of teams building agents now have one in production. Quality, not cost, is the top barrier.
LangChain, State of Agent Engineering 20261
How I see it
AI agent development
Production agent development is systems work. You define the outcome, the inputs, the tools the agent may use, the actions it may take, the tests that prove it is right, and the path for cases it should not finish.
The first build should be narrow. One workflow. A small set of tools. Explicit write-back. Evaluation on real historical cases, not a handful of happy-path examples.
The engineering sequence is usually: recover the workflow, instrument the baseline, build the agent loop, add controls, measure failure modes, then harden operations. Skipping evaluation is how fluent systems create expensive mistakes.
This is also where the five engines matter. Development here starts below the wrapper — state, tools, evaluation, and controls as one build — not a later phase after a demo looks fluent.
Common mistakes
What teams usually get wrong.
Framework-first development
Choosing an agent library before the workflow and tools are clear produces architecture in search of a job.
No evaluation set
If you cannot score completed cases, you cannot tell improvement from drift.
Building for every exception on day one
Cover the common path and a clean escalation. Expand after the baseline is real.
A useful diagnostic
Five questions before you fund the work.
Is the outcome specified as a completed business object?
A ticket, packet, reconciliation, or recommendation is a build target. A chat is not.Do you have historical cases to evaluate against?
No cases means you are guessing.Are the tools and write-back paths identified?
If the agent cannot act, you are building a summarizer.Who will own the agent after the first release?
Development without an operator creates a stranded pilot.Is the first release allowed to handle only part of the volume?
If it must do 100% on day one, the project will stall.
Economic model
Build scopeone outcome + limited tools + evaluation set + human control points = first release
If the first release needs more than that, the scope is a program, not an agent.
Three credible paths
How far should you go?
Do not force one solution. Choose the path the economics, the risk, and the organization can support.
Assist the existing team
Build a supervised copilot that prepares work for people who still complete the case.
Access, risk, or process ownership is not ready for write-back.
Capacity improves, but the workflow still depends on every human step.
Agent the common path
Let the agent complete the routine cases and escalate the rest.
A large share of volume is repetitive and the done state is clear.
Exception design and monitoring become part of the product.
Expand to a multi-step system
Add tools, specialist agents, and stronger operations once the first outcome is proven.
The first agent has a baseline, an owner, and a known cost to run.
Complexity rises quickly. Do not start here.
When this is the wrong next step
Do not fund an agent here.
- There is no workflow owner and no access to the systems of record.
- The company wants a general agent that can do anything a staff member can do.
- Legal or security will not allow write-back, and the team still wants to call it production.
A useful next step
Bring one workflow. Get guided into production.
We guide the implementation, go deep on the technical path, and stay hands-on through operations — or tell you when a simpler answer is better.
Discuss an AI opportunity