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 load-bearing 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 — over one kind of thing. 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. Each staged change carries provenance linking it to the conversation turn and tool call that produced it.
Staging is the natural agent workflow
Section titled “Staging is the natural agent workflow”The session client 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 — while humans watch the same live documents from browsers.