AI agent governance for a team of ten

AI agent governance is the set of rules that decides who may create an agent, what that agent may do, which actions need a person to approve them, and how the team checks what happened afterward. For a company of ten people, this does not need a committee, a thick policy manual or a new job title. It needs named owners, clear approval boundaries and one record that can answer a simple question six weeks later: who allowed this action, and why?

Small teams have one advantage here. The people who set the rules usually sit close to the work. Use that. Keep agent governance short enough that everyone can remember it, but specific enough that nobody has to improvise when an agent is about to send an email, change a record or spend money.

Limit who can create and change agents

We would not give every employee the ability to create an agent with any tools and any policy they like. That turns a staffing question into an access-control problem. For a ten-person company, two or three people can usually own agent creation: perhaps a founder, an operations lead and the person responsible for the system the agent will touch.

Everyone else can request an agent by describing the job. The owner then decides what the agent is allowed to read, which tools it can use, its spending limit, the actions that require approval and the conditions under which it should stop. The same rule should apply to later changes. Someone who can edit an agent's policy can change what the agent is allowed to do, so policy edits deserve tighter access than ordinary use.

Keep the roster small enough to inspect. Ten overlapping agents called "sales helper", "sales assistant" and "outreach bot" are harder to govern than one outreach agent with a clear brief and a named owner. Retire agents that no longer have an active job.

Match approvals to the effect of the action

Approval rules should follow consequences, not task complexity. An agent can spend twenty minutes drafting a report without affecting anybody outside the workspace. A two-second click that sends a refund has a very different effect.

There should also be a floor beneath the table. Some actions should never become automatic simply because the team has used an agent for a few months. In Delagents, eight classes always require a person: first contact outside the workspace, moving money or issuing refunds, deleting or overwriting records the agent did not create, changing roles or its own policy, connecting an integration or widening scopes, accepting terms or signing, publishing publicly, and acting in another workspace.

The approver needs to see the proposed action, not a vague request such as "approve outreach". A useful approval says what will happen: "Send this message to Maya Chen", "Refund EUR 84 to order 4182" or "Publish this draft to the company blog". The person can then approve, change or reject something concrete.

Give every agent one owner

Shared ownership usually means nobody notices drift. Give every active agent one named owner. That person does not need to approve every checkpoint. They are responsible for the agent's brief, tools, budget cap, approval rules and periodic review.

This matters most when an agent crosses team boundaries. An inbox triager might be used by operations but touch a founder's email. A bookkeeper might prepare work for finance but encounter a payment action. The owner decides where the handoff sits and names the person who can approve that class of action.

Do not write "manager approval" into a policy unless there is only one possible manager. Write a role or a name. If Alice is away, the team should already know who has authority to approve a refund or a new integration.

Put the log in one place and make it boring

An audit log is useful when it is complete, chronological and hard to rewrite after the fact. It should record the work the agent did, the tools it called, the approvals it requested, the decisions people made and any policy changes. Delagents uses an append-only activity log for tool calls, approvals and policy changes, alongside hard budget caps and other security and guardrails.

Do not split the record across chat messages, private notes and screenshots. If an owner has to reconstruct an incident by asking four people what they remember, the company does not have an audit trail. It has archaeology.

The log also needs enough context to explain a decision. "Approved by Sam" is weaker than a record that shows the proposed action Sam saw. Governance depends on knowing what was approved at that moment, not merely that an approval button was pressed.

Read the log on a fixed rhythm

A log nobody reads is mainly storage. For a ten-person company, we would use two review rhythms. The agent owner checks recent activity weekly for rejected actions, repeated corrections, unexpected tool use, budget pressure and requests that keep reaching the wrong approver. Once a month, one founder or operations lead reviews the roster itself.

The monthly review can be short. Which agents are still active? Did anyone widen an integration scope? Have approval rules changed? Is an agent repeatedly asking for the same exception? Has its job expanded beyond the brief that justified its access?

Incidents get read sooner. If an agent tries an action outside policy, repeatedly submits bad approval requests or uses a tool nobody expected, the owner should inspect that delegation before the next run. A calendar schedule should never outrank an obvious reason to look now.

Write the one-page policy before adding the next agent

A small company's first governance document can fit on one page. Name who may create or modify agents. List the action classes that always need approval and who can approve each one. Name the owner of every active agent. State where the append-only log lives, who reads it each week, who reviews the full roster each month, and what event triggers an immediate review.

Then test the policy against four ordinary situations before you trust it: an agent wants to email someone new, issue a refund, connect a new integration and overwrite a record created by another person. For each case, ask who sees the request, what information they see and what gets written to the log afterward.

Do that before adding another agent to the roster. If your team cannot answer those four cases without discussing the rules from scratch, the next task is not another automation. It is finishing the page.