Agents are software. Maintain them like software.

That line comes from Ethan Lo and Jason Jiang’s talk, Is Your Agent Any Good? Lessons From a Wide and a Deep Deployment, at AGNTCon + MCPCon North America 2026. I keep coming back to it.

Agents need more checks, more verification, and more guardrails than a fixed workflow, because they choose their own next step. But the checks are the ones we have always used: limits, validation, approval gates, tests, and an owner. What is new is the component we apply them to.

I have never shipped a production loop that ran without a limit, a timeout, or someone watching, and I doubt you have either. We have been running stored programs since the Manchester Baby’s first run on 21 June 1948 , and none of that experience stops applying because the next step now comes from a model.

The loop was never free

Anthropic draws the architectural line: workflows follow predefined code paths, while agents let the LLM dynamically direct their own process and tool use . The same article says agents often pause for human feedback at checkpoints, include stopping conditions such as a maximum number of iterations, and warrant extensive testing in sandboxed environments along with appropriate guardrails.

That reads like any operations checklist. The model changes which step runs next. It does not change who is responsible for what that step does.

Embabel is the same engineering, rearranged

I wrote earlier about what Embabel taught me . I went back to its 1.0 documentation for this post, and what struck me is how little of it is invented. Nearly every control maps to something we already did:

Even the planner is borrowed. The docs point to GOAP, OODA, and Domain-Driven Design as background. The docs also say that for workflows with defined outputs, branching, or loops, a deterministic, typesafe planner is more predictable than LLM-driven orchestration. That is the old advice, applied to a new component: keep the model inside a small, well-lit step and let ordinary code own the rest.

None of this makes Embabel unimportant. It is a good example of experienced engineers packaging familiar controls so that you don’t have to rebuild them for every agent.

The refund that succeeds after the timeout

Here is the kind of problem those controls exist for. An agent calls a refund service. The service issues the refund, but the response is lost, and the agent sees a timeout. Should it retry?

Asking the model to be careful does not answer that. A retry could pay twice. A restart could lose the record of the first attempt. A freshly generated request ID could make a duplicate look like a new operation.

This is the oldest distributed-systems problem there is. Amazon’s Builders’ Library describes the standard fix: a caller-provided request identifier that makes retries idempotent . The agent’s retry is a distributed-systems retry, and it needs the same contract.

The checklist we already had

Define the result. Name the person who can judge whether the task was done correctly, along with acceptable errors and when to escalate. A fluent answer is not evidence the operation succeeded. A valid JSON refund request can still be the wrong refund. Schema validation checks structure. Business rules and evidence decide whether to proceed.

Enforce permissions where the action happens. Validate arguments and check the caller’s authority in the service that executes the action. A prompt describing a permission is not an access check. MCP says the same: its tools specification requires servers to validate inputs, implement access controls, and rate limit invocations .

Design for recovery. Persist enough state to resume or reconcile interrupted work. Decide which operations can be retried, which need duplicate protection, and which need compensation or a human. Rolling back a release does not undo what it already did.

Test the software and evaluate the behavior. Keep unit, integration, contract, and security tests. Add representative tasks that check the model’s choices and the resulting system state, and run repeated trials because outputs vary. A prompt, model, or retrieval change can alter behavior with no code change, so evaluate those too. Anthropic suggests 20 to 50 simple tasks drawn from real failures as a starting point. That helps catch regressions. It is not a reliability guarantee.

Name the owner. Give the system a release process, an on-call owner, and a recovery procedure. Log model and configuration versions, tool calls, authorization decisions, and state changes, protecting sensitive data.

Use what you already have

Researchers and ML engineers built the models, and their expertise is still needed to measure how behavior changes. Domain experts still define what a correct result is. Software engineers bring the limits, contracts, recovery, and accountability.

An agent is a loop that picks its own next step. We already know how to put bounds, checks, and an owner around a loop like that. Don’t invent new controls for agents. Apply the ones you already trust.