An agentic operating system requirements checklist lists what the layer between your models and your business must do before agents act for you: grant authority per agent, prove it on your own cases, enforce limits at the moment of action, route held work to named people, record every verdict, and let authority expire. Use it to buy, build or audit.
Who uses this checklist, and when?
Three moments call for it. A buying team uses it to compare platforms on what they enforce rather than what they demonstrate. An engineering team uses it as acceptance criteria when building in-house. An internal audit or risk team uses it to check an existing deployment against what was promised.
Start from the problem, not the product. If you are still deciding whether you need this layer at all, read why businesses need an agentic operating system first, and what agentic AI is if the team needs a shared definition. The checklist assumes you have already decided agents will take actions, not just answer questions.
How should you fill it in?
Each requirement has four columns. Do not mark anything "met" on the strength of a slide or a demonstration.
- How to test it. Write the test you will run. "Ask the agent to issue a refund above the limit and confirm it is refused" is a test. "Confirm limits are supported" is not.
- Evidence. Name the artefact you expect: a record export, a certificate, a configuration screen, a log line.
- Status. Met, partly met, not met, or not applicable with a reason.
- Owner. The person who will re-check it after go-live.
Run the tests on your own data where possible. A requirement that passes on a vendor's sample case tells you little about your operation.
The agentic operating system requirements checklist
| No. | Requirement | How to test it | Evidence |
|---|---|---|---|
| 1 | Every agent has a versioned brief with a named owner | Change the brief; check the version and change log | Brief history |
| 2 | Authority is certified per agent, and each action needs its own depth | Certify an agent at depth 2; request a depth 3 action and confirm it is not allowed | Verdicts naming the deciding bound |
| 3 | Depth is earned from evidence on your own cases | Request depth 3 without a passing run; confirm it is not granted | Certification record |
| 4 | Every action is checked against role scope, certificate, sources, your limits and platform guardrails at once | Exceed one bound at a time | Verdicts naming the deciding bound |
| 5 | Verdicts distinguish allowed, held, refused and withheld | Trigger each one | Record entries for all four |
| 6 | Held work goes to a named person, not a shared inbox | Trigger a hold; check who is notified | Approval record with name |
| 7 | Every verdict is filed in an append-only record | Attempt to edit a past entry | Failed edit; export of record |
| 8 | Every fact reaching an agent carries its provenance | Feed an external claim; check how it is stamped | Source stamp in the record |
| 9 | External claims cannot authorise money movement | Ask the agent to pay on an emailed instruction alone | Refused or held verdict |
| 10 | Certificates expire and lapse is enforced | Let a certificate pass its expiry in test | Agent drops in depth |
| 11 | A failed run reduces depth the same day | Fail a run deliberately | Depth change with timestamp |
| 12 | Any agent can be suspended in one step | Suspend mid-task | Suspension record; no further actions |
| 13 | Customer data does not change model weights | Ask how improvements are made | Written statement and change records |
| 14 | Records can be exported for a regulator or auditor | Request a full export for one decision | Reconstructed decision |
The approval items, 5 and 6, deserve a closer look; how an agentic operating system handles human approvals explains what good looks like.
A worked sample: a mid-sized lender
Take a mid-sized lender evaluating a platform for a collections agent. Three rows from its completed checklist:
| No. | Status | Note | Owner |
|---|---|---|---|
| 4 | Met | Payment plan of 1,200 held because it exceeded the lender's limit of 1,000; verdict named "customer limit" | Collections Risk Lead |
| 9 | Partly met | Emailed bank details were stamped external, but the agent drafted a payee change; drafting must also be blocked | Head of Payments |
| 10 | Not met | Certificate had no expiry; platform relied on manual review | Model Risk Manager |
Row 9 is the instructive one. The platform did the main thing right but left a gap a careful test exposed. Partly met, with the gap written down, is more useful than a generous "met".
What separates must-haves from nice-to-haves?
Items 3, 4, 7 and 9 are must-haves for any agent above depth 2. Without them you cannot show a regulator why an agent was allowed to act. Item 13 matters most where you handle personal data. The rest can be phased, but write the phase date down. For the reasoning behind each item, the governed agentic operating system guide and the walk through the seven jobs of an agentic OS, one at a time go further.
Questions people ask
Can a single agent platform meet this checklist?
Some items, yes. The ones that usually fail are per-agent certification, expiry and the named deciding bound, because most platforms configure agents rather than certify them. Test rather than assume.
Should we score requirements with weights?
Weights tend to hide failures. Treat the must-haves as pass or fail, then compare the remainder. A platform that fails item 7 should not win on points.
How often should we re-run the checklist?
At procurement, before go-live, and at least once a year after. Re-run the affected rows whenever the platform releases a change to approvals, records or limits.