What to document up front so AI operations stay low-touch

Write down eight things before the first agent is built: who decides what, a named owner with a backup, response windows, acceptance criteria, the business rules and their known exceptions, the data and access map, who can stop the agent, and where the runbook lives. Do that up front and operations afterwards fit into one short written brief a week. Skip it and every exception turns into a message thread, then a call.

This post is the list, in the order we ask clients to write it, with what each item has to say and what goes wrong without it. It is the document we wish every buyer brought to the intake form.

Key Takeaways

• Most of the meeting load in AI operations comes from eight decisions that were never written down, not from the technology
• EY’s September 2026 survey found 49% of companies using agentic AI had not updated their governance for agent-specific requirements
• Nobody clearly owns agent access in most firms: 28% say security, 21% engineering, 19% IT, 9% identity teams (Cloud Security Alliance, March 2026)
• Each item takes an hour or less to write and is cheaper before the build than after the first incident

Why document before the build, not after?

Documenting after the build means documenting during the incidents, which is the most expensive time to do it. Most firms get there late. EY’s AI Risk and Governance Survey, published 15 September 2026 from 202 board, C-suite and VP-level leaders at US public companies above $1 billion in revenue, found 49% of agentic AI users had not updated their governance framework for agentic requirements, and 47% had skipped their own process for urgent deployments (EY, September 2026). Those are large companies with compliance teams. A 20-person firm has less slack, not more.

The cost of the gap lands on the calendar. Microsoft’s Work Trend Index of June 2025, built on Microsoft 365 telemetry plus a survey of 31,000 workers in 31 markets, found meetings starting between 8pm and midnight were up 16% year over year (Microsoft, June 2025). An agent that hands a case to a human at 9pm with no written rule for who decides produces exactly that kind of meeting.

The alternative is boring: write the rules while nobody is waiting on an answer. Our method already rules out calls on the vendor side. This list is the client side of the same deal.

What are the eight documents?

Eight short documents, each answering one question a human would otherwise be asked in a message thread. None needs to be longer than a page. The table is the whole list; the sections below say how to write the ones people get wrong.

Document	Question it answers	Who writes it	Without it
Decision rights	What may the agent decide alone, what needs a named person, what needs the founder	Owner of the process	Every edge case escalates to whoever is online
Owner and backup	Who is accountable for this agent this quarter, and who covers leave	Founder or ops lead	Agent runs ownerless within a quarter
Response windows	How fast a human answers an agent’s hand-back, and what counts as urgent	Owner	Hand-backs wait, then get chased by phone
Acceptance criteria	What “working” means on real data, with a pass condition	Owner, with the builder	The build is accepted on a demo and argued over in month two
Business rules and exceptions	The rules the agent follows, and the known cases where a human overrides	Person doing the job today	Rules live in one head, agent learns the wrong ones
Data and access map	Which systems the agent reads and writes, with which account, who can revoke	Whoever holds the admin logins	Shared credentials, nobody can say what the agent can touch
Stop authority	Who can switch the agent off, how, and who gets told	Founder	Nobody stops it, or everybody argues about it
Runbook location	One place where all of the above lives and is kept current	Owner	Eight documents in eight inboxes

How do you write decision rights and response windows?

Decision rights are a three-column list: the agent decides, a named person decides, the founder decides. Write the actual actions, not categories. “Agent decides: reply to a pricing question from a known customer using the published price list. Named person decides: any discount. Founder decides: any refund above an amount you choose.” A column with an amount in it is a column the agent can obey.

The founder column should be short. Our own fleet keeps five categories off every agent’s list: spending above a fixed threshold, any communication that leaves the company, hiring and firing, changes to the stated plan, and anything that cannot be undone. That list is in the governance post. Everything else sits with an owner or the agent itself.

Response windows are the other half. An agent that hands a case back needs to know how long to wait and what to do when nobody answers. Write two numbers: the normal window (we use one business day) and the urgent window (flagged, same day). Then write what the agent does at the end of each: keep waiting, go to the backup, or drop the case into the weekly brief. Without the third rule, hand-backs pile up silently and the owner finds 40 of them on a Friday.

