Authors: Jannik Luhn, Luis Bezzenberger
Today we're releasing an alpha version of Concorde, an open-source framework for giving an organization one shared agent that acts on behalf of the group.
TL;DR
You can bring the agent you already use or use Concorde’s standard agent. Concorde provides the infrastructure around it that lets multiple people use the same agent while maintaining a common record, making the agent's commitments verifiable, and keeping the agent controlled by the group.
This makes it useful for organizations, teams, DAOs, clubs, funds, homeowners associations, and other groups that need an agent to remember context, support collective decisions, and act on behalf of the group. The same infrastructure also supports a temporary agent called Discorde for situations such as disputes, escrow, hiring, and negotiations.
Shared agents are gaining ground
Three months ago we wrote On Shared Agents, arguing that the most valuable agents would be shared rather than personal, and that building them would take new infrastructure from a lot of teams at once.
Since then, others have started building.
For instance, Stanford's OpenLab ran an Autonomous Organizations Summit at the end of July, asking what management structures actually work and when autonomy helps. Alex Soto published a modular architecture for distributed institutions, arguing that first-generation DAOs over-invested in decision mechanisms and under-invested in continuity, and naming the failure mode: institutional drift, the slow divergence between what an organization says, does, and practices.
We love seeing this work. We just don't think either of them takes the idea as far enough.
Why one agent for the whole organization
Organizations split work between people because no one person can do it all. Keeping all those people aligned is what the org chart, the standups, the tickets, and the approvals are for. None of that is the work itself. It's overhead, and we call it the coordination tax.
Most companies bringing in AI agents keep that structure and just swap the occupants. An agent takes the marketing seat, another becomes the manager, and they file tickets to each other. But the org chart only exists because a person can hold limited context and sit in one meeting at a time, and an agent has neither limit. Copy the boundaries anyway and you pay the coordination tax in tokens instead of salaries. A faster bureaucracy is still a bureaucracy.
We think the answer is one agent for the whole organization. You've met the human version. Every organization has one person who's been there forever, holds everything in their head, and settles in a second what a committee would take a week over. Everything slows down the moment they leave. A shared agent is that person, made durable, reliable, and available 24/7. It holds context across every function, remembers each member's preferences, and keeps the knowledge that would otherwise stay scattered across people, systems, and conversations.
For that to work, the shared agent has to serve every member while being owned by none of them and reachable by none of them privately.
That last part is the whole engineering problem we sought to solve. And we built it.
How Concorde works
Separate access from control
At the center of Concorde is the Gateway, which sits between the members and the underlying agent. Members communicate through the Gateway and never touch the agent directly. That separates interacting with the agent from controlling it. A member with direct access effectively owns the agent, because they can change its instructions, read and edit its memory, and tell it things the others never see. Behind the Gateway, everyone gets the same way in and the same way out, and no member can quietly create a private route to the agent that the rest of the group doesn't have.
The architecture below shows the setup. The agent sits on one side, members sit on the other, and the Gateway handles everything between them, including identity, messaging, records, and the interfaces both sides talk through. Everything inside the dashed boundary is the Gateway, and which of those parts your deployment builds is your choice.
The system currently requires a trusted operator to run the agent and the gateway. Ideally an external neutral entity outside of the organization fulfills that role. For prototyping, the operator can also be internal if they can give credible assurance to not interfere with the agent or access its private state. In the future, reliance on a trusted operator can be reduced by means of cryptographic tools such as TEEs, zero-knowledge proofs, and censorship resistant ledgers.
Give the group a shared history
Concorde keeps durable records of every interaction between members and the shared agent. The group gets a common history instead of a record that lives somewhere one participant can quietly rewrite or is lost when they leave the organization.
Make the agent's commitments independently verifiable
The shared agent can put its name to a statement by cryptographically signing it, and anyone can verify it afterwards without an account. That matters when an agent is acting for several people and decisions need to be related to third parties.
Use the agent stack you already have
Concorde doesn't run your agent. It only decides what reaches it. The connection between the two is deliberately narrow. Concorde hands the agent a prompt and gets a result back, and nothing about the model, the tools, the memory, or the reasoning loop comes from us. If you've already built an agent you trust, you keep it and put the Gateway in front of it.
Connecting a new agent takes one small adapter that tells Concorde how to start the agent, what to send it, and how to read what comes back. pi is the default and ships with the framework, so an organization that doesn't have an agent yet can stand a shared one up from nothing. OpenClaw is already implemented as a reference alternative, and Codex, Hermes, or anything else you run is one adapter away.
The model is up to you too. The two shared agents we run today use different models, one GLM and one Claude, and neither choice is the framework's to make.
Add what your group needs
Every Concorde setup starts from the same foundation. There's a database that keeps the records, a worker that feeds the agent one task at a time, and two interfaces, one the agent calls back through and one that members' own clients talk to.
On top of that foundation, you add only what your group needs. Each piece is a line of configuration, and you can bring your own components alongside Concorde's:
- Members, and how they prove who they are. This can be passwords, Nostr keys, or both at once.
- Messaging. Each member gets one durable log covering both directions, plus a channel for each medium your group uses, whether that's the web, Nostr, or one you write yourself. One of our shared agents added Telegram.
- Signed commitments, so the agent can put its name to statements that anyone can check afterwards, without an account and without trusting whoever runs the server.
- A schedule, so time can wake the agent and not only people.
- Any custom component specific for your use case, providing an interface to the agent and/or one to the users and using the database to store structured data.
Long-lived agents and temporary neutral agents
The same infrastructure supports two kinds of shared agents, and everything described so far is the first kind: a long-lived agent designed to accumulate context, remember standing preferences, and become more useful as a group builds history with it.
The second kind is the ephemeral agent, called Discorde. It is a short-lived agent created for one contested situation, such as a dispute between two parties. Where a long-lived agent's value is the history it builds up, Discorde holds no history at all, because for a mediator history is a liability.
Our Discorde deployment shows what that looks like in practice. It runs as an ordinary Concorde deployment, and the mechanics are built so that neither party ever has to trust the other, the operator, or the agent itself.
A dispute runs like this. The two parties never speak to each other. Each side states its case to the agent in turn, and at the end of a round the agent writes its own account of that side. That account is the only thing the other party ever sees, so neither side can grandstand at the other directly. Rounds alternate until either party passes. Then the agent reads both sides in full, in a session of the dispute's own that names neither of them, and writes a verdict.
The verdict is published as a signed decision in the same transaction that closes the dispute, and a dispute closes once and never reopens. Anyone can read every verdict and the check runs in the reader's own browser against the agent's public key, with the page showing whether it passed, failed, or couldn't be run at all. For anyone who doesn't want to trust the page either, there's a script in the repository that runs the same check with none of Discorde's code imported.
The agent itself can't sign anything and can't publish a decision, because those routes aren't mounted anywhere it can reach. The one thing it can publish is a verdict on a dispute somebody has already passed in.
Beyond disputes, Discorde could be used for contract negotiations, escrow decisions, hiring processes, estate division, or other situations where several parties need to rely on an agent without giving one of them privileged control. The agent may last for years or only for one decision, but the underlying requirement is the same: it needs to be shared without belonging to any one participant.
Testing the idea with a homeowners association
Our first shared agent was a collaboratively curated newsletter about open source and local AI. Its coverage is decided by what its readers ask for, and every issue is a signed commitment in a public log. We built it first because it was an easy case.
For the second shared agent, we wanted the problem in its plainest form, so we invented a fictional homeowners association. Oak Street HOA keeps the record for forty-two households with no paid manager and a board that turns over every year. An association is a good test because disagreement is the normal case, preferences have to outlast the boards that heard them, decisions affect people's money, and nobody should have to take the record-keeper's word for anything.
We wrote the association as a spec describing the agent, its four owners, and its own signing key, then talked to it as the owners, over two rounds.
Round one brought the problems. A gate had been sticking since the frost, and two households were propping it open. A hedge had grown past a sightline after a near miss with a cyclist. One owner insisted that the cause be known before spending more than $200 on any repair, and someone wanted the 7am Saturday leaf blowers dealt with. The agent recorded each as a standing preference in the owner's own words, and when one owner guessed "maybe $300" for the gate repair, it marked that down as their estimate rather than a quote, without being asked to.
Round two brought the missing facts. A written quote of $240 came in. The cause turned out to be a warped strike plate, not the hinge the association had already paid to fix twice. The objecting owner withdrew their objection, and the owners took a vote.
What the agent did with all of that is the part we wanted to see. It published nothing, because nothing had been settled yet. It opened a note holding the matter open, since the cost was now known but the spend hadn't been authorized. It recorded the withdrawn objection as withdrawn for this repair, not abandoned as a principle. And its first notice refused to settle the gate at all, in its own words: "This agent will not invent a cost or imply a vote that did not happen."
That last line is why you build this on a shared agent rather than a group chat with a summarizer bolted on. The agent's restraint is the product, and the signature is what makes that restraint worth something to somebody who wasn't in the room.
Both shared agents, the newsletter and the HOA, are live to browse at https://concordeai.duckdns.org/.
A shared agent also needs institutional memory
Many organizations have a person who seems to hold the whole thing in their head and can resolve something quickly because they already know the history and what has been tried before. What makes that person useful is not intelligence alone. It is accumulated context. An agent with a strong model but no memory of the last two years is still a newcomer.
A long-lived shared agent therefore should not be deployed on its own. This goes beyond what Concorde itself ships, but here is how we think a deployment should look: pair the agent with a second brain built around two layers, because organizations hold two different kinds of knowledge that need different treatment.
Hard knowledge is what was written down: documents, email threads, repositories, CRM records, websites, and other systems. It needs to be indexed, kept in sync, and returned as written with its source attached. This is what a tool like Onyx is designed to do.
Soft knowledge is what nobody wrote down: why a vendor was dropped, what the deployment rule actually is rather than what the documentation says, or what was tried and quietly abandoned. This knowledge cannot simply be retrieved from a source. It needs to be distilled and revised as the organization's understanding changes. Andrej Karpathy's LLM wiki is a useful model for this: plain Markdown pages, cross-linked and written for a model to read.
The result is one index for facts as written and one wiki for what those facts mean. Both can be made reachable over MCP by whatever needs them, whether that is the shared agent, a member, or a coding agent in a terminal.
Set up this way, the second brain can outlive any particular agent, model, or member. The shared agent can change while the organization's accumulated knowledge remains.
A shared agent might also turn out to be the best collector of soft knowledge, not just its main consumer. People will tell a neutral party things they would never put in a report to their boss, like the mistake nobody owned up to, and a shared agent could gather that context by interviewing members or by being given access to their conversations. Because this task is highly privacy-sensitive, it requires strong trust in the operator setup.
Follow along for updates
In May we had a thesis and no product. Now we've released Concorde 0.1.0, open source and in alpha, so organizations can start setting up their own shared agent.
We’re actively building Concorde and we have a larger release and product in the pipeline. Follow along by subscribing to our blog and following us on X.
Try out Concorde and share your build
If you run an organization, a club, a DAO, or a fund, anything where a group has to remember, decide, and act together over time, Concorde is how you give it one shared agent. Bring the agent you already use, or start with the one we ship, and we would like to see what you build with it.
The public API is still changing, breaking changes should be expected, and there might be bugs. But the repository already includes four runnable examples that launch as self-contained deployments, a good starting point for exploring the framework.
- Documentation: https://shutter-network.github.io/concorde/
- Concorde repository: https://github.com/shutter-network/concorde
- Discorde repository: https://github.com/shutter-network/discorde
