Agents at work: where enterprise automation needs a person

The problem

Enterprises are moving agents from drafting to doing. An agent that drafts an email creates a suggestion; an agent that posts a journal, releases a payment or edits a customer record creates a fact. Most organisations still decide which actions need a person case by case, in meetings, and the answers rarely survive contact with the second agent.

Low trust is reasonable, but it often produces the wrong design: a person approving everything. Approvers who see hundreds of routine requests a day stop reading them, and the approval becomes a ritual. The goal is fewer, better approvals, not more.

Method

We reviewed the action types that agents are asked to perform in finance operations, claims, CRM and IT service management, drawing on the processes elan1 Work, elan1 Decide and elan1 Govern are designed for. For each, we asked two questions.

1. 01Reversibility: if the action is wrong, can it be undone completely, and at what cost?
2. 02Blast radius: how much value, how many people, or which obligations does a wrong action touch?

We did not measure customer outcomes. elan1 has no customer results to publish yet, and this paper does not imply any.

The map

Plotting actions on those two axes gives three zones. Each zone corresponds to one of the three outcomes elan1 Govern returns.

• Allow: reversible and narrow. Tagging a ticket, drafting a reply for review, reading a document the agent's role already permits. These can run alone, within a rule, and are recorded.
• Ask a person: reversible with effort, or wider in reach. Payments above a threshold, credit overrides, changes to workflows or price lists. A named person decides, with the evidence attached.
• Refuse: irreversible, or a known fraud route. Bank-detail changes, deletions of records under retention, filings with a regulator. Refused by default; a person does them directly if at all.

Findings

Three patterns came up in every function we examined.

1. 01Most of the volume is in the allow zone, and most of the risk is in a small number of action types. Rules should be written for the action types, not for the agent.
2. 02Thresholds drift. A payment ceiling set at launch is rarely revisited. Rules need an owner and a review date, like any other control.
3. 03The refuse zone is smaller than teams expect but non-negotiable. It should be written first, because it is the list that protects the business if everything else fails.

From map to rules

The map becomes useful when each zone is written as rules a named approver signs. We suggest a one-page rule sheet per process: the action types, the zone for each, the threshold that moves an action between zones, the approver and deputy, and the review date. Anything not on the sheet is refused, so a new action type cannot slip through because nobody thought of it.

Starting small helps. Pick one process that costs the most in review time, write its rule sheet, and run it in shadow beside the current process before switching anything on. The readiness check asks 12 questions that lead to the same sheet.

Limits of this paper

The map simplifies. Some actions are cheap to reverse financially but expensive in trust, such as a wrong message to a customer. Sector rules can also override the map: in credit, anti-money-laundering, clinical intake and hiring, elan1 Decide is recommend-only regardless of zone. Treat the map as a starting point for the conversation with your risk owner, not a substitute for it.