CORAL boundary

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

Boundary and evidence

This run examines CORAL as infrastructure for autonomous coding-agent experiments: task admission, agent launch and supervision, retained shared knowledge, evaluation, feedback and subsequent iteration. The intended use is to explain the shipped organization of that loop, including which responsibilities are executable and which depend on agents following prompts. It is not an evaluation of solution quality or proof that knowledge sharing improves outcomes.

The target class is enclosing runtime: CORAL owns the outer multi-agent run, while installed coding-agent harnesses own their inner model/tool turns. This does not attribute those harnesses' internal reasoning, compaction or tool policy to CORAL. The classification follows the shipped executable entry point and driver, not only the README. The package exposes coral.cli:main; the start command validates a task, creates an AgentManager, launches its agents and enters monitoring. The manager creates workspaces, starts supporting services and launches runtime adapters. For example, the Pi adapter constructs a pi command and launches it with subprocess.Popen (SRC-1, pyproject.toml, coral/cli/start.py, coral/agent/manager.py, coral/agent/builtin/pi_agent.py).

description = "Orchestration system for autonomous coding agents" --- pyproject.toml

manager = AgentManager(config, verbose=verbose, config_dir=config_path.parent) handles = manager.start_all() --- coral/cli/start.py

The whole-system functional boundary includes the CLI and its shipped callers, workspace and isolation setup, runtime adapters, gateway and sandbox integration, grader infrastructure, attempt records, single- and multi-island state, heartbeat and steering, warm-start and migration paths, generated instructions and seeded skills, and operator/dashboard consumption. The plugin is a shipped authoring/operation surface, not an excluded enclosing application. Example task configurations and graders are included as consumers of the same framework; they do not establish that every task or external benchmark has been reproduced.

The retained-state loop is material to this boundary. Project creation seeds bundled skills and subagent templates, preserves an existing agent role, and initializes a shared-state checkpoint repository. Worktree setup exposes notes, skills, roles, attempts and other island state through symlinks. Agent-facing instructions ask agents to read existing notes before implementation and update knowledge after evaluations. The consolidation prompt prescribes synthesis and role auditing. These are doctrine/design evidence, not evidence that an agent complied (SRC-1, coral/workspace/project.py, coral/workspace/worktree.py, coral/template/coral.md.template, coral/hub/prompts/consolidate.md).

1. Read notes: Start with {shared_dir}/notes/index.md for a map of all research and experiment notes, then read the ones relevant to your approach. --- coral/template/coral.md.template

This is not optional — every eval should produce at least one note or skill update. --- coral/template/coral.md.template

The executable evaluation path connects that state to later decisions. coral eval calls submit_eval, which commits the candidate, checkpoints shared state and writes a pending attempt. The daemon grades an isolated checkout and writes a finalized attempt. The manager reads scored attempts to select heartbeat actions and construct feedback. Notes are reloaded from files by the hub, CLI and dashboard rather than being an unused library API (SRC-1, coral/cli/eval.py, coral/hooks/post_commit.py, coral/hub/checkpoint.py, coral/grader/daemon.py, coral/agent/manager.py, coral/hub/notes.py, coral/cli/query.py, coral/web/api.py).

Checkpoint shared state at submission time (captures agent's current notes/skills).

shared_state_hash = checkpoint(str(coral_dir), agent_id, message, island_id=island_id) --- coral/hooks/post_commit.py

Repository coverage

The tracked top-level tree was inventoried at the pinned commit. “Included” identifies the functional evidence boundary, not a claim that every file was read. Initial inspection below distinguishes traced paths from inventoried paths awaiting detailed analysis. There was no unavailable material shipped path at boundary establishment; uninspected files are not access gaps. All rows refer to SRC-1.

Frozen evidence and external limits

The source is the acquired, read-only Git checkout at full commit 0123dfb939b35228cf2c1fde224cd0561e727408. HEAD matched that revision and Git reported no working-tree changes. The applicability cutoff is 2026-10-15, the supplied run date; it does not claim that the checkout represents all changes through that date. The overall tier is code-grounded because the classification and loop boundary are grounded in executable source. Documentation and prompts remain separately identified as doctrine/design evidence.

External coding-agent installations, model providers and credentials, host OS/process behavior, Git, Docker/tmux, installed Python dependencies and task-specific data/services are dependencies, not separately frozen sources. Only CORAL's shipped adapters, configurations and integration code are inside the evidence boundary. Consequently this run cannot establish those external implementations' internal policies, actual service behavior, effective security isolation in a deployment, or successful benchmark reproduction. External papers and linked live documentation are not added as evidence. No target code, tests or examples were executed, and no observed-run or causal-experiment evidence was established.

Source register