The three lists: what an agent may do unattended, propose, or never touch

The three lists

Before a line of agent code, we write three lists with the process owner. What the agent may do unattended. What it may only propose for a person to confirm. What it must never touch. The lists are short, specific and signed off. They are the single most useful document in the project.

• Unattended: read, classify, match, draft, post below a value threshold.

• Propose only: anything that moves money above the threshold or changes a master record.

• Never: credit limits, counterparty deletion, anything a regulator would ask about.

Why the lists come first

Without them, the default becomes approve everything, because nobody wants to be the person who let the agent post the wrong invoice. Every action then waits for a click, the agent saves no time, and the project is cancelled for lack of ROI while the technology worked perfectly.

The lists are agreed with the process owner, not the AI team. The owner knows what a mistake costs.

The lists are agreed with the process owner, not the AI team. The owner knows what a mistake costs.

The lists are agreed with the process owner, not the AI team. The owner knows what a mistake costs.

The lists move over time

After a quarter of clean exception-queue reviews, items move from propose to unattended. After an incident, they move back. The lists are how autonomy is earned rather than assumed, and they give leadership a document to point at when someone asks what the agent is allowed to do.

What it looks like in production

In the UAE commodity trading build, every write to the ERP passes a gate defined by these lists. The ops team reviews the propose-only queue each morning with the agent's reasoning attached. Nothing has been posted to the ledger without either a confident match or a human since go-live.

If your agent project has stalled at approval, the fix is usually a document, not a model.