Echel synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
Capture product meaning, then choose work
Echel is a product-memory and context-engineering system, not the enclosing agent runtime. This account covers the shipped repository at aee36de4d2d1c404fb36e9ad68cc0a920784ee61, with an analysis cutoff of 2026-10-15. SRC-1 supplies inspected implementation, declared methodology and an attributed synthetic benchmark result. No target commands, tests or examples were executed. Hermes internals, provider behavior and deployed identity controls are outside the evidence. The boundary and Source register identify the frozen source; the account below uses accepted records, without additional source inspection.
The architecture has two consequentially separate storage and workflow families. Current CLI initialization creates a canonical schema-versioned project and proposed raw-idea claim under .echel/records, with colon-namespaced identities. The work/context/run commands instead use legacy FileStore project, knowledge and work shapes with uppercase IDs. Even the shared project filename does not make the envelopes compatible. Thus the shipped CLI does not establish a continuous fresh-init-to-agent journey. The supported execution sequence starts with existing legacy state, which the in-repository initialization API can create. See RT-RTE-idea-init, RT-RTE-file-workflow and the workflow account.
Within that starting condition, the caller decomposes work and supplies objectives, acceptance criteria, verification commands and explicit knowledge relationships. Echel checks referenced records exist and persists the work packet; it does not thereby approve their truth. Its legacy stage gate checks accepted/validated knowledge kinds, but permits a force bypass, and knowledge writes can directly use caller-selected accepted status. These are caller-driven commands, not an autonomous scheduler or a model-generated implementation plan (RT-RTE-file-workflow).
Select context and delegate execution
On a context or run request, deterministic code reloads the work and selects knowledge by relates_to membership, plus open findings affecting those related IDs. Text supplies the objective, acceptance and verification directions, knowledge statements with status/confidence, and finding statements. It omits source references and much metadata. Status is displayed, not an accepted-only filter: proposed, rejected or stale related knowledge can reach the prompt. Complete selected dictionaries remain available in JSON context output; the narrower rendering is what run sends. This supports relationship-bounded context construction, not the public claim of the smallest trustworthy context (RT-OBJ-compiled-context, RT-RTE-compile-run, EPI-CLM-trustworthy-context).
This is requested read-back, not unsolicited memory injection. Echel implements no token-budget trimming, recursive dependency expansion or context compaction in this compiler. Excluded records remain on disk and may be reachable through tools. Each invocation recompiles current files; it does not recall an already delivered prompt. Hermes window management and internal delegation remain uninspected (RT-RTE-compile-run, including its memory annotation).
By default, run persists a preview command rather than launching an agent. Explicit execution starts one synchronous Hermes subprocess at the workspace directory, with rendered context, an optional model label and requested terminal/file toolsets. Hermes owns subsequent model/tool decisions. Requested toolsets and a working directory are not an Echel sandbox or per-tool approval gate. The implementation skill asks agents to verify and return knowledge proposals separately, but automatic loading and compliance are unestablished. Echel does not pin an exact model artifact or expose model-parameter updates (RT-RTE-compile-run, RT-BAP-context-prompt, RT-BAP-implementation-skill, RT-CMP-runtime-model).
Return a process result, then check separately
A returned Hermes exit code becomes completed/failed run status. Run JSON retains the command, context digest and last 4,000 stdout characters, not a full session or stderr. Delivery means this record is persisted and emitted; it does not close the work item, accept implementation quality or promote knowledge. Missing Hermes can fail before persistence; a returned nonzero exit can persist a failed Run while the CLI returns zero. Callers must distinguish CLI return from task outcome (RT-RTE-compile-run, MEM-OBJ-run, workflow account).
The caller separately invokes verification. Echel executes stored command strings as argv at the workspace, independently of Hermes toolsets. Exit codes produce passed/failed Evidence records; only a checksum of combined output survives, not the diagnostic bytes. The semantic strength of a check belongs to the supplied executable, not to the runner. Failure neither rolls back effects nor schedules another agent attempt; launch exceptions can interrupt after earlier commands have acted. Recovery and acceptance remain caller responsibilities (RT-RTE-verify-work, MEM-OBJ-evidence).
Review and revise retained knowledge through a different plane
Canonical services provide a stronger local review protocol: a proposed claim, decision or learning can receive accepted/rejected status with a caller-supplied human-labelled principal, capability and rationale. This is structural authorization under trusted principal provisioning, not authenticated human identity. It also does not require an evidence-consuming semantic criterion, intended use and scope. Legacy writes, direct schema-valid canonical writes, imports and migration edits do not universally traverse this service. Consequently an accepted label neither proves truth nor establishes that only approved verified discoveries reach execution (RT-RTE-knowledge-decide, EPI-RTE-portable-import, EPI-RTE-schema-migration, EPI-CLM-approved-discoveries).
Retained canonical state has concrete later effects. Clarification uses active claim kinds, including proposed claims, to suppress fixed questions. Maturity requires accepted claim kinds and checks active linked finding severity. Human-labelled profile changes select among shipped requirement policies. Findings can block maturity; reviewed backward revision can mark accepted protected knowledge stale along explicit informs/supports edges, retaining reasons and removing accepted eligibility. It does not infer falsity, generate replacements or revoke legacy prompts. Duplicate accepted kinds can leave some findings outside maturity assessment, and advance apply does not reassess all supporting claim/finding revisions (MEM-RTE-clarification-read, MEM-RTE-policy-revision, MEM-RTE-finding-maintenance, MEM-RTE-staleness-propagation, EPI-RTE-maturity-advance).
Canonical query provides a separate requested consumer route: a disposable SQLite/FTS index selects lexical hits or bounded relationship paths, then reloads canonical records and checks freshness. Reasons remain readable, but freshness and provenance are not semantic endorsement, and this service is not wired into the legacy Hermes compiler. Journals, staged bytes and migration backups support recovery; cleanup, cache discard and guarded byte restoration are distinct from knowledge withdrawal (MEM-RTE-canonical-query, MEM-OBJ-disposable-index, MEM-OBJ-recovery-state, MEM-RTE-storage-maintenance).
What the progression establishes
The strongest supported contribution is implemented retained-state control: work relationships bound supplied context, and canonical criticism/status changes can alter later question selection and maturity eligibility while preserving reasons. Those are real consumer paths, not merely stored labels. Whether criticism of a consumed theory improved future-action capacity remains unestablished: no exercised criticism-to-revision-to-later-capacity comparison is supplied. Raw run/evidence retention does not establish an automatic durable behavior-shaping derivation and later consumer; a canonical learning record's name and evidence IDs do not close that chain (MEM-BAP-canonical-gates, MEM-OBJ-run, MEM-OBJ-evidence, EPI-OBJ-learning).
Theory-building, reflection, autonomy and self-improvement are separate questions. The accepted account establishes no formulated theory route meeting conditions 1–4; it does not turn stored assertions into theories, delivery into content-dependent consumption, finding labels into content-directed criticism, or retained results into a demonstrated next round. Reflection and autonomous content criticism are likewise not established. Caller-controlled execution and review should not be described as autonomous orchestration. At this boundary, self-improvement is not demonstrated: profile selection changes policy and contributor changes could alter machinery, but evidence-responsive determination, admission into live organization and subsequent operation causally depending on an improvement-directed update are not traced. These limits do not establish universal absence, especially inside the excluded model runtime (epistemic bounded conclusion, EPI-RTE-profile-selection, RT-RTE-source-admission).
For a scenario with prepared legacy state and caller-owned sequencing, source supports context construction, external execution and separate evidence capture. For a fresh idea progressing through approved discoveries into future agent work, the canonical/legacy break and missing promotion bridge prevent the same conclusion. No scenario success rate or context benefit is established. The kernel evaluator measures synthetic SQL, bypassing the full canonical query chain; its attributed local result cannot establish end-to-end latency or agent improvement. Product-evaluation doctrine explicitly reserves success claims for later evidence (MEM-CLM-kernel-scope, EPI-RTE-kernel-gate, EPI-CLM-evaluation-contract).
A compatible init-to-work/run path would change the composition finding. An inspected bridge from verification and reviewed discoveries into subsequently consumed project memory would change the loop account. Traced evidence-consuming decisions and later operations would establish exercised reliance; a comparison varying the relevant context or revision mechanism independently would be needed for component-level benefit attribution. Authenticated principals and coverage of alternate writes would be needed for broader approval guarantees. These are conditions for revising this assessment, not claims that the changes already exist.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Source wiring is not observed execution or benefit. | SRC-1; RT-RTE-compile-run, RT-RTE-verify-work, MEM-CLM-kernel-scope | Shipped source, test contracts and attributed local synthetic result; no target execution | Successful agent workflow, full query latency, improved future capacity or causal component effect | Provenanced workflow traces and scenario results; independently varied comparison for component attribution |
| External runtime and deployed controls are not inspected. | SRC-1; RT-CMP-runtime-model, RT-RTE-compile-run, RT-RTE-knowledge-decide | Echel adapter/service boundary, not Hermes/provider internals or identity infrastructure | Model mutability/learning, runtime compaction, actual tool isolation, compliance or authenticated approval | Pinned runtime/model evidence, deployment controls and inspectable execution/identity traces |
| Canonical and legacy paths do not establish one continuous journey. | SRC-1; RT-RTE-idea-init, RT-RTE-file-workflow, RT-RTE-compile-run | Current initialization versus legacy project/context consumers | Fresh init-to-agent composition or inherited canonical approval at the agent prompt | Compatible shipped callers and a traced canonical-to-execution path |
| Specialized canonical consumers and caller-content origins remain unresolved. | SRC-1; MEM-OBJ-canonical-records, EPI-OBJ-learning, MEM-OBJ-run, MEM-OBJ-evidence | Generic storage/query and specific inspected gates; external artifact bytes excluded | Complete semantic/adoption inventory, exhaustive pull-only account, positive or system-wide negative trace learning | Dedicated task/release/artifact/learning consumers, provenance and trace-to-update-to-later-consumer evidence |
| Structural review and recovery checks do not settle semantic correctness or universal concurrency/security guarantees. | SRC-1; RT-RTE-knowledge-decide, EPI-RTE-maturity-advance, MEM-RTE-storage-maintenance, EPI-RTE-schema-migration | Selected service bodies and main recovery paths, not an exhaustive helper/fault audit | Evidence-consuming truth acceptance, atomic evidential snapshot, lossless migration or crash-tested durability | Recorded semantic criteria/decisions, complete relevant audits and fault/concurrency evidence |
| Authority comparison units group distinct consumers and effects. | SRC-1; profile-verification limit; RT-BAP-context-prompt, MEM-RTE-canonical-query, MEM-RTE-clarification-read, MEM-RTE-policy-revision, MEM-OBJ-recovery-state | Partial behavioral-authority inventory groups context/query knowledge, several routing consumers and multiple gates | Fine-grained authority-route counts and complete per-consumer coverage comparisons; supported local existence findings remain valid | Separate retained-part/consumer/effect units preserving each local force and uncertainty |