You document an AI loop by answering six questions: what the work is and who owns it, when it starts, how the agent knows it is done, what becomes real when it finishes, what capabilities it can use and the boundaries it must work within.

Those answers form the operating contract between the business and the agent.

They are not the final technical instructions. They are the management clarity required before detailed instructions, permissions and connections can be built.

First, what is an AI loop?

An AI loop is a repeatable piece of work with a clear definition of done, delegated to an AI agent that keeps working and checking until that definition is met.

The agent runs the loop.

A human owns it.

The human may be called when the work reaches an exception, a decision the organisation has not made or a protected boundary. But the human is not meant to complete a routine step every time the loop runs.

If a person has to continually prompt, check and redirect the agent, the work is still on an AI leash. It has not yet become a dependable loop.

Why six questions are enough

When organisations document a process, they tend to start listing steps.

Open this system. Copy that information. Paste it into this template. Send it to this person. Wait for approval.

That made sense when software could only follow a fixed path.

A capable agent can choose a path, use tools, recover from errors and check its own work. It does not need every movement prescribed in advance. It needs to understand the work, the outcome and the boundaries.

The six questions capture those decisions without turning the specification into a 40-page process manual.

1. What is this loop called, and who owns it?

Name the repeated piece of work and the human accountable for its specification.

A useful name describes the whole job:

Meeting to Action
Sales Follow-up
Proposal to Commitment
Customer Onboarding
Weekly Operational Reporting

"Sales AI Assistant" is not a useful loop name.

It names the technology, not the work.

The loop also needs one human owner. That owner does not perform every action or approve every run. They are accountable for what the loop is meant to achieve, the rules it follows and the way its specification changes over time.

A committee cannot own a loop.

A department cannot own a loop.

A shared inbox cannot own a loop.

One person needs enough authority to resolve contradictions and decide what the business has genuinely learned.

Name the work, not the technology. Give the specification one human owner.

2. When does it start?

Define the observable trigger items and whether the loop starts when all or any of them are true.

A trigger can be:

an event, such as a meeting recording finishing;
a state change, such as an opportunity becoming proposal-ready;
a threshold, such as an invoice becoming overdue;
or a schedule, such as the weekly reporting cut-off.

The agent needs to be able to observe it.

"When needed" is not a trigger.

"Regularly" is not a trigger.

"When somebody remembers" is definitely not a trigger.

Some loops require several conditions to be true together. A proposal loop might start when the opportunity is qualified and discovery is complete and the opportunity has been marked proposal-ready.

Other loops start when any one of several approved events occurs. An accounts-receivable loop might start when an invoice enters its reminder window or becomes overdue or is disputed.

Writing the trigger carefully prevents missed work, unsafe starts and duplicate runs.

If the agent cannot observe it, it is not yet a trigger.

3. How does it know it is done?

Write a checklist of conditions the agent can verify.

This is the definition of done.

Each checklist item should describe something that must be true before the agent may finish.

For a sales follow-up loop, that might mean:

the response addresses the customer's actual questions;
every commitment fits approved commercial rules;
the response has been sent;
the CRM is current;
and the next action has an owner and date.

"Draft an email" is not a definition of done. It is an activity.

"Review the CRM" is not a definition of done. It is another activity.

"Make it professional" is not testable unless the organisation has defined what professional means.

The checklist should protect the few conditions that matter, while leaving the agent room to work out how to make them true.

It should cover accuracy, completeness, delivery and required system updates. If evidence is part of correctness, the evidence must also be present and inspectable.

Avoid using routine human approval as the final checklist item. If the same person must approve every run, the organisation has not yet delegated the work.

A checklist protects the few things that must be true. The agent can work out how to make them true.

4. When it is done, what is now real in the world?

Describe the usable business state created, not merely the content generated.

This is different from the definition of done.

The definition of done tells the agent when to stop.

"When done" tells the business what changed.

Complete this sentence:

When this loop finishes, the business now has...

For Meeting to Action, the answer is not "meeting notes".

It might be:

Participants and the system that runs the work share one accurate account of what happens next.

For Weekly Operational Reporting, the answer is not "a report".

It might be:

Leaders have one trustworthy view of performance and a clear set of owned interventions.

