From a Portfolio Question to Continuous Collaboration: ETF Agent’s Six-Layer Architecture · V2

ARCHITECTURE FIELD GUIDE · ESSENTIAL READ 01

Understand how an Agent researches, acts, delivers and continues collaborating.

Not six isolated pipelines: one Native Agent Loop supported by clearly owned capabilities. Start with the system picture, follow the actual handoffs, and then study the principles.

Explore the research loop ↓Jump to a layer ↓Explore architecture principles ↗

6system perspectives

40+capability owners

26core handoffs

Architecture snapshot: October 24, 2026. A self-contained explanation of six architectural layers, more than forty capability owners and twenty-six core responsibility handoffs. It incorporates concurrent research, accurate tool presentation, evidence, computation, durable human interaction and recovery.

Essay catalogue · Capability architecture gallery · Background research experience

Consider a synthetic request: “Which industries dominate my funds, and how much do their holdings overlap? Use fund documents, and identify the evidence you could not obtain.” To the user, it is a sentence. To the system, the sentence starts a chain of authenticated work, model input, tool actions, evidence consumption, calculation, publication, and later questions. A correct answer depends less on the number of features than on whether each responsibility hands off the right facts.

No owner is automatically a new process. The conversational application manages research and conversation. A read-only investment data facade provides authoritative data and deterministic calculations; monitoring collects bounded observations. The Agent’s own database does not become a replacement portfolio ledger.

Figure 1 · Six architectural layers around the Native Agent Loop: decide → execute → consume evidence → decide again.

The highlighted return arrow is the Native Agent Loop: the model decides the next action, the Host executes it, and source-backed tool results return for another model decision. Only a sufficiently researched answer exits to Publication. A Direct response bypasses the research loop but uses the same publication system. Human waiting, recovery and observation support the Run without replacing this loop.

Layer	Main question	What it explains
1. Interaction	Which message and Run should proceed?	Identity, Entry, Native Loop, resources and Child
2. Context	What does the model actually receive?	Projection, Skills, Memory and compaction
3. Execution	Does a proposed tool have permission to run?	Gateway, MCP, Host and Hooks
4. Evidence	What do data and calculations support?	Retrieval, documents, arithmetic and Python
5. Continuity	What did the user receive and what resumes?	Publication, Control, HIL, Recovery and History
6. Evaluation	What happened, and was it useful?	Tracing, replay and quality review

Six-layer reading map: explore the handoffs

You do not need to memorize all forty-plus owners. Read each layer in order, or jump straight to the Native research loop, parallel foreground/background Runs, financial calculations, or durable human interaction.

01 / SYSTEM LAYERInteraction & researchMessage identity and native execution02 / SYSTEM LAYERContext & methodsWhat the model actually receives03 / SYSTEM LAYERCapability executionHow tools are authorized and dispatched04 / SYSTEM LAYEREvidence & computationWhat is sourced, complete and reproducible05 / SYSTEM LAYERDelivery & continuityPublication, recovery and human interaction06 / SYSTEM LAYERObservation & evaluationTrace actual outcomes and investigate errors

Reading terminology: separate capability ownership from code ownership

Four anchors: a Run is one execution; Main synthesizes the answer; Host dispatches authorized tools; Publication decides how answer text is delivered.

Term	Meaning here	Not equivalent to
Conversation / Message / Run	Exchange history / idempotent send / traceable execution	One ID or one lifecycle
Root / Main / Child	Root execution scope / primary researcher / delegated bounded worker	Separate authorization and budget ledgers
Capability Owner	Module accountable for a fact, decision or effect	Repository code maintainer or chapter heading
Code owner	Engineer/team maintaining a file or repository	Runtime permission to act
Ownership	The responsibility and authority to attest or correct an effect	An instruction to create another service
Host / Tool Surface	Actual tool-call authority / tools finally presented to the model	Tool discovery means permission
Projector / Publication	Model-input assembly / disposition and delivery of answer text	Source authority or numerical truth
HIO / HIL	Human Interaction Owner / Human-in-the-Loop interaction mode	User replies bypass all other runtime controls

Advanced glossary: recovery, effects and continuity

Term	Definition
ModelTurn / sealed turn	One model exchange, with durable facts protected against rewriting
Checkpoint / Recovery	Saved resume point / resuming the original Run from recorded facts
lease / fence	Bounded execution ownership / protection against stale actors committing effects
Correction / Continue	Adoption of new input at a safe point / creation of a linked new Run
Human Park	Safely parked but nonterminal Run awaiting a human or control event
Projection / Projector	Consumer-specific view / module assembling that view
ResultRef / Artifact	Durable result reference / separately versioned and authorized output
Publication / Effect	Candidate answer disposition / separate proposal, approval, execution and effect
TaskExecution / Schedule	One scheduled occurrence / a user-confirmed schedule
HIO / HIL	Human Interaction Owner / Human-in-the-Loop; the former owns request routing, the latter is a coordination pattern

