How to read the Governed Agents Reference

The people selling AI agents are writing the vocabulary. You are the one who signs off on an agent paying an invoice, closing a claim, or changing a record in your ERP. You need the words defined by someone who has had to defend them to a controller.

In one sentence: a plain-English reference for people who let software act for them and want to stay in charge.

/01What this reference is

A reference, not a tutorial. Each page explains one thing. Read it once and you can use the term correctly in a meeting. Want to build an agent? Read the vendor's docs. Want to know what "runtime enforcement" means before you sign a contract that promises it? Read ours.

Opinionated. A page with no take is a glossary. We say what works, what is marketing, and where we would put the hold. We also say when a competitor's approach is right for your case.

Sourced. Every fact about a law, a standard, a vendor feature or a published incident carries a numbered source. Where we quote, we quote the fetched text. Where a number is ours for illustration, the sentence says so right there, not in a footnote.

Written for operations and risk. Our reader runs accounts payable, claims or a service desk, or the risk function that oversees them. Not a platform engineer. So the reference leans towards controls, regulation and operations. It covers frameworks and vendors only as far as a buyer needs.

/02What this reference is not

Not vendor documentation. When we describe what Copilot Studio or n8n does, we work from their docs and link the page. If the docs and this reference disagree, the docs win. Tell us.

Not neutral. Surehand deploys and runs governed agents for clients, on a product we built. Every page has one block, labelled "Gatehouse fit", that maps the idea onto our product. That block is the only place the product appears. Skip it and the page still stands.

Not legal advice. The Regulation pages quote article numbers and dates, and say what we think they mean for a team running agents. Your counsel decides what they mean for you.

Not exhaustive. There are hundreds of agent tools. We cover the ones buyers actually weigh, and the ideas that stay true whichever tool wins.

/03What we mean by "agent"

The word is stretched. The EU AI Act defines an AI system as a machine-based system that "infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments"¹. That covers a spreadsheet macro with a model in it.

Anthropic draws a narrower line we find more useful. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths". Agents are "systems where LLMs dynamically direct their own processes and tool usage"².

Our working definition sits between the two. An agent is software that uses a model to decide, and then does something in a system you care about. Drafting an email is not it. Sending the email is. Reading an invoice is not it. Scheduling the payment is. Once the software can change state somewhere, every page here applies.

/04How the pages are organised

Seven groups.

• Meta. This page and the stack map.
• Controls. What you put between the agent and your systems. The control plane, the permission manifest, the two-person rule, holds and named approvers, spend limits, the sealed record.
• Risks. How an agent goes wrong. Prompt injection through documents, excessive agency, retries that duplicate payments, supply chain through plugins.
• Regulation. The EU AI Act for deployers, ISO 42001 against the NIST AI RMF, SOC 2 when the product is an agent, data residency.
• Operations. Shadow mode, evaluation in production, the numbers to watch weekly.
• Cost. What one run costs, hold-rate maths, model vendors as suppliers.
• Vendors and tools. Fair readings of the approval features in Copilot Studio, n8n and the agent frameworks, from their own docs.

Every published page is listed under Reference. New pages arrive weekly.

/05Conventions you will see

The lede answers the question. The first paragraph is the answer. The bold "In one sentence" line is the version you can repeat.

Where it comes from. Most controls here are older than the models. Separation of duties comes from accounting. The control plane comes from networking. Shadow mode comes from machine learning operations. The lineage tells you which parts are settled and which are new.

Good at, and not. Every concept and vendor page has a section on limits. If we cannot find a limit, we have not looked hard enough.

What to check. A short list of questions for a vendor, an auditor or your own team. This is the part people copy.

At a glance. A small facts table at the end. Category, other names, what it borrows from, the standard or doc behind it, who usually owns it.

Three names, used everywhere. The rules: the signed document that says what the agent may do. The approver: the named person who decides a held case. The record: what the run leaves behind. Technical terms appear once each, on their home page.

/06How to use it

Evaluating a vendor? Read the Controls pages first. Take the "What to check" lists into the call. Approving an agent's go-live? Read the stack map, then Shadow mode, then the EU AI Act page. An auditor? Start with the two-person rule and the permission manifest.

Something missing, wrong or out of date? Write to support@surehand.io with the page and the source. We would rather fix a page than defend it.

/07Gatehouse fit

Surehand runs client deployments on Gatehouse, the control plane we built. Its parts are the rules, the approver and the record. Each Controls page maps one idea onto one of those three. The Gatehouse page has the mechanism. This reference has the concepts. Screens on both sites are simulated and show no customer data.

/08At a glance