# Ablo: collaboration infrastructure for AI agents Ablo is collaboration infrastructure for AI agents: one API for agents, apps, and services to write to the same rows. Runs on your own Postgres. ## Ablo is collaboration infrastructure for AI agents For teams building products where agents, apps, services, and people write to the same rows: one API coordinates every writer, while your data stays in your own Postgres. Run `npm install @abloatai/ablo`, then `npx ablo init`, and follow the [quickstart](https://docs.abloatai.com/quickstart). ## Three ways to reach the same coordinated state ### Multiplayer state in TypeScript. One typed client claims a row, does the slow work, and writes it back. Runs wherever your code runs, with any framework or none. ### Scoped permission for agents. Mint an agent client that can only touch the models you name, run the operations you allow, and expire when you say. ### Your sync engine, in any AI assistant. Expose your resources as typed MCP tools with scoped writes and coordination intact. ## Context tells an agent what it knows. Shared state tells it what is currently true. ### Stale-read detection You can’t overwrite a change you never saw. Edits built on old data are caught, not committed. ### Authorship Nothing changes anonymously. Every edit carries who made it and what they based it on. ### Claims One editor at a time. Everyone else waits their turn instead of overwriting each other. ### Real-time sync Everyone sees the same state the moment it changes, with no refreshing or stale copies. ## Expose the same live state to every agent working together. ## How it works Ablo sits in front of a Postgres database you already own. Your agents, your application, and the people using it all write through one API instead of holding their own connections and racing each other in the same tables. Each accepted write is applied to your database and recorded in an append-only log, so the order things happened in is a fact you can read back rather than something you reconstruct. The problem it exists to solve shows up the moment a second writer appears. An agent reads a row, spends four seconds in a model call, and writes back what it decided. In those four seconds someone else changed the row. Written naively, the second write wins and the first edit is gone with nothing logged and nobody told. Ablo refuses that write instead: reads carry a stamp, writes carry it back, and a write built on a row that has since moved comes back as a typed error your agent can retry from the current state. When the work is slow enough that retrying is wasteful, a writer takes a claim on the row first. A claim is a fair queue rather than a lock. The second writer is not rejected and not allowed to overwrite; it waits, and when its turn comes it is handed the row as the first writer left it. A person editing in your interface is simply another holder, so an agent queues behind a human being without either side needing to know about the other. Claims can be narrowed to a single field or range, so two writers working on different parts of one row both proceed at once. Your rows never leave your database. Ablo reads them by tailing the logical replication stream Postgres already produces, and writes land back through a role you scope yourself. What Ablo hosts is the log and the coordination state. The shape is closer to a payments processor than a backend as a service: the system of record stays where it is, and you can point Ablo at RDS, Supabase, Neon, or a machine under your desk without changing a line of application code. ### Who Ablo is for Ablo is for engineering teams building multi-agent systems, agent-assisted products, and operational software where people and agents edit the same records. It is useful when model calls make a read-to-write cycle slow, when several workers can pick up the same job, or when every change needs a durable author and audit trail. It is not a replacement for an ORM in a single-writer application, a vector database, a queue, or an agent framework; those systems can remain in place while Ablo coordinates the shared state they act on. ## Frequently asked questions ### What is Ablo? Ablo is coordination infrastructure for AI agents. It puts one API in front of the rows that agents, applications, and people all write to, so a second writer waits for the first instead of overwriting it. Writes go through a commit chokepoint, land in your own Postgres, and are recorded in an append-only log you can read back. ### When should I use Ablo instead of an ORM? When more than one writer changes the same rows. If a single process owns the data, Prisma or Drizzle is simpler and you should use it. Ablo earns its round trip once you have concurrent agents, a read that sits in an LLM call before it is written back, or a person editing the record an agent is working on. ### Where is my data stored? In your own Postgres. Ablo reads by tailing the logical replication stream your database already produces, and writes land back in it through a role you scope. What Ablo hosts is the transaction log and the coordination state, never your application tables. Hosting your database anywhere is fine: RDS, Supabase, Neon, or your own machine. ### How do two agents avoid overwriting each other? A writer takes a claim on the row before its slow step. A claim is a fair queue, not a lock: the second writer is neither rejected nor allowed to clobber, it waits and is handed the row as the first one left it. Claims can also be narrowed to a field, a path, or a range, so two writers working on different parts of the same row are both granted at once. ### What happens if an agent writes based on stale data? It is refused, not silently applied. Every read returns a stamp; pass that stamp back with the write and Ablo rejects the write if the row moved in between. Your agent gets a typed error naming the conflict rather than a success that quietly discarded someone else’s edit. ### How do I connect Ablo to my app? Install @abloatai/ablo, run npx ablo init --yes, and construct the client with your schema and an API key. That scaffolds a schema file and the client that reads it. Connecting your database is one more command, npx ablo connect, which prints or applies the replication setup Postgres needs. ### Can an AI assistant integrate Ablo without me? Largely, yes. There is a Model Context Protocol server at www.abloatai.com/mcp that gives a coding assistant the documentation, schema validation, and scaffolding as tools, and a second one that exposes your own rows as typed tools with claims and scoped writes intact. The REST contract is published as OpenAPI, and llms.txt describes the whole surface including when Ablo is the wrong tool. ### Is Ablo a database, a queue, or a realtime service? None of the three. It is a write path over a database you already own. It does not store your rows, it does not deliver messages, and it is not a socket layer with presence bolted on. The nearest comparison is a payments processor: your system of record stays where it is and the coordination happens in front of it. We’re building the collaboration layer for apps where AI agents collaborate with a shared, auditable state. --- Canonical URL: https://www.abloatai.com/ Also machine-readable on this domain: /llms.txt, /llms-full.txt, /openapi.json, /sitemap.xml, /robots.txt