Why not compose LangGraph, AutoGen or OpenAI tooling?

The position: they can provide orchestration primitives. The application still has to define authoritative financial data, permission scope, actual effect receipts and user-visible delivery. The six-layer model describes those obligations; it does not argue that generic frameworks are incapable.

Platform	Useful building blocks	Additional ETF Agent contracts
LangGraph	Graphs, checkpoints, durable execution, human interrupts	Portfolio authority, Run grants, effect deduplication, publication and sharing
AutoGen AgentChat	Multi-agent teams and coordination	Shared Root/Child authorization, deterministic finance, real delivery auditing
OpenAI Responses API / Agents SDK	Models, hosted tools, MCP and agent-building primitives	Cross-provider application receipts, account permissions and domain consistency
ETF Agent six-layer architecture	Composition of orchestration with domain modules	Explicit authority for execution, evidence, calculation, Publication, HIO and Recovery

Historical note: OpenAI's Assistants API was sunset on August 26, 2026, so new projects should compare against Responses. Microsoft Agent Framework is also relevant to AutoGen's evolution.

Takeaway: a framework reduces orchestration code, not the obligation to prove who could read, compute, execute, persist and deliver.

V2 delta index — expand for October 2026 details

New or deepened capability	Where it appears	Evidence / status boundary
Root-owned Child; concurrent foreground/background runs	Layer 1, 06	One Root scope, separate lifecycles for separate Runs
Deep, action reminders, Main compaction	04, 05, 07	Existing owners; a toggle does not validate research quality
A34 Tool Surface	11	Final model presentation and Host admission are distinct
A35 content trust	13	External content is evidence, never an authorization instruction
A33 precise computation	16	Source/time, domain formula, decimal arithmetic have separate owners
A37 HIO / persistent HIL	HIL focus	Bounded engineering closure; production Human Park is off by default
A36 time and market sessions	Separate article	Independent verification still in progress; do not infer production readiness
Durable control, schedules and finalization	22, 23	Real outcomes belong to existing effect owners

This is an architectural snapshot, not a certificate that every capability has been verified in production. Historical V1 is preserved.

Capability owners: how more than forty modules contribute

A capability owner is the module accountable for a durable fact, decision or effect; it is neither a GitHub code owner nor a numbered chapter. Readers can follow the six-layer skeleton first, then expand the inventory to find the accountable module.

Complete owner inventory and implementation snapshot

The public owner gallery now recognizes 43 capability Owners (A01–A37, B01–B05 and E04), including A36 Temporal Semantics and A37 bidirectional Human Interaction. A36 still needs qualified real-agent calendar acceptance; A37 has scoped local provider-free formal close while production Human Park remains off. “More than forty” remains a descriptive label rather than an immutable inventory. Six layers are an explanatory map, not six services. Twenty-six numbered topics are a reading route, not the module count. Peripheral capabilities still belong to the system but need not crowd every paragraph.

Reading group	Independent capability owners	Responsibility for effects
Admission and research	Identity, Conversation, research decisions, Run grants	Actor, messages, scopes and research semantics
Execution and resources	Run resources and Deep, Child, termination, Provider admission and tools	Request usage, leases, execution and finish state
Model selection	Model catalogue and request configuration	Permitted model routes and selected reasoning options
Methods and extensions	Skills, plugins, MCP connection and Hooks	Guidance, package generations and execution callbacks
Context	Projector, Main compaction and action reminders	Actual model input, committed summaries and reminders
Research materials	Result references, assets, Web, PDF, retrieval and Python	Sources, versions, read coverage and analysis
Control and delivery	Durable Control, scheduled tasks, Artifact, Publication, History and client	Commands, occurrences, storage and rendered output
Memory and observation	Long-term Memory, daily research and trajectories	Personal context and execution records
Human interaction	HIO plus original Correction, Recovery and Continue	Durable question/reply routing without copying grants

Layer one: conversation identity and research control

Related judgment: Principle 1 · the model interprets; the system records execution facts.

Users can retry a send, ask a small question, correct a long analysis or stop a background run. These actions cannot all be inferred from the most recent visible message.

Figure 2 · Message identity: replay, new Run or conflict

