Your agent handles the happy path in a demo. Then a customer omits a field, two tools return conflicting data, or a timeout leaves the system unsure whether an external action happened. The agent guesses, repeats work, or produces a confident answer from incomplete evidence. A longer prompt won’t fix that control problem.

Before you switch models, change the architecture. A reliable agent turns open-ended reasoning into a bounded workflow: explicit states, narrow roles, independent verification, controlled permissions, durable execution records, and tested recovery paths. As access to capable models becomes less differentiating, the system built around the model becomes the durable advantage.

Turn one powerful agent into a bounded workflow

An agent shouldn’t own the entire journey from interpreting a request to changing the outside world. That design hides too many decisions inside one model call. When the result is wrong, you can’t tell whether the failure came from planning, missing evidence, tool selection, policy interpretation, or execution.

Give the work a graph instead. Split planning, independent investigation, reduction, verification, and synthesis into distinct roles. Each node should have one responsibility and a machine-checkable exit condition.

Node	What it owns	What it must not do	Exit evidence
Intake	Normalize the request, identify the actor and tenant, and validate required inputs	Invent missing intent	A complete request contract or a needs-input state
Planner	Break the request into tasks and identify real dependencies	Publish an answer or invoke write tools	A dependency-valid task graph
Workers	Produce bounded claims, options, calculations, or proposed operations	Approve their own work or cause side effects	Schema-valid artifacts with evidence and limitations
Reducer	Remove duplicates, preserve provenance, and expose disagreements	Treat agreement as proof	A claim or decision ledger ready for review
Verifier	Check evidence, rules, contradictions, and tool results	Improve the prose or invent replacement evidence	A verdict for every material item
Decision gate	Apply product policy, confidence requirements, and approval rules	Create new claims to justify approval	Approve, rework, reject, or escalate
Executor	Perform the specifically authorized operation	Reinterpret the plan while acting	A confirmed result, a known failure, or an unknown-outcome state

For every node, write an exit contract before writing its prompt. The contract should define:

• The fields the node is allowed to receive.
• The exact structure it must return.
• The tools it may call, including whether they are read-only or write-capable.
• The evidence required to advance.
• The allowed next states.
• The errors that can be retried and the failures that require escalation.
• The person or policy responsible when the node cannot complete its job.

A valid schema doesn’t make an answer correct. It does make malformed work visible before it contaminates the next stage. That is the first reliability gain: failures become named states rather than plausible-looking prose.

Keep the workflow state explicit. A run might move through received, planned, working, assembled, verified, approved, executed, and closed. Needs input, rejected, blocked, escalated, and unknown outcome should be first-class states too. If the only statuses in your system are running, succeeded, and failed, you won’t know what kind of intervention is safe.

The planner’s most useful question is not who should go next. It is whether the next task needs the actual output of the previous one. If it does not, the dependency is artificial. Evidence gathering, contrarian analysis, and rollout planning can often run independently. Separate contexts reduce anchoring because one worker cannot quietly inherit another worker’s assumptions.

Require each worker to return the same inspection fields: claim, evidence reference, publication or observation date when relevant, confidence label, limitation, and status. The reducer can then remove duplication without erasing disagreement. Two workers reaching the same conclusion is useful corroboration, but it is not verification, especially when they use the same model, prompt pattern, and underlying material.

Put verification before permission

Generation and verification are different jobs. The generator tries to produce a useful candidate. The verifier tries to disqualify it. Combining those objectives in one prompt invites the model to defend its own reasoning.

Give the verifier a clean context containing the candidate, its evidence, and the acceptance rules. Do not include the planner’s persuasive rationale unless that rationale is itself under review. A practical verdict vocabulary is PASS, REVISE, or REJECT for every claim. The verifier judges; it does not silently repair. A revision goes back through the appropriate worker and is checked again.

Your verification gate should be able to answer these questions:

• Does each material claim have supporting evidence, or is it clearly labelled as reasoning or uncertainty?
• Does the evidence entail the claim, rather than merely discuss the same topic?
• Do the date, population, product version, tenant, and operating context match?
• Were contradictory findings preserved and resolved by an explicit rule?
• Did the tool return a confirmed result, or is the system inferring success from a request being sent?
• Did summarization make a qualified statement sound absolute?
• Does the output satisfy the product’s policy and format contract?

