Rail Levels: The Levels of AI Agent Autonomy, From Read-Only to Bounded Action

Who this is for: heads of marketing operations, risk and AI governance leads, and architects. You will be able to set a maximum level for each job, write promotion and demotion rules, and design approvals that do not decay into rubber-stamping. This page is part of the AI agent rails method.

What are the five rail levels?

Five rail levels set what the agent may do and what the person does. Each one sits on a stage of the AI marketing operations roadmap.

The ladder stops at L4. Promotion needs written evidence and owner sign-off. Demotion is automatic on triggers: error budget breached, serious escaped error, drift alert, open incident, a model or tool change without a regression pass, no named owner.

Above L4, an agent would act across a broad scope or set its own goals, and we do not recommend that for customer data. The Cloud Security Alliance's scale goes higher, but its author says of the top level that "the control mechanisms required to safely operate at this level don't exist yet" 1.

Most work never needs the top rung. In our roster of 33 agents, 25 never go above L2. The five that reach L4 do so for one narrow action each: pausing a send, pausing a stream, raising a hold, retrying an approved sync and routing a request.

View or embed this diagram as SVG

How does this compare with other autonomy scales?

No standard scale for agent autonomy exists, so level numbers from different publishers do not line up. The crosswalk below is our own reading of two published scales and the common loop terms. Neither publisher has reviewed it.

Watch the numbers when you read across. CSA Level 1 is our L3, and CSA Level 3 is our L4. Our L1 and L2 both sit at CSA Level 0. Feng's L4 is not our L4.

The scales also measure different things. Feng and colleagues name the roles a user can take, and treat autonomy as a design choice separate from capability. We share that view: a capable model can still sit at L1. The CSA post counts how far decisions move to the AI, and its author offers it for discussion rather than as a finished standard.

The loop terms are common usage, not legal definitions. Human in the loop means a person acts before anything takes effect. Human on the loop means the system acts and a person monitors, with the power to stop it.

Why do levels belong to the job, not the agent?

Rail levels belong to the job because one agent can do two things with very different risk. Two examples show this.

The Anomaly Watcher explains alerts at L1 and pauses a send at L4. The paths differ. A model writes the explanation, while the pause path uses rules only and reads no free text. A wrong explanation wastes an analyst's morning. A wrong pause delays a campaign until a person resumes it, and transactional mail is excluded. See marketing anomaly detection.

The Segment Drafter proposes at L2 and has no execute tools. Publishing is a separate L3 step, run by an execution service after a named person approves the definition hash. The segmentation walkthrough shows that split. Adding an activation tool to the drafter would not be a small upgrade, because drafting and activating would then share one session.

So a company has no single level, and neither does a function. One team can run a read-only rail and an approved sync on the same day.

How do you find the maximum level for a job?

The maximum level for a job comes from six tests. Apply all of them, and the lowest ceiling that applies wins. A job that fails the last test cannot go above L3.

Three roster entries look like exceptions to this table, and each one shows how to read it.

• Consent Conflict Reviewer, L2, L4 for hold only. Work on consent state stays at L2. The L4 action only raises a hold on a launch. It changes no consent or suppression state, it fails safe, and a compliance reviewer clears it.
• Sync Medic, L3 to L4. A sync sends personal data out, so it needs named approval. A retry of an approved sync is not a new activation only if version, audience hash and destination are unchanged and consent is re-checked. Anything else needs approval. See failed sync retry.
• Anomaly Watcher, L1, L4 pause. The session that reads text explains. The pause runs on a written rule with no model in the action path, so no session holds all three Rule of Two properties 3.

A useful test follows: an L4 action should stop, hold, route or repeat something already approved. It should not start anything new.

What evidence does a promotion need?

A promotion needs written evidence from the level below, and the rail owner signs it. This page sets no thresholds, because a number that suits journey QA would be wrong for a consent check. Set them per rail and write them on the rail card.