Figure 2 · Message identity: replay, new Run or conflict

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["User submission"]
    B{"Known message ID?"}
    C{"Same message body?"}
    D["Replay original Run"]
    E["Reject identity conflict"]
    F["Create new Run"]
    A --> B
    B --> C
    B --> F
    C --> D
    C --> E
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 2 · Message identity: replay, new Run or conflict

Figure 3 · Entry and native research loop

Figure 3 · Entry and native research loop

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Interpret request"]
    B{"Need external evidence?"}
    C["Direct answer"]
    D["Start Research"]
    E["Model proposes action"]
    F["Runtime executes"]
    G["Receipt enters next turn"]
    H["Publish answer"]
    A --> B
    B --> C
    B --> D
    D --> E
    E --> F
    F --> G
    G --> E
    G --> H
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 3 · Entry and native research loop

Mechanism	Input and output	Value of the separate responsibility
Message identity	Authenticated message to linked Run	Replay rather than duplicate work
Entry	Question to Direct or Research	Keep easy questions on a short path
Native Loop	Action proposals and receipts to next turn	Let the model reason without owning execution facts
Run resources	Allowance and actual usage to admission	One accounting source across retries and children
Action reminders	Resource facts to advice in a dispatched prompt	Advice cannot silently change quotas
Root-owned Child	Selected subtask to evidence-bearing handoff	Main retains final answer ownership

01. Conversation and message identity

One point to remember: A Conversation holds exchanges, a Message identifies a send, and a Run records one execution.

The Conversation stores exchanges; a Run is an execution instance with its own tool receipts and publication. A stable client message ID lets the server recognize a retry.

The same identity and same body lead to a replay or recovery of the original Run, whereas a reused identity with different content is rejected. Account and scope admission happens in code before the model can examine private holdings.

Synthetic walkthrough: A retry with the same message ID and body replays the old Run; a conflicting body must fail.

02. Entry selects work, not a simplistic topic label

One point to remember: Entry chooses direct explanation or evidence-backed research based on required work.

” can be Direct. “Calculate the concentration of my actual funds from their latest reports” needs Research. Entry receives the question and bounded authorized context, then selects a structured short answer or a research route.

A directory describing available sources is not evidence that those sources were read. Skills may initiate relevant research, but they do not grant new access.

Synthetic walkthrough: A definition of sector concentration can be Direct; a question about my funds needs authorized data.

03. Native research loop: propose, execute, inspect

One point to remember: The model chooses research steps; Runtime records actual actions and their receipts.

For a complex request, the model proposes an actual action, Host and Runtime record admission and execution, and the resulting receipt enters the next model turn. The model may then read more sources, compute a comparison or publish its conclusion.

It should not be asked to maintain a second authoritative ledger of whether a tool ran, how many requests were billed, or which action can be safely retried. The runtime retains these observable facts.

Synthetic walkthrough: If a fund report conflicts with classifications, Main obtains more evidence before answering.

04. Run resources and Deep research

One point to remember: Main, Child and Recovery consume the same Root budget, with no separate Deep ledger.

A single Run’s request count, actual usage, bounded execution time and finalization allowance have one accounting owner. Child workers, retries and recovery do not independently reset the limit.

Deep is an authorized resource-mode adjustment; it is not automatically a different model, reasoning effort, or permission scope. A rejected upgrade cannot erase earlier usage or unknown effects.

Synthetic walkthrough: After a Child spends model calls, Main sees that spending in the same Run.

05. Unified action reminders

One point to remember: Reminders advise the model but do not grant resources or prove delivery.

Context pressure, approaching budget limits and publication constraints may be turned into bounded guidance for the model. Only a reminder actually incorporated into a dispatched model request counts as delivered guidance.

A suggestion to wrap up does not itself terminate the Run, authorize a more expensive tool, or increase available budget.

Synthetic walkthrough: A reminder omitted by context fitting must not be logged as already sent to the model.

06. Root-owned subagents

One point to remember: A Child explores a bounded branch while Root owns the scope and Main owns synthesis.

Main can directly perform a simple read or delegate a multi-step Web, PDF or Python investigation. Child subagents use their own bounded turns but derive authority from the Root.

They return identified sources, read ranges, artifacts, partial answers and gaps to Main, which owns the final synthesis. A Child having read a PDF does not mean Main consumed the entire PDF; the handoff has to preserve that distinction.

Figure 4 · Delegation: Main owns final delivery

