From Task to Evidence
English | 中文
How one business task crosses models, tools, permissions, and sessions
Start with one representative execution path, not the package tree. Watch input become actions, results, and inspectable evidence, then locate each responsibility in source.
A user submits an objective and working material.
An Agent composes models and tools, then executes under policy.
Results and process enter the session log for UI and SDK projections.
Start with a representative task
Imagine a business owner asks: “Inspect this repository's login flow, identify one risk that could cause duplicate submission, and explain the evidence. If code must change, show the scope and wait for approval.” This is not a fixed repository demo; it is a representative input used to explain implemented behavior.
The deliverable is more than an answer. It includes the Agent composition used for this session, messages shown to the model, tool calls and approvals, file changes, check results, and the order of those facts in the session.
Step 1: Give the session an Agent composition
When the Host creates an Agent, it first resolves the preset for that session. The preset mounts the model, system prompt, tools, and supporting plugins into the Agent scope; other sessions in the same process may use different compositions. An unknown, broken, or unmountable preset fails during creation instead of leaving a partially composed Agent.
For a business reader, this means “one platform, task-specific capability sets.” A code-review Agent can receive repository, shell, and LSP access; a read-only knowledge assistant can omit write tools; a high-risk back-office task can expose only approved domain actions. The mechanism lives in the Agent preset registry and session scope.
Step 2: Rebuild model requests from session facts
The agent loop opens a turn and step, appends the user message, and builds the model request from the composed system prompt, tool schemas, and deriveMessages(). Model history is not a separate hidden chat cache: it is derived from ordered surface events, and every new model-visible input must first have a session event.
As the model streams output, deltas and the committed message continue into the same log. Failures, retries, token usage, and request targets have their own events, so a refresh or different consumer does not have to guess what the model saw. The main path is implemented in the agent loop and session event implementation.
Step 3: Send tool calls through the governance pipeline
When the model asks to read a file, run a command, or call a domain tool, execution does not jump directly to the implementation function. The registry materializes arguments, then runs pre-execute, monotonic guards, approval, execution, post-execute, finalization, and immutable result notification. A guard may tighten a call into denial but cannot reopen a denial that already occurred.
A call requiring approval runs only after the approval service returns a one-time allow. Missing answerers, answerer failure, or session policy never deny by default. Delegated subagent sessions use never, preventing unattended children from expanding permission through a prompt nobody is watching. See the tool execution pipeline, tool registry, and approval service.
Step 4: Log results and rebuild the interface
Tool starts, endings, failures, and visible results enter the session event log. The Web client folds those events into user messages, assistant messages, tool cards, retry notices, and running state. Tools can also declare generic, terminal, or diff presentation intent so a domain action receives an appropriate transcript representation.
After a session persistence provider writes the log, a later process can load it again. Callers may also drive the same runtime spine through Web, CLI, ACP, TypeScript SDK, or Python SDK. Client projections live in the Web runtime, while persistence enters through session persistence.
Where the path fails loudly
| Position | Visible signal | Business meaning |
|---|---|---|
| Agent composition | Missing, broken, or wrongly scoped preset | The task does not continue with missing capabilities |
| Model request | Unsupported provider, model, credential, or content | The request fails before network I/O or at the adapter with a diagnostic |
| Tool decision | Invalid arguments, policy denial, or unavailable approval | The action does not run, and the reason becomes a tool result |
| Execution provider | Unavailable sandbox, process failure, or timeout | The failure belongs to the tool call and is not disguised as success text |
| Session recovery | Invalid format version, required event, or persisted content | Loading refuses instead of guessing what old data means |
Think of the Harness as a composition—decision—execution—record—presentation pipeline
The LLM proposes intent. Plugins determine available capabilities. The tool pipeline decides whether actions can run. Providers perform the work. The session log preserves facts. Interfaces and protocols project those facts to different users.
Evidence status: Confirmed against current source unless noted. The representative task explains mechanisms; it is not a ready-made business template or outcome guarantee.