This essay merges two posts I originally published on the Aicoo blog on 9 July 2026: The Loop Is the New Prompt. The Network Is the New Loop. and The Self-Improving Company Is Distributed.
On 7 July 2026, the Claude Code team published a short piece called "Getting started with loops." It crossed a million views in a day because it named a shift many of us had already felt: you don't prompt the agent anymore. You design the loop that prompts the agent.
A prompt is a single request. A loop is a standing commitment: gather context, act, verify, correct, repeat, until a stop condition is met.
The loop is the new prompt. The network is the new loop.
The loop is the new prompt
Boris Cherny put it bluntly: "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."
You stop writing requests and start writing the machine that issues them: /loop on an interval, /goal that runs until a separate model verifies your condition, proactive loops that fire on a schedule with no human in the moment.
The sharpest line in the discussion is about how loops end: the verifier is the whole game. Close every loop on a check the agent can't fake, cap it with a turn limit and a budget, and walk away.
It is a real unlock. It also has a ceiling that nobody is really naming.
The wall every loop hits
A loop makes an agent autonomous over time, not over what it knows. Its stop conditions are all internal: the tests pass, the file compiles, the model thinks it's done.
Most real work doesn't stall because the agent failed. It stalls because it is waiting on someone else: a deprecation policy only the platform team knows, a number in someone's head, an approval that isn't yours to give.
So a solo loop has three bad options: retry (wasteful), guess (dangerous), or halt and ping a human, which makes you the bottleneck again, the very thing loops were supposed to remove. "Waiting on Alice" collapses back into "stop everything and interrupt Alice."
A loop's reach ends at the limit of one person's knowledge.
The network is the new loop
At Aicoo we made every person a permissioned, callable agent. So mid-execution, a loop can message another person's agent:
POST /v1/agent/message { to: "alice_coo", message: "..." }That runs Alice's agent against her permitted context and returns an answer in seconds. "Waiting on Alice" now means "ask Alice's agent and keep going." The loop's boundary is no longer your knowledge. It is your network's.
The human isn't gone. The human is the fallback. If Alice's agent can't answer, or the decision is genuinely hers, the same infrastructure escalates to Alice herself. The resolved answer is accumulated back into context, so next time the loop already knows. Coordination continues, agent to agent, and gets cheaper every cycle.
Take a nightly migration loop that hits a question only the platform lead's context can answer: what is our deprecation window for the v1 tokens? A solo loop halts until morning, or guesses and ships something wrong. A networked loop asks the platform lead's agent, gets the policy from their permitted context, and finishes overnight. A human is touched only if that agent itself escalates.
That is the difference between a loop that waits on people and a loop that coordinates with their agents. The first is a fancy script. The second is an organisation that keeps running while everyone sleeps.
We run Aicoo on this ourselves. A hook fires on a market signal, say signups spiking from one channel or the same request surfacing across a dozen support threads, and wakes a growth agent. Instead of summarising it for a human to triage, the agent asks the code agent ("users from channel X keep asking for Y; is Y feasible against the current schema?"), which answers from the actual codebase: yes, small change. The backend agent scopes the endpoint. Each agent answers from its own context and the loop keeps moving. A human steps in once, for the call that is genuinely a judgment: ship it this week? A loop fired on its own, reached other agents for what it could not know alone, and carried a market signal most of the way to a shipped change before anyone was interrupted.
It isn't only us. Relay, the first-place team at our hackathon, built entirely on Aicoo as four parallel Claude Code sessions (orchestrator, frontend, backend, research), each reaching the others' context through Aicoo and escalating to a human only for judgment calls. Their product's thesis, that an agent answers from context and a human is the fallback, was also how they built it. Loops coordinating with loops.
The company as a set of loops
If a loop can call other people's agents, the company itself starts to look like a set of loops. Tom Blomfield made that case in a talk at YC, the clearest version I have seen: stop bolting an AI copilot onto a Roman-legion org chart, record everything, make the organisation legible, and run the company as self-improving loops that get better while you sleep.
He is right, and we have spent the last year building exactly this substrate. I would add two things. Not disagreements: they decide whether the architecture holds up past one team, and they are where my bet differs from a central company brain.
Company memory is distributed, not central
Blomfield's legibility is centralising: every email, DM and office hour goes into one living company brain. It is the intuitive move, and for a lot of it, it is fine. But it loses the most valuable part, because a company's memory was never one store. It is two things:
- Personal memory: what each person or agent knows, under their own permissions.
- Relationship memory: what A has learned to expect from B, the running thread of a hundred small exchanges. It is in neither head alone. It lives on the edge.
Company memory is personal memory on the nodes plus relationship memory on the edges. A central brain records the nodes and flattens the edges. Keeping each where it lives matters for three reasons.
Permission becomes native. Pour everyone's context into one store and you inherit the hardest problem in the building: who can see what. Every self-improving loop that reads the central brain is one bug away from a leak. With distributed memory, each node keeps its own boundary. You query it; you don't ingest it. The permission lives where the memory lives, which is the same premise as the network loop above: you ask someone's agent and never touch their raw context.
Coordination compounds on the edge. Quick questions get cheaper not because a central store memorised the answer, but because the edge got better: the growth agent learned how to ask the code agent and what it tends to know. That is a relationship, not a fact, and a central brain can't hold it. Improve the nodes and each agent gets smarter; improve the edges and the whole network gets better at using what it already knows.
One primitive, inside and across company walls. It is the same structure at 5 people or 500 companies. The edge between my agent and a partner company's agent is the same primitive as the edge between two of my internal agents. The self-improving company and the self-improving network are one architecture.
So yes, record everything, but into the right place: the person, or the edge between two people. Legibility is not centralisation. The living brain is emergent, not stored.
The loops that matter are multi-agent
Most loops, Blomfield's and, honestly, those in my own earlier writing, are drawn as single-agent. Even his best example, a monitoring agent that rewrites a failing query's tooling overnight, lives inside one codebase.
The growth, code and backend chain above was easy because we own all three agents. The frontier is the same chain when each agent belongs to someone else: my growth agent asks your code agent, which asks their backend agent. The moment a loop crosses an ownership boundary, three things that were trivial inside one agent become hard, and genuinely interesting.
Policy composition. A single-agent loop has one policy layer. A multi-agent loop has one per agent, and they have to compose. When my loop asks yours, both govern: your agent answers under your boundary (what it may reveal), and my loop acts under mine (what I may do with the answer). The design problem is not a central rulebook; it is policy composition, defined per relationship. That is why our permissions belong to the grantor-to-grantee edge, not a global setting.
Trust. A multi-agent loop has to decide how far to trust another agent's answer. Is it grounded or guessed? How confident did it signal? Has this agent been reliable on this topic before? That last one matters most: trust is learned on the edge, which is to say trust is relationship memory doing its job. The verifier is still the whole game, but now it is also a trust judgment about another agent, and it compounds every time that edge is used. Trust is the currency of multi-agent loops; relationship memory is how you earn and spend it.
Coordination efficiency. Multi-agent loops are where tokens get burned stupidly: agents ping-ponging, re-asking settled questions, everyone querying everyone, cold starts stacking latency. So you accumulate answers, ask the best-ranked agent first instead of broadcasting, go async so a loop does not block on a cold agent, and, most importantly, know when to stop and hand a human the decision instead of looping forever. Blomfield says "burn tokens, not headcount." The constraint goes one step further: headcount, then tokens, then coordination efficiency.
The two additions are one idea
Relationship memory on the edge is what makes multi-agent loops work.
Policy composes better, trust accrues and efficiency improves, all as a function of how much history two agents share. A self-improving company doesn't improve only because each node gets smarter. It improves because each edge gets more aligned, more trusted and more efficient every time it is used.
That is the version of "improve while you sleep" we are building toward. Not one brain in the middle getting fatter, but a network whose nodes keep their own memory behind their own permissions, whose edges accumulate the trust, policy and shorthand that make coordination cheap, and whose loops cross ownership boundaries without a human relaying every message.
Loop engineering made agents autonomous over time. A network makes them autonomous together.
The loop is the new prompt. The network is the new loop. And the network's memory, the part that actually compounds, lives on its edges.