Figure 4 · Delegation: Main owns final delivery

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Main chooses"]
    B["Direct read"]
    C["Web subagent"]
    D["Document subagent"]
    E["Compute subagent"]
    F["Result handoff"]
    G["Main synthesis"]
    A --> B
    A --> C
    A --> D
    A --> E
    B --> G
    C --> F
    D --> F
    E --> F
    F --> G
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 4 · Delegation: Main owns final delivery

Synthetic walkthrough: A PDF Child finds a table, a Python Child computes a scenario, and Main checks both.

Focus: foreground interaction and background research coexist

One long background Run can analyze the funds while a short foreground Run answers a definition question. Scope concurrency admits the appropriate class under a common bounded capacity policy. The client shows progress by Run identity rather than holding a single Conversation-wide busy flag. A correction and Stop must target the intended Run; an unrelated quick answer must not overwrite the background result.

Figure 5 · One Conversation, several Runs: concurrent research and quick replies with targeted Correction.

One Conversation can relate multiple Runs, but there is still one Runtime, Host authorization model, result identity system and publication path. That is the key architectural change, not simply raising a concurrency limit.

Go deeper · Entry and multi-run research: Entry decisions (Chinese original) · Root-owned subagents · Chat alongside background research · Model and Runtime responsibilities (Chinese original)

Layer two: context and reusable methods

Information saved somewhere in the application is not automatically information the model saw. The final transmitted model input must be inspectable separately from the surrounding repository of sources and results.

Figure 6 · Projector: actual model input

Figure 6 · Projector: actual model input

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["User question and history"]
    B["Skills and preferences"]
    C["Tool receipts"]
    D["Unified projection"]
    E["Fitting and compaction"]
    F["Dispatched model request"]
    G["Retained omitted materials"]
    A --> D
    B --> D
    C --> D
    D --> E
    E --> F
    E --> G
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 6 · Projector: actual model input

Figure 7 · Memory versus current portfolio facts

Figure 7 · Memory versus current portfolio facts

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["User request"]
    B["Stable preferences"]
    C["Versioned memory"]
    D["Current authorized read"]
    E["Authoritative holdings"]
    F["Explain current versus historical"]
    A --> B
    B --> C
    A --> D
    D --> E
    C --> F
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 7 · Memory versus current portfolio facts

Context material	Owner	Purpose
Question and actual receipts	Projector	Maintain exact request and consumed results
Fund-research procedure	Skill	Reuse methods without extending permission
Stable language preferences	Profile	Adapt communication
Explicit save, correction and forget	Versioned Memory	Retain controlled long-term context

07. Projector: what actually reached the model

One point to remember: Projector establishes what was actually included in a model request.

The Projector assembles current instructions, the exact user question, relevant history, selected Skill guidance, tool receipts, references and the final available tool surface. Context fitting can omit or externalize material while retaining the identity of omitted sources.

Main compaction commits a source-linked summary of a settled earlier range to the original checkpoint; summaries never become independent evidence or new execution receipts.

Synthetic walkthrough: A source was stored but left out of the request; investigate projection first.

08. Skills provide methods, not unlimited tools

One point to remember: Skills reuse domain research methods, not tool permissions.

An ETF research Skill may instruct the model to confirm product identity and report dates, inspect sources, use appropriate calculation assumptions, and disclose gaps. It cannot turn a missing or unauthorized capability into an executable tool.

Generic instructions belong in common guidance; domain procedures belong in Skills; concrete arguments and output formats belong in tool contracts. Extension packages also require controlled source, lifecycle and profile admission.

Synthetic walkthrough: A Skill can suggest checking a report date but cannot grant access to private tools.

09. Memory versus actual holdings

One point to remember: Long-term preferences differ from authoritative current portfolio facts.

Long-lived expression preferences should not be confused with current investment balances. Explicit save, correction and forget operations have durable versions and receipts; a later failed answer cannot undo a previously committed forget operation.

Private and temporary modes must preserve their own boundaries. A recollected conversation can help phrase an explanation but is not a substitute for a fresh authorized read of the user's portfolio.

Synthetic walkthrough: Remember 'be concise'; read the user's holdings afresh from authorized sources.

Go deeper · Actual model input: Keeping tool results outside context · Main compaction · Durable Memory effects · Principle 5: Context is a workbench

Layer three: capability discovery, admission and execution

The tool may be installed, registered with MCP, described to a model, admitted for a Run and finally executed. Each is a separate fact. A tool name in a prompt is not an execution receipt.

Figure 8 · From proposed tool to actual invocation

