Wuphf synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From requests to two execution families
Wuphf is an enclosing agent runtime that combines a shared office broker with a service for building and executing saved tools. The frozen repository calls the product gawkbot. Its claimed work is to turn described workflows into local microapps with tools, schedules, knowledge and human approvals. This account concerns SRC-1, https://github.com/nex-crm/wuphf, at commit 88023d4dac7491b6e71dbc1e86d274c435b9cb2c, with an analysis cutoff of 2026-10-15. The evidence is inspected implementation and attributed design, not execution traces or experiments. The boundary is complete artifact, partial loop: the repository is captured, but not every shipped producer, maintainer and consumer has been traced. External CLIs, providers and services are dependencies whose internals were not frozen. See the boundary and evidence and Source register.
In ordinary office work, the launcher starts the broker, web interface and background dispatch loops. A message becomes a targeted work packet, enters a bot/task/worktree lane and reaches a selected provider runner. Wuphf owns targeting, queueing, context assembly, process lifecycle and broker state; the external CLI/model owns much of the next-step and tool selection. The compatible-provider alternative instead has a local eight-iteration tool loop and can fall back to text-only operation when its MCP bridge fails. Streamed text, tool effects, final-message fallback and task ledger state are separate outputs. Neither a working directory nor these orchestration controls establishes filesystem containment or exactly-once external effects. See RT-RTE-office-turn and RT-RTE-compatible-turn.
The sidecar family has a different division of labor. A model can propose JavaScript tool code; software checks and stores it; a later worker executes its capability sequence. Saved code therefore controls behavior directly, unlike prose supplied as model context. Supplied workflow specifications have another path: deterministic ordered replay can issue HTTP requests without traversing the tool worker. App publication separately admits app bytes under actor/capability checks, with restoration available but full store validation untraced. These paths should not inherit one another's guarantees. See RT-OBJ-stored-tool, RT-BAP-tool-execution, RT-RTE-spec-replay and RT-RTE-app-publication.
A scheduled routine reaches a recorded outcome, not necessarily a completed action
The representative multi-step workflow is a scheduled custom-app routine because its shipped broker producer and service consumer form one inspectable chain. A due job selects the live playbook prompt when present, otherwise stored payload or label, and re-arms recurrence before asynchronous dispatch. App ID scopes data/capabilities; routine slug identifies the schedule/session association; saved tool name and returned session ID are different identities. The service searches saved tools by exact mention or title-word overlap. A match runs without fresh authoring verification; a changed prompt alone does not force new code. See RT-RTE-scheduled-tool and the workflow account.
When no tool matches, authoring receives the prompt, app schema and capability guidance. Static capability checks and simulated smoke execution can reject selected failures and trigger one error-informed model repair. They do not compare the result with a reference business answer. The manual build endpoint persists model-authored results only; the routine runner can persist any non-null tool, including fallback code. Same-name replacement increments a version without established retention of the previous code body. See RT-RTE-tool-authoring and RT-OBJ-stored-tool.
The routine executes with approved: false. Named send/browser capability gates can terminate it as needs_approval, while permitted app data changes may already have occurred. A gate rejection ends the worker: “paused” narration does not mean a resumable program counter. On an ordinary returned result, the runner appends prompt/outcome messages and writes a Markdown artifact; the service returns status, digest and session ID. Frontend request/display paths make these retained results accessible, without proving human receipt. The broker can record a successful scheduler fire with a partial playbook outcome. Separately, integration deferral may return ordinary successful result text while the action remains pending. Thus dispatch acknowledgement, recorded delivery and requested-action completion are distinct. See RT-RTE-saved-call, MEM-OBJ-session-transcript and the workflow annotations.
Successful scheduled operation also depends on a consequential wiring condition: the inspected broker POST does not attach the optional sidecar bearer authorization. Token-protected configuration can reject the handoff. Its 90-second caller deadline can expire before the worker's ordinary 120-second deadline. Continued recurrence neither resumes the old worker nor compensates prior effects. These are source-supported constraints, not observed deployment failures. See RT-RTE-scheduled-tool.
Earlier work changes later inputs through several unequal memory routes
Office context is selected rather than a replay of every prior turn. A notification brief can deliver two clipped private notes and up to three distinct shared-page snippets; the Claude fetch has a two-second deadline and frames the material as untrusted reference data. Task packets independently select up to five learning insights and three wiki snippets, while file search supplies up to five article titles/paths with a request to read the relevant bodies. Dependency IDs select upstream task outcomes and proof excerpts. Item limits and clipping are not a universal token budget. A delivered pointer or manifest is not evidence that the body was read or its advice followed. See MEM-RTE-memory-brief, MEM-RTE-task-knowledge, MEM-RTE-upstream-results and MEM-BAP-knowledge-guidance.
These automatic packets are push to the receiving model; explicit note queries, learning searches and article reads are pull. Local selection uses lexical relevance, confidence/recency and, when configured, dense embedding ranking. Remote GBrain ranking and storage remain opaque. Private notes live in persisted broker state; learning/fact logs and wiki prose use files and Git; saved tools use per-agent files. Dense vectors, fixed-rule metadata/code and interpreted prose have different consumers. See MEM-OBJ-private-memory-note, MEM-OBJ-shared-memory-write, MEM-OBJ-learning-record, MEM-OBJ-typed-fact and MEM-CMP-retrieval-embedding.
The strongest supported learning-related contribution is a wired path from completed task activity and verification feedback into durable knowledge selected for later work. A second conditional path uses simulated smoke errors to shape repaired code that can be retained for later execution. Both qualify as automatic trace-fed durable updates; neither demonstrates improved capacity. Raw routine transcripts are instead retained for readers, not established history for future author calls. See MEM-RTE-task-distillation, MEM-RTE-task-knowledge, RT-RTE-tool-authoring and profile verification.
Checks constrain reliance only within their actual domains
Completion verification can test command exit, a nonempty matching file or HTTP 2xx. Required failure can block completion; optional failure or no specification can permit continuation. A passing result gates trusted learning capture, but entity associations/article regeneration occur before that gate. Copying a title and details under “Verified outcome” does not verify those narratives, explain success or establish transfer. See EPI-RTE-task-check, EPI-RTE-task-admission and MEM-RTE-task-distillation.
Artifact extraction and fact-fed brief rewriting retain source-linked candidates under software checks, not established semantic acceptance. Source-to-fact and fact-to-brief relations remain indeterminate without actual content and support checks. Citation bounds filtering can remove invalid indices while returning unchanged answer prose; it does not verify entailment or require every claim to be cited. Likewise, contradiction judging has a positive, consequential route: a model identifies inconsistency, then a caller can expire one fact or acknowledge both. This changes retained metadata and future lint eligibility, but does not authenticate either proposition or establish withdrawal from every derivative. See MEM-RTE-artifact-extraction, MEM-RTE-brief-synthesis, EPI-RTE-query-answer, EPI-RTE-lint-judge and EPI-RTE-lint-disposal.
Operational approval is equally local. Selected task plans require human authorization; named capabilities test a run flag; integration mutation uses broker classification; supplied-spec replay trusts each step's gated field. Manual calls can assert approval as a Boolean, and native execution permissions vary by provider/posture. The inspected routes therefore do not establish the universal external-action approval promise. Source-bearing answer structures and citation guidance similarly fall short of universal cited, verified knowledge. These are bounded claim/route mismatches, not observations of unauthorized actions or uncited user-facing outputs. See RT-RTE-plan-approval, RT-CLM-external-approval, EPI-CLM-verified-lookup and EPI-CLM-cited-knowledge.
What the mechanisms establish, and what would change the assessment
For recurrent app work, the architecture supports reuse of admitted executable tools, bounded capability gates and accessible recorded outcomes. For later knowledge-assisted tasks, it supports selected reuse of earlier outcomes and derived prose, without establishing retrieval quality or justified reliance. Compression/archive and contradiction disposal have bounded effects; procedural compilation affords later instructions, but full skill assignment/loading remains untraced. See MEM-RTE-wiki-maintenance, EPI-RTE-playbook-compile and MEM-RTE-skill-registration.
The runtime establishes executable construction and limited repair, not a theory-builder assessment satisfying conditions 1–4. The positive contradiction criticism/disposal mechanism does not by itself establish localized theory consumption, content-directed blame and retained iteration across all four conditions. Whether criticism of a consumed theory improved future capacity remains unestablished. Autonomous scheduled execution is wired; a fully autonomous theory builder is not established. Reflection likewise has no established complete two-way self-representation account in these records. These are independent findings, not deductions from missing runs alone. See RT-RTE-tool-authoring and the epistemic bounded conclusion.
Smoke-error repair is an evidence-responsive, improvement-directed standing pathway: error feedback can shape code, retained code enters the runtime's own later execution path, and reducing the checked crash failures is an objective independent of the particular edit. This supports a bounded dispositional account of self-change, not exercised self-improvement or successful improvement. No subsequent execution causally dependent on a repaired tool is supplied. Task-derived future context similarly demonstrates a standing update path, not benefit. Provider parameter learning remains uninspected rather than absent. See RT-RTE-tool-authoring, RT-BAP-tool-execution, MEM-RTE-task-distillation and RT-CMP-office-model.
A trace linking a specific smoke failure, admitted repair and later dependent execution would change the exercised-self-change assessment; outcome comparison would separately be needed for improved capacity. Representative source-to-fact/brief and answer-to-source checks would change semantic-reliance conclusions. End-to-end evidence under token-protected scheduling, plus authenticated approval and common effect classification across alternate routes, would change the operational guarantee assessment. None is supplied by this run. The report and profile verifications found no blockers or additional declared limits; their acceptance concerns this bounded account, not production success. See report verification and profile verification. No frozen source files were read for this synthesis.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Selected source paths, no execution or causal comparison | SRC-1; RT-RTE-office-turn, RT-RTE-scheduled-tool, MEM-RTE-task-distillation | Frozen repository, complete artifact/partial loop; no target execution | Successful deployment, reliability, actual uptake, capacity improvement or causal benefit | Registered traces linking inputs, effects and later consumers; objective-specific comparisons for benefit |
| Token-protected routine handoff and recovery remain conditional | SRC-1; RT-RTE-scheduled-tool, RT-RTE-saved-call, workflow account | Broker POST, service authentication, worker settlement and recurrence | Successful authenticated scheduling, resumable approval continuation, non-overlap or exactly-once effects | Authenticated handoff implementation and traces; explicit continuation/idempotency/compensation protocol and tests of its stated scope |
| Approval and isolation guarantees do not cover all effect paths | SRC-1; RT-RTE-office-turn, RT-RTE-plan-approval, RT-RTE-saved-call, RT-RTE-spec-replay | Selected native runners, worker capabilities and supplied-spec replay; other runners and deployed grants untraced | Universal human authorization or adversarial containment | Complete effective grants and effect-path inventory, authenticated approval provenance and enforced classification at each boundary |
| Semantic checks and provenance delivery are narrower than labels | SRC-1; EPI-RTE-task-check, EPI-RTE-query-answer, EPI-RTE-knowledge-packet, MEM-RTE-artifact-extraction, MEM-RTE-brief-synthesis | Generic check implementations, extraction/rewrite and selected packet/answer construction; actual instances absent | Verified task narratives, faithful transformations, accepted novel ampliative claims or universal supported citations | Actual inputs/outputs, source-support evaluation and evidence-consuming acceptance scoped to intended use; delivery preserving necessary conditions/provenance |
| Withdrawal and procedural activation are incompletely traced | SRC-1; MEM-RTE-wiki-maintenance, EPI-RTE-lint-disposal, MEM-RTE-skill-registration, EPI-RTE-playbook-compile | Article search exclusions, fact metadata, compiler and registry | Global derivative retraction, complete skill invocation or reliable transfer from task example to procedure | Index/derivative invalidation through consumers; full assignment/loading/invocation trace and procedural evaluation |
| Remote, native-session, app-state and alternate admission paths remain unresolved | SRC-1; MEM-OBJ-shared-memory-write, MEM-CMP-retrieval-embedding, MEM-OBJ-session-transcript, MEM-OBJ-session-memory-snapshot, RT-RTE-app-publication, RT-CMP-office-model | Inspected wrappers and selected callers, not external internals or all shipped alternatives | Complete memory classifications, durable resume/compaction guarantees, pinned model parameters or system-wide negatives about acceptance/theory-building | Records tracing included alternative producers and consumers; captured dependency contracts/implementations and effective model identities |
| Standing trace-fed updates lack later improvement attribution | SRC-1; RT-RTE-tool-authoring, RT-BAP-tool-execution, MEM-RTE-task-distillation, EPI-RTE-lint-judge | Conditional repair/persistence and future-context wiring; simulated check domain | Exercised or successful self-improvement, improved future capacity from theory criticism, or a complete reflective/autonomous theory-builder finding | Specific retained update and later dependent operation; independent objective/outcome evidence; separately evidenced theory conditions and self-representation links |