Many agents, one record of what was decided
The framework runs the agents. The record keeps them working from the same facts.
The Problem
Multi-agent frameworks differ in how they schedule and message agents. They share a problem: each agent builds its own picture of the task, and the pictures drift.
A worker re-reads files the lead already understood. Two agents make different assumptions. The next run starts again from the task description.
How Stompy Helps
Stompy is the shared part. The lead locks the architecture, the constraints and the decisions once. Workers recall what they need instead of rediscovering it, and lock back what they found.
It does not matter which framework runs the agents: AutoGen, OpenAI Swarm, MetaGPT, ChatDev, TaskWeaver, Semantic Kernel, DSPy, Smolagents and the rest all end up calling the same two actions, search and lock, over MCP or REST. Tickets divide the work: a lead creates them with what a worker needs already written on them, and a worker claims one.
Nothing is automatic. No agent watches the board. Work starts when a session is started, and the person running it decides what is kept.
In our own six-agent benchmark (one full-stack feature, built by six agents, run on 7 March with Sonnet 4.6 and Opus 4.6), the swarm working from a shared record cost 43% less than the same swarm without one. That is one run of one workload, not a saving to expect on yours. Haiku 4.5 went from 0 of 40 tasks to 39 of 40. The full tables are on the deep dive page.
Integration Walkthrough
The lead locks the shared picture
Decisions, constraints and the reason for each. Keep one fact per entry.
lock_context(project="my-project",topic="booking_feature_architecture",content="""Decision: bookings are written by one service; the UI only reads.Why: two writers produced double bookings.Must not change: the booking id format.""")
Workers read instead of rediscovering
Recall by name for what the lead named, or search by meaning. recall_batch reads several topics in one call.
recall_batch(project="my-project", topics=["booking_feature_architecture", "api_conventions"])context_search(project="my-project", query="how bookings are written")
Divide the work with tickets
A ticket carries where, the exact change, why and what must not change. A worker claims it, and the lead reads the board rather than trusting a summary.
ticket(action="create", project="my-project", title="Add the availability endpoint",description="Where: api/availability. Why: the UI needs it. Must not change: booking ids.")ticket(action="claim", project="my-project", ticket_id="...")ticket_board(project="my-project", view="summary")
Or reach it over REST
Frameworks with no MCP client can call the same record with a project API key. A project API key is minted by the project's owner while signed in, and works for that one project only. Read the project's own contexts and search with it; managing the project still needs a signed-in user.
import osimport httpxBASE = "https://api.stompy.ai/api/v1/projects/my-project"HEADERS = {"Authorization": f"Bearer {os.environ['STOMPY_PROJECT_KEY']}"}def lock(topic: str, content: str) -> dict:"""Keep a decision. Only called when the person asked for it."""r = httpx.post(f"{BASE}/contexts", headers=HEADERS,json={"topic": topic, "content": content})r.raise_for_status()return r.json()def search(query: str) -> dict:"""Find what the project already holds, by meaning."""r = httpx.get(f"{BASE}/search", headers=HEADERS, params={"query": query})r.raise_for_status()return r.json()
What You Get
- Agents read the same entries instead of drifting private summaries
- Any framework works: the record is reached over MCP or REST, not through the framework
- Tickets divide the work and carry what a worker needs
- Nothing runs on its own: a person starts the session and decides what is kept
Start your own record
Join the waitlist and we will tell you when your place is ready.