ReframeWeb synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From accepted input to selected work
ReframeWeb is an enclosing runtime for agent-driven interactive work through semantic tools, visual panels, persistent memory and executable Stores. Python owns external I/O and process lifetimes; BAML owns model-routed decisions. This account covers the shipped host, orchestration, memory producers and consumers, workspace services, Store/panel integrations and session-management application at commit 318987dcde9a016f8e3db819ed9a73abf6b3ad81, with an applicability cutoff of 2026-10-14. SRC-1 supplies inspected implementation and source-native doctrine. No inspected target execution or causal experiment establishes operation or benefit. A whole-system functional boundary is not an exhaustive audit of its implementation leaves (boundary, source register).
Voice transcription and Store/UI text submission converge on a routed request processor. The host pins the session/conversation at acceptance, so subsequent UI selection does not silently retarget that invocation. Each cycle reloads context, selects a catalog task, plans graph searches, retrieves candidates, asks a model to keep memory IDs and composes a standalone task input. A no-action choice can bypass execution. The ordinary execution branch depends on whether the task has an agent configuration (RT-RTE-request-cycle).
Memory reaches this progression through several different channels. Automatic loaders supply layer guidance, preferences and non-relevance session context; they impose no numerical context cap in the inspected loaders. Requested graph retrieval uses hints and time thresholds, followed by model relevance selection. Store-project search has a separate 32-result cap. Read timestamps are updated before relevance selection, so they do not establish that content reached execution. Task-linked instruction bodies are appended or assembled into workspace AGENTS.md independently of relevance selection (MEM-RTE-context-reload, MEM-RTE-graph-selection, MEM-BAP-linked-instructions).
These are selected-input boundaries, not a shared model window. The composer receives filtered context and rewrites it for an executor that cannot dereference the upstream objects. Deterministic packaging preserves supplied strings; semantic preservation by model composition is unestablished. Relevance means intended usefulness, not factual endorsement. Graph locators describe saved projects without delivering their full file bodies merely by becoming candidates (EPI-OBJ-task-input, EPI-RTE-prompt-assembly, MEM-RTE-graph-selection). Task links and selected Store references are not the only workspace-input sources: report verification also establishes automatic projection of eligible live saved-panel projects, including files and generated instruction context (report verification limit).
Execution, review and bounded return
A task without agent configuration uses BAML's native model runner with assigned Host tools and a 64-step bound. An agent-configured task instead gets a prepared workspace and a fresh ephemeral Codex subprocess, with task-scoped MCP plus native shell/file tools. Retries preserve the workspace and reject a changed task identity/configuration; they are not clean-slate trials. The representative shipped workflow connects this delegation directly to completion, retry and host return (RT-RTE-model-task, RT-RTE-codex-task, workflow account).
Task tool assignment is enforced at the Host attempt boundary. Call-ID reuse returns the same future within an attempt; uncertain mutating fingerprints can be rejected across retries sharing the cycle ledger. This reduces covered replay risk without providing global exactly-once effects. Codex native tools, trusted Host composition and Store callbacks are separate paths. Store callbacks require current activation/revision and operation-specific grants; native panel imports check invocation capabilities and request/result bounds. Neither the task allowlist nor the requested Codex sandbox is a universal effect monitor (RT-OBJ-tool-attempt, RT-BAP-store-callback, RT-BAP-panel-import).
Effects occur before completion review. Normal tasks summarize recorded action history; Codex tasks return their executor's required feedback, not a second independent workspace-review conversation. Missing or oversized executor feedback marks failure. The completion model compares the newest summary with the task requirement, request and scoped conversation. Its criterion deliberately favors PASS when compact material failure evidence is unavailable; code additionally requires null execution and summary failures. This is operational acceptance of an attempt, not authentication of every reported fact or artifact (MEM-RTE-history-summary, RT-RTE-codex-task, EPI-RTE-completion-check, EPI-RTE-completion-gate).
Failure guidance uses summary-level information and earlier refusals, rather than the full execution object accepted by the helper's signature. BAML can refine and retry or reselect a task. Defaults allow two attempts per cycle and two cycles. Exhaustion returns the newest concrete result even if request completion has not passed. Delivery here is return to the Host caller, not proof that a user saw a satisfactory answer. Iteration bounds also depend on callbacks/providers returning or failing; rejection does not roll back earlier effects (workflow account, RT-RTE-request-cycle).
What survives and how it changes later work
The strongest supported contribution to use-time adaptation is an implemented observation-to-guidance path. Decision models may stage reusable lessons for five layers; a review model can reject all candidates, and code intersects kept IDs before persisting title/description text. Later cycles reload that text as standing decision guidance. This is wired automatic trace-fed guidance, not observed improved capacity. The reviewer receives purpose, candidates and stored guidance, without a separate interaction/tool trace. Structured criticism, rejection reasons and original evidence links are not required retained fields (RT-RTE-guidance-review, EPI-RTE-guidance-check, EPI-RTE-guidance-disposition, MEM-OBJ-context-memory).
A separate trace-fed path reduces graph-backed tool outcomes into a summary retained for later completion/retry invocations within the request. The history is an update input; the summary supplies outcome context downstream. This does not establish a cross-session summary index, novel accepted knowledge or beneficial learning. The inspected evidence also does not identify the original observation category feeding guidance review, whereas action-history summarization has recorded tool activity as its source (MEM-OBJ-task-history, MEM-RTE-history-summary, profile verification).
Review is not a universal memory gate. Browser/API edits, guarded instruction replacement, graph import, locator visibility migration and project-save tools have distinct admission predicates. Verified project locators require attempt-local successful tool evidence and kind-specific live identity; saved-artifact locators instead require registered workspace/path checks. Caller-supplied prose remains separate from generated provenance. Human exact-content UI decisions are distinguishable from unspecified API/script callers, whose per-content control cannot be inferred from invocation alone (MEM-RTE-node-curation, MEM-RTE-memory-migration, MEM-RTE-project-locator).
Retention also reaches executable organization. Graph filesystem locators identify either mutable directories or checkpoint manifests; backing bytes reside separately in workspace SQLite metadata and filesystem blobs/session files. Explicit path publication is distinct from ordinary workspace recovery. Saved Store metadata can reference code/UI checkpoints, instructions and startup parameters. Reference checks and expected-content comparison govern metadata admission; startup membership and live activation are separate operations. Live replacement can attempt recovery without undoing the saved candidate, and recovery can fail (MEM-OBJ-filesystem-memory, MEM-OBJ-workspace-store, RT-RTE-saved-store).
For this maintenance scenario, the important distinction is between available evidence and an enforced gate. A private candidate test checks startup readiness, accepting selection and cleanup under a fixture configuration that strips instruction links. Generic Store publication records caller verification text without requiring that test result. Initial session-management application publication instead checks matching build/acceptance receipts and can edit task prompts, grants and instruction links; its multi-write operation can partially publish. Neither predicate alone establishes authentic passing tests, production parity or successful improvement (EPI-RTE-candidate-startup, RT-RTE-saved-store, RT-RTE-application-publish).
Evidence mechanisms retain similarly local scopes. Screenshot tools preserve full returned PNGs, while a model may receive a lossy preview among its eight newest images. Rendering evidence does not verify every interaction or website assertion. Benchmarks check expected identifiers or prompt shape; their inspected consumers report metrics rather than automatically revising production guidance (EPI-RTE-panel-evidence, EPI-RTE-benchmark-checks).
Independent assessment of adaptation properties
The supported result is retained prompt-shaping guidance and trace-fed summary supply, alongside routes that can change future executable configuration. Criticism of a consumed theory improving capacity for future action is not established: no concrete theory/criticism instance, later capacity evidence or attributing comparison closes that claim. Likewise, theory-builder condition 1 (a stated theory unit), condition 2 (decisions depending on its content), condition 3 (content-directed criticism with blame and changed reliance), and condition 4 (that criticism shaping another round) are each unestablished by these records. Proposal, delivery, review and retry do not substitute for their separate warrants; opaque model processing is not evidence of absence (RT-RTE-guidance-review, EPI-OBJ-candidate-entry, EPI-RTE-guidance-check).
Computational task selection, execution and retry without per-step human approval are wired in the selected open-request route. This does not establish autonomous theory building or autonomy of every maintenance admission. Reflection is also unestablished: decision-layer subject matter alone does not demonstrate a self-representation with both causal directions. These conclusions do not negate the automatic guidance mechanism (RT-RTE-request-cycle, RT-RTE-guidance-review, MEM-RTE-node-curation).
For later-turn decision usefulness, guidance admission provides an improvement-directed self-change pathway whose retained output is wired into the system's own decision organization. Exercised self-improvement remains unestablished: no supplied observation shows subsequent decisions causally depending on that update, and no comparison establishes better capacity. Store publication likewise permits machinery change without establishing that evidence determined an improvement-directed update or that later operation exercised it. Success is a further question beyond either architectural pathway (RT-RTE-guidance-review, MEM-RTE-context-reload, RT-RTE-saved-store).
The assessment would change with linked candidate/evidence/review/later-decision traces; concrete content-directed criticism and iteration; controlled outcome comparisons; or an enforced candidate-test receipt consumed at generic publication. Startup/activation traces would establish exercised machinery change, while tests varying retained guidance independently would be needed for a guidance-specific benefit attribution. No further frozen-source reads were needed for this synthesis.
Limitations
| limitation | affected SRC IDs and record citations | inspected boundary | conclusion prevented | evidence that would resolve it |
|---|---|---|---|---|
| Implementation is not observed operation or causal benefit | SRC-1; RT-RTE-request-cycle, RT-RTE-guidance-review, EPI-RTE-benchmark-checks | Frozen source and embedded prompts; no inspected execution or experiment | Successful delivery, reliable model compliance, exercised adaptation, performance and component-specific improvement | Provenance-linked runs and controlled comparisons at the relevant consumer and horizon |
| Review lacks separately supplied interaction evidence and concrete theory instances | SRC-1; EPI-OBJ-candidate-entry, EPI-RTE-guidance-check, EPI-RTE-guidance-disposition | Purpose/candidate/stored-text review interface and title/description writeback | Independent factual acceptance, complete trace origin, theory-builder conditions and capacity improvement from criticism | Original observations linked to candidate content, criticism/disposition rationale and later dependent decisions |
| Model composition and summary fidelity are unobserved | SRC-1; EPI-OBJ-task-input, EPI-OBJ-output-summary, MEM-RTE-history-summary | Selected-context composition and action-history reduction; deterministic packaging separately inspected | Semantic preservation, warranted novel inference or truthful effect reporting | Paired inputs/outputs checked against original evidence and live outcomes |
| Initial provenance and generic-caller admission control remain unresolved | SRC-1; MEM-OBJ-context-memory, MEM-OBJ-session-memory, MEM-OBJ-instruction-memory, MEM-RTE-node-curation, RT-RTE-application-publish | Known subsequent writers, UI decisions and unspecified API/script callers | Complete authorship/agency classification or universal human approval | Initialization and per-content admission provenance for each alternative |
| Task-link and relevance routes omit live-panel input projection | SRC-1; MEM-RTE-graph-selection, MEM-BAP-linked-instructions, RT-RTE-codex-task; report verification limit | Verification traced Host wiring, eligible saved-panel selection and preparation of files/manifest/generated instructions | Comparisons treating task links and relevance-selected Store references as the only workspace inputs; exercised projection or compliance | Expanded route inventory and projection/consumer traces |
| Coarse profile units do not enumerate every part/consumer pair | SRC-1; MEM-OBJ-task-history, MEM-RTE-history-summary, MEM-RTE-graph-selection, MEM-BAP-linked-instructions, RT-RTE-saved-store; profile verification limit | Partial grouped form, authority and direction inventories | Complete route-level comparison or distribution of every grouped finding to every part, such as ranking authority for every receipt | Separate part-by-consumer units with recorded selector, channel and effect |
| Payloads, physical backing and native maintenance are incompletely inspected | SRC-1; MEM-OBJ-context-memory, MEM-OBJ-filesystem-memory, MEM-OBJ-workspace-store, EPI-OBJ-rendered-evidence | Known graph/local KV, checkpoint SQLite/files and image metadata; unresolved remote backing, arbitrary bytes and native cleanup | Complete storage/form/curation inventory, crash durability, disk reclamation or arbitrary application-internal memory use | Payload-specific consumer evidence and native storage/cleanup/recovery inspection and tests |
| Test, publication and activation have different scopes | SRC-1; EPI-RTE-candidate-startup, RT-RTE-saved-store, RT-RTE-application-publish | Private startup/cleanup predicate, generic recorded verification, initial matching receipts and separate live recovery | Mandatory generic acceptance, instruction/UI coverage, receipt authenticity, atomic publication/activation or guaranteed recovery | Authenticated results tied to candidate/configuration, mandatory consumer gate, acceptance coverage and failure/recovery traces |
| External models and platform contracts are not frozen or audited | SRC-1; RT-CMP-model-transport, RT-CMP-codex-model, RT-CMP-whisper-transcriber, RT-RTE-codex-task, RT-BAP-panel-import | Shipped adapters and requested policies, excluding provider/Codex internals and database/VM/browser/platform implementations | Immutable model identity, hidden training/compaction conclusions, deployed sandbox/security, compatibility or live website acceptance | Frozen dependency/configuration identities and targeted deployment evidence |
| Selective inspection cannot establish system-wide absences of other checks or writers | SRC-1; boundary coverage, epistemic coverage, report verification | Selected host routes, evaluator consumers and omission challenges; other acceptance/native/maintenance leaves remain available | Exhaustive evaluator, publisher, withdrawal or epistemic-route comparison | Question-directed inspection of remaining material alternatives and their consequential consumers |