What is Autonomy level?
A setting that decides how far an agent may take work before a person must act — propose only, file tickets, build, or approve the result.
It turns “can we trust agents?” into a dial you move per project as evidence accumulates.
On this page
An autonomy level is a setting that decides how far an AI agent may take work before a person must act — from "propose only" through "file tickets" and "write the code" up to "approve the finished result". It is the dial that converts the org-wide question "can we trust agents?" into a per-project, per-work-type setting that moves as evidence accumulates.
The need for the dial comes from an asymmetry: agent work differs enormously in risk, but "trust the agent" is usually discussed as a single binary. Documentation updates and database migrations do not deserve the same leash, and a system that gives them one is either too slow for the safe work or too loose for the dangerous work.
The typical levels
YATFA's own ladder matches what the industry converged on:
| Level | The agent may | What still requires a person |
|---|---|---|
| Propose | Suggest work: findings, ideas, drafts | Everything — nothing enters the queue without a person |
| File tickets | Turn proposals into tickets with acceptance criteria | Ticket approval; all implementation |
| Write code | Implement approved tickets end-to-end, submit for review | Review is independent; approval of the result |
| Approve | Pass review and QA; merge when checks are green | Only the trust setting itself |
Two properties matter more than the specific rungs. First, the dial is per type of work, not just per project: tests and docs can run at "approve" while new features stay at "write code" in the same project. Second, the dial is server-side: an autonomy level that lived in a prompt would be a suggestion, renegotiable by the agent or by injected text — the same reason guardrails belong in the platform rather than the context window.
Why a dial instead of a decision
The binary question — "do we let agents work autonomously?" — fails both ways. Answer "no" and you pay people to supervise keystrokes, and the economics of agents never materialise. Answer "yes" and one early incident — an agent merging something it should not, a retry loop burning a weekend of tokens — buys you a blanket ban and a culture of fear around the tooling.
The dial's value is that trust can be earned incrementally and reversed cheaply. Start low: propose-only. As the review loop demonstrates it catches real defects before delivery, widen one category at a time — tests first, then docs, then small fixes, then features — watching bounce rates and escalation quality at each step. Narrowing is equally cheap: a bad experience with a category of work narrows that category, not the whole programme.
Choosing the right level
| Evidence you have | Reasonable level |
|---|---|
| Fresh project, no review history | Propose only |
| Review loop demonstrably catches defects; bounce rate known | File tickets; maybe build for tests and docs |
| Months of first-pass-clean deliveries, evidence attached to everything | Build for most work; approve for low-risk categories |
| Any category with repeated rework or unexplained failures | Narrow that category, whatever the rest runs at |
The decision input is evidence about your loop, not benchmark numbers about anyone else's. A team whose review catches a real defect in every third ticket has a different correct answer from one where review bounces are all formatting nits — at the same model quality.
Autonomy level vs human-in-the-loop
The terms are related but not interchangeable. Human-in-the-loop describes where people act in a workflow; the autonomy level describes how much of the workflow runs before a person is needed. High autonomy means fewer, later gates; low autonomy means earlier, denser ones. The autonomy setting is the configuration of the human-in-the-loop design — and the gate that always remains, whatever the level, is the setting itself.
One boundary is worth stating plainly: the level decides how far work may go on its own, and "approve" is the top of the ladder, not a bypass. Even at full autonomy, review and QA still run — autonomy changes who can say yes to the result, never whether anyone checked it.
Autonomy level in YATFA
YATFA's autonomy regulator makes the dial explicit: per project, per kind of work — refactors, tests, docs, new features — with the levels from propose-only up to approve, enforced on the server so no agent can renegotiate its own leash. Where agents hit their limits, work stops into escalations with the failure history attached, which is what makes widening the dial an evidence-based decision rather than a leap of faith.
Frequently asked questions
Should autonomy be set per project or per person?
Per project, and per type of work within it. Autonomy is a property of the work's blast radius and the project's verification loop, not of whoever happens to be dispatching. Person-level variation reintroduces the trust binary the dial exists to avoid.
What is the right starting level?
Propose-only for the first weeks, then file-tickets once briefs prove complete enough for agents to implement without human clarification. Promotion from there follows the review loop's record — the sequence is slow by design, and still faster than absorbing one unbounded incident.
Does higher autonomy mean less review?
No. Review and QA run at every level; what changes is who may accept the result. The reviewing agent's independence from the author, and the evidence attached to the work, are the same at "propose" and at "approve" — autonomy moves the human gate, never the verification.