From AI demos to dependable operations

01

Define the outcome before choosing the agent

Begin with a decision that matters to the business. For a missing delivery, that decision might be whether to wait for updated tracking, investigate with the carrier, or offer a replacement. Each path changes cost, customer effort, and operational workload. The workflow needs a clear definition of which cases it can handle and which belong with a person.

A useful initial objective is to resolve eligible delivery exceptions accurately and within policy while reducing repeat contacts and unnecessary replacements. Measure resolution quality alongside speed. A quickly closed ticket is a weak success signal if the customer has to open it again the next morning.

Establish a baseline from comparable cases: time to resolution, repeat-contact rate, incorrect replacements, manual review effort, and total handling cost. Segment cases by difficulty so a pilot that receives only straightforward requests is not mistaken for an improvement across the whole service.

Write an operating contract before implementation. It should name the process owner, supported case types, allowed actions, required approvals, escalation route, and completion criteria. For this example, the first release can investigate a case and prepare a replacement proposal. Creating that replacement remains a separately authorised operation.

02

Separate interpretation, authority, and execution

Start with one focused agent and an application that owns the workflow. The agent can gather permitted evidence and propose a resolution. The application maintains case state, evaluates eligibility, requests approval, and invokes a restricted action service. These are separate responsibilities even when they run in a small deployment.

This separation gives each failure a place to be handled. Missing tracking information belongs to evidence collection. An ineligible replacement belongs to policy validation. An uncertain write belongs to reconciliation. A model should receive a clear result from each boundary instead of being asked to invent its own recovery policy.

The proposed architecture has five stages. The sequence shows the normal path; a failed check pauses the transition and routes the case to its owner. The write service receives validated arguments, authenticated identity, and the approval record. It enforces its rules independently of the model’s explanation.

Add specialised agents when the work requires different expertise or parallel investigation. Define what each agent receives, what it may return, and which component owns the handoff. Multiple agents add communication, consistency, and evaluation work; they should earn that complexity through a measurable benefit.

03

Build a reliable picture of the current situation

A conversation can describe an order without establishing its current state. Before proposing a replacement, the workflow needs an authenticated customer reference, the order revision, shipment status and timestamp, any existing replacement, and the applicable policy version. Those facts should come from systems with defined ownership.

Use retrieval for policies and relevant documents. Use operational APIs for live records. Store workflow progress in durable application state. Keep these roles distinct: a retrieved paragraph about delivery policy cannot confirm that a particular parcel is still missing, and a chat message cannot authorise a fulfilment change.

Prepare an evidence packet that travels with the proposal. Include source identifiers, retrieval times, record versions, and unresolved conflicts. If the carrier reports delivery while the customer disputes receipt, preserve both claims and follow the defined investigation route. A confident summary should never erase an unresolved disagreement.

Recheck volatile facts at the action boundary. Where supported, pass an expected version to a conditional update so the destination can reject a stale proposal atomically. Where that is unavailable, use the destination’s supported coordination mechanism and document the remaining race conditions. Reading a record immediately before a write alone cannot eliminate concurrent changes.

Memory supports continuity. Business records establish operational truth. Give remembered facts an owner, a provenance record, and an expiry or revalidation rule.

04

Make approval a precise, enforceable decision

Reading shipment status, changing an address, issuing a refund, and creating a replacement are different capabilities. Give the workflow only the capabilities its task requires. Enforce customer scope and operation permissions at the service boundary, using authenticated identity rather than a customer identifier chosen by the model.

Human review is useful when the reviewer can see the proposed change and its consequences. Present the current evidence, the rule that makes the case eligible, the exact proposed action, and any uncertainty. Approval should attach to a specific revision of that proposal, with the reviewer’s identity and decision time recorded.

If the items, quantity, destination, eligibility, or other approval-relevant facts change, invalidate the affected approval and request a new decision. Recheck permission at execution time as well: authority can be revoked between review and submission. A prompt asking the agent to follow policy supplements these controls; enforcement lives in the application.

