The transaction layer for AI agents.
Docs | Quickstart | API | GitHub
Reading the implementation? Start with the source code map. It shows which files own
create,update,delete,claim, schemas, transports, and the reactive client.
Safely coordinate AI agents, humans, workflows, and services writing to the same database.
Ablo is an authoritative transaction layer for shared application state. Every write goes through one typed API where authority, idempotency, conflicts, ordering, and confirmation can be enforced. Your Postgres remains the source of truth.
Why Ablo
Software used to have one writer: a human clicking through an application. AI applications now have humans, agents, workflows, and services acting concurrently. Databases keep transactions consistent. They do not coordinate autonomous work that reads now, reasons for thirty seconds, and writes later.
Humans handle this naturally. We see that somebody is editing, agree on who takes which part, wait our turn, and look again before continuing. Ablo gives software actors those same capabilities: bounded authority, shared ownership, fresh context, safe handoffs, and an attributed record of what happened.
Start
npm install @abloatai/ablo npx ablo init npx ablo dev
ablo dev prepares an isolated Ablo branch for your Git branch, writes its
temporary credential to gitignored .env.local, pushes the schema, and watches
for changes.
Read and write through the transaction layer:
const order = await ablo.orders.get({ id: orderId }); if (!order) throw new Error('Order not found'); await ablo.orders.update({ id: order.id, data: { status: 'approved' }, });
confirmed means the authoritative database reported the change back. The
same commit can be retried safely if the caller loses its connection.
When work takes thirty seconds instead of one request, coordinate before the agent starts reasoning:
await using claim = await ablo.orders.claim({ id: orderId }); const priced = await pricingAgent(claim.data); await ablo.orders.update({ id: claim.data.id, data: { total: priced.total, status: 'repriced' }, claim, });
Another actor touching the same work waits fairly and receives fresh state when its turn begins. If the agent fails, the claim releases automatically. If its context became stale, the write is rejected instead of silently overwriting work it never saw.
If you use AI SDK, expose the same operation as a typed model tool:
import { updateTool } from '@abloatai/ablo/ai-sdk'; const approveOrder = updateTool(ablo.orders, { description: 'Approve an order after reviewing it.', inputSchema: z.object({ orderId: z.string() }), id: ({ orderId }) => orderId, apply: () => ({ status: 'approved' }), });
Ablo supplies readTool, createTool, updateTool, and deleteTool over the
same authoritative resources. AI SDK keeps ownership of the model loop and tool
execution.
Use @abloatai/ablo for agents and backend code,
@abloatai/ablo/client for live applications, and
@abloatai/ablo/react for React. All entrypoints share the same schema,
authority, commits, claims, and ordered changes.
Read the Quickstart, browse
docs.abloatai.com, or run npx ablo docs.
Navigating the source
This repository preserves the package ownership boundaries instead of
flattening the implementation into packages/ablo:
packages/ablois the branded public facade. Its files mostly re-export the package that owns each API.packages/transactionowns the shared model-operation contracts and the stateless HTTP implementation.packages/humansowns the reactive WebSocket/local/React implementation.
That means searching only inside packages/ablo/src will not find the
implementation of create, update, delete, or claim. Read the
source code map for a verb-by-verb ownership table and
guided call traces for both the default and reactive clients.
Contributing
Ablo is free and open source. You can help by opening an issue, suggesting a feature, or contributing code.
Please report vulnerabilities privately through GitHub Security Advisories.
