Framework
Operating Boundaries for AI Agents
The six-part specification every intelligence role carries before it is allowed to touch live work.
- Type
- Framework
- Topic
- AI Agents
- Author
- AEGIS OS™
- Published
- Updated
Key takeaways
- An agent without a written boundary is not a role, it is an experiment running against production data.
- Six elements define a role: scope, permitted data, permitted actions, approval point, escalation path and review signal.
- Scope is written as one workflow and one outcome. A role defined by a job title rather than a workflow cannot be evaluated.
- The review signal — how often an approver edits the output — is what tells you whether to narrow or widen the boundary.
The six-part specification
| What it fixes | Failure it prevents | |
|---|---|---|
| Scope | One workflow, one outcome, stated in a sentence | A role that drifts across workflows and cannot be assessed |
| Permitted data | The records and fields the role may read, and those it may not | Reasoning over data the organisation never intended to expose |
| Permitted actions | What the role may write, send or change — usually drafts and internal records only | An irreversible external action taken without a decision |
| Approval point | The named person and the held state before the work proceeds | Accountability detaching from anyone who can exercise it |
| Escalation path | What the role does when confidence is low or inputs conflict | A confident answer assembled from contested inputs |
| Review signal | The approver's edit rate, tracked over real volume | A boundary that has quietly become a button |
Writing a scope that can be evaluated
Scope written as a job title — 'analyst', 'assistant', 'coordinator' — cannot be tested, because there is no defined output to compare against. Scope written as a workflow can: a trigger, the records involved, the artefact produced and the state it lands in.
- Weak: an intelligence role that helps the operations team.
- Usable: when a new document arrives against a deal record, extract the named terms, flag deviations from the agreed template, and place a draft summary in review for the deal owner.
Rolling a role into live work
From specification to live
- 01Specify the six elements and have the workflow owner approve them in writing.
- 02Run against real historical work, with output visible but not acted on.
- 03Move to live with every output held for approval.
- 04Track the edit rate over a representative volume, not a handful of cases.
- 05Narrow or widen the boundary from that evidence, one condition at a time, reversibly.
Widening is a decision, not a default
A boundary is relaxed only for the specific condition that proved reliable, with the monitoring that would show the assumption breaking and a defined trigger to reinstate it.
Attribution is part of the boundary
Every artefact an intelligence role produces carries which role prepared it, from which records, on which version, and who approved it. Without that, a reviewer cannot judge the output and an auditor cannot reconstruct the decision. Attribution is not reporting overhead; it is the thing that makes the boundary enforceable after the fact.
Sources and references
- AI Workforce page — Published intelligence roles and their approval boundaries — keep terminology identical.
- AEGIS AI Use Policy — Published governance position on human decision authority.
Reviewed and published. Reflects AEGIS implementation practice. No client example, model benchmark or performance figure is described.
Start with an Architecture Assessment
An Architecture Assessment turns these questions into a documented blueprint, readiness analysis, implementation roadmap and quote for your organization.
Related resources
Framework
AI Agents vs Automations vs Workflows
How agents, automations and workflows differ in scope, control and accountability, and when each one is the right instrument.
Framework
Human Approval Architecture
Designing approval boundaries so intelligence can draft, prepare and route work while people stay accountable for decisions.