Figure 8 · From proposed tool to actual invocation

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Visible tool"]
    B["Validate arguments"]
    C["Pre-call hook"]
    D["Host admission"]
    E["Dispatch and receipt"]
    F["Post-call projection"]
    G["Next model turn"]
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 8 · From proposed tool to actual invocation

Figure 9 · Post-call hooks narrow, never replace facts

Figure 9 · Post-call hooks narrow, never replace facts

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Original receipt"]
    B["Preserve source facts"]
    C["Hook model projection"]
    D{"Removal only?"}
    E["Accept narrowed projection"]
    F["Reject fact rewriting"]
    A --> B
    A --> C
    C --> D
    D --> E
    D --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 9 · Post-call hooks narrow, never replace facts

Execution seam	What changes there	What it must preserve
Gateway	Transport and protocol conversion	Observed stream and interruption
MCP and Host	Discovery, validation and dispatch	Grant, tool identity and source
Pre-call Hook	Local action decisions	Normalized arguments and Host rules
Post-call Hook	Narrow model-visible results	Unchanged retained facts and provenance
End Hook	Observe the conclusion	Termination and publication ownership

10. Model Gateway and provider requests

One point to remember: Gateway preserves provider protocol facts and must not invent an incomplete tool call.

Gateway normalizes different provider protocols, streams and tool-call argument encodings. A partial response cannot be treated as a complete authorized action. Provider admission controls shared concurrency and endpoint lease; the Run resources owner controls the execution's own consumption.

The configured model catalogue determines eligible routes while the model-call owner binds requested settings, including supported reasoning effort.

Synthetic walkthrough: An interrupted JSON tool-call stream must not trigger a guessed call.

11. MCP, Host and actual Tool Surface

One point to remember: MCP connects tools; Host admits, dispatches and settles each actual invocation.

The MCP owner handles service connections, discovery, schemas, protocol transport and close behavior. Host validates the concrete Run and tool invocation. A34 guards the actual tool synopsis and final model-visible tool surface against mismatch with admitted capability contracts.

Discovery does not imply the model saw a tool; visibility does not imply the action passed Host authorization. The real invocation also needs valid parameters, permission, reservation and a settled receipt.

Synthetic walkthrough: An MCP service lists a tool without giving this Run permission to use it.

12. Hooks and plugins with limited authority

One point to remember: Hooks may block or narrow model-visible content, not rewrite source authority.

Pre-call hooks may block a particular invocation; post-call hooks may remove details from a model-visible projection. They cannot replace a source, timestamp or amount while retaining the same field path as though the tool returned it. Original receipts stay intact.

The extension owner manages package admission and profile lifecycle, while hook execution manages callbacks and local errors. Neither acquires Root termination or Publication ownership.

Recorded engineering case: A recorded hook passed structural checks but altered source, date or numerical values.

Go deeper · Capability contracts: MCP from discovery to use · The final Tool Surface · Content trust and prompt injection · Tool lifecycle and model input

Layer four: source evidence and reproducible calculation

Retrieval, document reading, financial definitions, exact arithmetic and sandboxed exploration solve different problems. The synthetic portfolio question needs all of them to establish a credible sector overlap explanation.

Figure 10 · From retrieval hit to consumed evidence

Figure 10 · From retrieval hit to consumed evidence

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Retrieve candidates"]
    B["Verify version"]
    C["Read passage and context"]
    D["Check coverage and time"]
    E{"Evidence sufficient?"}
    F["Record gap"]
    G["Source-backed conclusion"]
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    E --> G
    F --> G
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 10 · From retrieval hit to consumed evidence

Figure 11 · Separate source, formula and computation

Figure 11 · Separate source, formula and computation

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Sourced data"]
    B["Choose financial definition"]
    C["Exact deterministic arithmetic"]
    D["Isolated Python analysis"]
    E["Preserve assumptions and lineage"]
    F["Model explains risk"]
    A --> B
    B --> C
    A --> D
    C --> E
    D --> E
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 11 · Separate source, formula and computation

Activity	Output	Supported inference
Retrieval	Source-bearing candidate passages	Where to read next
Document reading	Consumed ranges and versions	Exactly what was inspected
Financial arithmetic	Inputs, method and reproducible output	Correct value for the selected formula
Isolated analysis	Work products with assumptions	Executed exploration, not investment authority

13. Retrieval identifies candidate material

One point to remember: Retrieval returns candidates, not a proof of evidence consumption or adequacy.

Lexical and semantic retrieval can locate passages about fund objectives or industry concentration. A similar product name, older share-class prospectus or truncated snippet can still be the wrong evidence. Candidate passages must preserve source and version.

