Tom Blomfield gave a talk at YC that's the clearest articulation I've seen of where this is going: stop treating AI as a copilot bolted onto a Roman-legion org chart, and start treating your company as a set of recursive, self-improving loops (sensor, policy, tool, quality gate, learning) that get better while you sleep. Record everything, make the org legible, keep humans at the edge for the high-stakes moments. He's right, and we've spent the last year building exactly this substrate.
Two things we'd add. Not disagreements; they're the parts that decide whether the architecture holds up as it scales past one team, and they're where our bet differs from "one central company brain."
Add 1: The company brain is distributed, not central
Blomfield's version of legibility is centralizing: every email, DM, and office hour into the company database, diarized into one living brain. It's the intuitive move, and for a lot of it, it's fine. But it quietly loses the most valuable part, because a company's real memory was never one store. It's two things:
- Personal memory: what each person (each agent) knows, in their own context, under their own permissions.
- Relationship memory: what lives between two people, the accumulated history of A and B working together. What A has learned to expect from B, the shared context of that specific edge, the running thread of a hundred small exchanges. This is in neither head alone. It lives on the edge.
So the real equation is: company memory = the sum of personal memory across the nodes, plus the sum of relationship memory across the edges. A central brain records the nodes and flattens the edges, and the edges are the part you can't afford to lose, for three reasons.
Permission becomes native instead of bolted on. The moment you pour everyone's context into one store, you inherit the hardest problem in the building: who's allowed to see what. Every self-improving loop that reads the central brain is one bug away from a leak. Distributed personal memory sidesteps the whole thing: each node keeps its own boundary, and you query it, you don't ingest it. The permission lives where the memory lives. This is the entire premise of what we build: every person is a permissioned, callable agent, so you ask their agent and never touch their raw context.
Relationship memory is where coordination actually compounds. The reason "quick questions" get cheaper over time isn't that some central store memorized the answer. It's that the edge got better: the growth agent learned how to ask the code agent, what it tends to know, what to include, how to phrase it so it lands. That's relationship memory, and it's irreducibly two-sided. A central brain can't hold it, because it isn't a fact, it's a relationship. Improve the nodes and each agent gets smarter; improve the edges and the whole network gets better at using what it already knows.
It's the same structure at 5 people or 500 companies. A central brain is a single point that stops at the company wall. Distributed personal plus relationship memory has no wall: the relationship memory between my agent and a partner company's agent is the exact same primitive as the one between two of my internal agents. The self-improving company and the self-improving network are one architecture; the second just doesn't stop at the edge of the building.
So we'd amend Blomfield's rule. Yes, record everything. But don't record it into one place; record it into the right place: the person, or the edge between two people. Legibility is not centralization. The living brain is emergent, not stored.
Add 2: The loops that matter are multi-agent
Blomfield's loops (and, honestly, my own earlier writing) are mostly drawn as single-agent loops: one agent, one sensor, policy, tool, gate, learning cycle. Even his best example, the monitoring agent that rewrites a failing query's tooling overnight, is tightly coupled inside one codebase.
The frontier is the multi-agent loop: a loop that spans several independently-owned agents. My growth agent asks your code agent, which asks their backend agent. The instant the loop crosses an ownership boundary, three things that were trivial inside one agent become hard, and genuinely interesting.
Policy interaction. A single-agent loop has one policy layer: one set of rules about what it can do and when it must ask a human. A multi-agent loop has one policy per agent, and they have to compose. When my loop asks yours, whose rules govern? Both: your agent answers under your boundary (what it may reveal), and my loop acts under mine (what I may do with the answer). Policies meet at the edge and negotiate. The design problem isn't a central rulebook; it's policy composition, defined per relationship. Which is why, in our system, permissions are a property of the grantor-to-grantee edge, not a global setting.
Trust. A single-agent loop trusts its own outputs, or its own verifier. A multi-agent loop has to decide how much 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 question is the important one: trust is learned on the edge, which is to say trust is relationship memory doing its job. "The verifier is the whole game" gets a network twist here: the verifier isn't only a test you run, it's a trust judgment about another agent, and it compounds every time that edge is exercised. Trust is the currency of multi-agent loops, and relationship memory is how you earn and spend it.
Efficiency. A single-agent loop is bounded by one agent's tokens. A multi-agent loop can detonate: agents ping-ponging, re-asking what's already settled, N agents all querying each other, cold starts stacking latency. Blomfield says "burn tokens, not headcount," and he's right that the constraint is moving, but multi-agent loops are exactly where tokens get burned stupidly if you don't design for it. So they need efficiency built in: accumulate so you never re-ask a settled question, rank the agents so you ask the best one first instead of broadcasting, go async so a loop doesn't block on a cold agent, and, most importantly, know when to stop and hand a human the decision instead of looping forever. The constraint doesn't end at headcount, then tokens. It goes one more step: tokens, then coordination efficiency.
The two adds are actually one idea
Put them together and they collapse into a single point: 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 have on their shared edge. The self-improving company Blomfield described doesn't improve only because each agent (each node) gets smarter. It improves because each relationship, each edge, gets more aligned, more trusted, and more efficient every time it's used.
That's the version of "improve while you sleep" we're building toward. Not one brain in the middle getting fatter, but a network whose nodes hold their own memory behind their own permissions, whose edges accumulate the trust and policy and shorthand that make coordination cheap, and whose loops cross ownership boundaries without a human relaying every message.
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.