Talorys synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From owner request to bounded model work
Talorys is a personal-information application that delegates answers and tool choice to a model while retaining execution authority in application code. Its claimed work is organizing information, remembering personal facts, managing tasks and automating routines. This account covers the shipped browser, Worker/Durable Object application, retained-state maintenance, scheduled work and provisioning paths at https://github.com/rociiu/talorys, commit c5da440010402ed4c1b9789ae22eab96a8f0f379, with an analysis cutoff of 2026-10-15. The whole-system boundary is code-grounded, not an exhaustive audit of every file. SRC-1 supplies implementation, declared design and an attributed evaluation; it supplies no execution trace or causal experiment. Neither this run nor its verification executed the target, tests, inference or deployment. See the boundary and evidence and Source register.
An authenticated owner submits a browser chat request. Both deployment variants converge on one fixed agent instance. The runner persists the request, assembles selected context, exposes registered tool callbacks and invokes Workers AI through an SDK adapter. The model chooses text and tool arguments; code checks schemas, grants and budgets before executing owner-bound services. The application persists assistant text, activity and completion/error state and streams browser events. Per-conversation active-run coordination is in memory, not durable global serialization. Cancellation and retry do not undo completed tool effects. RT-RTE-owner-chat, RT-OBJ-active-runs.
This is not a general shell or remote-worker runtime: the inspected registry exposes personal-information tools rather than arbitrary code/network execution or sub-agent delegation. Product changes follow maintainer source edits, package generation and operator deployment, not a model self-edit tool. Owner settings can change model selection and runtime controls through a separate authenticated channel. RT-RTE-product-update, RT-RTE-owner-changes, RT-BAP-shipped-policy.
Retaining information before granting factual warrant
Personal memories persist as prose with symbolic category, origin and lifecycle fields in owner-bound SQLite. Model remember writes are immediate; an explicit model correction saves a successor and retires its predecessor without an approval card. Owner in-place editing instead overwrites wording. Saving precedes optional conflict diagnosis, so a failed check does not remove the new assertion. These are operative retention and revision mechanisms, not evidence that a saved assertion is true. Backup admission is another route: owner file selection is followed by automatic schema/timestamp/link merging, without the normal conflict diagnosis or proof of each statement's provenance. MEM-OBJ-tal-memories, MEM-RTE-memory-write, EPI-RTE-memory-retention, RT-RTE-owner-changes.
Conflict handling has consequential but narrower authority. Deterministic wording rules nominate reviews rather than retire old facts directly. When configured, a real Clef hook and available request budget permit pairwise model checking; Clef receives at most 500 characters of each assertion and same-person relationship criteria. A supersession confidence of at least 0.8 can retire the older assertion automatically. Unusable judgments fall back to rule reviews. The owner can later keep both, mark history, replace or discard. These decisions govern currentness relative to supplied statements, not independent verification of either fact. A static negation counterexample also shows that the wording rules are fallible semantic judgments. EPI-RTE-wording-check, EPI-OBJ-conflict-assessment, EPI-RTE-clef-check, EPI-RTE-conflict-disposition.
Correction preserves predecessor wording and links, but does not generally retain its justification. Pending reviews carry short reasons to the owner; ordinary prompt recall does not consume those reasons. Owner review evidence and intended-use criteria are not recorded. Consequently lifecycle organization and operational reliance do not establish evidence-consuming truth acceptance or post-acceptance integration. The promise of history preservation holds for correction, not a universal append-only store covering edits and imports. MEM-OBJ-memory-reviews, EPI-RTE-lifecycle-change, EPI-CLM-current-facts, EPI-CLM-history-preservation.
What reaches the next invocation
Automatic memory recall pushes selected facts into chat and scheduled prompts using the current request text. Keyword selection is available without semantic mode; optional hybrid selection combines lexical and vector ranks. It keeps at most eight memories before a separate estimated budget of the smaller of 1500 tokens or 20% of configured context. Historical intent and recent-preference padding change selection. Historical status normally suppresses current automatic recall, but general requested search can still expose historical text, sometimes without lifecycle labels. Newer-neighbor additions and advisory newer-wins guidance do not guarantee that a predecessor's actual replacement survives final selection. MEM-RTE-memory-recall, MEM-RTE-requested-search, EPI-RTE-recency-guidance.
Semantic indexes retain normalized numerical vectors and symbolic model/hash/stamp metadata in SQLite, with decoded in-memory caches. Vectors select items; current source rows supply delivered wording. Foreground item recall requires enabled semantic mode and a cached query vector, then supplies at most three task/note/automation lines under a separate estimated 300-token budget. It has no below-floor fallback, and is not called by the scheduled runner. Ordinary retrieval can use stale same-model vectors to select edited text; conflict-neighbor nomination applies a stronger current-hash check. Asynchronous capped repair is not atomic freshness. Excerpt slicing can omit a necessary condition, and requested note reload is itself capped at 8000 characters. MEM-OBJ-semantic-vectors, MEM-OBJ-item-vectors, MEM-RTE-item-recall, MEM-RTE-index-maintenance, EPI-RTE-item-delivery.
Conversation continuity uses a different chain: code loads at most 200 eligible history messages, evicts older material to an estimated budget and can invoke a separate summarizer on overflow plus the previous summary. Compaction requires at least eight overflow messages and two remaining AI requests. Code trims the result to 2000 characters and stores it automatically with a cutoff. Later turns receive the summary by value plus a recent suffix. Raw messages remain independently owner-readable, but conversation search does not reload a full transcript into the model. The isolated summarizer receives selected inputs without the main tool context; only its return crosses back. Retention therefore preserves more than the model window, without making omitted history automatically dereferenceable. Summary fidelity and a hard total-context bound are not established. RT-RTE-context-window, MEM-OBJ-conversation-records, MEM-OBJ-conversation-summary.
The strongest supported learning-related contribution is wired trace-fed adaptation: chat-derived facts and automatically compacted conversation summaries become durable context for later invocations. Recorded conversational input and action-outcome feedback can feed these updates. This establishes more than logging, but not improved capacity for future action, reliable preservation of reasons or parameter training. Other saved prose and imported prehistory remain incompletely classified. No comparison demonstrates that criticism of a consumed theory improved future capacity. The runtime records do not establish a formulated-theory route assessed against theory-builder conditions 1–4; these conditions remain unestablished here, not evidenced absent. Reflection and autonomous theory construction likewise remain unestablished in the supplied account, independently of the supported memory mechanisms. Exercised self-improvement is not established: later operation causally depending on an improvement-directed organizational change is not supplied. MEM-RTE-memory-write, RT-RTE-context-window, RT-BAP-retained-context, profile verification, epistemic bounded conclusion.
From proposal to effect, and from stored routine to notification
The representative workflow is a possible owner-requested note rewrite, not an observed successful run. The model can search/read, then propose a complete replacement; reading is not enforced and is bounded even when performed. A destructive callback stores the exact replacement as payload and owner preview rather than changing the note. A separate authenticated owner approval claims a pending, unexpired action and compares the current title/content/project snapshot before commit. A stale target fails and requires a fresh proposal; decline or 30-minute expiry prevents approval. The resulting note mutation and exposed action outcome, not proposal success, constitute delivery. This is content-specific human authorization, not an automated correctness oracle. The reachable textless-turn fallback can still say “Done.” while approval is pending. Claim-before-commit gives at-most-one approval attempt through this handler, not crash-safe exactly-once completion or undo. RT-RTE-action-approval, workflow account, workflow chat annotation.
That approval invariant covers registered destructive model callbacks, not all changes: ordinary writes, memory corrections and direct owner CRUD have separate admission. Likewise, scheduled model work has a narrower grant set enforced by actual executor lookup: read tools plus notify_owner. Stored automation text becomes its task instruction, with selected memories but without foreground history/summary or automatic item recall. Reminder and digest branches can bypass the model. Notifications, receipts, metering and derived indexes can still be written; restricted tools do not make the whole invocation a read-only transaction. Receipts are owner-readable results, not an established feedback loop revising the routine. RT-CLM-approval-boundary, RT-RTE-scheduled-work, RT-CLM-scheduled-grants.
For a routine asking about saved information, the architecture supplies bounded recall, requested reload and persistent guidance. For a rewrite requiring preservation of all original content, the source instead exposes an input-visibility gap and relies on owner preview. For an unattended routine, it supplies restricted model tools and recovery bookkeeping, not verified notification receipt or exactly-once useful work. Recalled data and summaries enter system input under a natural-language data-not-instructions policy; routine messages intentionally carry instructions. Prompt delivery does not prove instruction isolation. RT-BAP-retained-context, RT-CLM-context-authority, workflow account.
The reported semantic evaluation does not close these gaps. Its 18/18 PASS measures a threshold predicate: a positive target can rank fourth outside a three-item section and still pass. It establishes neither guaranteed runtime delivery nor answer quality, and no causal comparison isolates a component's benefit. End-to-end captured inputs, selected context, tool/approval outcomes and later consumption would change the operational assessment. Fidelity checks against original content, calibrated conflict decisions and controlled outcome comparisons would change the accuracy and benefit assessment. Enforced complete-input review, strict freshness checks or an atomic approval/commit protocol would change the corresponding architectural limits, rather than merely provide more observations of the current design. MEM-CLM-eval-scope, EPI-RTE-semantic-evaluation, report verification.
Limitations
Neither supplied verification declares a publication limit or blocker, and reconciliation reports no unresolved conflict. The following rows retain the evidence and mechanism bounds on this synthesis. No frozen-source files were read for synthesis; support comes from the supplied members.
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Static wiring, not exercised operation or benefit | SRC-1; RT-RTE-owner-chat, RT-RTE-scheduled-work | Frozen shipped application; no target execution or deployment trace | Actual activation, quality, delivery reliability and causal benefit | Captured deployed configuration and end-to-end traces; controlled comparisons for benefit |
| External service behavior and exact weights are opaque | SRC-1; RT-CMP-workers-ai, RT-CMP-workers-embedder, RT-CMP-clef | Talorys adapters and model names, not Cloudflare/provider internals | Immutable weight identity, provider-internal learning/retention, cloud durability or push guarantees | Pinned provider identities, applicable service contracts and inspectable operational evidence |
| Admission and pair disposition do not independently verify facts | SRC-1; EPI-RTE-memory-retention, EPI-RTE-clef-check, EPI-RTE-lifecycle-change | Save, conflict and review paths; unknown imported prehistory and unrecorded owner criteria | General factual warrant, calibrated conflict accuracy or evidence-consuming acceptance instances | Source-linked claims, actual decisions with evidence/criteria and independently checked pair outcomes |
| Selection and compression can lose conditions or omit material | SRC-1; MEM-RTE-memory-recall, EPI-RTE-item-delivery, RT-RTE-context-window | Final recall budgets, bounded excerpts/history and automatic summary storage | Complete recall, faithful summary/rewrite input or hard total-token guarantees | Original-to-delivered context comparisons and fidelity checks; changed visibility/budget enforcement where needed |
| Lifecycle withdrawal, freshness and cleanup are route-local | SRC-1; MEM-RTE-requested-search, MEM-RTE-index-maintenance | Current recall versus alternate search, asynchronous index repair and source deletion | Universal historical suppression, atomic freshness/convergence or erasure of independent copies | All-consumer tests/traces, transactional freshness evidence and an explicit copy-retention/erasure account |
| Authorization is neither semantic verification nor crash-safe completion | SRC-1; RT-RTE-action-approval, workflow approval annotation, workflow chat annotation | Destructive callbacks, bounded note read, preview, conditional claim and subsequent commit | Guaranteed preservation/truth, approval of every write, exactly-once delivery or completion inferred from “Done.” | Complete-input checks, actual review/commit evidence and atomic or recoverable effect protocol |
| Data/instruction separation is a model policy | SRC-1; RT-CLM-context-authority, RT-BAP-retained-context | Prompt construction and distinct retained-context channels | Reliable rejection of instructions embedded in data | Adversarial execution evidence within a specified threat model and stronger isolation controls where required |
| Evaluation and memory positives do not establish general improvement or exhaustive theory coverage | SRC-1; MEM-CLM-eval-scope, MEM-RTE-memory-write, RT-RTE-context-window, epistemic bounded conclusion | Threshold scorer and wired fact/summary updates; arbitrary prose, remaining computations/tests and provider internals not exhaustively assessed | End-to-end retrieval benefit, improved future capacity, exercised self-improvement or system-complete negatives about theory building/reflection | Runtime-delivery scoring, controlled later-capacity comparisons and pathway-specific evidence of criticism, retained change and causally dependent later operation |