renezander030/agentic-task-system

ats is an **MCP server and CLI that keeps AI-agent context in the task systems you already maintain** — TickTick, Taskmaster, Beads, Obsidian, Notion, GitHub, Airtable, Google, or several at once through the composite adapter. It retrieves relevant tasks, notes, decisions, and runbooks with provenance, then can write results back when the active adapter supports writes. Works with Claude Code, Claude Desktop, Cursor, and any MCP client.
**Adapter, not migration.** Your task app, repository, or vault remains authoritative. ATS maps that source into a common task contract; optional caches and vector indexes improve retrieval but never become a second record that people must edit. It is **task-first**: the task is the spine, while supporting material such as GitHub issues and Notion specs is retrieved as context behind it.
**Two layers, one CLI: tasks and a knowledge graph.** The task layer is record-based on purpose — every entry lives in one backend's projects and fields, and that backend stays authoritative. A record-based layer structurally cannot hold the other thing agents accumulate: durable knowledge **written from any source, about mixed subjects, into one space**. The knowledge-graph layer — **ats kg** (kg = knowledge graph) — is ATS's answer to exactly that: subject–predicate–object facts with provenance and temporal validity, proposed by agents from anywhere (a call, a task, a repo, a chat), ratified by a human, and queried in one place no matter which backend the surrounding work lives in. The built-in store is embedded and dependency-free. For a dedicated graph engine, the recommended pairing is **Graphiti as the graph database server** and **LadybugDB as the embedded graph database**: ats kg export --cypher emits a LadybugDB-loadable script (--dialect neo4j|falkordb for the server engines, re-runnable), and ats kg export --graphiti emits episode JSONL with the provenance record for a Graphiti ingest pipeline.
One ats find across GitHub + Notion + TickTick . ATS ranks the available retrieval branches with RRF and retains result provenance.
Architecture and trust boundaries
ATS separates the authoritative record from the retrieval machinery around it:
- **The backend remains authoritative.** ATS does not ask users to edit a duplicate memory database. Writes go through the active adapter, which owns backend-specific authentication, field mapping, and deep links.
- **Retrieval state is derived, not canonical.** Core keeps a five-minute corpus cache by default. Dense retrieval is optional: adapters can provide embeddings, and the TickTick reference adapter can use Qdrant plus Ollama. Without vectors, keyword and adapter-native branches still run.
- **Credentials stay at the adapter boundary.** A composite adapter delegates authentication to each child and stores no additional cross-source credential. Its children still execute inside one ATS process; this is routing separation, not process isolation. Local stdio does not expose an MCP port. The hosted blueprint adds a bearer-token gateway, private Qdrant/Ollama services, and a separate public demo backend for the optional operator deck.
- **Core reports the failures it can see.** Retrieval branches and top-level composite corpus failures return degraded and warnings. Known omission paths inside adapter fallbacks are called out under Tradeoffs and limits.
- **State changes are traceable.** Results carry source provenance; find --explain exposes RRF contributions; writes use patch semantics, and supported writes can retain before-images for undo.
The corpus cache can contain full task records; the query log contains search text; the action ledger can contain write before-images; and Qdrant payloads can contain task text and metadata in addition to embeddings. ATS does not apply application-level encryption or runtime redaction to these copies. Scope host access, backups, retention, and deployment to the sensitivity of the underlying task systems. See retrieval, state integrity, and the deployment guide for the exact behavior.
Deployment choices
| Mode | Retrieval | Trust and operations boundary |
| --- | --- | --- |
| **Local stdio** | Keyword/native retrieval by default; dense retrieval only when the adapter provides it | The MCP endpoint is not network-exposed. Adapter calls may still reach their source systems; credentials and cache files stay on the machine running ATS. |
| **Composite adapter** | One combined child corpus; Core ranks keyword and unioned native-search branches, with RRF across those available branches. The composite does not currently expose child vector search. | Each child owns its auth and mapping but runs in the same ATS process. A top-level child corpus failure is reported as degraded; see the known fallback gaps below. |