Why agents raise the stakes
Chat assistants suggest. Agents act. That one difference changes what governance has to do.
When an employee asks an AI for a draft, a human still stands between the output and the world. The draft gets read, edited, sent or discarded. The blast radius of a bad answer is one person's judgment. An agent removes that buffer by design: it sends the email, writes to the CRM, books the meeting, files the ticket, changes the record. A bad skill produces a bad draft. A bad agent takes a bad action, and the action is already done by the time anyone notices.
The failure modes are ordinary, not exotic. An agent quoting last quarter's pricing does not just answer wrong, it sends the wrong quote to a customer. An agent with broader CRM access than its task needs will eventually touch records it should never have touched. An agent built on a method its author half-tested becomes the default way forty accounts get handled. None of this requires malice. It requires only what most companies already have: agents that ship without anyone reviewing them.
Your employees are already building agents
This is not a future problem. The same AI tools your teams use every day now make agent building a mainstream activity, not an engineering project. An account manager can wire an assistant that reads inbound requests and updates records. An operations person can chain a research step into an outreach step. Claude, and every comparable platform, keeps lowering the barrier on purpose.
What none of these platforms adds is a review step. The person who builds the agent is the person who decides it is good enough, and the decision is invisible: it happens in an individual account, with no owner assigned, no reviewer named, and no record kept. Companies discovered this pattern once already with prompts and skills spreading through Slack and shared docs. Agents repeat the pattern with one difference: this time the unreviewed thing has hands.
The three governance questions
Strip away the frameworks and vendor language, and AI agent governance reduces to three questions a company should be able to answer at any moment:
What exists? Which agents are acting for the company right now, in which team, on which process. If the honest answer is "we would have to ask around," governance has not started.
Who approved it? For each agent, a named person who reviewed it and said yes. Not a policy document, not a committee that met once: a name attached to a decision on a specific agent.
What can it touch? The tools it can call, the data it can read, the records it can change, the messages it can send. An agent's method can be excellent while its access is far wider than the task requires, and the access is where the damage lives.
Everything else in this guide is a way to make those three answers cheap to produce and hard to lose.
The agent register
The simplest structure that answers all three questions is one we call the agent register: a single list, one line per agent, five fields per line.
Owner. The person accountable for the agent's behavior and updates. Every agent has exactly one.
Reviewer. The named person who approved it: the team lead who owns the process the agent acts in, the domain expert rather than IT.
Exact version. The precise configuration that was reviewed. If the agent's instructions or tools change afterwards, the entry is stale and the approval no longer applies.
Scope of access. What the agent can call, read, and change, written down explicitly. An approval that does not name the scope approves nothing.
Review date. When it was last reviewed, so stale entries are visible instead of silent. Pricing changes, policies change, and an agent approved in January is not automatically fine in June.
A register like this is deliberately boring. It fits in a table, anyone can read it, and it turns "are our agents under control?" from a debate into a lookup.
| Ungoverned agents | Governed agents | |
|---|---|---|
| Visibility | Nobody can list what is running or where. | Every agent is one line in the register, findable in seconds. |
| Approval | The builder decides alone; no one else is asked. | A named reviewer, the domain expert, approved the exact version. |
| Access scope | Whatever the builder connected, often more than the task needs. | Written down, reviewed, and limited to what the process requires. |
| Versioning | The agent quietly changes; nobody knows which version acts today. | The exact version is recorded, and edits require a new decision. |
| When someone leaves | Their agents keep acting, unowned and unknown. | Ownership is reassigned from the register; nothing runs orphaned. |
Start with skills, extend to agents
Here is the useful realization: the approval mechanics do not change between a skill and an agent. In both cases, a named reviewer approves an exact version, the approval is scoped to a team, the decision is recorded, and there is no bulk approve, because fifty things approved in one click is zero things reviewed. What changes with agents is one added dimension: the approval must also bind to the scope of access, since an agent's power comes from what it can touch, not only from what it knows.
That is why the practical path starts with skills. A company skill is an approved, versioned method: the same governed unit an agent will run on. A team that already proposes methods, routes them to the right reviewer, and ships only approved versions has built the muscle agent governance requires. A team that cannot review a document-producing method will not suddenly review an action-taking agent.
knacks is the approval layer for the AI your employees are building, skills and agents on one path: employees propose from Claude, the team lead reviews the exact version with evidence attached, and only what was approved ships to the chosen team, recorded and current by default. For agents, the approval also binds to the scope of access: the same review path, the same named reviewer, the same rule that nothing ships unreviewed. Regulation points the same way: inventory and accountability expectations in rules like the EU AI Act reward companies that already know what AI systems they run and who is accountable for each.
The order matters. Skills first, then agents. Companies that govern their methods now will hand their agents a register, a reviewer, and a habit. Companies that wait will hand their agents nothing.
Frequently asked questions
What is AI agent governance?
AI agent governance is how a company decides which AI agents are allowed to act on its behalf: who approves each agent, what systems and data it can access, and who keeps it current once it runs. In practice it comes down to three questions the company must be able to answer at any time: what agents exist, who approved each one, and what each one can touch.
Who should approve an AI agent?
The team lead who owns the process the agent acts in: the domain expert rather than IT. A renewal follow-up agent goes to the Head of Customer Success, an invoicing agent to Finance. When the agent has access to systems or data, a security review is added on top, but it complements the domain review, it does not replace it.
How is agent governance different from skill governance?
The mechanics are the same: a named reviewer approves an exact version, with no bulk approve. The difference is what the approval must also cover. A skill shapes what the AI says, so review focuses on the method. An agent acts, so the approval must also bind to its scope of access: which tools, which data, which permissions. If either the version or the scope changes, the approval no longer applies.
Put a review step in front of your AI.
Book a walkthrough and start where governance actually starts: one team, one repeated method, approved by the right expert and shipped as your first company skill.
Book a walkthrough