Architecture pillar
Production agent architecture
The model is a component. The harness owns production behavior.
A production agent is not an LLM call surrounded by glue. It is a runtime that controls what the model sees, which actions it may request, how those actions are validated, what state survives, and how interrupted work recovers. The model contributes judgment; the harness makes that judgment operable.
This distinction changes the investment decision. Model selection matters, but production behavior belongs in explicit software contracts: control flow, tool interfaces, authority, state transitions, verification, budgets, checkpoints, and recovery. If those contracts exist only in a prompt or in the model’s expected behavior, the system has no dependable operating boundary.
Diagnose an agent that is too unreliable to operate →
Own control flow before adding autonomy
The first architecture decision is who chooses the next step. A workflow keeps control flow in developer-owned code; an agent discovers it at runtime. Use the workflow when the path is cheaply enumerable. Buy autonomy only when runtime discovery materially changes the next action and the benefit exceeds the added supervision, evaluation, and recovery cost.
Most production systems should be hybrids: a deterministic outer workflow for lifecycle, budgets, approvals, and effects, with model-directed judgment inside bounded steps. That arrangement keeps replay and audit mechanical without pretending every useful task can be reduced to a static decision tree.
Choose workflows where determinism is cheap, agents where it is expensive →
Make state and tools explicit contracts
Context assembly, session state, durable memory, and tool results are different kinds of data. Each needs a schema, freshness rule, scope, and owner. A transcript should not quietly become long-term memory, and a tool result should not remain actionable after the world it described has changed.
Tools are also authority boundaries. Their schemas should constrain what can be requested; policy should constrain who may request it; validation should constrain what is accepted; and idempotency should constrain what happens when a call is retried. The harness owns all four. A stronger model does not remove that responsibility.
The harness is the product; the model is a component →
Route work on evidence, not role labels
When a harness delegates work, an agent name or role description is not an operating guarantee. The routing contract should match explicit task requirements against evaluated capabilities, reject candidates outside the required trust boundary, and preserve the evidence behind the final assignment.
Agent routing should buy verified capability, not declared capability →
Design recovery as part of correctness
Once work outlives a request or can create consequential effects, recovery is not an operational afterthought. The runtime needs checkpoints, explicit commit boundaries, replay-safe tools, cancellation semantics, and evidence of every attempt. Otherwise a restart can duplicate effects, skip work, or resume from state that never matched reality.
Durability does not mean snapshotting everything. It means recording enough intent and outcome to determine what was committed, what remains safe to retry, and where human intervention is required. The recovery contract is part of the application contract.
Durable execution is the recovery contract for long-horizon agents →
Proof and limits
A narrower durable-execution pattern is available as a tested local reference build. It demonstrates checkpoints, idempotent effects, explicit cancellation, and replay recovery. It is not a deployed production workflow engine, client evidence, or a performance claim.
Inspect the durable-execution reference build →
Review the architecture around your model
A focused architecture review traces one real trajectory through context, control flow, tools, state, authority, verification, and recovery. The output is a bounded production decision and a sequenced remediation path—not a generic checklist.