AI Loops: How to Scale AI Across Teams and Departments to Drive Organisation-Wide AI Adoption

Ben: Thanks for giving me your lunch hour. As always, I've tried to pack this with as much value as possible. If you've got a question or a thought, jump in — don't wait for the end. Everyone on this call has something to add on this topic.

The topic today is something I've been working on more and more with organisations: how to scale AI beyond the enthusiastic individual. Organisations are full of enthusiastic individuals — people who will spend their own time getting to the bottom of how something works. But when you start trying to roll that out within a business, two things happen. One: two enthusiastic individuals end up driving in two different directions, so we need a way to align those efforts so everything everyone does is additive, not fighting each other. Two: we need to roll AI out in a way that all the people who aren't excited about it — which is fair, not everyone should have to stay up at night figuring this out just to do their job in accounts or HR — can get the benefit too.

The best way I've found to do that is by building AI loops. "Loops" is a relatively new term. It's come out of the hardcore engineering world, but when I saw it pop up I thought: that puts a label on something we've been rolling out through transformation work in organisations for years. This is the thing leaders actually need to learn.

The individual–organisation gap

When you roll AI out in a business, individuals anecdotally feel it dramatically increases their productivity. Around 65% of people in organisations rolling out AI report that it increases their personal productivity. But measure it at an organisational level and it mostly disappears — only about 14% of that cohort say it improves the organisation. Whether the business has three people or a thousand, that pattern shows up.

People experience this in one of three ways. Either AI feels like a money pit — you put money in and don't see much come out. Or, where most people are, it's a grind — you do a little, you get a little, and the cost or time takes it back. Or you're seeing people on LinkedIn talking about outsized productivity improvements and wondering how they got there. That place is real, but it exists for individuals first. Rolling it out across a business is the second, harder step.

The reason AI works for us individually but doesn't translate into organisational productivity is bottlenecks. If you roll out AI in marketing and get three times the output — three times the ads, the posts, the campaigns — all of that work flows into sales, legal, delivery and ops. If those functions aren't using AI effectively, the productivity gains are simply absorbed, and you create tension between parts of the business. You need to unlock AI capability across functions. Once you line the departments up, the exponential improvements are real — but they're hidden until you optimise the system rather than one individual role.

Which means this is coming less to the technical people and more to the leadership of the business: orchestrating adoption is now a leadership problem.

Pick a real bottleneck

Let's make this practical. Think about a workflow in your business right now that you would love to hand over to a capable AI assistant. It could be big or small. The key is to pick something that's an actual bottleneck. People spend a lot of time automating things because they look easy to automate — but what you want to automate is a real constraint, so you get the return right away.

Attendee: Two come to mind. Organising meetings — finding time in everyone's diaries and coordinating it. It feels like something I shouldn't have to do, and I spend a huge amount of time on it. And running large workshops with, say, 100 people: splitting them into groups, making sure the right leaders and the right skills are in each group — hours of effort, hugely stressful, especially when the CEO decides at the last minute they want to join a group.

Ben: Two very good potential loops. They can be devilishly difficult to fix with plain automation because there's a lot of knowledge inherent in them — who needs to be in which group, whether you're optimising a meeting for "as early as possible" or something else. There's nuance you need to capture, and it's very possible to capture it, but you have to do it the right way.

Attendee: Mine is the number of very similar meetings you run to disseminate information, get alignment, and get endorsement on approaches or priorities. You go through all these roundabout sessions with different stakeholders in different departments, then you get to the end and someone says "that's not what I said," or they've changed their mind, or the politics have shifted. The sessions are short but it adds up to weeks.

Ben: And not having everyone's app in every meeting doesn't solve it, because we all end up with our own definitions of the tasks, notes and summaries. Everyone has their own little bank of context and none of it talks to each other. That's a great one.

Attendee: Mine is documentation. Working through a critical client flow: the meeting happens, then extracting the transcript, organising it into our system hub, taking it from there into a sheet, and from there into ClickUp. Everything's set up, but I have to do that manually for each one.

