An agent is a process with a retry policy. Treat it like one.

We stopped putting agents in the first demo. Not because the loop is useless. Because the demo trains everyone to watch a chatbot wander, and then they ask why it cannot also file GST, email the customer, and update Salesforce “while it is in there”.

An agent is a worker. It takes a job, calls tools, writes state, and either finishes, waits for a human, or fails in a way you can see. If you cannot draw that on a whiteboard without the word magic, you are not ready to let it touch a customer.

The last two years made the loop easy to start. Frameworks, MCP connectors, cheap reasoning models. Starting was never the hard part. Finishing a job you can explain on Monday is the hard part. That has not moved.

Give the loop a job record

We persist a row per run: goal, tenant, tool calls, tokens, status, and the last error. The model is allowed to be stateless. The process is not. When something dies at step four, we resume from the record, not from a chat transcript someone forgot to store.

Statuses we actually use: `queued`, `running`, `waiting_human`, `succeeded`, `failed`, `cancelled`. If your framework hides these in a trace you cannot query, add a table. Product people will ask “what is stuck” before they ask “how smart is the model”.

This is ordinary backend work. People skip it because the framework showed a streaming UI and it felt like the product. The product is the job you can inspect on Monday.

Tools are APIs. Gate them like APIs.

• Allow-list. The model does not get a generic “run SQL” tool in production. It gets `find_policy(id)` and `draft_reply(thread_id)`.
• Idempotency on every tool that writes. The loop will call it twice. You know this. Act like it.
• A budget: max steps, max rupees, max wall time. Infinite “thinking” is a billing incident.
• Human approval on irreversible tools. Send, pay, delete, grant access. The list is short. Honour it.
• Per-tenant credentials. An agent that inherits a god token is a confused intern with production keys.

MCP and similar connector standards made it easier to plug tools in. That is a gift and a hazard. A connector is still an access grant. We review them the way we review OAuth scopes, not the way we review npm packages on a Friday.

We have seen a “helpful” file connector that could read a whole Drive. The demo fetched one PDF. The grant said everything. Treat the grant as the design. The demo is advertising.

Eval the trajectory, not the vibe

A correct final sentence can hide a sloppy path — extra tool calls, a retrieval from the wrong tenant, a retry that duplicated a side effect. We score the trace. Did it call only what it needed? Did it stop when the evidence was thin? Did it ask the user instead of guessing a date?

That set is smaller than people think. Twenty messy real jobs beat two hundred synthetic ones. Update it when a new failure shows up in support. That is the product backlog now, whether you like the phrase or not.

Replay matters here too. If you cannot re-run a job against recorded tool responses, you cannot tell whether a prompt change helped or whether the provider was in a good mood. Record the tool I/O. Stub it in CI. This is not optional once money moves.

A job we will take, and one we will not

We will take “draft a reply from the last three tickets and the policy chunk, then wait for ops to send”. We will not take “the agent handles customer email end to end” until the refuse path is boring and the eval set includes the nasty cases — refunds, legal threats, a VIP who is also wrong.

The difference is not model quality. It is whether a human still owns the irreversible step. You can move that step later. You cannot skip naming it. Teams that skip it do not have an agent. They have a mail server with opinions.

GST filing, payroll, and anything that submits to a government portal stays in the “not yet” column until we have a replayable job and a human on the submit tool. Those systems do not offer a sense of humour when a loop invents a line item.

What we show instead of a wandering chat

A queue. An item. A proposed action. A diff. A button that says approve. The model can still do the research. The operator stays in the job. Autonomy is a slider, not a personality.

The first setting on that slider is “draft only”. The second is “act inside a sandbox tenant”. The third is “act on production with a human on the irreversible step”. We have never met a programme that should start at four.

If a vendor tells you the agent will “just handle it”, ask them where the job record lives and what happens when step three succeeds and step four does not. The answer tells you whether you are buying a process or a demo.