Building Agents That Run the Work

1. Build it. That is not the part that breaks.

Nothing here argues that you should not. An operations lead who has watched somebody ship a working board in a weekend is right about the direction and right about the cost. Assembly is falling towards zero, we do not sell assembly, and a page that opened by telling you to stop would deserve to be closed.

There is competing advice doing the rounds in owner rooms at the moment: do not start with AI, start with the process. Map every step, every handover and every judgement call, and the agent becomes the easy part. Half of that is true and worth saying out loud. The half that is not is the order. A full process map is an open-ended prerequisite, most businesses never finish one, and under that rule no value arrives until they do.

So run one narrow job end to end this week instead, with the log on. The map you get from three weeks of workshops is what people say they do. The map you get from two weeks of logs is what they actually did, including the steps nobody mentions because they stopped noticing they were doing them.

The rest of this page is the second pass. It assumes the first version exists, somebody is using it, and you now want it to survive contact with a customer, a regulator and the next model release. The steps themselves are published: the standards library carries one specification per step, each with its own checks, exceptions and pass test. This page is about what joins them together.

2. Four ways a working agent stops working

Each of these looks like a model problem from the inside and is a design problem from the outside. None of them is fixed by a better model, which is why they keep surviving upgrades.

The first one is the expensive one, because the cost lands on somebody else. When a reviewer cannot diff this week’s output against last week’s, oversight stops being by exception and becomes a full re-read, every time. That is how an agent that saves its builder an afternoon quietly costs the person checking it a day, and it is the reason the reviewer is usually the one who kills it.

3. The unit is a step with a shape

Before anything can supervise the work, the work has to be made of parts that hold still. A step is the smallest piece that takes one object, returns one object, and can be read afterwards by somebody who was not there.

step
  id            stable across rebuilds, because the prompt is not
  consumes      one object, named and typed
  emits         one object, named and typed
  refuses       what this step will not touch, in writing
  decides       what the model may choose, and from which fixed set
  writes        the system it writes into, or none
  evidence      what it attaches so the run can be read later

run
  job_id        one id, carried the whole way through the chain
  step_id
  started_at    ended_at
  input_ref     output_ref
  outcome       done | parked | escalated | failed
  reason        required when parked, escalated or failed
  actor         model | code | person, and which one

Parked is a real outcome, not a failure. Half the value of writing the steps down is that the system gains somewhere to put the things it cannot finish, instead of finishing them badly to clear a queue. The other half is that decides forces you to say what the model is choosing between. A step whose answer set is “whatever it says” cannot be tested, and will not be reviewed twice.

4. The chain, and the queues between the steps

A chain is not a longer prompt. It is a set of steps joined by the objects they hand over, with one job id running the whole way, so that a question about an outcome has a single thread to pull.

1. What turned up

   A call, an email, a form, a row that changed in the ledger. You do not control the shape of it and you cannot make it arrive politely.

   • Phone
   • Inbox
   • Form
   • Ledger change

   Not yours to control

2. The step that reads and drafts

   Classify against a fixed set, pull the fields out, draft the wording. The model is good here, and wrong here cheaply, because nothing has left the building yet.

   Model allowed

3. The gate

   Code, not judgement. Suppression, trading hours, consent, credit hold, the amount. It is allowed to refuse, and a refusal is recorded with its reason rather than swallowed.

   Code only

4. The act

   The call, the message, the write. Carries a key, so running it twice lands once.

   Once, or not at all

5. The system of record

   Job system, ledger, rent roll, list. It holds the outcome. You did not build it and you are not replacing it.

   • Job system
   • Ledger
   • The list

   Stays theirs

The interesting part is the gap between two steps, not the steps. Every gap is a queue, and every queue needs a named owner and a clock on it. A queue nobody owns is a list of things not happening, and it will fill silently for weeks because nothing in the system is unhappy about it.

When a step escalates, it hands over a context pack: what happened, what it already tried, the transcript or the document, the customer, the job, and the one decision being asked for. An alert that says “needs attention” is not an escalation. It is a second job, handed to the person least able to refuse it.

5. Which half the model is allowed to do

This is the line that decides whether the thing is safe to leave running, and it does not move with model quality. A better model makes the left column better. It does not make the right column acceptable.

The test that sorts a new step: if being wrong is recoverable by editing some text, the model can do it. If being wrong is recoverable only by ringing a customer back, it is code.

6. The supervisor is machinery, not a cleverer agent

The word supervisor suggests an agent watching agents. Resist it. You get a second thing that can be confidently wrong, one more context window to lose, and still no record. Supervision here is ordinary and boring, and all three parts of it are older than any of this.