A35 keeps external Web/PDF/tool content in the status of data: instructions embedded inside a document do not become Host or system authority.

Synthetic walkthrough: A PDF says 'ignore previous instructions'; it remains untrusted source text.

14. Web, PDF and research assets enable continued reading

One point to remember: Continued research preserves document identity, version and reading position.

Search hits are starting points. Real reading requires document identity, exact consumed ranges and the ability to continue into adjacent sections or PDF pages. A search snippet is weaker evidence than a read source passage.

Page-image generation does not prove that the image actually entered a model request. Cached content and current permission to display the content are also distinct.

Synthetic walkthrough: A search hit needs adjacent PDF tables and caveats from the same revision.

15. Deterministic finance and A33 precise arithmetic

One point to remember: Financial calculations require time-bound authoritative inputs and reproducible formulas.

Source and version owners establish where data came from and its effective date. Financial domain rules select the appropriate formula and units. A33 performs the bounded decimal operation under those already chosen parameters and rounding rules.

Numerically exact computation cannot choose the correct denominator or validate an investment strategy. Outputs need source references, definitions and assumptions to be reproducible.

Synthetic walkthrough: Combining an old holdings snapshot with a new price can wrongly infer share quantity.

16. Isolated analysis and artifacts

One point to remember: A Python sandbox enables exploratory calculations, not authority over real holdings.

Python is appropriate for temporary comparisons, scenario tables, plots and experimental models. Its execution receipt records that a computation took place, not that an exploratory value has become an official portfolio position.

Direct HTML and files created in an isolated workbench still require the original export, publication and Artifact storage path before the user has an authenticated download.

Synthetic walkthrough: A hypothetical sector exposure script can succeed without changing any account data.

Go deeper · Sources and numbers: Web research (Chinese original) · PDF evidence · Financial definitions and reproducibility · Python research workbench

Layer five: answer delivery, human interaction and continuity

Related judgment: Principle 2 · proposal, approval, execution and effects are different facts.

The time when an answer is drafted, rendered, published, saved or read from History can differ. Partial results and background work make this distinction essential.

Figure 12 · Visible preview versus durable publication

Figure 12 · Visible preview versus durable publication

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Candidate body"]
    B["Publication disposition"]
    C["Authorized preview"]
    D["Durable commit"]
    E["History revision"]
    F["Client reconciliation"]
    A --> B
    B --> C
    B --> D
    C --> F
    D --> E
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 12 · Visible preview versus durable publication

Figure 13 · Three kinds of continuation

Figure 13 · Three kinds of continuation

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Receive message"]
    B{"Identical retry?"}
    C["Replay original Run"]
    D{"Explicit continuation?"}
    E["Parent-linked new Run"]
    F["Ordinary follow-up Run"]
    A --> B
    B --> C
    B --> D
    D --> E
    D --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 13 · Three kinds of continuation

User action	How it is handled	Why it matters
Identical message resend	Find existing identity and Run	Do not execute the same action again
Resume interrupted work	Recover original receipts	Do not duplicate settled effects
Explicit task continuation	Create linked new Run when allowed	Do not silently reopen terminal work
Ordinary follow-up	Create new Run with relevant context	A new request is not a replay
Reply to human question	Route by exact interaction identity	Do not target whichever chat is latest

17. Publication and progressive answers

One point to remember: Text, citations, attachments and durable save are separate publication effects.

Publication determines which candidate text and associated citations may become user-visible and durable answer revisions. A missing optional attachment or citation can be handled locally without erasing unrelated allowed prose.

Real account authorization and sensitive-data constraints still apply to the relevant content. Progressive corrections should identify the part being revised rather than append another duplicate full answer.

Recorded engineering case: A failed citation binding previously suppressed independent usable answer text.

18. Citation presentation is not evidence certification

One point to remember: Citation rendering is navigation, not a certification of support.

A citation renderer converts recognized source links into readable navigation and ordered markers. The underlying source identity, grant and supporting passages are still owned elsewhere. Displaying a citation number does not mean every sentence nearby is established by the material.

An unmatched citation is a limited navigation problem, not permission for a renderer to silently delete the complete answer.

Synthetic walkthrough: Displaying a research-citation: marker as [1] does not validate the adjacent claim.

19. History, events and frontend rendering

One point to remember: Visible previews can precede durable history, so reconciliation must protect identity.

Provider streaming and browser delivery are different streams. The client receives approved answer, progress and terminal events, then projects them by Run and Publication revision.

