Exo synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From request to harness-owned action
Exo is an enclosing runtime around interchangeable agent harnesses. It supplies durable state, turn coordination, sandboxes, credentials and network controls; the selected harness owns model requests, context construction and action selection. This account covers the shipped repository, including its older persistent-agent experiment and Harbor evaluation caller, at commit 423d7d0f4394a1ddc9955d13c73c9f8a9c4d4e7e, with cutoff 2026-10-15. SRC-1 supplies static implementation and source-authored design evidence, not observed runs or causal experiments. External providers, native-agent internals and deployed state are outside that evidence. “Whole-system” describes the functional boundary, not exhaustive inspection of every implementation branch. See the boundary and Source register.
An ordinary local invocation loads an agent definition, opens or resumes a thread and submits a turn. Definition admission can change instructions, model, harness and resources; sensitive changes require operator authority when a scoped caller exists. Queue admission captures configuration and gives the work a durable identity. The coordinator, rather than the terminal connection, owns progression. Basic then builds context from instructions and prior events, lets the configured model propose answers or tools, authorizes actions before dispatch, journals results and continues. Its final-answer/completion commit records a completed runtime turn, not independently verified task success. See RT-RTE-definition-admission and RT-RTE-managed-turn.
This execution map branches materially. The TypeScript Responses loop reconstructs messages and its tool registry each round. Native bridges instead invoke agents such as Codex or Pi, whose own loops retain control over model/context behavior. RLM makes separate, no-tool model requests over foreground-selected text; an answer preview and optional JS value return, not a shared context. Scheduler results can wake an owner conversation without a terminal user, and the hosted runtime has its own queue-draining wake mechanisms. These are distinct ownership and recovery routes, not interchangeable implementations of one policy. See RT-RTE-responses-loop, RT-RTE-native-bridge, RT-RTE-rlm-subquery and RT-RTE-background-wakeup.
For a disconnected-client scenario, durable admission is the supported architectural contribution: accepted work need not disappear when waking a worker fails. It still requires storage durability and a later host wakeup. Basic can reconstruct committed model rounds, but refuses unsupported unresolved-tool replay; Codex has different reattachment guards. Neither route establishes exactly-once external effects or universal successful resumption. Capability control is similarly path-specific. Host Node imports, custom harness code and guardian commands do not acquire sandbox isolation merely because shell tools use a sandbox. See RT-CLM-recovery-scope and RT-CLM-isolation-scope.
Carrying context into later work
The persistent-agent profile adds three different retained-content channels. Agent-wide facts are pushed in full during instruction assembly, up to the writer's 200-entry cap and 600-character entry limit. Conversation-local plans are replayed only while an item remains open. Skills push a catalog of names and descriptions; the foreground model requests a selected body or bundled file. These mechanisms provide continuity through later consumers rather than merely exposing unused storage. They do not implement a universal relevance selector or total context budget. See MEM-RTE-fact-revision, MEM-RTE-plan-replacement and MEM-RTE-skill-lifecycle.
Admission checks shape, length, names and paths, not factual truth or procedural usefulness. Saved facts are labelled authoritative in developer messages without mandatory source evidence or reasons. The label requests model reliance; it does not warrant the proposition. Plan completion is likewise a caller assertion. Web acquisition adds outside assertions, but transport checks and text extraction do not endorse them, and extraction can remove qualifications. No evidence-consuming factual acceptance or subsequent lifecycle integration is established for these inspected writers; that is not a system-wide absence claim about arbitrary tools or hosted agents. See EPI-RTE-memory-write, EPI-RTE-memory-read, MEM-RTE-plan-replacement and EPI-RTE-web-access.
Withdrawal has different reach on each channel. Forgetting removes a fact from current injection while version history and earlier conversation copies can remain. Closing every plan item suppresses injection without deleting the artifact. Uninstalling a skill removes catalog membership and blocks the catalog-mediated body route, but a known bundled-file path can still be read directly. Corrupt facts block writes and produce a warning; corrupt plans can instead disappear from injection. These distinctions prevent treating removal as global revocation or recovery as one transaction across state planes. See MEM-RTE-fact-revision, MEM-RTE-plan-replacement, MEM-RTE-skill-lifecycle and MEM-RTE-sandbox-rewind.
Context reduction is also route-specific. Responses tool results retain full bytes in artifacts, keep a full inline value only at or below 8,000 serialized characters, and cap the preview at 4,000. That is deterministic offload and prefix reduction, not semantic summarization; a pointer does not automatically reload omitted evidence. Codex replay instead preserves call/output units in chunks and requests native compaction between chunks. Its resulting continuation payload is opaque. RLM's separate-context requests resemble temporary frames with selected input and value return, but do not establish cross-turn JS restoration or automatic dereferencing of offloaded text. See MEM-RTE-result-offload, MEM-RTE-codex-compaction and RT-RTE-rlm-subquery.
The strongest supported trace-fed contribution is implemented continuation: result normalization, scheduler feedback formatting and Codex replay compaction automatically turn recorded activity into retained material supplied to a later invocation. Under the memory comparison's write-route meaning, these qualify as wired trace learning. Tool results and scheduler execution feedback supply tool traces; Codex replay also consumes session messages. This does not establish improved future capacity, faithful native summarization or reusable lessons. Foreground fact, skill and code proposals do not by themselves establish their trace origins. All ten memory comparison axes remain partial, as confirmed by profile verification; the underlying mechanisms are MEM-RTE-result-offload, RT-RTE-background-wakeup and MEM-RTE-codex-compaction.
Changing capabilities and the running system
Exo can retain changes beyond conversation text. Reusable-tool installation validates and publishes modules that later registries reload. Import and initialization can already execute host code during validation, before publication or later handler authorization. A failed installation's cleanup cannot undo arbitrary import-time effects. This is a wired capability-change path, not a semantic safety or improvement gate. See RT-RTE-tool-admission and RT-BAP-installed-code.
For own-source maintenance, the practical profile exposes a deferred guardian build/restart tool. A writable source tree and host maintenance permission are required. Its immediate result is a queued update identity; the detached script waits two seconds, not for proof that the requesting turn ended. Successful build/restart can put changed code into later services, while outcome recording can itself fail. Development hooks and CI contain real bounded checks, but the ordinary guardian build does not invoke those hook gates. Neither build success nor finite tests certify improvement. See RT-RTE-guardian-update, RT-BAP-rebuilt-services and EPI-RTE-development-checks.
The strongest supported self-change result is therefore conditional executable activation capacity, not exercised self-improvement. For the local Exo source/runner/services over rebuild to later service turns, no independently specified improvement objective and actual evidence-responsive update are supplied. The causal link from objective-bearing evidence to update determination, and the link from changed organization to subsequent exercised behavior, remain unestablished. Build/load pathways implement possibilities for the intervening links. The recursive-improvement design claim does not supply the missing events or a successful outcome. See RT-RTE-guardian-update and EPI-CLM-recursive-improvement.
These independent assessments must not be collapsed into a grade:
- Theory-builder condition 1, localized content: facts and skills could carry formulated theories, but no supplied theory instance establishes this condition for a theory-building episode.
- Condition 2, consumption: instruction delivery is wired; decisions depending on what a particular theory says are not established.
- Condition 3, content-directed criticism: no supplied instance identifies a challenged claim, blame placement and resulting revision or changed reliance.
- Condition 4, iteration: retention exists, but no supplied criticism result is shown shaping a next round.
- Learning from criticism of consumed theory: improved capacity for future action is unestablished, independently of the wired continuation updates above.
- Reflection: self-inspection and maintenance instructions are available, but a complete self-representation loop with both causal directions is not established.
- Autonomy: unattended task continuation is wired; role-by-role computational performance of every internal theory-building operation is not established.
- Self-improvement: own-organization change is wired conditionally; exercised evidence-responsive change and successful improvement remain unobserved at the declared horizon.
These are evidence limits, not proofs of impossibility or absent model processing. They follow the separate assessments in RT-RTE-guardian-update and the epistemic bounded conclusion.
A task attempt and its delivered evidence
The representative multi-step workflow is a Harbor evaluation trial. The plugin binds one shared agent and requires sequential trials for the default Exo harness. The driver creates a trial conversation, rejects ambiguous Docker-container matches, attaches Harbor's container and sends the task through the Exo profile. Existing agents are reused without reapplying the requested model. The task caller provides neither an expected answer nor an independent answer-review stage. On failure or timeout the driver attempts trajectory export in finally; it does not retry, and resume is unsupported. Killing the CLI subprocess does not prove cancellation or rollback of every effect. See WF-RTE-harbor-trial.
Its durable delivery is metadata plus an attempted trajectory file, not the discarded CLI answer value. The exporter reads one page of at most 10,000 selected events, does not follow the cursor, and may use already truncated previews. Export failure is suppressed after logging. Thus a delivered artifact, runtime completion and correct task outcome are three separate conclusions. Sequential shared state creates an opportunity for later changes but supplies no grade-driven update or measured learning. For evaluation scenarios, this wiring supports inspectable partial-attempt salvage, not a benchmark-performance or improvement conclusion. See WF-OBJ-trajectory, WF-RTE-harbor-trial and EPI-RTE-harbor-task.
The account would change with pinned execution evidence showing recovery across named failure points, full-result retrieval into an actual later model request, or an objective-bearing maintenance episode tracing evidence through update selection, activation and subsequent dependent behavior. Demonstrated benefit would additionally require outcome evidence and a comparison whose design supports the claimed attribution. Neither verification adds execution evidence; report verification and profile verification found no blockers or additional declared limits. This synthesis adds no source reads or records.
Limitations
| limitation | affected SRC IDs and record citations | inspected boundary | conclusion prevented | evidence that would resolve it |
|---|---|---|---|---|
| Static evidence only | SRC-1; RT-RTE-managed-turn, WF-RTE-harbor-trial | Frozen shipped implementation and design; no target execution | Successful activation, recovery reliability, model compliance, task success or measured benefit | Pinned run artifacts showing the named route, inputs, results and later consumers; controlled comparisons for causal benefit |
| Recovery and isolation depend on path and deployment | SRC-1; RT-CLM-recovery-scope, RT-CLM-isolation-scope, RT-RTE-background-wakeup | Basic replay guards, selected native bridges, host Node and scheduler/host wakeups | Universal safe resumption, exactly-once effects, eventual execution or whole-runtime isolation | Backend and grant configuration, external contracts and failure-point traces covering each claimed path |
| Opaque dependencies and incomplete alternative coverage | SRC-1; RT-CMP-model-binding, RT-RTE-native-bridge, MEM-RTE-sandbox-rewind, RT-RTE-background-wakeup | Provider/native internals external; Claude/Cursor, adapter lifecycle, hosted retention, UI selection, full fork lineage and checkpoint fidelity not comprehensively inspected | Fixed model identity or parameter-update conclusions, complete memory inventory, complete lineage or cross-harness/backend parity | Accepted records inspecting the material included alternatives; separately frozen dependency evidence and backend restoration traces |
| Stored bytes do not ensure complete model context or export | SRC-1; MEM-RTE-result-offload, MEM-RTE-codex-compaction, WF-OBJ-trajectory | Prefix offload, opaque native compaction and single-page export | Universal full-result reload, preserved native rationale, complete model-visible evidence or complete trajectories | Recorded model-facing reload consumer, inspectable native checkpoint lineage, and pagination/full-output export evidence |
| Content provenance and acceptance are unresolved beyond structural admission | SRC-1; EPI-RTE-memory-write, EPI-RTE-memory-read, EPI-RTE-web-access, MEM-RTE-skill-lifecycle, RT-BAP-harness-instructions | Inspected fact/skill/web writers and mutable guidance; initial authorship, generic caller control and actual contents unsupplied | Authenticated truth, per-content human approval, universal epistemic acceptance or complete trace-origin classification | Content instances with provenance, admission decisions and intended-use criteria; evidence of the actual later reliance route |
| Own-source change and continuation do not demonstrate improved capacity | SRC-1; RT-RTE-guardian-update, EPI-CLM-recursive-improvement, MEM-RTE-codex-compaction | Guardian activation pathway and trace-fed continuation; no formulated criticism episode or comparative outcomes | Exercised self-improvement, learning benefit, completed reflection loop or theory-builder conditions 1–4 | Objective-responsive update trace through later dependent operation; separately evidenced theory consumption, criticism and iteration; comparative outcome evidence for benefit |
| Evaluation grading and later artifact use are external and uninspected | SRC-1; EPI-RTE-harbor-task, WF-OBJ-trajectory | Shipped Harbor driver, shared-agent plugin and exporter only | Oracle-domain judgment, benchmark success, grade-responsive adoption or trajectory-fed learning | Frozen grader criteria/results and a recorded feedback-to-update/later-consumer chain |