Spacebot boundary

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

Boundary and evidence

This run analyses Spacebot as an enclosing runtime, not merely its memory API or an OpenCode client. Its intended use is persistent agent operation across conversations, tasks and background work. The boundary is whole-system: the repository's shipped runtime, its callers and interfaces, prompts, state stores, maintenance paths and evaluators are included. “Whole-system” describes functional scope, not exhaustive inspection or demonstrated correctness of every file.

The source is SRC-1 at 5c2ee47b397e09c956dc15000ea576ecd28e92bb, with an applicability cutoff of 2026-10-14. HEAD matched that revision and the checkout reported no working-tree changes during initial inspection. The overall tier is code-grounded. Source text establishes implementation paths; documentation and prompt instructions establish intent. No target executable, test, example, model call or external service was run. Consequently this boundary supplies no observed-run or causal-experiment evidence and establishes neither production reliability nor learning quality.

Classification and shipped loop

The executable owns startup and channel execution. Cargo.toml declares the spacebot package and default executable; src/main.rs dispatches Start to cmd_start, constructs user channels, runs them, and routes their responses to adapters and SSE. The classification rests on these shipped responsibilities, not the project's use of the word “harness” (SRC-1, Cargo.toml, src/main.rs). A minimum implementation anchor is:

if let Err(error) = channel.run().await { tracing::error!(%error, "channel event loop failed"); } --- src/main.rs

The included loop spans these responsibilities:

• Admission and execution: configuration and identity loading, messaging adapters, Portal/API callers, user channels, cron scheduling, durable wakes and autonomy supervision, branches, built-in workers and Spacebot's OpenCode driver. The main executable starts these paths; a caller is not excluded because it uses the library or HTTP API (SRC-1, src/main.rs, src/agent/autonomy.rs, src/agent/channel_dispatch.rs, src/api/server.rs, src/opencode/worker.rs).
• State production and persistence: conversation logging, memory extraction branches, file ingestion, memory-save tools and associations, task/worker lifecycle stores, session chronicles, working memory, skills and instance-wide wiki storage. src/db.rs opens per-agent SQLite/LanceDB/redb and instance-level SQLite and applies both migration sets (SRC-1, src/db.rs, src/agent/channel.rs, src/agent/ingestion.rs, src/tools/memory_save.rs, src/wiki/store.rs).
• Maintenance and improvement: compactor and chronicler, cortex loops, the instance memory janitor, write-time consolidation advice, and memory-persistence passes that can reflect on completed work and write skills. Their inclusion does not assert that prompt instructions are always obeyed (SRC-1, src/main.rs, src/agent/compactor.rs, src/agent/chronicle.rs, src/agent/maintenance.rs, src/memory/consolidation.rs, prompts/en/memory_persistence.md.j2).
• Reload and later consumption: user channels hydrate durable conversation messages; channel prompt construction renders stored memory and task state, working memory and participant context; the skill loader exposes procedures to later workers. These consumers are inside the boundary rather than assumed external applications (SRC-1, src/agent/channel.rs, src/memory/render.rs, src/skills.rs, src/prompts/engine.rs).
• Operator surfaces and evaluation: web and desktop clients, shared API client, configuration/admin routes, memory and transcript displays, developer/integration tests and model-dependent behavioral fixtures. Test definitions are evidence of the evaluation design, not results obtained by this analysis (SRC-1, src/api/server.rs, interface/src/api/client.ts, desktop/src-tauri/src/main.rs, packages/api-client/src/client.ts, tests/behavioral_fixtures.rs).

The retained-state loop is visible at both ends. The persistence prompt declares the extraction responsibility:

You are a memory persistence process. You have the channel's full conversation history. Your job is to extract and preserve important information as memories. --- prompts/en/memory_persistence.md.j2

The channel's implemented consumer passes its memory store and task store to the renderer:

match crate::memory::render::render_memory_store( self.deps.memory_search.store(), &self.deps.task_store, &self.deps.agent_id, cortex_config.memory_render_max_words, ) --- src/agent/channel.rs

These passages support inclusion of production and consumption, not a claim that every extracted memory is correct. Skill maintenance instructions and built-in wiki-writing instructions are also runtime content: the binary embeds the built-in skill files through include_str! (SRC-1, src/skills/builtin.rs, skills/builtin/wiki-writing/SKILL.md). Repository-contributor skills under .agents/ are a different surface.

Repository coverage

The table accounts for every top-level tracked entry. Included directories name the material responsibilities within them. “Initial inspection” means entry-point tracing, selected bodies or tree/search inspection as stated; it is not a claim to have read every descendant. No material shipped responsibility is excluded because its implementation is large. Unread detail remains available at SRC-1, not an access gap.

Dependencies and access limits

External services and separately distributed implementations are outside the frozen source: model-provider internals, messaging-platform servers, OpenCode itself, MCP servers, browser/search services, package registries, and hosted Spacebot deployment infrastructure. Spacebot's adapters, provider routing, driver code, policy gates and deployment configuration remain included (SRC-1, Cargo.toml, src/main.rs, src/tools.rs, src/opencode.rs, src/api/server.rs). Excluding the external implementations prevents conclusions about their internal orchestration, memory, security, uptime or exact deployed behavior. It does not transfer their responsibilities to Spacebot.

Only this repository and revision are frozen. Dependencies named in manifests are not independently registered sources. There are no unavailable repository paths identified by initial inspection. No live deployment data, user database, execution trace or experimental comparison was supplied. That evidence absence prevents efficacy, throughput, recovery-under-failure and model-compliance conclusions. Files not yet read are available evidence for later jobs, not access failures. Documentation, prompts and implementation may disagree; this boundary does not reconcile those disagreements or treat intended behavior as observed behavior.

Source register