Ben: That's exactly the pattern we'll talk about shortly — you have these powerful tools, and then you end up being the person copying and pasting between them. It does something almost magical, and then you have to sit there feeding it. You're not actually getting the productivity because you're still the connective tissue.

Attendee: One more: refactoring code. We produce a lot of things, but harmonising and unifying it always gets left for later.

Ben: That's probably the most sophisticated loop I personally run. And it's a good example of doing it the right way — you want the AI generating the code, checking the code, and refining the code, otherwise it all becomes mess.

Why loops, and why now

For a long time this stuff was stuck in the heads of technical people — these practices came up from software development. But as with any organisational rollout, the technical people shouldn't lead it; they should enable it. Loops are the first framing I've seen that lets leaders document what they need — without knowing what a "workflow" or an "agent" is technically — in a way technical people can directly build from. It stops the two groups talking past each other.

Why now? Because technology is no longer the bottleneck. If OpenAI and Anthropic didn't release a single new thing for the next eighteen months, most organisations still couldn't exhaust what's already available. That's why adoption is the frontier.

And why us? I run BusyWork Dispatch — we help leaders drive AI adoption at scale from the bottom up. We integrate with whatever your teams already use every day — ChatGPT, Copilot, Claude — and people ask for what they need in plain language: "we keep manually copying things between platforms", "I want an agent that does X", "can you update this vibe-coded internal tool". The request gets packaged with context and sent to a senior developer who understands the platforms, security and licensing. They estimate it, and once approved it's built in roughly 48 hours to five days.

That gives us an interesting dataset of what actually drives adoption. Two things stand out. First, around 60% of the requests we get cost under $200 to build, and the next 20% are under $1,000 — so about 80% of the AI tooling people actually use is small and cheap, even with senior developers building it. That runs against how procurement works in most organisations. You want people to be able to ask for a small update and get unblocked, not write a big use-case document that gets built slowly. Second, if something ships back within five days, it's about three times more likely to be adopted than anything that takes longer. If you've ever redesigned a process on sticky notes and then heard nothing for three months — that thing never gets adopted. The context is gone and three other initiatives have started. Loops are easy to document and quick to build, which is exactly why they survive contact with a real organisation.

Breaking the AI leash

There's a pattern I call the AI leash: you ask a chatbot to do something and it works for an inconvenient amount of time — ninety seconds is enough to lose your context, pick up your phone, start another task. You're leashed to the tool, feeding it.

Attendee: Question on that. I've been using a coding agent at home and asked it to stop checking in with me every five seconds. It said yes — but it might run in the wrong direction. My assumption is: if the intent and specification are right, it gets the right outcome, but maybe by a roundabout route that burns more tokens. So unleashing costs more in tokens but saves my time. Do you have a view on what the increased cost looks like?

Ben: Everything you said is correct — this is a more expensive way to use AI, and, put another way, it's a good way to get your money's worth from a flat-rate subscription. But there are two things that reduce token waste rather than token spend. One: a very clear definition of done — make sure it knows what good looks like. Two: make sure it has access to the tools it needs to do the job. When those two things are true, it works pretty directly. When they're not, it tries its hardest anyway — it's eager to please — and that's where the money goes.

The reason this matters: AI's ability to work over longer time frames is climbing fast. Early models could work for about 36 seconds before falling over. Frontier models, on the right task, can now work for something like 16 hours and succeed half the time. People are getting agents to work for multiple days, particularly in coding. That's where you want to get to — a delegate who does things without bothering you, and whom you trust not to muck it up. So when you look at the workflow you picked: it needs to be a bottleneck, and it needs to be meaningful. "Answer an email" doesn't need 16 hours. Start stretching what you think you can ask for.

What an AI loop actually is

As simply as I can put it: a loop is a repeatable piece of work with a very clear definition of done, delegated to an agent that keeps working and checking until those conditions are met. It also has a trigger. The trigger can be you asking for it, or it can be an event — every time code is committed, an agent checks and cleans it up; every time a customer hits a bug, a ticket is raised and investigated automatically.

