Phantom boundary

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

Boundary and evidence

This run examines Phantom as a deployed autonomous co-worker service, not merely its memory API or SDK wrapper. Intended use is to establish how the shipped service admits work, calls models and tools, retains state, maintains learned content and supplies that content to later work. The target class is enclosing runtime: Phantom owns service startup, ingress, session coordination, prompt construction, persistence, scheduled work and learning orchestration. It delegates the inner model/tool execution loop to a selectable Agent SDK. The boundary is whole-system at the repository revision, not a claim that dependency internals or a cloud deployment have been inspected. [SRC-1: package.json, src/index.ts, src/agent/runtime.ts, src/agent/agent-sdk.ts, src/agent/agent-sdk-loader.ts]

The project's declared composition is:

Phantom is a single Bun process that runs on a VM. It combines an agent runtime, memory system, self-evolution engine, MCP server, and multi-channel communication into one process. --- docs/architecture.md

Entry points and state-loop coverage

The executable chain is package.json's phantom bin → src/cli/main.ts → src/cli/index.ts → src/cli/start.ts → src/index.ts. The direct start script and Docker entrypoint also reach src/index.ts. These shipped drivers are included, not treated as external callers. Startup wires the database, vector memory, evolution engine and cadence, MCP tools, scheduler, channel router, web-chat stores and HTTP service. [SRC-1: package.json, src/cli/main.ts, src/cli/index.ts, src/cli/start.ts, scripts/docker-entrypoint.sh, src/index.ts]

// Import and run main directly await import("../index.ts"); --- src/cli/start.ts

Functional inclusions cover these distinct paths; their existence does not establish identical learning behavior across ingress types:

• Channel work and post-response learning: the router callback calls runtime.handleMessage, delivers its response, invokes vector-memory consolidation when ready, and submits session summaries to evolution. Feedback has a separate evolution submission path. [SRC-1: src/index.ts, src/memory/consolidation.ts, src/evolution/engine.ts]
• Web chat and later consumption: startup wires dedicated chat stores and a handler rather than routing its hot path through the channel callback. ChatSessionWriter persists user/assistant messages, stream events and durable run timelines, and calls runtime.runForChat with context rebuilt from retained events and timeline artifacts. Web chat remains inside the boundary; the channel callback's post-response learning must not be attributed to it without tracing its own callers. [SRC-1: src/index.ts, src/chat/http-handlers.ts, src/chat/writer.ts, src/chat/continuity-context.ts]
• Other admitted work: scheduler execution and the HTTP trigger call the runtime directly. Their inclusion prevents treating the router callback as the only driver. [SRC-1: src/scheduler/executor.ts, src/core/server.ts]
• Vector memory: consolidation creates episodes and heuristically extracted facts; the context builder recalls facts, episodes and procedures under a prompt budget. This is distinct from file reflection. [SRC-1: src/memory/consolidation.ts, src/memory/context-builder.ts]
• File memory and maintenance: evolved configuration, agent-written notes, working memory, SDK user/project settings, dashboard memory-file editing, installed skills and the reflection teaching prompt are included. The assembler injects evolved sections and instructions, while agent notes are deliberately left for tool-mediated reading rather than automatic injection. [SRC-1: src/agent/prompt-assembler.ts, src/agent/prompt-blocks/evolved.ts, src/agent/prompt-blocks/agent-memory-instructions.ts, src/agent/runtime.ts, src/memory-files/paths.ts, src/memory-files/storage.ts, scripts/docker-entrypoint.sh]
• Learning admission and refresh: the evolution gate feeds a persistent queue; the reflection subprocess writes permitted files, checks post-state and commits or restores snapshots. Startup registers a callback that refreshes the live runtime's evolved configuration after applied changes. Shipped tests and evaluators are included as executable specifications, not test results. [SRC-1: src/evolution/engine.ts, src/evolution/reflection-subprocess.ts, src/index.ts, e2e/reflection-subprocess.spec.ts, .github/workflows/ci.yml]

Two short passages establish that the inspected boundary reaches both admission control and subsequent consumption, rather than ending at a write API:

if (!invariant.passed) { restoreSnapshot(input.config, snapshot); --- src/evolution/reflection-subprocess.ts

engine.setOnConfigApplied(() => { runtime.setEvolvedConfig(engine.getConfig()); }); --- src/index.ts

Top-level tracked coverage

The tracked tree was enumerated at the pin. Every top-level tracked entry is classified below. “Included” means within the functional/evidence boundary, not that every file has already been read. Initial inspection is identified separately; unread available material is not an access gap. All paths in this table belong to SRC-1.

Frozen evidence and external limits

The acquired checkout's HEAD was verified as f8c7ab42d885936ee54abc785528000260f4acc5; its status was clean. This exact Git object is the sole frozen source. analysis-cutoff is the supplied run date, 2026-10-15, not a claim that the revision reflects subsequent upstream changes. Evidence tier is code-grounded: source text establishes implemented branches and wiring; target documentation establishes declared intent. No target code, examples, tests, providers or services were executed.

External dependencies are not omitted Phantom subsystems. The Anthropic Agent SDK, optional Murph-compatible runtime/module override, model providers, Qdrant, Ollama, Bun/SQLite, browser/MCP packages and channel/email services supply external execution or storage. Phantom's configuration, invocation, adapters and consumption of them are included; their own implementation is not in this source. This prevents conclusions about provider internals, SDK-enforced sandbox effectiveness, storage durability under failure or end-to-end model quality. [SRC-1: package.json, src/agent/agent-sdk.ts, src/agent/agent-sdk-loader.ts, src/evolution/reflection-subprocess.ts, docker-compose.yaml]

Cloud fleet provisioning, metadata gateway/server implementations and the external phantom-cloud-deploy fixture are not frozen here. Shipped metadata clients, readiness wiring, identity overlays and CI references remain included. The external gap prevents conclusions about fleet isolation, provisioning correctness and cross-repository fixture agreement. [SRC-1: src/index.ts, .github/workflows/ci.yml]

No independent execution trace or causal experiment has been registered. Available but unread target-authored verification records are not access gaps and are not silently counted as observed runs. This boundary supports source-grounded analysis of the shipped service, not claims of successful deployment, learning benefit or cross-channel learning equivalence.

Source register