How do you write acceptance criteria and business rules?

Acceptance criteria state the pass condition on your real data, before the build, in a sentence a non-engineer can check. “Of the last 200 supplier invoices, the agent posts at least 190 to the right ledger account, and flags the rest with a reason” is checkable. “Automates invoice processing accurately” is not. We covered the mechanics in the statement of work post; the point here is that the client writes the first draft, because the client knows what a wrong answer costs.

Business rules are harder, because they are usually not written anywhere. Ask the person who does the job today to write the rules they follow, then ask them for the exceptions: the customer who always gets net-60, the product that is never discounted, the supplier whose invoices arrive in a different format every month. The exceptions matter more than the rules. An agent trained on the rules alone will get the exceptions wrong with confidence, and every one of those becomes a message to a human.

Keep an exceptions log once the agent runs. Each override a human makes is a line in it, and each line is a candidate rule for the next version. That log is the single most useful input to the monthly roadmap, and it costs the human one sentence per override.

How do you write the access map and stop authority?

The access map lists every system the agent touches, the account it uses, what that account can do, and who can revoke it. Most firms cannot produce this. The Cloud Security Alliance surveyed 228 IT and security professionals in January 2026, in a study commissioned by Aembit, and found only 22% apply their access frameworks very consistently to AI agents (Cloud Security Alliance, March 2026).

Asked who owns agent identity, 28% said security, 21% engineering, 19% IT and 9% identity and access teams. No single answer reached a third. When nobody owns access, nobody can answer “what can this agent reach” without a meeting.

The fix is one dedicated account per agent, created in your name, with a named human who can revoke it. One line per system. The same line answers the first question on the handover checklist, so write it once.

Stop authority is one paragraph: who can switch the agent off, the exact switch (a flag, a schedule, a credential), and who is told when it happens. A stop switch nobody is authorised to pull is not a stop switch.

Regulators ask for the same thing in formal language. Article 26 of the EU AI Act requires deployers of high-risk systems to assign human oversight to people with “the necessary competence, training and authority”, and Article 11 requires technical documentation to exist before the system is placed on the market, with a simplified form for small and medium firms (EU AI Act Service Desk, Article 26). The NIST AI Risk Management Framework Playbook puts it plainly in GOVERN 2.1: roles, responsibilities and lines of communication for AI risk are documented (NIST AI RMF Playbook). Most business agents are not high-risk under the Act. The habit is still worth copying.

What does this look like on our own fleet?

On our own group’s fleet, every agent is registered with an owner, a fence it operates inside, and a run log before it runs, and a weekly written health report is the only scheduled reporting. The agent fleet case study gives the dated figures: 41 registered agents and 5,450 runs with zero failures in one 13-day stretch, as of July 2026. Those numbers describe one measured window on our systems, not a guarantee for yours.

The honest part is that we retrofitted most of the eight. The register, the stop conditions and the ownership rules were written after agents were already running, following an internal audit through mid-August 2026 that found a double-publish race from a missing lock and credentials expiring with no advance warning. That is the expensive order. Clients get the list up front because we paid for learning it the other way.

What does it cost?

Writing the eight documents costs the client about a working day, spread across two or three people, before the build starts. Keeping them current is part of what the fractional AI officer retainer covers: $2,900 a month, cancel monthly, one new automation shipped each month, monitoring of everything already running, and a weekly brief that reads in four minutes. The runbook stays current at all times, so if you leave, the documents leave with you. You own the delivered code, data and documentation from day one.

If you only want the build, the eight documents are still the intake. A sprint that starts with them written ships faster, because the builder is not discovering the discount policy in week three.

Start async

Describe your process at /start and paste whichever of the eight you already have, even if it is a half-page. You get a written reply within one business day, no meetings, naming which documents are missing and which ones we would write with you first. Each agent we build is a tomte, our word for one production agent with one defined job, and a tomte with its eight documents written is one your team will rarely need to talk about.