And — this always gets skipped — a loop needs a human who is accountable for the result. If the head of sales creates a proposal loop, they need to be comfortable that the agent will do a good job, because if it doesn't, someone will be asking them why. They need to be tightly integrated into how it's controlled and refined over time.

The simplest mental model is a thermostat. You set the target temperature; it keeps checking whether the room is at that temperature; it has the tools to do something about it — turn the heater on and off. And note: if the thermostat wasn't connected to the heater but charged you a dollar every time it tried, it would burn a lot of money getting increasingly irritated. That's the "give it the tools" point again.

Or think of it this way: everyday chatbot use is a food processor — "make this thing smaller", done, and then you carry the pieces to the next step. A loop is a system that knows there needs to be a cake at the end and knows how to use everything in the kitchen to get there.

Triggers and definitions of done

Attendee: When you say an observable trigger — would "a decision needs to be made" count? That's usually when I have to corral people and find time in calendars.

Ben: There's something interesting in that. Most organisations have no reliable way of recording when decisions need to be made.

Attendee: From one meeting to the next you'd know, from the AI notes. One meeting could be the trigger for the next meetings that need to happen — with a human validating: "from this meeting I've identified three decisions that need to be made — confirm?"

Ben: Right — and if you kept a running list of decisions, there are probably two triggers: one when a new decision is added (check it's understood, who needs to be involved), and one at the end of every meeting — did we just answer one of the fifty open decisions, or break one we made four weeks ago?

Attendee: Building on that, for product development the decisions sit inside a system: objective → problem → solution → launch, with legal, security, architecture, marketing all doing their part. Some decisions have ingredients — maybe security and architecture need to provide input before legal makes the final call. If the organisation works in one workflow system, those become automatic triggers: "I think a meeting needs to occur now."

Ben: Exactly — and the difference between a systems-level loop and a rigid automated workflow is that you stipulate the rules as a definition of done: "legal signs off after architecture", whatever they are. Then instead of a fixed set of meetings every time, the loop just keeps rebooking the meeting until someone makes the decision. It stays flexible, because in reality everything is always a little different from everything else.

One more thing: loops are technology-agnostic. The same loop can run in ChatGPT, Claude or Copilot — mine run in whichever tool I have the most credits on that month. Don't build your capability inside one vendor; as the market consolidates and prices move, "great at ChatGPT, terrible at everything else" is a trap.

The six questions

Here's how to document a loop. Looking at all six at once makes it feel more complicated than it is — day to day you're rarely writing every field in detail — but this is the anatomy. The amount of detail should match the stakes: a loop that runs daily and saves hundreds of hours deserves more specification than something small that runs twice a year.

1. What is this loop called, and who owns it? The name matters more than people think — if you want other people (and other agents) to trigger this loop, the name carries the context of what it's for. And it needs a human owner who is accountable.
2. When does it start? The triggers — which can combine: this kind of meeting, with these people, about this topic.
3. How does it know it is done? The definition of done it keeps checking against.
4. When it is done, what is now real in the world? Not strictly necessary, but very helpful: the outcome you're optimising for. A meeting loop's definition of done might be "actions ticked off in the project tool", but the when done is "people feel aligned and bought in". Fluffy — but it changes what the loop optimises for, and it stops it from becoming something that runs without thinking.
5. What tools, agents, resources, templates and sub-loops does it have available? If you're hitting usage caps constantly, it's usually because you asked for something without giving it the resources to do the job efficiently — it tried its hardest, and that costs. Templates, examples, platform access: anything that helps it do the job well.
6. What are the guardrails and limitations it needs to work within? The eat-your-vegetables question — the one you skip when it's just you, and can't skip when you're giving this to a broader organisation.

Document those six answers in a simple markdown or Word document. Often, giving that document to Claude or ChatGPT as a prompt and asking it to set the loop up is enough to get it working.

Attendee: With guardrails, sometimes you don't know what you don't know — especially consulting into someone else's business. How do you define them then?

Ben: Start by asking: what's the cost of this being wrong? If the cost is high — say it's creating and sending proposals — start restricted: it can't send the email, it checks two or three times, and you loosen the restrictions as it earns trust. If the cost of being wrong is low, it's often easier to give it few guardrails, let it run, and add a guardrail every time you notice a way it fails. The trap is over-defining: half the things you'd write down it would have figured out anyway, and as models get smarter your restrictions start fighting them. Keep guardrails limited, tasteful, and proportionate to the downside.

Attendee: Playing it safe at the beginning. Thanks.

Worked examples and failure modes

The biggest barrier we run into: organisational data is stored in applications but not attached to meaning. Take running a project — specific information about that project is locked in every person's email, in SMS, and — the most common blocker — in someone's head. "We can't automate this, not because AI can't do it, but because it's all in George's head, and George is leashed to answering questions for the rest of his life." A new version of this: people's best thinking is trapped in their private ChatGPT and Claude conversation histories — really smart documents and reasoning that just gets lost down the left-hand sidebar. Getting data out of those silos and organised is the hardest part of building loops, so agents don't have to hop from thing to thing to piece the story together.

Meeting to accountable action. Trigger: the transcript lands when the meeting ends. Definition of done: every action has an owner and a date, decisions are recorded, the follow-up is sent. The unlock is having one AI transcriber per team or business, so everyone ends up with the same actions, owners and dates. Otherwise everyone has their own version of reality and nothing happens.

Sales fan fiction. It's very easy to get AI to write a proposal, and very easy to get a proposal the customer will buy. The problem arrives at delivery, when you have to execute it profitably. Teams using their personal chatbot to generate proposal PDFs end up with commitments where you think: did we promise that? Who put that in? A proposal loop's definition of done has to reference what you actually offer, at what price, and escalate discounts and variations to the right person — not let one owner say yes-yes-yes to close the sale without looping in the rest of the organisation.

Process karaoke. Organisations with strong standard operating procedures try to hand the agent the SOP: "do these steps in order, like the person did." The agent performs the process — goes through the motions convincingly — with no check at the end. You get terrible results that look procedurally correct. It's much better to give the agent the ability to check its own work against criteria than to march it through steps.

Approval addiction. How many approvals is too many? You're balancing "I want this to be safe" against "I don't want it asking me questions all day." If you need to check every single thing it does, there's no point having it run — that's micromanagement of software. And if a process genuinely needs that many approvals, it's usually because it's a bad process and nobody trusts anybody; fix the process rather than baking the dysfunction into the agent.

Rolling it out

Get practice writing loops for parts of the business — and go slow to go fast. Fast is messy; slow is smooth. If you skip bringing people along, you'll come back in a few months and nobody will have any idea what you were trying to do.

And choose the right things. The temptation is to start in a low-risk, non-aligned corner of the business and automate something there. But nobody cares about that corner for a reason — you get no adoption, and the money is wasted. That's where proofs-of-concept go to die. It feels riskier to pick the thing tied to a real business goal, with real heat on it, but the technology is ready for prime time, and solving real problems is how adoption actually happens. Loops help here because instead of "let's design an agent" — an inherently technical conversation — you sit business people around the six questions, have sales and delivery argue out what a good proposal actually is, put it into production, and learn quickly.

Attendee: Coming from a systems perspective — we have SOPs. Once you create the loop, do you fold it back into the SOP?

Ben: I'd think of it as SOPs for people, loops for agents — documented differently for their intended audience. People being trained want steps to replicate; agents want a definition of done and the tools to reach it. Keep the manual SOP and the loop side by side in your system, and keep both current as things change.

Attendee: So the SOP is the manual way and the loop sits above it. Great, thanks.

Ben: Thank you everyone for your time — I really appreciate you giving me the hour. I'm happy to stick around for questions, and I'll send out the notes and documents so you can work through them.