A master loop owns an end-to-end business outcome. It calls smaller sub-loops to complete repeated specialist work, then keeps checking until the overall definition of done is met.
This is how organisations can scale AI without building one enormous agent that knows everything, accesses everything and tries to do everything.
A business is already made of nested work
Consider customer onboarding.
The outcome sounds like one piece of work: make the customer ready to begin.
In practice it includes:
- validating the commercial start event;
- checking customer identity and compliance information;
- creating records and workspaces;
- configuring a product or service;
- arranging equipment or access;
- scheduling meetings;
- sending communications;
- assigning dependencies;
- and confirming that finance, delivery and the customer share the same context.
You could put all of that inside one enormous instruction set.
Or you could create a Customer Onboarding loop that calls smaller dependable capabilities:
- Identity Check
- Workspace Setup
- Configuration
- Scheduling
- Welcome Communication
- Internal Handoff
The lead agent does not need to perform every specialist action itself.
It needs to know which sub-loop to call, what result to expect and whether the combined work has created the final business state.
What makes a sub-loop different from a step?
A step is an instruction.
A sub-loop is a reusable piece of work with its own trigger, definition of done, capabilities and boundaries. In other words, a sub-loop answers the same six questions as any other loop.
"Update the CRM" is a step.
"Opportunity Record Update" could be a sub-loop that:
- receives an opportunity and approved changes;
- verifies the correct record;
- updates the agreed fields;
- records the source of the change;
- checks that the update is visible;
- and stops if the customer or opportunity cannot be identified.
That sub-loop can be used by Sales Follow-up, Proposal to Commitment, Customer Onboarding and Accounts Receivable.
The organisation specifies it once and improves it wherever it is used.
Why not build one giant agent?
A single all-purpose agent appears simpler at first.
Give it access to the CRM, finance system, email, project platform, policies, customer data and company knowledge. Tell it to handle the work.
The complexity has not disappeared.
It has been hidden inside one difficult-to-understand system.
When something goes wrong, the organisation cannot easily tell whether the problem was:
- the trigger;
- the source data;
- a specialist action;
- a permission;
- a decision boundary;
- or the overall definition of done.
Large agents also tend to accumulate broad permissions and conflicting context. Every new responsibility makes testing and ownership harder.
Small loops create visible boundaries.
Each can be tested, owned and improved. The master loop composes them into a larger result.
The master loop owns the outcome
Sub-loops should not cause the parent loop to lose accountability.
The Customer Onboarding loop may call six other loops, but it still owns the final condition:
The customer and delivery business are ready to begin value-producing work without repeating information.
The lead agent keeps checking whether that condition is true.
If Workspace Setup succeeds but the customer does not know what happens next, onboarding is not done.
If the welcome message is sent but delivery lacks the commercial context, onboarding is not done.
If five sub-loops complete and one reaches an exception, the master loop decides whether it can continue, ask the owner or stop.
Completion of the parts is not automatically completion of the whole.
The handoff should be a business state
Weak automations pass content between systems.
One agent generates a summary. Another receives the text. A third converts it into tasks.
Strong loops pass a defined state.
For example:
- the opportunity is qualified;
- the pricing check is complete;
- delivery capacity is confirmed;
- the customer identity is verified;
- the decision is recorded;
- the exception has an owner.
The next loop can depend on that state because it knows what has been verified, by which specification and from which sources.
This is more dependable than asking another agent to reinterpret a document and hope it reaches the same conclusion.
A practical example: proposal to delivery
Imagine a fictional 260-person professional-services company. The situation is a composite of recurring patterns rather than one identifiable client.
Its end-to-end commercial system might contain:
Lead Qualification
Determines whether there is an opportunity worth pursuing and records the evidence.
Sales Discovery
Creates a reliable account of the customer's need, constraints, stakeholders and desired outcome.
Pricing Check
Applies approved pricing and margin rules, escalating genuine exceptions.
Delivery Feasibility
Confirms whether the proposed scope, timing and capabilities are realistic.
Legal Terms Review
Checks standard terms and routes deviations to the person authorised to accept them.
Proposal to Commitment
Calls the other loops, assembles the proposal, sends it, updates the commercial record and creates an owned next step.
Customer Onboarding
Starts only when an approved commercial start state becomes real.
Each loop has a named owner.
Each can improve independently.
The organisation can change its pricing rules without rewriting customer onboarding. It can improve legal review without redesigning discovery. It can reuse identity checks in support, finance and onboarding.
Humans own specifications, not routine handoffs
Nested loops do not remove human accountability.
They make it more precise.
The commercial owner is accountable for Proposal to Commitment.
The finance owner is accountable for Pricing Check.
The delivery owner is accountable for Delivery Feasibility.
The people do not need to approve every routine run. They own the rules, exceptions and durable changes within their area.
When a master loop reaches a genuinely new decision, it should route the decision to the correct owner with a useful brief.
It should not send everything to one senior manager "just in case".
Start small and earn the architecture
Do not begin by drawing the complete map of every future agent and loop in the organisation.
Start with one valuable loop.
As it runs, identify work inside it that is:
- repeated;
- specialist;
- useful elsewhere;
- independently testable;
- and capable of having a clear owner.
That work is a candidate sub-loop.
Build the reusable capability when there is evidence that reuse is real.
Over time the organisation develops a library of dependable loops. New master loops can call existing capabilities rather than rebuilding them.
The architecture emerges from useful work.
Keep the specification technology-agnostic
A loop may begin in ChatGPT, Claude, Microsoft Copilot, a CRM, a coding environment or a shared cloud service.
The platform can change.
The business specification should remain understandable.
"When a qualified opportunity has complete discovery, create a deliverable commercial commitment" is a durable description of work.
"Run workflow 18 in vendor platform X" is not.
Keep the name, trigger, definition of done, business state, capabilities and guardrails separate from the current implementation.
That gives the organisation room to replace models and platforms without rediscovering what the work is for. A library of living loop specifications is one practical unit of a spec-driven organisation.
Bottom line
AI at scale does not require one super-agent. It requires small, dependable pieces of delegated work that can be connected without losing sight of the business outcome.
Sub-loops make specialist work reusable.
Master loops compose those capabilities and remain accountable for what becomes real.
Start with one useful loop. Let repeated work reveal the reusable parts. Build an operating system from evidence, not an architecture diagram from imagination.