Treat retrieved messages and documents as untrusted content. Instructions embedded in them must not expand permissions or replace the operating policy. Validate tool arguments, limit sensitive fields before they enter model context, and scope retrieval before records are returned. If another customer’s data crosses the boundary, stop its propagation and treat it as an access-control incident.

05

Model recovery as part of the workflow

A timeout tells you that a response did not arrive within the expected period. It does not establish whether the destination applied the request. Production workflows need to represent that uncertainty explicitly and preserve it across worker restarts, duplicate events, and manual intervention.

Persist a stable action identity and the approved payload before attempting the write. Use the destination’s supported idempotency mechanism when available, and understand its scope and retention period. If the response is lost, query for the existing result or use the destination’s documented reconciliation path. Without a reliable deduplication or lookup mechanism, pause for investigation instead of blindly resubmitting.

A confirmed write is still only one step in the customer’s resolution. Record the destination identifier and accepted revision, then track fulfilment under a named owner. Tell the customer which milestones are confirmed and which are pending. A workflow that creates a replacement order should not announce that the replacement has already arrived.

Give recovery a bounded attempt budget, a deadline, and an escalation route. A stop control should prevent new actions while preserving the record of work already submitted. External effects may need a compensating business action, such as a cancellation request, subject to fresh checks; restoring local state cannot undo a parcel that has shipped.

The detailed recovery pattern is covered in When AI workflows fail: designing retries without duplicate actions. The same principle applies here: preserve the reviewed decision and reconcile its effect before choosing the next action.

06

Evaluate the path as well as the final answer

A reassuring reply can conceal a wrong customer record, an unauthorised tool call, or an unresolved write. Evaluation should inspect the trajectory: evidence retrieved, checks applied, tool arguments, approval decisions, customer-visible messages, and final system state. Define acceptance criteria for each boundary.

Use unit and integration tests for deterministic controls, then run scenario evaluations across the whole workflow. Repeat representative cases to expose behavioural variation. Include incomplete evidence, interruptions, changing permissions, and requests phrased in different ways. Each scenario needs an expected result that can be checked independently of the model’s own assessment.

Keep a versioned set of reviewed cases, including failures discovered in production. Use appropriate redaction and retention controls when turning real cases into evaluation material. Rerun the relevant set after changes to models, prompts, retrieval, tools, or policy, and inspect both aggregate scores and the consequential failures hidden inside them.

07

Operate with evidence, ownership, and cost visibility

Instrument the workflow so an operator can reconstruct what happened without relying on the agent’s narrative. Retain evidence references, relevant versions, validation results, approval records, tool receipts, and final status. Record only the personal data needed for that purpose and control who can inspect it. A generated explanation is useful context, not a guaranteed account of internal model reasoning.

Use failure evidence to choose the improvement. Stale tracking may require fresher reads. Wrong tool arguments may need a clearer schema or stronger validation. Incorrect eligibility may require policy changes. Test those changes before widening access, and retain a working configuration to restore when behaviour deteriorates.

Account for the whole case, including unsuccessful attempts and work transferred to people. Compare like-for-like cohorts against the baseline and report unresolved cases separately. Lower model spend is useful only when the service’s quality and total operating cost remain acceptable.

Assign ownership for each intervention: who can pause actions, who resolves uncertain outcomes, who approves policy changes, and who authorises expansion. Feedback should create a reviewed change in the system. Allowing an agent to rewrite its own permissions or promote unverified memories would bypass that operating discipline.

08

Expand autonomy through evidence-based stages

Begin with a narrow case type and a representative evaluation set. Agree the quality standard, tolerable failure rate, response-time expectations, cost budget, and stop conditions with the process owner before the pilot begins. Those thresholds depend on the consequences of mistakes; there is no universal score that makes an agent production-ready.

Move between stages after the evidence meets the agreed criteria. When the workflow changes materially or incidents reveal a new failure mode, reduce its scope and evaluate again. Keep a person accountable for the decision to expand; an agent’s confidence score alone should not grant additional authority.

A dependable AI workflow leaves a clear account of what it knew, what it was allowed to do, what it attempted, and what changed. Start with one decision, build the controls that make its outcome verifiable, and measure the work it actually improves. That is a practical foundation for expanding automation with confidence.