Build
20.6%
of long-horizon computer-use tasks completed by the best tested agent in OSWorld 2.0.
Xie et al., OSWorld 2.0, 20261Agent architecture is the set of decisions that keep a fluent model from becoming an unreliable employee.
If the architecture is only a model plus a prompt, the system will look smart and fail in ways operators cannot explain.
How I see it
Enterprise agent architecture
A production agent needs a clear loop: receive a case, gather context, decide the next action, use a tool, check the result, stop or continue, and record what happened. Around that loop sit identity, permissions, evaluation, observability, and human control points.
Memory should be deliberate. The agent needs the case, the relevant records, and the policy that applies. It does not need an unbounded conversation history that quietly changes behavior.
The architecture should make failure boring. Timeouts, low confidence, missing fields, and policy breaches should become exceptions, not improvisation.
The harness is the effective world: what the agent can see and what it is allowed to do. That layer has to be designed, not assumed. Some companies should buy a workflow-specific product. Others have a unique process that justifies a custom agent. The architecture has to support the choice, not force it.
Common mistakes
What teams usually get wrong.
Prompt as architecture
Instructions are not permissions, evaluation, or an audit trail.
Unbounded memory
Long context feels like intelligence. It often creates drift, cost, and leaked information.
No environment for tests
If you can only try the agent in production, you do not have an architecture. You have a hope.
A useful diagnostic
Five questions before you fund the work.
Can you draw the agent loop without mentioning a vendor?
If not, the architecture is a purchase, not a design.Are tools explicit functions with schemas and permissions?
Free-form browsing of internal systems is not a tool interface.Is there an evaluation path that uses real cases?
Architecture without evaluation is a diagram.Can you turn the agent off without stopping the business process?
If not, you created a single point of failure.Is cost per run visible in the design?
Context size, retries, and tool calls are architecture choices.
Economic model
Architecture fitnessloop + tools + controls + evaluation + fallback = production shape
If one of those is a slide instead of a working path, the agent is not ready for volume.
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.
Thin supervised agent
One loop, a few tools, human approval, and a simple log.
You are proving the first workflow.
It will not survive broad use without more operations.
Production agent platform for one domain
Add evaluation, monitoring, scoped identities, and a standard exception path.
The first agent is working and a second workflow is in sight.
Requires ownership beyond the original project team.
Shared agent platform
Common tooling for multiple outcomes after the operating model for agents exists.
Several production agents share the same controls and cost problem.
Easy to become a transformation program. Wait until the first wins are real.
When this is the wrong next step
Do not fund an agent here.
- The company wants a platform before it has one production workflow.
- There is no one who can own identity, logging, and evaluation.
- A bought product already covers the workflow and custom architecture would only add delay.
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