WakeLoop
WakeLoop started with a simple problem: my coding agents could do useful work, but only I could assign work to them, follow their progress, or see their results. I built the full system—from cloud services to local runtimes—to make that work shared, visible, and reliable.
The agentic engineering behind WakeLoop
Making agents useful
- Coding agents — Claude Code, Codex, Cursor, and OpenCode working inside real projects.
- Agent harnesses — The tools, permissions, recovery, and safety checks agents need to finish real work.
- Context engineering — Each agent receives only the task context it needs: the people involved, relevant history, documents, permissions, and memory—not the entire workspace.
- Agent memory — Personal memory belongs to one person. Organization memory is shared only when the organization enables it, so agents can learn without mixing private and team context.
Coordinating the work
- Multi-agent orchestration and subagents — The Center Agent breaks down broad requests, delegates parts to Codex and Claude Code as subagents, waits for their results, and returns one combined answer.
- Loop engineering — Each task ends with one visible result or one clear failure, even through retries and interruptions.
Running it reliably
- Cloud and local infrastructure — Teams assign and follow agent work in the cloud while repositories and credentials stay on the computers where agents run.
- Observability — Each request can be traced from the first message to the final reply, so failures can be found instead of guessed at.
- Operational evaluation of agent work — Weekly reports show whether agent tasks finished, failed, went stale, or overlapped with another task.
Example: From a production signal to a verified fix
A checkout drop moves through PostHog, Cloudflare, GitHub, two local agents, a human approval, and Slack—and still ends with one clear result.
A scheduled Routine notices that checkout completion has dropped in PostHog after a new Cloudflare deployment. It posts the signal and supporting evidence to a shared Release Watch Space.
Felix wakes the Center Agent with one request: investigate the drop, coordinate the right agents, and do not change production without approval. After any approved change, check PostHog again thirty minutes later in the Release Watch Space and send the final verified result to the team's Slack channel.
- Build the full picture — The Center Agent checks the PostHog data, the Cloudflare deployment, related GitHub changes, and any approved organization memory about earlier releases.
- Delegate across computers — The Center Agent delegates two subagent tasks: Felix's local Codex investigates the web repository on his Mac while a teammate's local Claude Code checks the Worker and API code on another computer.
- Keep code and access local — Each agent receives only its task and relevant context. Repositories, branches, credentials, and development tools stay on the computers where the work runs.
- Wait for real outcomes — WakeLoop keeps an exact record of both runs instead of guessing from chat messages. When both agents finish or fail, the Center Agent resumes with their real results.
- Keep a human in control — The Center Agent compares the evidence, explains the likely cause, and proposes a fix. Felix approves the exact GitHub merge and Cloudflare deployment before production changes.
- Close the loop — A one-time Routine checks PostHog again thirty minutes later, returns the evidence to the Space, and publishes the approved result to Slack. The final decision can become organization memory.
If a computer goes offline, an agent stops, a result comes back late, or a message fails to publish, the work does not silently disappear. WakeLoop keeps the loop visible and shows where it stopped.
The work was trapped on my computer
Coding agents could finish useful tasks, but their work stayed inside one tool, one computer, and one terminal.
Most of my daily work runs through coding agents such as Claude Code and Codex. They were capable, but only I could start the work, follow it, and see the result. Every finished task ended in terminal history that only I could see.
I built partial fixes first. Agents Router sent completion signals from local agents to the chat apps I already used. OpenTag, which I worked on at Amplift, let teams start agent runs from the threads where work already lived. Each solved one part of the same loop. WakeLoop began when I realized that assignment, execution, and reporting needed to be one system.
Private agent loops leave the team behind
A team cannot build shared knowledge around agents that only live in one person's terminal.
A teammate could not assign work to an agent in my terminal. Nobody could see what other agents were doing or what they had done yesterday. The agents had no shared identity, permissions, or history, so every person had to build a private loop.
I stopped thinking of WakeLoop as a remote control for my own agents. It became collaboration infrastructure for teams made of people and agents.
Agents act one turn at a time
Multi-agent work is mainly a context and timing problem: what should each agent see, when should it act, and what should everyone else know?
Agents do not stay active in a shared room. Each one reads the current context, takes one turn, and stops. The Raft team showed this with a simple counting game: even a room of agents trying to count upward can collapse into collisions.
Rules about who may speak can reduce noise, but they can also turn agents back into tools that wait to be called. I treated the problem as context and attention engineering: control what each agent sees, when it acts, and what becomes visible to the rest of the team.
WakeLoop also separates the current request from historical messages. Older messages can give an agent background, but only the current request can tell it to act. WakeLoop starts with the current conversation and reads more only when the task requires it.
The same problem spans cloud and local machines. Laptops sleep, processes stop, and networks fail. The system still has to stay understandable, affordable, and reliable.
Every request must have a visible outcome
A Wake must produce exactly one visible reply or one clear failure.
A Space is the shared cloud room where work starts and where the result returns. Mentioning an agent with wake assigns work; mentioning it as a reference only adds context. This keeps agent attention explicit.
The rule is simple: no silent drops, no maybe-it-ran, and no result that only exists in a terminal. I call this loop engineering: the whole system protects the path from request to execution to visible outcome.
One team, one shared record
Profiles, local runtimes, Spaces, and Agent Activity make agents visible and accountable members of the team.
An Agent Profile says who an agent is: its name, instructions, and continuity. A Binding says where it runs: the machine and local tool that execute its work. Keeping them separate lets an agent move to another computer without losing its identity or permissions.
Spaces keep the shared work and history. Agent Activity shows current and past work, so visibility comes from the system rather than the person who ran the agent.
The Center Agent coordinates work for the organization. It can turn a vague request into a Space, bring in the right people and agents, and delegate parts of the work to subagents. It uses the same Wake pipeline as everyone else, so every action stays recorded and auditable.
WakeLoop is complete for one person working with several agents. Organization roles and shared directories appear only when more people join.
Making cloud and local agents reliable
WakeLoop connects cloud services to agents running on personal computers, then makes the full path observable.
The cloud side runs on Cloudflare. Workers run the services, each Space keeps live state in its own SQLite database, D1 stores durable records, Queues move work, and R2 stores attachments. Serverless keeps idle cost low and scales with use. On top of it is a multiplayer chat room with streaming replies, live progress, attachments, and membership.
Execution stays on people's computers. A small local service keeps repositories and credentials on the machine and connects Claude Code, Codex, Cursor, and OpenCode. The CLI lets both people and agents send work into Spaces, watch and stop active Wakes, and trace delivery from start to finish.
- Readiness uses the same evidence across web, CLI, and desktop
- Retries, duplicate handling, timeouts, and failure states protect the visible-outcome rule
- Full-path tracing shows where time was spent and separates system delay from model thinking
One product for the whole loop
WakeLoop combines capabilities that would normally be separate products.
- Commits
- 4,000+
- Workspace packages
- 33
- Cloud services
- 4
- Ways to use it
- 4
- Agent platforms
- 4
- Test files
- 1,400+
WakeLoop connects Slack and Lark as message channels and provides twelve Apps for code, documents, email, calendars, design, analytics, and Cloudflare operations.
People can use it through the web app, desktop app, CLI, or a new project starter.
A typical morning can start with a Center Agent digest. The digest finds something worth acting on, brings in the right person and agent, opens a Space, and returns the result where the team can see it.
- Scheduled Routines that run in the cloud for the organization
- Proactive work that notices opportunities and proposes next steps
- Agent Activity across every connected local agent
- Organization documents that stay beside the work
I use WakeLoop to build WakeLoop
The product is also the working method I use to design, build, and review it.
I direct a fleet of coding agents that work in parallel. They write much of the code, while the product direction, design, architecture, decisions, and reviews stay mine. The repository gives agents one entry document, an owner document for each subsystem, and a running decision record so parallel work does not turn into chaos.
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. Using WakeLoop every day is the fastest way to find what the product still gets wrong.
Organizations should keep what their agents learn
Agent loops, decisions, memory, and working knowledge should become assets the organization owns.
When people and agents work together, the useful output is more than a final answer. It also includes the process, decisions, documents, memory, and evidence that made the work possible.
In a direct conversation, WakeLoop saves and recalls memory for that member only. Shared conversations use a separate organization memory, and only after the organization opts in. Keeping them separate prevents private context from quietly becoming team context.
In his essay on the Reverse Information Paradox, Satya Nadella argues that organizations should turn the way they work, what they know, and their judgment into AI systems they own. I see that as the defining constraint for this category: an organization's working knowledge should not quietly disappear into an AI provider.
WakeLoop turns that idea into infrastructure. Memory, Routines, documents, and activity stay inside the organization's boundary. The coordination layer can work across models and tools, so the organization can keep the system and grow it over time.
WakeLoop is not a bot added to a chat app or a thin control panel over another platform. It is my first full answer to how people and agents can work as one organization.