1. A schedule outside the agent

   Something other than the agent decides when a step runs, and can be paused without editing a prompt.

2. A retry that cannot double

   Every write carries a key, so running it twice lands once. This is what makes an automatic retry safe.

3. Somewhere failures land

   A dead queue with a reason on every item, read by a named person daily. Not a log file nobody opens.

Then a log line per transition: which job, which step, what came in, what went out, what it decided and why, written at the time rather than reconstructed later. That log is the only thing that answers “why did it do that” in a year, it is the cheapest item on this page to build, and it is the first one people skip.

It is also the answer to the question that follows any incident. Key person dependency was the old problem. Agent dependency is worse, because nobody can say who decided. A log plus a named human on every exception is what turns that back into an ordinary management question.

7. What has to survive a rebuild

You are going to rebuild this. Models change, frameworks change, and the whole point of it being cheap to build is that it is cheap to build again. So decide now which parts are allowed to die with a rebuild and which are not.

Allowed to die: the prompt, the framework, the tool wiring, the conversation. None of those are assets. Treating them as assets is how a business ends up unable to upgrade the model it rents.

Not allowed to die: the objects and their keys, the log, and the facts the business has accumulated. Who agreed to what, on what date. Who must not be contacted. What this customer was told last time. What you refuse to quote on. Those are not chat history. Chat history is a record of how you arrived somewhere. A fact is the thing itself, with a date, a source, and a way to correct it when it turns out to be wrong.

The worked example is a promise to pay. In a transcript it is a sentence, and it is gone. As an object it has an amount, a date, who said it and what happened next, and it can be counted, chased and argued with. Store those where a new agent can read them on day one, or every upgrade starts from zero and the business quietly gets worse at remembering its own customers.

8. The list it is never allowed to do

Write this before launch, keep it short, and put it somewhere a person can read it rather than buried in a prompt. It is the same list on most builds.

• A price change without a person. Discounts, waivers and write-offs included. The agent can draft one and hand it over.
• Any assurance that something is safe, current or approved. It can say what is on the record and when it was checked. It never says that a business or a build complies.
• Anything implying a licence or registration that the business holds and the agent does not.
• Legal or tax advice, however casually it is asked for.
• A first-time variation, where the answer needs somebody who has seen the site.

The list is a selling point rather than an embarrassment. It is the difference between something a manager will put on the phone and something they will keep in a browser tab and use privately.

9. Provider: what to stub, and what not to hand-roll

Almost all of this is yours to build, which is the point of the page. Three things are worth naming, and one of them is a warning rather than a recommendation.

stub in development
  - a step that logs the call or message it would have sent
  - a clock you can move, so a dated rule is testable today
  - one job id, one queue, a file for the store

production
  - the chain, the queues, the log: your own build. Ordinary
    work, and it should stay yours.
  - the models: rented, and swappable on purpose. Never the
    thing you defend internally.
  - a live Australian number with consent, trading hours,
    disclosure and do-not-call handled in code: a product,
    where a standard calls for one. Recording and disclosure
    are not features you add in month three.
  - the person on each gate: a person. production: none.

do not hand-roll
  - the write-back, wherever a double write can create a
    second job or a second invoice. Idempotency is easy to
    describe and unpleasant to retrofit.
  - the live phone call, once it is a real customer on a real
    number. Everything else here degrades gracefully.

The warning specific to agents: a demo is not an implementation. The same thing that makes this cheap to start makes a half-built version look finished, because it answers confidently either way. The pass test below is the whole difference, and it takes an afternoon.

10. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Every step names what it consumes and what it emits. Written down as fields, not implied by a prompt
• ✓2. One job id runs the whole chain. Any outcome can be traced back to whatever arrived
• ✓3. Parked and escalated are real outcomes, each with a reason. Nothing gets forced to done to clear a queue
• ✓4. Gates are code and are allowed to refuse. Suppression, hours, consent and amount are never model judgement
• ✓5. Writes carry a key and are idempotent. The same job run twice leaves one record
• ✓6. Every queue has a named owner and a clock. A queue nobody owns is a list of things not happening
• ✓7. An escalation carries a context pack. The person receiving it reconstructs nothing
• ✓8. There is a log line per transition, written at the time. Why it did that is answerable in a year, by someone else
• ✓9. The refusal list exists and is visible to a person. Not a paragraph inside a prompt nobody has read since April
• ✓10. Someone other than the builder can run it, on accounts the business owns. The keys, the store and the phone number survive the person who set it up