A visible preview may temporarily precede the durable database record; an immediate empty History read should not erase that still-authorized preview. Once authoritative History arrives, it reconciles by identity and version.

The UI cannot treat a stale message array or animation as an execution fact.

Recorded engineering case: An empty history read once overwrote a visible authorized answer preview.

20. Artifact access and sharing

One point to remember: An Artifact URL is only a locator; readers still need revision-specific access.

A saved HTML report, chart or Python file has immutable identity and authenticated access rules. A sharing grant must bind the exact recipient, Run and revision and cannot simply turn a URL into a reusable download credential.

Artifact failure should be reported for that effect; it does not automatically revoke an independent legitimate explanation already published as text.

Synthetic walkthrough: A shared artifact grant is rejected for a mismatched reader or file revision.

21. Durable Recovery and idempotent retry

One point to remember: Recovery consumes sealed effect receipts; unknown outcomes cannot be replayed blindly.

Recovery reconstructs sealed model turns, executed actions, unknown effects, checkpoints, grants, leases, fences and committed answer versions. It must not ask a model to invent what supposedly happened.

A previously settled tool action can be replayed from its original receipt; an uncertain external effect must remain uncertain until reconciled. The original lease and fence ensure stale workers cannot publish over a newer claimant.

Synthetic walkthrough: After restart, a completed tool call must not execute again just because it is missing from context.

22. Durable Control versus a scheduled occurrence

One point to remember: Parking and schedules are durable control facts rather than model polling loops.

An original nonterminal Run can be safely parked and then awakened through an original Control event, with its identity and budget retained. A user-confirmed recurring schedule instead creates a fresh bounded occurrence and Task Run at the scheduled time.

Both reuse the existing Control system, but a wake is not a new task and a scheduled task is not infinite authorization to keep invoking a model. Automatic scheduled research does not initiate human waiting.

Figure 14 · Durable control: wake versus new scheduled Run

Figure 14 · Durable control: wake versus new scheduled Run

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Original Run parked"]
    B["Original Control event"]
    C["Wake same Run"]
    D["Confirmed schedule"]
    E["New occurrence"]
    F["New scheduled Run"]
    A --> B
    B --> C
    D --> E
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 14 · Durable control: wake versus new scheduled Run

Synthetic walkthrough: A parked Run wakes on a Child result; a confirmed weekly schedule creates a new occurrence.

23. Run termination and bounded finalization

One point to remember: Run finalization owns the terminal decision, not every local optional failure.

A local optional-tool failure or pressure reminder cannot decide the whole Run has failed. The original Run-level termination owner combines actual receipts, resource limits, recoverability and finalization protection before choosing an allowed closing phase.

It leaves financial data, accounting, Publication and underlying transaction state with their original owners.

Synthetic walkthrough: A failed optional tool cannot terminate the entire Run without the finalization decision.

24. Follow-ups, replay and explicit continuation

One point to remember: Retry, follow-up, explicit continuation and clarification have different semantics.

An identical network retry reuses existing execution identity. An ordinary follow-up creates a new Run using selected authorized context.

A user-approved continuation of unfinished or terminal work creates a linked Run under the existing Continue contract rather than silently waking a terminal record. Textual similarity never grants access to an old source, read cursor or action.

Synthetic walkthrough: 'Continue the research' creates a linked Run while a network retry reuses a message ID.

Focus: durable Human-in-the-Loop (HIL)

A research agent sometimes needs a human answer while still being capable of independent reads and calculations. A37 HIO is a standalone logical Owner for bidirectional interaction admission and response routing. The model proposes a question using the Native ask-user tool; HIO durably binds it to the original authenticated scope, Conversation, Run, Action, request revision and deadline. A cross-conversation inbox shows accessible pending items without assuming whichever chat is newest must be the answer target.

By default, asking is non-blocking. Work continues until a true dependency is reached, while the user can respond to the exact persistent request. Receipt of the user's text is different from adoption: the original Correction safe point carries it into an actual Main model input. When necessary, the original Recovery owner may safely Human Park an unfinished Run; Control and Scope then manage wake-up and readmission. Parking never resets consumed model usage or explicit hard deadlines.

Figure 15 · Durable HIL: return to the original Correction or Recovery; explicit Continue for a terminal Run.

If the original Run is terminal, a late answer stays associated with the original interaction. The user must explicitly confirm Continue Research before the existing Continue path creates a parent-linked new Run. Stable response identity, conflict handling and lost-ack reconciliation prevent retries from creating new work merely because a button was pressed again.

Implementation boundary: durable human interaction has bounded engineering validation, but production Human Park is disabled by default. Real-model behavior and long-term quality are not yet established.

