WakeLoop

Most of my daily work runs through coding agents — Claude Code, Codex, and others on my own machines. They are genuinely capable, but everything they did was trapped inside one tool, one computer, and one terminal session that only I could see. Every finished task died in a scrollback buffer.

I kept building partial fixes. Agents Router forwarded completion signals from local agents to the chat apps I already used, so I could at least walk away from the keyboard. OpenTag, which I worked on at Amplift, let a team start agent runs from the threads where work already lived. Each project repaired one segment of the same loop — reporting, or initiation — and each made the missing whole more obvious: delegation, execution, and reporting wanted to be one system.

Put a team around that agent fleet and the cracks turn structural. A teammate cannot hand work to an agent that lives in my terminal. Nobody can see what anyone else's agents are doing, or what they did yesterday. The agents themselves have no identity — no name in a directory, no permission model, no way to be part of the team in any real sense. So every person rebuilds a private workflow, and none of it accumulates into something the organization owns.

That reframing changed the project. I was not building a remote control for my own agents; I was building collaboration infrastructure for teams made of people and agents. That is a general problem — the multi-agent problem — and I wanted to attack it directly.

Multi-agent collaboration sounds simple and is not. Agents are turn-based: each one reads a snapshot of the room, reasons, commits an action, and goes silent until the next invocation. There is no continuous presence, no half-listening. The Raft team illustrated this with a game — ask a roomful of agents to simply count upward together, and most shared workspaces collapse into collisions within seconds. Bolting rules on top, like mention gates and allowlists, quiets the noise by turning agents back into tools waiting to be invoked.

My position is that multi-agent collaboration was never about handing out identities and role-play prompts. It is context and attention engineering: deciding what each agent sees, when it is asked to act, and what everyone else can know about its work. Anything less is theater. And beneath that definition problem sits some of the dirtiest engineering there is — coordination across clouds and personal machines, where laptops sleep, processes die, and networks lie — which still has to come out stable, legible, cheap to run, and able to scale.

WakeLoop's answer starts by refusing to pretend agents are continuously present. It gives the turn-based reality an explicit protocol instead. The unit of collaboration is a Space — a shared cloud room that is both where work is requested and where it ends. Addressing is explicit: mentioning an agent with wake assigns it work; mentioning it as a reference shares context without asking for anything. Wake is the only way an agent is put to work, so attention is allocated deliberately, never by ambient noise.

One rule holds the whole product together: a Wake produces exactly one visible reply or one explicit visible failure. No silent drops, no maybe-it-ran, no result that exists only in someone's terminal. Everything else — setup, readiness, diagnostics — is supporting evidence for that promise and is never allowed to impersonate it. I think of this as loop engineering: treating the request-execute-report loop as the core object the entire system defends.

The model answers the team-level gaps one by one. An Agent Profile is a stable identity — a name, instructions, continuity — like a badge. A Binding is the desk: which machine and which local tool currently executes for that badge. Separating the two means an agent can appear in the organization's directory, hold permissions, and move to a new computer without losing who it is. Spaces keep the shared record, and Agent Activity shows what every agent is doing and has done — visibility is a property of the system, not a courtesy of whoever ran the work.

The Center Agent is the organization's coordinator — a chief of staff that can shape a vague request into a running Space, bring in the right people and agents, and delegate to local agents in parent-child fashion. Crucially, it works through the same Wake pipeline as everyone else: no privileged transport, no backdoor, every action attributed and audited. That is what separates production coordination from role-play orchestration. The whole model also discloses progressively: one person commanding a fleet is already a complete WakeLoop; Organizations, roles, and shared directories appear only when you invite someone.

The cloud side runs entirely on Cloudflare: Workers for the services, a Durable Object with its own SQLite database per Space, D1 as the durable ledger, Queues for dispatch, R2 for attachments. Serverless was a deliberate fit for the constraints — near-zero idle cost, nothing to babysit, scale that follows usage. And on top of it sits something easy to underestimate: a real multiplayer chat room — streaming replies, live agent progress, attachments, membership — that has to feel ordinary and dependable before any agent ambition matters.

