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

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

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.

A valid schema can still be a poor fit, so lintSchema (from the schema entry point) gives advisory warnings about a schema’s design. It flags an array of objects, where a record keyed by the entity’s id would let concurrent edits to different entries merge, with ordering in a fractionalIndex field. It also flags an id field that repeats the record key. A tool that lets an agent define schemas can return these warnings to the agent, and an eval can count how often its schemas come out clean.

Runtime schema editing requires admin authorization, including authority to change the schema’s access rules. See scoping schema editing for how to block changes to folder roles and per-document permissions, and what that restriction leaves editable.

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

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

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.

The docs are readable by agents too

This site publishes an llms.txt index. The full documentation is one Markdown file at /llms-full.txt, and /llms-small.txt is the same without the asides and collapsed sections. Hand an agent whichever fits its context window.