Agentic AI is moving from experiment to daily operation inside real businesses. That's the useful part. The part most teams skip is simpler than it sounds: knowing what an agent is allowed to touch, who signed off before it acted, and being able to show that afterward. This framework lays out, in order, how to get there — without turning it into a compliance project bigger than the thing you're trying to run.
Most people's experience of AI is still a chat window: ask a question, read an answer, go do the work yourself. An agent removes that last step — you give it a goal, and it plans, acts, and hands back a finished result, often by reaching directly into your inbox, your calendar, your files, or a business system. That's the productivity story every vendor tells. It's also the exact moment a helpful tool becomes something that needs a boundary around it.
Multi-step work finished end to end — drafting, researching, reconciling, following up — without someone re-keying every step by hand.
Standing access and decision-making that used to sit only with a trained person now sits with a system that can be misdirected — by a bad prompt, a bad instruction hidden in a document, or just an unclear goal.
Not more process — the minimum structure that lets you say, with evidence, what an agent was allowed to do and who approved it when it mattered.
The rest of this framework follows one thread: what an agent is actually doing under the hood, then what needs wrapping around it.
Strip away the product names — Claude, GPT-5, Copilot, whatever comes next — and every agent repeats the same three-step cycle, often twenty or thirty times on one task: observe the current situation, think about the next move, act using an available tool, then check whether it's done. Understanding this loop matters because it tells you exactly where to intervene — you don't need to touch the model to change how an agent behaves, you need to change what it observes and what it's allowed to act on.
| Layer | What it is | What to check |
|---|---|---|
| Model | The reasoning engine doing the "think" step — Claude, GPT-5, and so on | How its data handling and retention are documented |
| Harness | The runtime actually running the loop — Claude Code, Cowork, Copilot Studio, or a custom setup | Whether it keeps a record you can export when someone asks for it |
| Context, tools, and instructions | What the agent is allowed to read and which tools it can reach | Whether every tool connection is written down somewhere, with a reason |
| Checkpoint and record | Where a person signs off, and where that decision gets kept | Whether there's one named person, not a shared inbox |
Swapping a model or upgrading the harness shouldn't mean rebuilding your whole approach to oversight. The context, the tools, and the checkpoint are the layer that stays yours regardless of which vendor sits underneath — designed once, reviewed on a normal cadence, and portable if you ever change providers.
Once you can see the loop, the next question is practical: what do you actually hand the agent before it starts?
A new employee doesn't get access to everything on day one — they get context about the business, a defined set of tools, and a few written procedures for the tasks they'll repeat. Guardian treats an agent the same way: a short set of plain files that describe the business, the tools it can reach, and how it should do its recurring tasks. Nothing exotic — just written down, owned by someone, and revisited when things change.
A handful of files describing the business, its customers, and how you like things done — the agent's version of onboarding notes. Each file has a person who owns it and updates it when something changes.
One file the agent re-reads at the start of every session — its working brief. Keep it current, and treat a change to it like any other change to how the agent operates.
A short written procedure for each task the agent repeats. When a procedure both drafts something and sends it out unattended, that's worth a second look — a different threshold for "just draft it" versus "and send it" is a small, sensible habit, not a bureaucratic requirement.
Every connection an agent has — email, calendar, files, a business system — written down somewhere with a reason it's needed. If you can't say why a connection exists, that's usually a sign to remove it.
Once the agent is set up, the real question becomes: what happens the moment it wants to do something that actually matters?
A dependable agent workflow isn't "the agent did something" — it's a bounded plan with one clear pause point before anything hard to undo happens, and a record of what happened either way. Most of the time, the person who set the goal is also the one who checks the pause point — this isn't a committee, it's one person doing a quick check on their own work. The diagram below is the shape Guardian recommends for any agent that can write to a real system: most steps run on their own, and only the ones that matter stop for that person.
In practice, the check-in can be as small as a daily morning email: one message listing everything waiting on a decision, replied to with a yes or a hold. That's the whole mechanism — it doesn't add a meeting or a queue, it's what lets an agent run all day without anyone watching it in real time. The point of a pause point is to speed the process up, not slow it down: it's the difference between reviewing five minutes of decisions once a day and re-doing the work yourself.
An email leaving the company, a public post, anything a customer or third party will actually see.
Deletions, payments, access changes — anything that can't be cleanly reversed once it happens.
Anything touching hiring, credit, or a system that already carries compliance obligations on its own.
A pause point is only useful if you can later prove it happened as described — which is really a measurement problem.
A handful of simple, repeatable checks tell you far more than a good feeling after watching an agent run a few times. None of these require special tooling — they're closer to the checks any careful team already runs on a new process before trusting it fully.
| What to check | What good looks like | How to check it |
|---|---|---|
| Does it finish the job | Reaches the stated goal without a human stepping in to fix it | Re-run a handful of past tasks and note the pass rate |
| Does it stay in its lane | Never reaches for a tool or file outside what it's been given | Compare what it actually touched against the list it was given |
| Does the pause point hold | Every hard-to-undo action has a matching, timestamped approval | Match the action log against the approval record — any gap is a finding |
| Can it be fooled | Doesn't treat text inside a document or email as an instruction to follow | Try a few documents with hidden instructions and see what happens |
| Can you explain what happened | Every action can be traced back and, if needed, undone | Walk through one real run end to end using only the log |
Agents lose track of earlier instructions as a session runs long — the practical symptom is one that starts ignoring a rule you set ten minutes ago. Starting a fresh session for a new goal is usually more reliable than patching a long one with corrections.
Guardian builds these checks the same way it builds any compliance evidence — which is where this framework connects to a wider set of obligations you may already be tracking.
Guardian's EU AI Act and NIS2 compliance work already covers AI systems generally. An agent adds one wrinkle: it doesn't just produce an answer, it takes actions — which is exactly what the checkpoint and the log above are built to account for.
| Article | What it asks for | How it shows up for an agent |
|---|---|---|
| Art. 9 | An ongoing risk management process | Every agent with tool access gets listed somewhere, with a note on what it can reach and why |
| Art. 10 | Sound data governance | What the agent is allowed to read matters as much as what a model was trained on |
| Art. 11 | Technical documentation | The working brief, the procedures, and the tool list together are effectively that documentation |
| Art. 12 | Automatic logging | Every action and every approval decision lands in a record that can be pulled up later |
| Art. 13 | Transparency to those affected | Anyone affected by something an agent did can be told that, and how to raise a concern |
| Art. 14 | Human oversight | The named person from the checkpoint above — usually the same one who set the goal — not a shared inbox |
| Art. 15 | Accuracy and robustness | The reliability checks above are the evidence for this |
The same shared building blocks — access control, logging, incident reporting, vendor due diligence — cover NIS2 Article 21 at the same time, so this isn't a second, separate workstream if you're already tracking one of the two.
All of which raises one more question: whose job is each of these pieces?
This doesn't need a governance committee. In most small and mid-sized setups, the same person sets the goal and checks the pause point — that's normal, not a gap. What matters is that someone separate maintains the tool connections, so the person making the calls isn't also the only one who knows what the agent can technically reach.
| Decision | You (sets goals & reviews) | Whoever sets up the tools |
|---|---|---|
| What the agent is trying to do | Owns it | Informed |
| What it's allowed to know and touch | Consulted | Owns it |
| Where the pause point sits | Owns it | Consulted |
| Whether the log is trustworthy | Reviews it | Owns keeping it running |
The founders and employees that are now using agents are, no word of a lie, five to ten times more productive in their day.On the shift toward agentic AI this framework responds to