Execution stays on people's machines, behind a small background service that is the trust boundary: repositories and credentials never leave the computer, with adapters for Claude Code, Codex, Cursor, and OpenCode. The CLI deserves its own mention. Local agents do not drive a web page — they operate WakeLoop through a CLI designed for them as much as for humans: sending into Spaces, pulling people and agents in, watching and stopping running Wakes, tracing a delivery end to end. An agent is a first-class operator of the system, not something the system merely hosts.

Most of the effort went into making a distributed system tell the truth. Keeping the one-visible-outcome rule honest through retries, duplicate delivery, timeouts, and partial failures. Treating readiness as a joint claim — route, binding, prepared machine, live process — where no single signal may declare health alone, and web, CLI, and desktop must reach the same conclusion from the same evidence. And hunting latency with a full-path ledger, reconstructing every hop from timestamps until container cold starts became per-Space reuse and the remaining seconds could be attributed precisely — separating system debt from the model's own thinking time.

The system already covers what would normally be a small company's roadmap: more than four thousand commits, thirty-three workspace packages, four cloud services, four clients — web, CLI, desktop, and a project scaffold — adapters for four local agent platforms, and around fourteen hundred test files. WakeLoop connects to Slack and Lark as channels, and ships a catalog of a dozen apps — GitHub, Gmail, Google Drive and Calendar, Notion, Linear, Figma, PostHog, Cloudflare — behind one extensible connector model.

A morning inside it looks like this: a member asks the Center Agent for a daily digest; the digest flags an external signal worth acting on; the Center Agent finds the right person and the right agent, opens a Space, and a local agent picks up the work — and the result lands back where everyone can see it.

Beyond that daily loop, an organization gets capabilities that are usually separate startups — each item below could be a product on its own. WakeLoop treats them as one system, because the problem is one system:

• Scheduled agent loops (Routines) that run in the cloud on the organization's behalf
• Proactive work — noticing opportunities and proposing solutions, not just answering
• Maintenance and iteration of those loops as the organization changes
• Organization profiles and evolving member context
• Organization memory that accumulates across conversations and work
• Agent Activity across every connected local agent
• Organization documents that live next to the work

WakeLoop is built the way WakeLoop says teams should work. I direct a fleet of coding agents that write much of the code in parallel, while the design, the architecture, every decision, and every review stay mine. To keep concurrent agents from colliding, the repository carries a governance layer designed for them: one agent-facing entry document that routes to an owner document per subsystem, plus a running decision record. That discipline is why a solo project could sustain this pace without dissolving into chaos.

And I use WakeLoop to develop WakeLoop. The Center Agent runs a daily routine that scans the project and posts a digest to Slack; Spaces coordinate real work between me and the agents; the loop that the product promises is the loop that ships it. Dogfooding is usually a slogan — here it is the development method, and the fastest source of truth about what the product still gets wrong.

The larger argument is about what organizations get to keep. In a widely read essay on what he calls the Reverse Information Paradox, Satya Nadella argued that in the AI age the buyer of intelligence risks giving away the knowledge that makes their company unique — and that organizations should turn their workflows, domain knowledge, and accumulated judgment into AI systems they own, systems that improve with each use. I read that as the defining constraint for this whole category: an organization's processes, memory, and working knowledge are its core assets, and they should not quietly leak away to a model vendor.

WakeLoop is that argument turned into infrastructure. Organization memory, routines, documents, and activity accumulate inside the organization's own boundary; the orchestration layer is deliberately model-agnostic and tool-agnostic; and the direction is a system an organization can run for itself and grow with — one that learns the organization's workflows instead of replacing them with a vendor's. Not a bot added to a chat app, and not a thin control panel over someone else's platform: a system built into the production line of collaboration itself. People and agents working as one organization — WakeLoop is my first full answer to what that should look like.