Daita agents / guide
Daita Overview
Daita is a persistent, read-first data agent with guarded tools, durable outputs, and bounded automation.
#What Daita Is
Daita connects a language model to admitted data and files through one persistent agent. It is read-first: SQLite and ordinary PostgreSQL access are read-only, local workspace access begins with contained reads, and remote MCP tools must be explicitly admitted as reads. The only supported source-data mutation is an explicitly enabled, structured PostgreSQL update.
The runtime follows one direct loop:
user message -> model -> zero or more tool calls -> ordered tool results
-> model -> answerNormal model text completes the run. A tool failure is returned as a structured result, so the model can correct a call on a later step. There is no verifier pass, hidden synthesis pass, workflow graph, or resumable foreground session.
#Current Surfaces
| Surface | Current capability |
|---|---|
| SQLite | Catalog discovery, validated reads, and exact CSV/XLSX exports |
| PostgreSQL | Selected-schema discovery, validated reads and exports, plus opt-in structured updates |
| Local workspace | Contained search and text reads; bounded CSV, TSV, JSON/NDJSON, and Parquet queries; approved exact text-file replacement |
| Remote MCP | Explicitly admitted Streamable HTTP read tools with identity and schema revalidation |
| Artifacts | Documents, exact tabular exports, validated JSON snapshots, conversion, previews, and local delivery |
| Durable jobs | One shipped read-only data-profile job with lifecycle inspection and a bounded follow-up |
| Scheduled routines | One-time, interval, and timezone-aware calendar reads delivered to the conversation inbox |
#Capabilities and Toolboxes
Every model-facing tool is a view over an immutable registered capability and executor. The common runtime validates the tool projection, arguments, current admission, operational effects, output schema, sensitivity, provenance, and bounds.
Applicable tools are organized into six toolboxes: Files, Sources, Artifacts, Knowledge, Jobs, and Routines. Common tools are pinned into the model request. Larger surfaces use the fixed toolbox_search and toolbox_load controls to load an exact on-demand definition for the next model step.
#Persistent Agent State
Each agent home stores one SQLite state database containing the agent identity, source registrations and permissions, catalog snapshots, exact run transcripts and terminal results, memory, skills, semantic annotations, MCP bindings, artifact records, jobs, follow-ups, routines, occurrences, deliveries, and immutable write receipts. The artifact store separately owns committed payload bytes and manifests inside the agent home.
Provider keys, PostgreSQL passwords, and MCP bearer tokens are persisted only as secret references. Values are resolved lazily at the integration boundary.
One open agent home has one writer. A foreground terminal, a headless CLI process, and a resident host must hand off that writer lock rather than opening the same agent concurrently.
#Trust and Authority
The current catalog is authoritative for source and resource identity, schema, relationships, revisions, and freshness. A validated tool result is authoritative only for the values it returned.
Model text, source values, file contents, remote MCP metadata and results, memory, skills, and semantic annotations are treated as untrusted or advisory content. They cannot grant permissions, change a tool's operational effect, expand a scheduled execution scope, or replace catalog truth.