Archie synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
Archie's inspected agent mechanism is a runtime client: shell functions configure and invoke the external coding-agent executable omp. It does not implement the agent's model/tool loop. This account covers that subsystem, its deployment/loading chain and its planned documentation assistant as design context, not the whole desktop distribution. Evidence is SRC-1 implementation and doctrine/design at commit 76caf94548cf76f2399d9a7446da15e0daa22685, with an applicability cutoff of 2026-10-15. No target executions, agent sessions or causal experiments support the analysis (boundary and evidence, Source register).
From profile selection to configuration change
The shipped installer requests deployment of the shell packages; shell initialization and a file-existence check then make the profile definitions available. This is wired code delivery, not observed installation or accumulated agent memory (RT-RTE-shell-load). A representative caller invokes omp:gpt, an alias for omp:openai. Seven profile functions and four aliases expose different model-role presets. The shell deterministically selects arguments; multiple role names do not establish multiple agents, isolated contexts or an executed planning stage (RT-RTE-profile-launch).
Before launch, every profile calls a shared helper. It requests the external modelRoles JSON value, replaces .default with the profile's fixed selector, and submits the whole result to omp config set. For ordinary object input, the symbolic transformation preserves non-default fields. The helper's minimum source passage and admission account establish this implemented request, not successful durable storage (RT-OBJ-model-roles, RT-RTE-default-update). The documented preservation contract must therefore be read conditionally, rather than as a transaction guarantee; some documented model selectors also differ from executable selectors (EPI-CLM-profile-contract).
The strongest supported retained-state contribution is this automatic configuration revision and a concrete later helper request for the whole configuration. It is not merely a passive launcher. However, the previous default is overwritten on that later request, while other ordinary fields survive mechanically. This does not establish that a later agent chooses its model from the retained default: profile launches supply their own explicit model option, and external default precedence is uninspected (memory read-back, RT-RTE-default-update). The retained backend and initial provenance are unknown. Symbolic consumption, deterministic subsequent derivation and request-driven read-back are supported; downstream retained-content authority remains unresolved (profile verification).
Operational gating and external handoff
A nonzero helper return stops a profile before launch. That gate checks shell continuation, not answer quality, provider readiness or factual warrant. It also does not guarantee detection of every getter failure: the helper's pipeline lacks an established pipeline-failure setting, so an upstream failure need not produce a failing final pipeline status. There is no wrapper schema check or read-after-write verification. Whole-object read/modify/write has no wrapper lock or compare-and-swap, and a later launch failure causes no compensating restoration of the old configuration (RT-RTE-default-update).
After helper success, foreground omp receives role selectors and unchanged appended caller arguments. The external runtime owns option precedence, model scheduling, context construction, tool authority, recovery and any final answer. Its output is not synthesized or accepted by the wrapper; its final command ordinarily supplies the function's return status. This supports launch preparation and handoff, not an established multi-step agent task through accepted delivery (RT-RTE-profile-launch, workflow account). Direct omp calls bypass the helper and presets, and user shell overrides can alter command resolution (RT-RTE-direct-handoff).
Two scenario-relative conclusions follow. For choosing a predefined launch configuration, the source establishes fixed argument construction and a prerequisite configuration update request. For local-only execution, the omp:local alias supplies no such guarantee: its Qwen profile requests OpenAI-Codex auxiliary roles. This establishes mixed selectors, not observed remote calls or data export. For constrained documentation assistance, the launcher supplies no implemented documentation-only envelope (runtime alternatives, RT-BAP-role-arguments).
Planned assistance and improvement claims
The optional documentation assistant remains Planned. Context injection, restrictions on edits and commands, provenance presentation and fallback are decisions still to define. Those intentions cannot be attached to the existing launcher as permissions, trusted retrieval or answer acceptance (RT-CLM-assistant-guide). No inspected answer instance or evidence-consuming acceptance decision establishes acquisition with preserved warrant, checked derivation, accepted conjecture or post-acceptance integration. External answers and model processing remain uninspected rather than presumed absent (epistemic conclusion).
The implemented configuration change is a supported operational contribution, but no comparison establishes improved capacity for future action. Its inputs are configuration and a fixed profile literal, not evaluated task outcomes. The runtime establishes no formulated-theory route: condition 1 (localized theory), condition 2 (content-dependent consumption), condition 3 (content-directed criticism) and condition 4 (retained criticism shaping another round) are each unestablished for this mechanism. The same evidence does not establish reflection or autonomous theory building; automatic shell dispatch is not evidence that computation performs an entire theory-building process. These are separate findings, not a combined grade (RT-RTE-default-update, epistemic conclusion).
Self-improvement is likewise not established for the selected subsystem. The visible change is not selected by evidence bearing on an independent improvement objective, and no subsequent operation is shown causally depending on that change. Persistence requests alone close neither gap. Provider parameter changes and exact model revisions remain separately uninspected for every selector; changing a selector does not establish changing weights (RT-CMP-model-services).
Pinned external getter/setter and parser implementations could resolve storage and precedence questions. Traces linking configuration writes to later consumers could establish activation and delivered work. An implemented assistant with concrete restrictions, context selection and acceptance decisions would change the design-only assessment. Improvement claims would additionally require evidence-responsive updates and comparisons at the claimed boundary, rather than successful launches alone. Independent report verification and profile verification found no blockers or additional declared limits. No new source reads were needed for this synthesis.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| External persistence, initialization and consumer semantics are opaque. | SRC-1; RT-OBJ-model-roles, RT-RTE-default-update, RT-BAP-role-arguments | Complete wrapper helper and its callers; external backend and role interpretation not frozen. | Durable or atomic preservation, complete initial lineage/admission classification, and model selection caused by retained configuration. | Pinned getter/setter and default-consumer implementations, plus write/read/consumption traces. |
| External agent execution and actual task delivery are not evidenced. | SRC-1; RT-RTE-profile-launch, RT-RTE-direct-handoff, RT-CMP-model-services | Shell argument construction, status gating and handoff; runtime/providers outside the implementation boundary. | Successful activation, internal delegation or context policies, effective permissions, answer acceptance, delivered task success and causal benefit. | Frozen external implementation and inspectable request-to-result traces with applicable grants and acceptance criteria; controlled comparisons for causal benefit. |
| Documentation guidance and its safeguards remain design requirements. | SRC-1; RT-CLM-assistant-guide | Assistant epic/work item and inspected profile/dispatch paths. | Implemented documentation retrieval, context budgets, provenance checking, mutation restrictions or accepted documentation answers. | Shipped assistant routes and evidence of their selectors, enforcement points, evaluators and consumers. |
| Configuration replacement does not establish learning or self-improvement; initial production and model internals remain unresolved. | SRC-1; RT-RTE-default-update, RT-OBJ-model-roles, RT-CMP-model-services | Fixed helper transformation and symbolic service selectors, without outcomes, update histories or numerical state. | Improved future capacity, exercised evidence-responsive self-change, a complete trace-origin classification, or model parameter/fixed-version conclusions. | Retained-input provenance and update histories; evidence linking an independent objective to a live organizational update and later dependent operation; pinned model state and comparison evidence where relevant. |