Why agents like datadata
datadata is being honed against applications where AI agents and humans edit the same data. Several properties that are merely nice for humans turn out to be essential for agents.
The API fits in a prompt
Section titled “The API fits in a prompt”The whole surface is a handful of referential verbs — subscribe, read, create, update, delete — over one kind of thing: the document. An agent’s tool definitions stay small, and there are no special cases to teach: the same calls work for user documents, schemas, and system state.
Agents can create their own document types
Section titled “Agents can create their own document types”Because schemas are documents at sys:schema:<type>, an agent that needs a
new shape of data can write the schema and start using it in the same
session — designing a data model is just more document editing. The schema it
writes is validated against the meta-schema, so a malformed design is
rejected like any other bad write.
Changes are legible
Section titled “Changes are legible”Structured edits are RFC 6902 patches — compact, diff-shaped, and readable by the agent itself, by a reviewing human, and by the model judging a conflict. When a change commits, the event log records which principal wrote it — human or agent — so “which edits did the AI make?” is answerable from the data.
Staging is the natural agent workflow
Section titled “Staging is the natural agent workflow”The staged session gives agents what they actually need: a place to accumulate multi-document work, a three-way conflict preview they can read as data, and an atomic, refusable commit — detailed in Sessions as agent workflow.
The server can host the agent
Section titled “The server can host the agent”With in-process clients, an agent runs server-side as a first-class client — same API, no WebSocket. Its edits stream to the browser as it works, and the user can keep editing the same documents by hand at the same time. Both sides converge on the same live state.