Verification answers, “Can this output be trusted for its intended use?” Authorization answers, “May the system act?” Keep those gates separate. A factually correct action can still be unauthorized, addressed to the wrong tenant, over a spending limit, or too consequential to automate.

My default is simple: if a node can spend money, send something externally, change access, delete data, or deploy code, the model may propose the action but should not grant itself permission. A deterministic policy layer should validate the actor, tenant, target, entitlements, limits, and required approval before an executor receives the request.

Represent every proposed tool call as an operation envelope. Include the workflow and run identifiers, tool and action, target, validated arguments, actor and tenant, idempotency key, authorization decision, approval evidence, and expected result. Do not let free-form prose flow directly into a write-capable tool.

The idempotency key matters when a tool times out after receiving a request. Without it, a retry can send a message twice, create duplicate records, or repeat a financial operation. If the destination supports idempotency, reuse the same key for the same intent. If it does not, keep an effect ledger and reconcile the remote state before retrying. An ambiguous timeout is an unknown outcome, not an ordinary failure.

Human approval is useful only when the reviewer can see the decision. Present the intended operation, target, evidence, uncertainty, expected impact, material changes, and rollback path. Showing only polished final prose turns approval into a proofreading exercise.

Route failures by cause instead of sending all of them back to the model:

• Missing or ambiguous input moves to needs input.
• An unsupported claim moves to rework or rejection.
• A policy denial moves to blocked. Rephrasing the request must not bypass it.
• A malformed artifact can enter a bounded schema-repair path.
• A transient tool failure can be retried under the tool’s retry policy.
• An unknown tool outcome must be reconciled before any repeat attempt.
• A material disagreement without a decision rule moves to human escalation.

Keep state outside the model and make every run inspectable

A context window is not a system of record. It is temporary working material assembled for a model call. The canonical workflow state belongs in durable storage, where the orchestrator can resume from a confirmed checkpoint without asking the model to reconstruct what probably happened.

Store an immutable or append-oriented trace for each run. At minimum, capture:

• The workflow version, node name, node status, and attempt identifier.
• The validated input, input hash, and produced artifact.
• The model, provider, configuration, and prompt-template version.
• The evidence identifiers and retrieval times used for material claims.
• Tool requests, authorization results, responses, and external operation identifiers.
• Verifier verdicts, revision reasons, approvals, and overrides.
• Latency, cost, token use, and terminal reason.

This trace is more than debugging data. It lets you reproduce a failure, identify which contract changed, compare model versions on the same cases, audit external actions, and turn production incidents into regression tests.

Make nodes pure where practical: the same validated input and versioned configuration should produce an artifact without changing external state. Isolate unavoidable side effects in executor nodes. That boundary makes replay safe because historical reasoning can run against stubbed tools while real writes remain disabled.

Retries need a classification, not just a counter. Timeouts, rate limits, and temporary service errors are usually retry candidates, using backoff and jitter where appropriate. Invalid input, policy rejection, exhausted budgets, and missing authorization are not. Retrying a non-retryable failure wastes money and can turn a contained mistake into an incident.

Retry the failed node from its last confirmed checkpoint, not the entire workflow. End the retry path when its defined budget is exhausted, then escalate with the trace attached. An agent that loops until it gets an acceptable answer is not resilient; it is unbounded.

Your operational dashboard should show more than availability. Track terminal states, verifier verdicts, unsupported-claim failures, human revisions and overrides, escalation reasons, tool errors, unknown outcomes, duplicate-effect incidents, latency, and cost. Set acceptable thresholds from the consequence of the workflow. A draft content assistant and an agent that changes customer access should not share the same release bar.

Aggregate metrics tell you that reliability changed. Traces tell you why. Product, engineering, risk, and operations need both views to decide whether to revise a prompt, change a tool contract, tighten a policy, improve retrieval, or remove autonomy.

Build evals before autonomy, then swap models safely

Choose one narrow workflow with a visible finish line

Start with a repeated workflow whose output can be judged. A practical first candidate is work that takes more than two hours each week and produces a predictable output. Lead qualification, support-response drafting, document review, and structured research can fit. Deletion, access changes, deployments, and consequential financial actions are poor first targets because a plausible mistake can create an immediate external cost.

