Funnels execute. Loops remember.

We are told AI transformation is an execution problem: put tools into workflows, train people, measure adoption. The harder problem is whether execution actually teaches the organisation anything.

In 2001, Jeff Bezos sketched a loop on a napkin. Lower prices improved the customer experience. Better customer experience increased traffic. More traffic attracted sellers. More sellers expanded selection. Greater selection improved the customer experience again, which created still more traffic. Each output became the input to the next cycle.

Amazon was not merely trying to out-execute its competitors. It was designing itself so that running the business made the business better at running.

That is the distinction most AI programmes still miss. They improve the rate of work but leave the architecture of learning untouched. A customer complaint is resolved. A sales call is lost. A product feature is shipped. A finance team revises a forecast. Work enters, work is processed, work exits. The ticket closes. The call note sits in a CRM field nobody trusts. The decision is remembered by the people in the room, until it is not.

That is a funnel. It may be digitised. It may be automated. It still resets.

A loop works differently. It does not treat the completed task as the end of the process. The complaint changes the support playbook. The lost deal sharpens qualification. The shipped feature updates what the product team knows about customer behaviour. The forecast miss improves the next forecast. The organisation does not merely complete work. It turns work into memory, and memory into better action.

The difference is not philosophical. It is mechanical. A loop needs memory, capture, retrieval and frequency. Miss one, and the organisation falls back into the funnel.

The sequence starts with memory, not as an archive but as a working asset. A strategy deck buried in a shared drive is not organisational memory. Nor is a Slack thread, a meeting anecdote, or the private judgement of a manager who has seen the problem before. Useful memory is structured enough to travel beyond the person who created it and fresh enough to guide the next decision.

Memory then depends on capture. This is where the old knowledge-management bargain breaks down. It asks people to complete the work, then pause, reflect, document, tag and contribute what they learned. Under pressure, that final step disappears. That is not laziness. It is bad design. The organisation has made learning a second job.

Capture has to work like exhaust. An engine does not decide to produce exhaust after combustion. Exhaust is a byproduct of the engine running. Work should have the same relationship to learning. When a support agent corrects an AI answer, the correction should not trigger a separate knowledge ritual. It should update the relevant answer, flag the failed retrieval, and improve the review queue because the correction happened. The contribution should be inseparable from the work.

Capture alone creates storage, not learning. So the next problem is retrieval. The post-mortem may exist, but the next project never sees it. The customer objection may be logged, but the pricing discussion never uses it. The product exception may be known by support, but invisible to engineering. A loop compounds only when the right context reaches the right person at the moment of decision.

This is where AI can help, provided it is aimed at the right problem. The prize is not a larger archive. It is timely retrieval: surfacing the relevant exception, decision, customer signal or prior mistake when someone is about to act. Data changes outcomes only when it arrives in time to change a decision.

The last condition is frequency. Two teams can have the same memory and the same retrieval tools, yet compound at different rates. One reviews customer signals at the end of the month. The other sees them during each design decision. After a year, the second team has not merely worked faster. It has made dozens of small corrections the first team never knew to make. Compounding depends on how often the loop turns, not just how well it is designed.

The practical test is simple. Look at any workflow and ask what happens after the work is done. If the output is delivered and the learning stays trapped in individuals, the workflow is a funnel. If the output leaves a trace, the trace is retrieved, and the next decision changes because of it, the workflow is becoming a loop.

The distinction shows up in small details. In a funnel, a customer escalation is solved by whoever knows the workaround. In a loop, the escalation updates the routing rule, the help content and the product backlog. In a funnel, a missed forecast becomes a tense review. In a loop, the miss is attached to the assumptions that produced it, so the next forecast is better calibrated. In a funnel, an AI error is corrected and forgotten. In a loop, the correction changes the next answer.

This brings the Amazon loop back from the napkin to the ordinary surfaces of work. Another example is Airtable. Competitive analysis against a major enterprise-work-management competitor had traditionally taken weeks. To address this, Airtable synced more than 2,900 Gong call recordings that mentioned the competing product, created AI agents to act as competitive-intelligence analysts, and produced SWOT analysis, customer quotes, and a live dashboard of win, loss and at-risk accounts in no more than two hours.

The tempting conclusion is that the report became faster. That is true, but it is the smaller point. The larger point is that detailed insights from sales conversations, which normally decay into scattered notes and private anecdotes, suddenly became a reusable market signal. The output of one selling cycle became an input to the next product, pricing and go-to-market decision.

That is the loop Bezos drew, tightly integrating company strategy into daily work via compounding organisational design. Amazon showed the pattern at company scale: each cycle strengthens the next. Airtable shows the same pattern inside a workflow: each call can improve the next decision if the organisation captures, retrieves and uses what the call revealed.

That is the loop Bezos drew, tightly integrating company strategy into daily work via compounding organisational design.

The Bezos napkin was not a growth strategy. It was an answer to a different question: if we run this business well, what does running it well make easier? Most organisations do not ask that question. They are designed to execute, then reset.

The question is not where AI can make execution faster. It is whether, a year from now, the organisation will know more, decide better, and recover more quickly from its mistakes than it does today. If the answer is uncertain, find where the learning currently escapes. That is where the design work begins.