Each step up also needs new systems, not only a better record. The next table draws on the roadmap's prerequisites.

What triggers automatic demotion?

Automatic demotion applies on six triggers, because a rail is most likely to fail when people are busiest. The system acts first, and people review afterwards.

The gateway or execution service applies the demotion by dropping the scope, so nobody has to act and the agent cannot argue. Write the fallback on the card. A sensible default is that an L4 rail falls to L3, so the action now waits for approval. An L3 rail falls to L2, so the execution service refuses the run and the agent can only propose. Pending approvals lapse. Climbing back needs the same evidence as a first promotion.

PrivyCDP's product page describes limits on data access, review of results and an immutable audit ledger that records each AI-assisted action with the human or system actor that authorised it, which is the kind of record a promotion case draws on.

How do you design approvals that hold up?

Approvals hold up only if the design assumes people over-trust automated suggestions. In a 2023 Radiology study, 27 radiologists read 50 mammograms with suggestions from a purported AI, some deliberately wrong. Very experienced readers fell from 82% correct to 45.5% when the suggestion was wrong, and inexperienced readers fell from almost 80% to under 20% 4. It is a small study in another domain, so treat it as a warning and not as a measurement for marketing.

Ben Green's review of 41 human oversight policies argues that people often cannot perform the oversight those policies expect, which creates a false sense of security 5. Article 14(4)(b) of the EU AI Act names automation bias, though Article 14 applies to high-risk systems only, with Annex III obligations from 2 December 2027 67.

The legal test points the same way. Guidelines from the Article 29 Working Party on GDPR Article 22 ask for oversight that is "meaningful, rather than just a token gesture", by someone with the authority and competence to change the decision 8. In CJEU case C-634/21 SCHUFA, a score counted as the decision when others drew strongly on it 9. In the UK, section 80 of the Data (Use and Access) Act 2025 treats a decision as solely automated when there is no meaningful human involvement 10. Explainable AI for customer decisions covers this in depth.

Eight design rules follow from that evidence.

1. Show a diff and counts. The approver sees what changes and for how many people, not the agent's summary of it.
2. Seed known-bad items. Put deliberately wrong proposals in the queue, and make sure the execution service would refuse them if approved.
3. Keep the approver apart from the requester. No one approves their own request.
4. Add a second approver above a size threshold. Set the threshold per rail.
5. Bind approval to a hash of the exact payload. A later change voids it.
6. Let timeouts expire. They never auto-approve.
7. Watch queue length and approval turnaround. Long queues push people to bypass.
8. Report by rail and role. Seeded-item results can look like a score for each reviewer. Annex III point 4(b) of the EU AI Act lists monitoring workers' performance and allocating tasks by individual behaviour as high-risk uses 11, so take advice before using results about named staff.

When do we reach L4?

L4 is reachable for a few reversible jobs, after months of evidence, and many jobs never should reach it. The roadmap's Stage 4 conditions and its list of what not to automate set the boundary, and the 7 things agents should never do add the hard limits. A quick check: if nobody can say how the action is undone within minutes, it is not an L4 job.

Reaching L4 is also not a goal in itself. A rail that stays at L2 for years and catches real defects is doing its job. Moving it up should answer a specific problem, such as a queue that delays a safe action, and not a wish to show progress.

How do you set levels for your agents?

Setting levels takes eight steps, and it works best one job at a time. Use it as a checklist.

1. List every agent job, not every agent.
2. Run each job through the six tests and write down the ceiling.
3. Set the current level at or below the ceiling. Start low.
4. Name the human role for that level: reader, reviewer, approver or auditor.
5. Confirm that the systems for that level exist and have been tested.
6. Write the promotion evidence and thresholds on the rail card.
7. Write the demotion triggers and the fallback level, and connect them to the gateway or execution service.
8. Review levels on a schedule and after any model, prompt or tool change, and record each move in the ledger.