Write the acceptance contract before tuning the prompt. Define the required output, permitted evidence, forbidden behavior, tool permissions, escalation conditions, human approval points, and product-specific limits for quality, latency, and cost. If stakeholders cannot agree on what passes, the agent cannot be evaluated reliably.

Test the first version on ten real examples, not polished examples written to match the prompt. Include ordinary requests, ambiguous intent, missing fields, conflicting evidence, stale information, tool errors, policy-sensitive cases, and attempts to smuggle untrusted instructions through retrieved content. Ten cases are a seed acceptance set, not proof of production reliability. Add every meaningful production failure to the suite.

Score the system at workflow level and node level:

• Was the final task completed correctly?
• Were material claims supported and qualifications preserved?
• Did every artifact satisfy its schema?
• Did the planner select valid tools and arguments?
• Did policy-sensitive cases stop at the correct gate?
• Did the system ask for missing information instead of guessing?
• Did simulated retries avoid duplicate side effects?
• How much did a human need to correct, add, or remove?
• Did latency and cost stay inside the product’s declared budgets?

A single average score can hide the failure you care about. Keep hard safety gates separate from quality metrics. Excellent writing cannot compensate for crossing tenant boundaries, inventing evidence, bypassing approval, or repeating a side effect.

Promote the workflow through controlled operating modes

Autonomy should be earned by the same workflow, not granted because a demo looked convincing. Use progressively more consequential modes:

• Historical replay: run recorded inputs with external tools stubbed and compare results with known outcomes.
• Shadow mode: process live inputs while keeping outputs invisible and side effects disabled.
• Draft mode: show the result to a human who can edit, reject, or approve it.
• Constrained execution: allow only explicitly listed, low-consequence operations with reconciliation and rollback.
• Broader execution: expand permissions only for paths whose evals, production traces, and incident history satisfy the agreed release gates.

Define promotion and rollback conditions before each mode begins. Include verifier performance, human correction patterns, unresolved outcomes, policy failures, operational cost, and recovery tests. If a team cannot explain what would cause the agent to lose autonomy, it has not designed a control loop.

Keep the model behind a stable contract

Model selection should be a replaceable implementation decision. The market is shifting from raw capability alone toward usefulness, cost, and reliability for particular workloads. Hardwiring provider-specific prose or tool formats into downstream systems makes every model change a workflow migration.

Put a provider adapter behind your node contract. Normalize requests, structured responses, tool definitions, errors, usage data, and safety signals. Route models using the requirements that matter to the node: task type, context need, conversational quality, data constraints, tool support, latency budget, cost budget, and tested reliability.

Run every candidate model through the same versioned eval suite and compare workflow outcomes, not just the elegance of individual answers. Recheck schema adherence, evidence fidelity, tool behavior, verifier performance, latency, cost, and escalation. A cheaper model that triggers more revisions or tool failures may increase total workflow cost.

Treat a fallback model as a separate execution path. Differences in schemas, tool calling, refusals, or context handling can change system behavior precisely when the primary path is already degraded. Use only tested fallbacks. If no tested path is available for a consequential action, fail closed and preserve the run for recovery.

Key takeaways

• Reliability is a property of the workflow, not a personality trait of the model.
• Give planning, bounded work, reduction, verification, authorization, and execution separate contracts.
• Parallelize only genuinely independent work, isolate worker contexts, and preserve provenance and disagreement.
• Verify claims before applying a separate permission gate to any external action.
• Keep canonical state outside the model, isolate side effects, and reconcile unknown outcomes before retrying.
• Start with one judgeable workflow, test it on ten real cases, and expand autonomy only when the traces and evals support the decision.

This week, take one candidate workflow and draw the graph from intake to terminal state. Mark every node that can change the outside world. Write an exit contract for each node, put verification and authorization before those side effects, and run the flow against ten real cases. The first workflow you can inspect, interrupt, replay, and recover will teach you more than another general-purpose agent demo.

References

• AI Cheatcode – Three AI models dropped this week.
• Think Tank AI – Stop Building Bigger Prompts: Build Your First Verified AI Graph

---