Scope Boundary

Scope Boundary

Columbus is intentionally small. It does three things — index, search, memory — and deliberately refuses a fourth.

What Columbus is

A local-only, deterministic context server that an agent calls as a tool. It stores and retrieves; it never drives.

What lives in Columbus

• Indexing the codebase (tree-sitter) and embedding it on-device
• Natural-language semantic search and show
• The dependency graph
• Durable memory (decisions, patterns, failures, …)
• Structured memory (epics → stories → tasks) as a passive, durable record

What does NOT live in Columbus

• Orchestration — running workers, worktrees, verification, preflight
• Guardrails / policy — what the agent may or may not do
• Workflow control — gating or enforcing state transitions
• LLM calls — ranking and hints are deterministic heuristics

These belong to the agent / plugin layer (its hooks, commands, skills, and agents). Columbus is the trustworthy data layer underneath.

Work is recorded, not enforced

Structured memory stores epics, stories and tasks with a status field from a fixed vocabulary — todo, in_progress, blocked, done, cancelled. Columbus records transitions in an append-only event log but enforces no order: any status can move to any other. It will not block, gate, or "advance" work. The agent (or you) decides; Columbus remembers. See Tracking Work: Epics, Stories & Tasks.

Why keep it this small

A small, single-purpose tool is easy to trust, test, and reason about. By refusing orchestration and policy, Columbus stays deterministic and side-effect free — exactly what you want from the component that feeds an autonomous agent.

Related

Using Columbus with Your Agent · How Columbus Works