Concept
Claims: the unit of human–agent coordination
Ablo Team5 min read
Where Ablo fits in a multi-agent system
A multi-agent system is made of agents, an environment, and the mechanisms they coordinate through. Ablo is not the agents and not the orchestrator — it is the typed, conflict-safe shared environment those agents (and the humans beside them) write through.
Key takeaways
- Google Cloud defines a multi-agent system (MAS) as three elements: autonomous agents, a shared environment, and interaction mechanisms (shared state, delegation, explicit invocation), usually with an orchestrator sequencing the work.
- Ablo provides two of those three: the shared environment and the shared-state interaction channel. It deliberately provides no agents and no orchestrator.
- Ablo is the substrate a MAS writes through — closer to “Postgres-of-record + a transaction layer for agents” than to an orchestration framework like Google ADK, LangGraph, or CrewAI.
- Its distinctive feature is that humans are first-class actors alongside agents, coordinated on the same rows through claims — a property most agent-to-agent MAS frameworks do not have.
- Calling Ablo a “MAS” would overclaim the agent/orchestration layer it does not build and underclaim the shared-environment layer it does.
When teams start building with multiple AI agents, one question comes up fast: is the coordination layer underneath them a multi-agent system? It is a fair question — and answering it precisely is the clearest way to explain what Ablo is and what it is not. The short version: Ablo is not a multi-agent system. It is the shared environment and shared-state channel that a multi-agent system runs on.
To make that concrete, it helps to use a definition. Google Cloud describes a multi-agent system as three fundamental elements — agents, an environment, and interaction mechanisms — usually coordinated by an orchestrator or a predefined graph. Mapping Ablo against those elements shows exactly which layer of the stack it occupies, and why naming matters for positioning.
What a multi-agent system actually is
Per Google Cloud, a multi-agent system (MAS) uses autonomous agents to solve complex problems through interaction, and it comprises three fundamental elements. First, agents: the active, decision-making entities, each with a degree of autonomy to perceive its surroundings and choose actions toward its objectives. Second, the environment: the shared operational space agents perceive and act on. Third, interaction mechanisms: the channels agents coordinate through.
Google names three interaction mechanisms, and on top of them sits an orchestrator (or a predefined graph) that decides who runs when:
- Shared state — agents read and write a common store that the others can see.
- Delegation — an agent hands a sub-record to another agent.
- Explicit invocation (agent-as-a-tool) — one agent is exposed as a callable function another agent can invoke.
- Orchestration — an orchestrator or graph sequences the agents, routes information between them, and drives toward the final goal.
A MAS, in other words, is defined by its decision-makers — the autonomous agents and the orchestrator that sequences them. That is the part that "thinks." Frameworks like Google’s Agent Development Kit (ADK), LangGraph, CrewAI, and AutoGen live here: they help you define agents, their roles, and the graph that connects them.
Where Ablo sits in that model
Ablo never decides anything. It does not contain agents, it does not plan, and it does not sequence work. The actor — a person, a server action, or an LLM agent running on some agent framework — lives entirely outside Ablo. What Ablo owns is the layer underneath: a typed, transactional, realtime store where all of those actors write to the same rows without overwriting each other.
Mapped against Google’s three MAS elements:
- Agents — Ablo provides none. By design. The agent loop belongs to your AI SDK or agent framework.
- Environment — this is Ablo’s core. Your Postgres is the system of record; Ablo adds typed models, realtime fanout, and React selectors on top. That is precisely the shared environment agents perceive and act on.
- Interaction · shared state — also Ablo’s core. The typed model graph plus realtime fanout is exactly Google’s "shared state" channel: every confirmed change shows up everywhere, live.
- Interaction · delegation — partial, and at a different altitude. Ablo’s claim (a FIFO lease taken before slow work) is hand-off coordination over rows, not record delegation between agents.
- Interaction · explicit invocation — none. Ablo has no notion of one agent calling another as a tool.
- Orchestration — none. Ablo has no planner and no graph. The "one correct way" surface is a small data API, not a control plane.
So Ablo cleanly occupies two of Google’s three elements — the environment and the shared-state channel — and deliberately occupies none of the agent-and-orchestration column. That is not a gap; it is the design. Ablo is the substrate the agents write through, the way Postgres or a message bus is not itself "a system" but the thing systems are built on.
The one place Ablo touches MAS territory: claims
An agent’s work is rarely one instant write. It reads something, thinks, calls an LLM or a tool, then writes back — and during that gap the row can change underneath it. Before that slow work starts, the agent claims the row. If someone else is already working on it, the claim waits, re-reads the fresh row, then hands it over. No stale overwrite, no separate agent mutation path.
This is the closest Ablo comes to a MAS interaction mechanism — but it is concurrency control, a lease, not delegation in the agent sense. It coordinates writes, not work. And critically, it treats a human editing in the UI and an agent calling the API as the same kind of actor competing for the same row. That human-and-agent symmetry is the property most agent-to-agent MAS frameworks simply do not model.
So should Ablo be called a "MAS"?
No — and the reasons are practical, not pedantic. Naming Ablo a multi-agent system would overclaim the exact column it does not build (agents and orchestration) and underclaim the column it builds better than most: a typed, transactional, realtime shared environment where humans are first-class actors, not just bots.
Concretely, the "MAS" label backfires three ways:
- It invites the wrong comparison. "MAS" puts Ablo next to ADK, LangGraph, and CrewAI — orchestration frameworks — and the first question becomes "where is your planner / agent graph?" Ablo intentionally does not compete there; it sits underneath.
- It erases the human. Ablo’s wedge is people and agents on the same rows. "Multi-agent" semantically excludes the human and implies agent-to-agent only.
- It is not differentiated. Nearly every framework calls itself a MAS now. "The shared-state layer any MAS can write through" is a more defensible position than being one more MAS.
The honest, sharper framing keeps the MAS keyword without writing a check the product does not cash: Ablo is the shared state and coordination substrate that multi-agent systems run on. It is the environment and the shared-state channel — Google’s elements two and three — that your agents (Google’s element one) and your orchestrator plug into. Think of it as the system of record and transaction layer for agentic apps, with humans in the loop by default.
Filed under Concept
By Ablo Team
Frequently asked questions
Is Ablo a multi-agent system?
No. A multi-agent system is built from autonomous agents, a shared environment, and interaction mechanisms, usually with an orchestrator. Ablo provides the shared environment and the shared-state interaction channel — not the agents and not the orchestrator. It is the layer a multi-agent system runs on, not a multi-agent system itself.
How is Ablo different from an agent framework like LangGraph or Google ADK?
Agent frameworks like LangGraph, Google ADK, CrewAI, and AutoGen define agents, their roles, and the graph or orchestrator that sequences them — the decision-making layer. Ablo sits underneath that layer: it is the typed, conflict-safe shared state those agents read and write, backed by your own Postgres. You can run any agent framework on top of Ablo.
Which parts of a multi-agent system does Ablo provide?
Using Google Cloud’s three-element model, Ablo provides the environment (a typed, realtime store backed by your Postgres) and the shared-state interaction mechanism (realtime fanout where every confirmed change is visible everywhere). It does not provide agents, delegation between agents, agent-as-a-tool invocation, or an orchestrator.
What is an Ablo claim and is it the same as agent delegation?
A claim is a FIFO lease an actor takes on a row before doing slow work (read → think → call an LLM → write back). If another actor holds the row, the claim waits, re-reads the fresh row, then hands over — preventing stale overwrites. It is concurrency control over data, not record delegation between agents, so it is related to but distinct from a MAS delegation mechanism.
Do humans count as agents in Ablo?
Ablo treats people, server actions, and AI agents as the same kind of actor writing to the same rows through one typed path. That human-and-agent symmetry — coordinated by claims and realtime shared state — is a defining feature of Ablo and a property most agent-to-agent multi-agent frameworks do not model.
The collaboration layer for humans and agents
Let people, server actions, and AI agents work on the same data without overwriting each other — on top of the Postgres you already have.