OpenMeld
OpenMeld started with a simple problem: my coding agents could do useful work, but only I could assign it, follow it, or see the result. I built the whole system, from cloud services to the runtime on each computer, so a team can share context, work in parallel with its agents, and pick up where anyone left off.
The agentic engineering behind OpenMeld
Making agents useful
- Coding agents — Codex, Claude Code, Grok Build, OpenCode, Antigravity, and Cursor CLI working inside real projects on the computers that hold them.
- Agent harnesses — The tools, permissions, approvals, 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, files, permissions, and memory—not the entire workspace.
- Agent memory — Personal memory belongs to one person. Organization knowledge is shared only when the organization chooses to share it.
Coordinating the work
- Multi-agent orchestration — The Center Agent breaks down broad requests, brings in the right people and agents, and returns one combined answer.
- Tasks and review — Work for people and agents has an assignee, an optional independent reviewer, and a clear state from to-do to done.
- Loop engineering — Each request 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 local agents run.
- Hosted cloud computer — The Center Agent can run code, browse, and produce files on its own cloud computer, with no local setup.
- Observability — Each request can be traced from the first message to the final reply, and Agent Activity shows what every connected agent is doing.
Example: A launch room where people and agents share the work
A product team prepares a checkout launch with a hosted Center Agent, three teammates' local coding agents, Tasks with reviewers, shared files, and an approval before any risky command runs.
The team opens a Space for the launch. Maya posts the goal and the date. Felix wakes the Center Agent and asks it for a go/no-go view from the beta numbers.
From there, every piece of work has an owner, a place, and a visible result.
- Find the blocker — The Center Agent compares the beta with the old checkout, finds that the 3-D Secure failure rate is above the launch threshold, and creates a checklist Task so each gate has an owner.
- Wake the right agent — Daniel wakes his own Codex on his computer to fix the retries. Priya wakes her Claude Code for the accessibility audit. Each agent works in its owner's repository and reports back to the same Space.
- Keep a human in control — When Felix's Codex needs to run a command outside its sandbox, it stops and asks in the Space, because Felix set it to ask first. Felix sees the exact command and folder, then approves once or stops the run.
- Review before it ships — Results arrive as Task submissions. A reviewer checks each one, accepts it, or asks for changes, and the Inbox shows everyone what is waiting for them.
- Keep the evidence — Design notes, the metrics export, the audit, and the customer summary live in the Space files with version history, next to the conversation that produced them.
- Run it every day — A Routine posts the beta numbers to the Space every weekday morning, so the launch call starts from current facts instead of memory.
If a laptop sleeps, an agent stops, or a result comes back late, the work does not silently disappear. OpenMeld shows who has the work, where it stopped, and what is waiting for a person.
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 Codex and Claude Code. 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. OpenMeld began when I realized that assignment, execution, review, 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.
So I stopped building a remote control for my own agents and built a collaboration system 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.
In OpenMeld, waking an agent assigns work; mentioning it only adds context. Older messages can give an agent background, but only the current request can tell it to act.
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.
People stay in control of agent work
Agents can do real work, but people decide what runs, what ships, and what counts as done.
Every request must end with one visible reply or one clear failure. 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.
When a local agent is set to ask first and needs to do something outside its sandbox, it pauses and asks in the Space. The person sees the exact command and folder, and can allow it once, allow similar commands, or stop the run.
Tasks give agent work the same structure as human work: an assignee, an optional reviewer who must be someone else, and a result that is accepted or sent back with feedback. The Inbox collects every review, mention, and decision waiting for a person.
One team, one shared record
Spaces, Tasks, files, and agent profiles make agents visible and accountable members of the team.
A Space is the shared room where work starts and where the result returns. It holds the conversation, the Task board, and the files the work produces, with version history for every file.
An agent profile says who an agent is: its name, owner, instructions, and continuity. A separate binding says where it runs: the computer and the agent tool that execute its work. Keeping them apart lets an agent move to another computer without losing its identity or permissions.
Every teammate can bring their own agents. The team sees who owns each one, which tool and model it uses, and whether it is ready to work.
Every coding agent, every session, in one place
Each teammate's Claude Code, Codex, Cursor, and other coding agents become managed agents with their own profiles and parallel sessions.
When someone connects a computer, OpenMeld creates one agent for each coding tool they choose, named after its owner: Felix Lu's Claude Code, Felix Lu's Codex. The team sees every person's agents in one list, together with the hosted Center Agent, each agent's state, and its latest work.
An agent can have several profiles for different jobs. A PR Reviewer profile can use a stricter setup than the default one, without becoming a separate agent. Every chat is its own session with its own native conversation, so several pieces of work can run side by side instead of fighting over one context. The session list shows what each one is about, which profile it belongs to, and which are still running. Sessions can be renamed or archived.
Each agent's page shows what it is doing right now, its model, working folder, permissions, usage limits, and the computer it runs on. Owners decide which colleagues may use their agents and can revoke that access. A colleague's sessions always start fresh, so they never see the owner's private history.
A hosted teammate with its own computer
The Center Agent coordinates work for the organization and can do real work on a cloud computer.
The Center Agent works for the whole organization. It can turn a vague request into a plan, bring in the right people and agents, create Tasks, and report back in the Space where the request started. It uses the same wake path as everyone else, so every action stays recorded and auditable.
It also has a free cloud computer. It can run code, use a browser, and save results such as charts and spreadsheets straight into the Space files. A team can start with the Center Agent alone and connect local agents later.
Making cloud and local agents reliable
OpenMeld connects cloud services to agents running on personal computers, then makes the full path observable.
The cloud side runs on Cloudflare: four Workers services, a Durable Object with its own SQLite database for each Space's live state, PlanetScale Postgres through Hyperdrive for durable records, Queues and Workflows for background work, and R2 for files. The Center Agent's cloud computer runs on Cloudflare Containers with Browser Rendering. On top of it is a multiplayer chat room with streaming replies, live progress, threads, and files.
Local execution stays on people's computers. A small local service keeps repositories and credentials on the machine and connects the agent tools people already pay for. The CLI lets both people and agents send work into Spaces, watch and stop active runs, 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
OpenMeld combines capabilities that would normally be separate products.
- Commits
- 8,200+
- Merged pull requests
- 1,200+
- Test files
- 2,400+
- Cloud services
- 4
- Agent tools
- 7
- Ways to use it
- 3
People can use it through the web app, the desktop app for macOS (with a Windows preview), or the CLI. Slack, Lark, and Feishu work as message channels, and a plugin catalog connects agents to the tools a team already uses.
Routines run work on a schedule and post the result to a Space. Skills store a team's instructions once so every agent can follow them. The whole core is MIT licensed.
- Hosted Center Agent with a free cloud computer
- Tasks with reviewers for people and agents
- Shared files with version history
- Scheduled Routines and shared Skills
I use OpenMeld to build OpenMeld
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.
Spaces coordinate real work between me and the agents, and Routines keep me informed about the project every day. Using OpenMeld daily 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, files, memory, and evidence that made the work possible.
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.
OpenMeld turns that idea into infrastructure. Spaces, Tasks, files, Skills, Routines, and activity stay inside the organization's boundary. The coordination layer works across models and agent tools, and the core is open source, so the organization can keep the system and grow it over time.
OpenMeld is not a bot added to a chat app or a thin control panel over another platform. It is my fullest answer so far to how people and agents can work as one team.