Agents Are Not Chatbots: What Changes When Software Takes Actions

For two years the default shape of an AI feature was a text box that returned text. You typed, a model answered, and the worst thing that could happen was a wrong answer on a screen. That era is closing. The systems shipping in 2026 do not answer questions so much as operate things: they fill forms, move records between systems, run builds, open pull requests, and reconcile spreadsheets. The interface looks similar. Almost nothing underneath it is.

The failure mode moves from wrong to expensive

A chatbot that hallucinates costs you a moment of confusion. An agent that hallucinates writes to your database. That single difference reorganises the whole engineering problem. In a question-answering product, quality work means better retrieval and better prompts. In an action-taking product, quality work means permissions, dry runs, idempotency, and audit trails, which are the least glamorous parts of software and the ones that decide whether the feature survives contact with real users.

The practical consequence is that agent work is closer to payments engineering than to machine learning. You are not tuning a model. You are building a system that can be trusted to execute, and every property you would demand of a payments integration applies: retries that do not double-charge, operations you can replay safely, a log that tells you exactly what happened and in what order.

Give every action a blast radius

The most useful mental model I have found is to grade each tool the agent can call by how hard it is to undo. Three buckets are enough:

• Reversible: reads, searches, drafts saved somewhere private. Let the agent run these freely.
• Recoverable: writes to your own systems that you can roll back. Allow them, but version the before-state so you can restore it.
• Irreversible: sending email, charging cards, deleting data, anything that touches a third party. These need an explicit human confirmation or a hard policy that permits a narrow, well-defined case.

Teams that skip this grading end up bolting confirmation dialogs onto everything, which trains users to click through them, which returns you to the original problem with extra friction.

The context window is not your architecture

A recurring mistake is treating the model's context as the place where state lives. It is a cache, not a database. When an agent runs for twenty minutes across thirty tool calls, the durable record of what it did belongs in your own store: a task row, a list of steps, inputs and outputs for each, and the current status. Rebuild the prompt from that record on every step.

This costs a little more per call and buys you three things you cannot get otherwise. You can resume a run after a crash. You can show a user exactly where the agent is without asking the model to summarise itself. And you can replay a failed run against a new prompt or a new model version to see whether you actually fixed the bug.

Evaluation has to be behavioural

Scoring an answer for helpfulness tells you very little about whether an agent completed a task. What you need are end-state assertions: after this run, does the CRM record contain the right values, was exactly one email queued, is the branch pushed and does it build. These read like integration tests because that is what they are.

Build a fixture environment where the side effects are real but disposable, run the agent against a set of recorded tasks, and assert on the world afterwards. Ten well-chosen scenarios that check end state will tell you more before a release than a thousand rows of vibes-based rating.

Latency budgets are a product decision

Multi-step agents are slow by construction, and no amount of streaming hides a ninety-second task. The teams doing this well stop pretending it is instant and design for the wait: return a task id immediately, show the plan, stream each step as it completes, and make the whole thing survivable if the user closes the tab. The interaction becomes closer to a build pipeline than to a chat, and users adapt to it easily once the progress is legible.

If a user cannot tell what the agent is doing right now, they will not trust it with anything that matters, no matter how good the final output is.

Where this lands

The uncomfortable summary is that most of the work in shipping agents is not AI work. It is the boring discipline of state machines, permissions, and observability, applied to a component that is probabilistic rather than deterministic. That is good news for experienced engineers. The scarce skill is not prompt craft. It is knowing how to make an unreliable dependency safe enough to put in front of customers, and our industry has been doing exactly that with networks, disks, and third-party APIs for decades.

Start with one workflow that is genuinely reversible, instrument it properly, and only widen the blast radius when your logs tell you it has earned it.