Exocomp boundary

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

Boundary and evidence

This run examines Exocomp as a self-hosted multi-agent environment for software development and related security work. Its intended use includes a human-facing planner, role-specific contractor agents, tool-mediated project work, and retained session and project records. The target is in scope as an enclosing runtime: it issues model requests, dispatches returned tool calls, starts contractor processes, and supplies its own operator interfaces. It is not merely a library consumed by an excluded application. SRC-1: README.md, source/cmds/exocomp/main.go, source/engine/Session.go, source/tools/Agents.go.

The whole-system boundary includes the shipped Go command variants, embedded role prompts, session engine, provider configuration and adapters, tools, filesystem-backed records, recovery/debug driver, terminal/JSONL/web/webview interfaces, authored browser application, packaging scripts, and test/evaluation sources. These paths are available in the frozen repository. Initial inspection traced the main entry points through session setup, model requests, tool execution, persistence, restoration and operator consumption; it is not an exhaustive implementation audit of every helper or tool method.

The decisive runtime path assembles requests from agent messages and tool schemas, then handles assistant tool calls and requests another completion. SRC-1: source/engine/Session.go.

resolved_url := session.Config.ResolveURL(session.Agent.Model, "/chat/completions") resolved_model := session.Config.ResolveModel(session.Agent.Model) resolved_token := session.Config.ResolveToken(session.Agent.Model) --- source/engine/Session.go

session.CallTool(tool_id, tool_name, tool_method, tool_arguments) --- source/engine/Session.go

Contractor execution belongs inside the target: the agents tool launches an agent-mode executable, defaulting to its own executable unless EXOCOMP_AGENT overrides it. The child receives role, prompt and sandbox parameters. SRC-1: source/tools/Agents.go, source/cmds/exocomp-agent/main.go, source/ui/jsonl/Client.go.

exe, _ := os.Executable()

if os.Getenv("EXOCOMP_AGENT") != "" { exe = os.Getenv("EXOCOMP_AGENT") } --- source/tools/Agents.go:512-516

Retained state is also part of the boundary, not just the inference loop. Recovery serializes sessions and agents; terminal and web setup reload those records. The agimus command restores an existing project session into a debug sandbox. Project tools read and write requirements, bugs and changelog records, and skills admit project-local instructions. The browser application sends chat/tool requests and reloads agent state through the shipped web API. SRC-1: source/engine/Recovery.go, source/ui/tty/Client.go, source/ui/web/Server.go, source/cmds/agimus/main.go, source/utils/engine/RestoreSession.go, source/tools/readRequirements.go, source/tools/writeRequirements.go, source/tools/readSkills.go, app/engine/Session.go.

path := filepath.Join(recovery.Playground, ".exocomp", "session.json") err2 := os.MkdirAll(filepath.Dir(path), 0755) --- source/engine/Recovery.go

Shipped prompts are operational evidence of declared role responsibilities, not proof that models follow them. They are included because they guide the same runtime that executes tools and consumes retained records. SRC-1: source/agents/planner.yaml, source/agents/NewAgent.go, source/agents/Roles.go.

• Track completed tasks of other agents via "agents.Await"
• Track created bug reports via "bugs.List"
• Track created specifications via "requirements.List"
• Track changes via "changelog.List" --- source/agents/planner.yaml

Top-level coverage

Every top-level tracked file or directory is classified below. “Included” establishes functional scope, not that every file was read. Material paths identified by the tree and scoped searches remain available for later inspection under SRC-1. No unavailable material runtime source path was discovered.

Frozen revision and limits

The evidence boundary is repository https://github.com/cookiengineer/exocomp at full commit b36f7ba1f3e2eee25bbcd2711db7d2d5d4824251, with applicability cutoff 2026-10-14. The acquired checkout's HEAD matches this pin and its working tree was clean when checked. The source object is preserved unchanged. No later commits, moving web pages or linked external repositories are included.

The overall evidence tier is code-grounded. Source inspection supports implemented control and state paths; role prompts and documentation supply doctrine/design. The stored session/debug artifacts may support narrowly scoped observed-run findings once examined in detail, but do not connect their historical execution to this commit. No target commands, examples, tests, providers or services were executed in this run. No causal experiment or measured efficacy evidence has been established.

External dependencies include OpenAI-compatible inference services and model behavior; operator project files, installed programs and project-local skills; Go and host operating-system/process facilities; and Gooey/native browser facilities for the UI. Exocomp's integration code is included, while these dependencies' implementations and arbitrary consuming projects are excluded. This prevents attribution of model quality, external tool correctness, operating-system isolation or external GUI behavior to Exocomp itself. The authored UI path is available, but generated web assets are absent from the tracked tree and app/go.mod replaces Gooey with a sibling checkout. That gap prevents claims that this frozen checkout alone is a complete runnable browser distribution; it does not remove the shipped UI caller from the functional boundary. SRC-1: README.md, source/engine/Session.go, source/tools/readSkills.go, app/go.mod, app/build.sh, .gitignore, source/ui/web/Server.go.

Source register