Atomic boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run analyses Atomic as a shipped personal knowledge system, not merely its Rust library or MCP endpoint. The intended use is to explain how retained notes and generated content enter storage, receive model-dependent enrichment, are maintained and admitted, and are later consumed by search, chat, wiki synthesis and reports. The target class is memory/knowledge/context-engineering system; its bounded chat and research agents are included mechanisms, not evidence that Atomic owns an external MCP client's enclosing runtime.

The boundary is whole-system: the frozen repository includes core logic, the standalone server's background drivers, the cloud composition's dispatcher, desktop and mobile shells, browser capture, frontend state consumers, plugins, import/reset utilities and evaluators. Shipped callers are included even when they communicate through HTTP or directly write SQLite. There is no excluded in-repository host supplying the material maintenance loop. This is an initial boundary trace, not a claim that every included implementation detail has already been audited.

The immutable evidence is SRC-1 at commit 983bea6baf449d060514c94b3b15b5f85f77ba9b, with applicability cutoff 2026-10-12. HEAD matches the acquisition object and the checkout reports no modifications. No other repository, website, downloaded dataset or release binary is frozen. Overall evidence is code-grounded: inspected implementation supplies operation paths, while target documentation supplies declared intent. No target code, tests, examples, benchmark or provider calls were executed. Therefore this boundary does not establish observed reliability, deployed behavior, benchmark scores or causal improvements.

Initial shipped-loop trace

1. Produce and persist. The public core create_atom writes through storage, enqueues embedding/tagging work and processes the queue. The MCP adapter calls that core path; the browser extension posts to /api/atoms; the iOS share extension posts to /api/ingest/url. Obsidian sync retains a file-to-atom mapping and updates or creates atoms. The shared command-line importer instead prepares a direct SQLite insert with pending enrichment statuses. These are included producers, not interchangeable execution paths. SRC-1: crates/atomic-core/src/lib.rs, crates/atomic-server/src/mcp/server.rs, extension/background/service-worker.js, mobile/ios/App/ShareExtension/ShareViewController.swift, plugins/obsidian-plugin/src/sync-engine.ts, scripts/import/shared/index.js.

let atom_with_tags = self.storage.insert_atom_impl(&id, &request, &now).await?; --- crates/atomic-core/src/lib.rs

INSERT INTO atoms (id, content, source_url, created_at, updated_at, embedding_status, tagging_status) VALUES (?, ?, ?, ?, ?, 'pending', 'pending') --- scripts/import/shared/index.js

1. Maintain. The standalone server supplies feed polling, registered draft-pipeline and graph-maintenance tasks, ledger garbage collection, wiki retry sweeps and scheduled report dispatch. The cloud driver is also material: its executor dispatches pipeline batches, system tasks, feed polls, wiki regeneration and reports into core routines. The desktop shell launches atomic-server as a sidecar. Thus neither the standalone scheduler nor the cloud dispatcher can be omitted by calling Atomic a library. SRC-1: crates/atomic-server/src/main.rs, crates/atomic-cloud/src/main.rs, crates/atomic-cloud/src/dispatcher.rs, src-tauri/src/lib.rs.

registry.register(Arc::new(atomic_core::pipeline_task::DraftPipelineTask)); registry.register(Arc::new( atomic_core::graph_maintenance::GraphMaintenanceTask, )); --- crates/atomic-server/src/main.rs

1. Admit generated state. Reports resolve source scope, call their agent, reject empty prose and write a finding with provenance and citations through a transactional storage helper. Wiki routes expose proposal creation, retrieval, acceptance and dismissal. Agentic wiki retrieval explicitly filters to captured atoms rather than report findings. These paths establish that generated-content admission belongs inside the boundary; the detailed correctness of each gate remains for later analysis. SRC-1: crates/atomic-core/src/reports/runner.rs, crates/atomic-server/src/routes/wiki.rs, crates/atomic-core/src/wiki/agentic.rs.

let kinds = crate::models::KindFilter::only(crate::models::AtomKind::Captured); --- crates/atomic-core/src/wiki/agentic.rs

1. Reload and consume. Chat saves the user message, reloads the conversation and its scope, builds model context and runs a bounded tool loop. Its completion path saves the assistant turn, tool calls and citations. The shipped frontend can also turn an answer into a new atom through the ordinary create path. MCP supplies retained wiki and report readers as well as atom readers and writers. These consumers are part of Atomic; downstream MCP clients are not. SRC-1: crates/atomic-core/src/agent.rs, crates/atomic-core/src/agent_runtime/run.rs, src/components/chat/saveAnswerAsAtom.ts, src/stores/chat.ts, src/lib/transport/command-map.ts, crates/atomic-server/src/mcp/server.rs.

let mut api_messages = vec![Message::system(system_prompt)]; api_messages.extend(messages); --- crates/atomic-core/src/agent.rs

export async function saveAnswerAsAtom(input: AnswerAtomContentInput): Promise { const content = buildAnswerAtomContent(input); const tagId = await findOrCreateChatAnswersTag(); return useAtomsStore.getState().createAtom(content, undefined, [tagId]); } --- src/components/chat/saveAnswerAsAtom.ts

1. Evaluate. The benchmark crate and fixtures are included consumers. The inspected LongMemEval path imports sessions as atoms, waits for enrichment, searches in hybrid mode and maps retrieved atoms back to session IDs. Its documentation distinguishes retrieval scoring from future answer-generation and judge scoring. Evaluator source is not an observed evaluation result. SRC-1: bench/README.md, crates/atomic-bench/src/suites/memory_longitudinal.rs, crates/atomic-bench/src/suites/pipeline_smoke.rs.

Top-level tracked coverage

Every top-level tracked entry is classified below. Grouped entries receive the same classification individually. “Included” fixes scope; the inspection column distinguishes an initial trace from detail not yet inspected. An available but unread file is not an access gap. Directory rows name material paths rather than treating the directory name as sufficient coverage. All rows refer to SRC-1.

External dependencies and limits

Provider implementations for OpenRouter, Ollama and OpenAI-compatible services are inside the repository; provider services, model weights and their response behavior are outside it. SQLite/sqlite-vec, PostgreSQL, Rust/JavaScript/native framework dependencies and third-party editor/platform libraries are dependencies, not separately frozen sources. Browser, Obsidian, Discord, mobile OS and MCP-client runtimes are external hosts; the shipped Atomic integration code remains included. These exclusions prevent conclusions about host internals, provider quality, dependency guarantees or the end-to-end behavior of an external autonomous agent. The declared provider and platform roles are grounded in SRC-1 README.md, Cargo.toml, package.json and the integration paths named above.

No source access gap was encountered for the frozen checkout. No runtime credentials, live cloud tenant, production logs, external provider trace or benchmark execution result was supplied. That absence prevents operational and causal conclusions, not source-level analysis. Uninspected included files are future inspection work under SRC-1, not evidence that their mechanisms are absent. Later analysis may inspect any file at this commit without adding a source ID; another revision, repository or capture requires a new evidence-boundary decision.

Source register