October 24, 2026: HIO acceptance scope and exclusions

As of October 24, 2026, HIO Stages A–D have completed their stated local provider-free formal close and archive, covering non-blocking questions, Human Park and recovery, the cross-conversation inbox, Effect Approval, Permission Requests and original-text Child coordination. Scoped PostgreSQL, fresh-process and authenticated-browser evidence supports the corresponding engineering seams. Production Human Park remains disabled by default; natural model behavior, real-user quality and production reliability are not thereby qualified. HIO does not grant permissions, execute protected effects or own a second model loop. See the detailed durable human-response mechanism.

Go deeper · Publication and recovery: Publication (Chinese original) · Progressive answer coherence · Background delivery by deadline · Collaborative background research

Layer six: observing facts and evaluating answers

Observability spans all preceding layers; quality review asks whether the user actually got a useful, supported answer. Neither should be compressed into a single completed flag.

Figure 16 · Observable handoffs, not one success flag

Figure 16 · Observable handoffs, not one success flag

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Run identity"]
    B["Model input and output"]
    C["Tool receipts"]
    D["Publication storage"]
    E["Client rendering"]
    F["Diagnostic view"]
    A --> B
    A --> C
    A --> D
    A --> E
    B --> F
    C --> F
    D --> F
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 16 · Observable handoffs, not one success flag

Figure 17 · Evaluation of actual delivery

Figure 17 · Evaluation of actual delivery

%%{init: {"flowchart": {"curve": "step"}}}%%
flowchart TD
    A["Original user goal"]
    B["Delivered answer"]
    C["Source and numeric check"]
    D["Semantic review"]
    E["Pass, fail or unknown"]
    F["Identify owner"]
    A --> D
    B --> C
    B --> D
    C --> E
    D --> E
    E --> F
classDef default fill:#FFFFFF,stroke:#A3B9C7,stroke-width:1.5px,color:#193649;
linkStyle default stroke:#517A8D,stroke-width:1.8px;

Figure 17 · Evaluation of actual delivery

Observation	What it captures	What it does not prove
Generation	Candidate text	That the user received the text
Delivery	Transport and display evidence	That server emission equals visible rendering
Persistence	Durable publication revision	That the original task was fully answered
Consistency	Matching IDs and revisions	That the interpretation is true
Execution	Run and action final facts	That an answer is useful
Quality	Explicit semantic and numerical checks	That unreviewed cases passed

25. Langfuse and trace: locate the first incorrect handoff

One point to remember: Tracing locates the first wrong handoff in real request and delivery records.

When a reported source seems missing, the investigator needs the actual model request, not just proof that a PDF existed in the repository. The source might not have been consumed, may have been omitted by context fitting, or may have arrived in a Child summary without the original caveat.

Run-scoped model requests, tool receipts, Publication revisions and rendered-content observations expose where evidence was lost. HIL adds separate request-admitted, reply-saved, Correction-committed and Main-adopted facts.

Synthetic walkthrough: If a document existed but never reached the model, inspect Projector rather than blaming retrieval.

26. Evaluation: compare the original question to actual delivery

One point to remember: Quality review must examine what the user actually received, not just draft text.

An excellent candidate answer that never reached the user is not successful delivery. The sector-overlap case needs reproducible numbers and documented coverage, valid citation support, and a meaningful explanation of uncertainty.

Model-judge scores may help compare semantic outputs, but they cannot replace source reading or deterministic calculation. Keep failed, partial and unknown cases in the denominator and repair the owner controlling the actual failure.

Synthetic walkthrough: An excellent model candidate never delivered to the user cannot pass outcome evaluation.

Go deeper · Observation and evaluation: Langfuse and trustworthy traces · What green tests prove · From bug loops to task convergence · Principle 8: Actual user outcomes

Temporal semantics and market sessions explains user-local days, frozen task time and calendar evidence. Shadow Credits keeps dispatch identity and observed usage separate from Run budgets.

From V1 to V2: evolving interfaces rather than piling on controllers

The first six-layer story still explains admission, methods, execution, evidence, publishing and feedback. V2 preserves that complete journey and incorporates concurrent interaction, final tool-surface consistency, content trust, source-linked results, exact arithmetic, durable background delivery and HIL. The goal is deeper capability behind clear contracts, not a second manager for each newly invented feature. New work should deepen existing responsibilities where possible, introduce a truly missing owner only where needed, and remove obsolete duplicate mechanisms.

Historical edition

V1 (October 20, 2026): the original complete Chinese architecture story