A document, email, dashboard or summary may be produced inside the loop. But generating content is not the same as creating a useful business state.

If the output finishes in another chat window, you probably have an AI activity, not yet an organisational loop.

Definition of done tells the agent when to stop. When done tells the business what changed.

5. What does it have available to complete the task?

Identify the tools, agents, resources, templates and sub-loops the lead agent can use.

An agent may be capable of reasoning through the work, but it cannot succeed without the right context and the ability to act.

List:

the systems where the work happens;
authoritative policies and rules;
approved templates and examples;
current customer, employee or operational data;
actions the agent is permitted to perform;
specialist agents it can call;
and reusable sub-loops that already complete part of the job.

Be specific.

"Use company data" tells the agent almost nothing.

"Use the current pricing rules in the commercial policy repository" identifies an authoritative source.

"Update the CRM" is only useful if the agent has access to the right CRM records and permission to change them.

Conflicting resources are particularly dangerous. If three documents contain different pricing rules, giving the agent all three does not create more context. It creates uncertainty.

This field should reveal whether the work is genuinely ready to delegate. If the agent cannot find the truth or use the required tools, better prompting will not fix the problem.

An agent is only as capable as the tools it can use and the truth it can find.

6. What guardrails and limitations must it work within?

Define permissions, operating limits, escalation conditions and hard stops.

A simple way to do this is to separate three behaviours. I've written before about when an agent should act and when it should ask; the third behaviour, stop, completes the set.

Act

The agent should act when the organisation has already made the decision and the situation sits inside agreed rules.

For a sales loop, this might include sending follow-up using approved offers, prices and availability.

Ask

The agent should ask the human owner when it reaches a genuinely new decision or an explicit exception.

That might include a non-standard discount, an unusual promise, a disputed policy interpretation or a relationship-sensitive choice.

Stop

The agent should stop when required context, authority or safety is missing.

It should not guess which customer it is dealing with, invent a price, grant access without an approved role basis or proceed when a protected control cannot be verified.

"Use judgement" is not a guardrail.

"Be sensible" is not a guardrail.

"Ask before doing anything important" usually creates approval addiction and puts the human back inside every run.

Useful boundaries are specific. They cover money, promises, privacy, risk and irreversible actions.

The agent should never have to invent authority.

A complete example in six answers

Consider a fictional 180-person professional-services business that wants to improve what happens after a sales conversation. The situation is a composite of recurring patterns rather than one identifiable client.

Name and owner

Sales Follow-up, owned by the Head of Sales.

Starts when

Any of these is true:

a sales-call transcript enters the CRM;
or a customer enquiry is marked ready for response.

Definition of done

The response addresses the customer's questions.
Commitments match approved offers, pricing and availability.
The response has been sent.
The CRM is current.
The next action has an owner and date.

When done

The prospect has a useful response and the business has a reliable, owned commercial next step.

Available to complete the task

CRM, transcript, prior correspondence, approved offers, pricing rules, delivery availability, response templates and customer-research, pricing-check and CRM-update sub-loops.

Guardrails and limitations

Act: inside approved offers, pricing and availability.
Ask: about non-standard promises, discounts or strategic positioning.
Stop: if the customer, offer or price cannot be verified.

That is enough for business and technical teams to discuss the same piece of work.

It does not prescribe every action the agent will take. It defines what the organisation expects.

I've documented twelve worked examples in this format if you want to see the same six questions applied across meetings, sales, reporting, onboarding, support, finance, hiring, compliance, marketing and product.

The specification should live with the work

A loop specification is not a document created once and filed away.

It is the living, human-owned record of how the loop operates.

When the agent encounters an exception, the owner decides whether it was:

noise that should be ignored;
an experiment worth running;
or durable learning that should change the specification.

The agent may surface evidence and propose a change. It should not quietly turn every result into a new organisational rule.

The specification becomes more useful as the loop runs, but it changes deliberately.

Bottom line

You do not need to learn how to build an agent to design useful work for one. You need to be able to name the work, define its start and finish, describe the business state it creates, give it the capabilities it needs and make its authority explicit. Six questions are enough to begin.

If those six answers are unclear, the technology is not yet the bottleneck.