# Goose: a persisted, ordered operation pipeline

Goose is useful for learning how an agent harness grows beyond “call the model, execute tools, repeat.” Its central design is an ordered pipeline of operations over a saved conversation. Approval, tool execution, compaction, retry policy, and model inference each get their own operation. After an operation changes state, Goose saves its effects and starts scanning the pipeline again. This makes control flow explicit, while moving some complexity into message metadata and operation ordering. [G1], [G2]

**Snapshot:** local `goose` checkout, clean tracked worktree, commit `34a222e3f2b95d8b4a43482b53c2cc957ecce26d`; origin `https://github.com/aaif-goose/goose.git`. Inspected October 18, 2026. All source links below are pinned to that commit. This chapter analyzes implementation, not benchmark performance. No Goose sessions, builds, or tests were executed.

## Start with four layers

![Goose architecture: the Agent assembles a state machine that loads session state, scans operations, persists effects from the first applicable operation, then reloads and scans again.](../guide/assets/goose-architecture.svg)

*Simplified Goose-managed execution map. Providers that own their own loop follow a different path.*

1. **Clients:** the CLI and Electron desktop provide input, rendering, and permission responses. Desktop sends prompt/cancel/steer requests using Agent Client Protocol (ACP). CLI definitions expose `acp` over stdio and, with the `acp-http` feature, `serve` over HTTP/WebSocket. These are delivery surfaces, not separate model algorithms. [G3], [G4]
2. **Goose application:** `Agent` assembles provider, session manager, extensions, hooks, inspection, and steering. Its `reply` method returns a stream of `AgentEvent`s. [G5]
3. **Reusable engine:** `goose-agent` supplies `StateMachine`, `Operation`, and `InferenceRunner`. The Goose application selects and configures operations. An *effect* is a requested state change, such as appending a message or changing message visibility. [G1], [G6]
4. **Capabilities and storage:** providers translate model requests; extension clients implement tools; `SessionManager` stores conversations and session metadata in SQLite. [G7], [G8], [G9]

Do not equate every provider with a remote language-model API. The interface also allows providers that own their conversation context. The Goose builder skips its own full compaction for those providers. `ProviderDef::RUNS_OWN_TOOL_LOOP` separately identifies integrations handed MCP servers to run their own tool loop. This chapter's detailed trace describes Goose-managed execution. [G2], [G7], [G10]

## One user request, several model requests

A *user turn* here means the work initiated by a user message until the harness yields or stops. A model request is one inference within that work. Goose's `max_turns` mechanism counts contiguous assistant blocks since the kickoff message; it is not a universal measure of user turns, tokens, or elapsed time. Streaming chunks in one assistant block do not individually consume that count. [G6], [G11]

`reply_with_state_machine_inner` acquires a per-session active-turn guard and saves the user message. `stream_state_machine_session` resolves provider/model/context limit, builds the machine, and forwards its events. Inside the reusable machine, the first operation that applies wins that iteration. [G1], [G5]

```text
persist incoming message
build the ordered pipeline
repeat:
    session = load persisted session and conversation
    for step in pipeline order:
        stop if cancelled
        if step is inference:
            prepare a session/extension snapshot
            gather every operation's tools and prompt contributions
        result = run step
        if result applies:
            ensure message IDs
            persist result.effects
            break the scan
    if nothing applied, or result yields/cancels: stop
finalize cancellation and repair unanswered tool requests if needed
```

The concrete order begins with slash-command dispatch, approval, skills, recipes, extension tool execution, remaining-tool handling, subagents, steering, and bang-shell handling. Then come context operations and completion controls, ending with inference. Every restart begins at the front; an operation must recognize from persisted state that its work is already done. `Operation::set_message_meta` records past actions for this purpose. This is reconstructible control flow, not a claim that external side effects execute exactly once after arbitrary crashes. [G1], [G2], [G6]

## A read → edit → test → finish trace

This illustrative Unix trace assumes the developer extension and an ordinary model provider. It does **not** execute commands. At this revision, developer tools are flat names such as `shell`, `edit`, `write`, `tree`, and `read_image`; its instructions use shell commands to read text files. A fictional `read_file` call would misrepresent this particular tool surface. [G12]

1. User: “Fix the parser's empty-input case and verify it.” The message is saved; inference advertises the currently leased tool definitions.
2. Model: `shell({command: "cat src/parser.ts"})`. The assistant request gets an ID and an advertised-tool list. The next pipeline scan inspects permission, dispatches the tool, and persists its response under the same request ID. [G5], [G13]
3. The model sees the file and requests `edit` with path and exact replacement text. The tool description requires an exact, unique match. If approval is required, Goose records an action-required message and marks execution unavailable pending a decision. The outer agent stream waits for confirmation answers before rerunning the machine. [G12], [G14]
4. After editing, the next model request asks `shell` to run the appropriate focused test. A failed tool result is information returned to the model; it can choose another edit. The harness does not inherently know that this particular test proves the original request correct. [G13]
5. The model returns a plain final answer. If no recipe/goal/stop-hook operation asks for more work, inference no longer applies and the pipeline yields. An optional recipe success check can reject apparent completion and initiate another attempt. [G6], [G15]

The trace uses separate model requests because the edit depends on reading, and testing depends on the edit. Emitting dependent calls together would undermine that ordering.

## Tools: contracts, routing, concurrency

Tools use MCP's `Tool` representation, including JSON input schemas and annotations. The developer extension generates schemas from Rust parameter types and deserializes arguments into those types at execution. The inference adapter canonicalizes recoverable tool names, coerces arguments using the advertised schema, and records advertised tool names on assistant messages. Execution checks that model-originated requests were advertised. [G12], [G16], [G13]

An extension lease is the selected set of extension instances and capabilities for a session snapshot. Its catalog maps a public tool name to its extension and server-side name. A call resolves that entry, builds a context containing session, working directory, and cancellation, and calls the extension's MCP client. Platform extensions run in the agent process; configuration also supports bundled, stdio, and Streamable HTTP extensions. MCP standardizes the contract, not the trustworthiness of the implementation. [G8], [G17]

Concurrency has two stages. `ToolExecutionOperation::run` prepares dispatches in a loop, then uses `select_all` to poll their result and notification streams together. Thus tool futures can progress concurrently; this is not a sequential “await each complete result” loop. `ToolBatch::record` adds responses as observed, deduplicating by request ID. There is no request-order sorting in this operation: result order can differ from request order. Notifications can reach the client before the batch finishes; the final response message is emitted and persisted after the combined stream finishes. Cancellation finalization can preserve results already recorded in the batch. [G13]

The engineering implication is specific: independent reads can overlap, but the model or caller must preserve dependencies between writes and subsequent tests. The generic execution operation does not infer a filesystem dependency graph. That is a bounded observation about this operation, not a statement about every extension's internal scheduling.

## Approval is policy; isolation is execution environment

Permission inspection distinguishes `Chat`, `Auto`, `Approve`, and `SmartApprove`. In the permission inspector, Auto allows calls; Approve and SmartApprove consult explicit tool permissions. SmartApprove additionally uses read-only annotations and model-based classification for candidates. Other security inspectors can override the permission baseline. A read-only hint or model judgment is a policy input, not an operating-system guarantee. [G18], [G14]

Approval requests and responses are saved conversation records. The wrapper can reconnect to pending confirmations or apply a saved answer, but the original extension lease still matters: when an executable request has no valid retained lease, tool execution returns an “approval expired” response asking for a new request. Therefore “the conversation is persistent” must not be shortened to “every pending authorized action can be replayed after restart.” [G5], [G13]

For execution isolation, the inspected stdio connector supports explicitly running an extension using `docker exec` when supplied a container; without it, it starts the configured local process. The developer platform extension's ordinary shell builder launches a host shell with the selected working directory. Neither path shown establishes a universal filesystem/network sandbox for all Goose tools. Container configuration is a separate deployment choice, and the stdio container branch should not be advertised as enclosing all in-process platform tools or remote MCP servers. [G19], [G20]

## Context and persistence are different views of history

Goose records user visibility and agent visibility separately. The provider receives a projection of the saved conversation, not necessarily the entire transcript. Inference removes unanswered old tool requests from prior turns, repairs provider-facing conversation structure, and merges compatible messages. [G21]

Compaction can run before inference when usage exceeds the configured threshold, or reactively after a context-length error. The operation bounds repeated reactive attempts; providers owning context bypass Goose's full compaction. `compact_messages` summarizes the agent-visible history, makes original messages agent-invisible, adds an agent-only summary and continuation instructions, and preserves the current text request for automatic compaction. The user-visible history can therefore remain longer than the model context. Optional tool-pair summarization is separately configured and defaults off in the inspected configuration helper. [G22], [G23]

`SessionManager` persists messages and session configuration in `sessions.db`, using SQLite WAL mode. Effects include append/replace, request-metadata patches, visibility changes, recipe/extension state, and usage. Compaction saving updates existing records' agent visibility and inserts new summary records in a transaction rather than blindly deleting concurrent messages. Session persistence supports reconstruction, while streaming output may be visible before its operation's effects have been stored. Approval requests deliberately publish after persistence so an immediate answer can find them. [G9], [G24], [G33]

## Steering and multiple clients

Steering is guidance submitted while a run is active. `Agent::steer` adds a message to a session's in-memory queue. `SteerOperation` drains that queue after tool results or a completed assistant response, emits the messages, invokes prompt-submit hooks, and returns persistence effects. It does not splice instructions into an in-flight model request. Undrained steers are not yet durable transcript entries; the ACP wrapper discards pending steers when clearing the run. [G34], [G35]

For **multiple humans or clients**, the ACP server shares an `ActiveRunRegistry` across connection-specific agents. It admits only one prompt run per session; a competing prompt gets an error directing the caller to steer. A second connection can steer the agent owning the active run, supplying `expectedRunId` to reject stale targeting. The factory contains a test specifically for this cross-connection routing. [G35], [G36]

This establishes shared input arbitration, not a complete multiplayer editing experience. The inspected `forward_agent_stream` sends notifications through the prompting connection; loading a session replays stored history. These paths do not establish a generic live broadcast subscription, per-human authorship model, or conflict-free shared editor. Treat those as unverified product capabilities, separately from the demonstrated multi-client steering and the separate subagent mechanism. [G37], [G38]

## Code mode for MCP: a second tool-calling shape

Goose's optional Code Mode is compiled behind the `code-mode` feature and registered with `default_enabled: false`. It exposes `list_functions`, `get_function_details`, and `execute_javascript`. Discovery lists exact callable names and short descriptions; details return original input/output schemas. The model writes `async function run()` and invokes `await tools.call(name, args)`, using `Promise.all` for independent calls. The callback catalog is taken from the dispatching extension lease; it excludes app-only tools, MCP resource tools, the code-mode extension itself, and Summon's delegate tool. [G39], [G40]

The model-facing tool list is reduced, but first-class platform tools and MCP resource tools remain directly visible. Thus code mode is not “all tools replaced by one interpreter.” Its practical advantage is letting JavaScript combine/filter results before returning text to the model, reducing intermediate context traffic; this is a design rationale, not a measured speed or token claim. [G41]

The interpreter uses Boa with an idle module loader and injected `tools`/`console`, rather than a Node.js environment. It limits instructions, loop iterations, recursion, output, worker slots, and execution time. Its own documented interface has no ambient filesystem, shell, network, packages, or environment access; external effects go through callable tools. These interpreter restrictions do not confine the external tools themselves. [G40], [G42]

There is an important policy boundary: the outer `execute_javascript` request follows normal tool approval/execution, while nested `dispatch_tool` invokes the lease directly. The inspected nested path does not re-enter `ToolApprovalOperation` or `run_pre_tool_hooks` for each callback. Therefore do not assume approving one script provides the same per-call review as separate model-issued tool requests; underlying tools may also enforce their own policy. Nested tool errors reject the JavaScript call and can be caught, and cancellation propagates to dispatch tasks. [G13], [G14], [G40]

## Cancellation, errors, and three distinct retries

The machine races each step against a cancellation token. On cancellation, it asks operations to retain partial output and creates interrupted responses for unanswered tool calls. Inference retains accumulated chunks; tool execution retains completed batch results. The developer shell handles cancellation by killing and waiting for its child, but this does not establish rollback of file edits or cancellation guarantees for every remote tool. [G1], [G13], [G20], [G21]

Keep these mechanisms separate:

- **Transport retry:** Goose's provider-stream adapter retries qualifying transient first-item failures before accepting stream output, with backoff and provider retry policy. This branch skips providers owning context. It is not a general replay of partially emitted output. [G25]
- **Empty-response retry:** `InferenceRunner` can retry an empty response up to three times, with special handling after successful tool responses. Exhaustion leaves a marker that completion operations can handle. [G21]
- **Task retry:** configured recipe checks can reject a completed answer, run an optional failure command, reset history to the kickoff, and try again within `max_retries`. Resetting conversation history does not undo files or external side effects. [G15]

Unrecovered errors eventually reach `ExitOnErrorOperation`, which yields. The operation pipeline therefore expresses both continuation policy and exit policy; neither should be inferred merely from whether the model emitted text. [G26]

## Extensions, recipes, and subagents

Recipes package instructions/prompt, extensions, provider/model settings, parameters, optional output schema, sub-recipes, and retry configuration. They describe reusable task setup and completion contracts; they are not a second implementation of the base state machine. Skills and hook operations add prompt material or lifecycle behavior around the same pipeline. [G2], [G27]

Foreground subagents have separate persisted sessions linked to the parent. Their saved recipe, provider/model, extension selection, and turn budget are used to prepare execution. The reusable `SubagentOperation` tracks multiple child update streams with `SelectAll`, persists delivered outcomes as agent-only parent messages, and records cancelled children so reconstruction does not relaunch them. A child can forward approval or elicitation requests to the parent. [G28], [G29]

The inspected Goose runner refuses to discover new subagents when the parent is already a `SubAgent`, and validates that a child belongs to the requesting parent. This is a bounded nesting restriction in this runner. These children are foreground work managed by the parent turn; the source explicitly distinguishes this implementation from older background-delegation history. [G30]

## What a builder should borrow

**Separate a decision from its durable effect.** A permission answer can arrive immediately. Persisting its request before emitting it prevents a race; recording operation notes lets reconstructed control flow recognize completed work. The cost is that metadata becomes part of the state-machine contract and needs migration/reconstruction tests. [G24], [G6]

**Separate transcript, model context, and live events.** A learner might delete old messages to save tokens, inadvertently destroying the audit trail. Goose's visibility projection and summary records preserve both views. The cost is more invariants: hidden messages, request/result pairing, and compaction must all agree. [G21], [G23]

**Make capability ownership explicit.** A provider may own context; an extension owns execution; the client owns interaction. This allows many integrations, but means “supports MCP,” “has approvals,” and “runs safely in a container” are three different claims. A new harness should expose those boundaries before adding more integration options. [G7], [G10], [G17], [G19]

For verification, the repository includes a dummy-provider pipeline test that reconstructs after every applied step and checks a two-inference tool exchange. Observability includes streamed message/usage/MCP events and tracing spans for inference, tool execution, and agent invocation. These are source-level capabilities; their presence is not evidence that tests passed here or that a telemetry exporter is enabled in every installation. [G31], [G32]

## Evidence matrix and reading path

Read G1 → G6 → G2 first, then G5 for the outer wrapper. Follow G13/G14/G8 for execution, and G21/G23/G24 for model context and durable state. Each row is a bounded implementation claim.

| ID | Claim | Source symbol |
|---|---|---|
| G1 | First applicable operation; save/reload; cancellation repair | [StateMachine::step/run/finalize][G1] |
| G2 | Concrete operation order and optional compaction | [build_state_machine][G2] |
| G3 | Desktop uses ACP prompt/cancel/steer | [acpPromptSession][G3] |
| G4 | CLI ACP stdio and feature-gated HTTP server | [Command::Acp/Serve][G4] |
| G5 | Persist kickoff, stream events, wait/resume approvals | [Agent::reply_with_state_machine_inner][G5] |
| G6 | Operation notes, kickoff and assistant-block counting | [Operation; assistant_turn_count][G6] |
| G7 | Provider stream/resume/context-ownership contract | [Provider][G7] |
| G8 | Lease resolves tools and builds execution context | [ExtensionLease::call_resolved][G8] |
| G9 | SQLite file and WAL storage configuration | [SessionStorage::create_pool/new][G9] |
| G10 | Some providers run their own tool loop | [ProviderDef][G10] |
| G11 | Autonomous assistant-block budget | [MaxTurnsOperation][G11] |
| G12 | Flat developer tools and typed schemas | [DeveloperClient::get_tools/call_tool][G12] |
| G13 | Advertised-tool check, lease expiry, concurrent streams | [ToolExecutionOperation::run][G13] |
| G14 | Durable approval effects and metadata | [ToolApprovalOperation::run][G14] |
| G15 | Recipe success checks and bounded retries | [RetryOperation::run][G15] |
| G16 | Tool-name recovery and argument coercion | [prepare_tool_requests][G16] |
| G17 | In-process, bundled, stdio, HTTP extension types | [ExtensionConfig][G17] |
| G18 | Modes, explicit permissions, read-only classification | [PermissionInspector::inspect][G18] |
| G19 | Optional Docker branch for stdio subprocesses | [connect; docker_exec][G19] |
| G20 | Host-shell creation, timeout and child cancellation | [run_command; build_shell_command][G20] |
| G21 | Provider projection, partial output, empty retries | [InferenceRunner::infer][G21] |
| G22 | Proactive/reactive compaction policy | [CompactionOperation::run][G22] |
| G23 | Visibility-based summarization and default-off pair summaries | [compact_messages][G23] |
| G24 | Durable effects and post-persistence approval emission | [SessionManager::apply_effects][G24] |
| G25 | Transient retry before first accepted stream item | [stream_response_from_provider][G25] |
| G26 | Unhandled trailing errors stop execution | [ExitOnErrorOperation::run][G26] |
| G27 | Recipe task/settings/output/retry fields | [Recipe][G27] |
| G28 | Child-stream concurrency and durable delivery notes | [SubagentOperation::run][G28] |
| G29 | Saved child configuration and forwarded decisions | [prepare_subagent; ForegroundSubagentRunner][G29] |
| G30 | Parent ownership and bounded nesting restriction | [SubagentRunner implementation][G30] |
| G31 | Reconstruction after every applied step | [tool_turn_reconstructs_after_every_applied_step][G31] |
| G32 | Client-visible event variants | [AgentEvent][G32] |
| G33 | Compaction transaction preserves existing rows | [save_compacted_conversation][G33] |
| G34 | Steering is drained between model/tool phases | [SteerOperation::run][G34] |
| G35 | Single active prompt; run-ID-checked steering | [start_active_run; require_active_run][G35] |
| G36 | Connections share ownership registry | [AcpServer::create_agent_with_session_cwd][G36] |
| G37 | Stream forwarding targets the current connection | [forward_agent_stream][G37] |
| G38 | Loading replays persisted conversation | [handle_load_session][G38] |
| G39 | Code Mode is optional and disabled by default | [PLATFORM_EXTENSIONS registration][G39] |
| G40 | Discovery, leased catalog, nested callback dispatch | [CodeExecutionClient; dispatch_tool][G40] |
| G41 | Some direct tools remain in code mode | [prepare_inference_tools][G41] |
| G42 | Restricted Boa context and bounded workers | [evaluate; execute_with_slots][G42] |

Limitations: the detailed path is Goose-managed inference and extension execution at this commit. Provider-specific internal loops, every remote MCP server, every platform-specific process behavior, and full crash consistency were not exhaustively audited. Code-mode restrictions and multiplayer conclusions are bounded to the cited paths. No runtime benchmark or security certification is implied.

[G1]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-agent/src/machine.rs#L118-L292
[G2]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine_builder.rs#L43-L136
[G3]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/ui/desktop/src/acp/prompt.ts#L9-L35
[G4]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-cli/src/cli.rs#L832-L859
[G5]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/agent.rs#L639-L1040
[G6]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-agent/src/operation.rs#L32-L203
[G7]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-provider-types/src/base.rs#L520-L697
[G8]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/extension_manager/lease.rs#L573-L729
[G9]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/session/session_manager.rs#L1056-L1078
[G10]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/providers/base.rs#L31-L69
[G11]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_maxturns.rs#L35-L68
[G12]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/platform_extensions/developer/mod.rs#L41-L255
[G13]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_toolcalling.rs#L251-L1106
[G14]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_tool_approval.rs#L39-L164
[G15]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_retry.rs#L170-L279
[G16]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_llm.rs#L75-L200
[G17]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/extension.rs#L158-L234
[G18]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/permission/permission_inspector.rs#L134-L283
[G19]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/extension_manager/stdio.rs#L14-L53
[G20]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/platform_extensions/developer/shell.rs#L414-L593
[G21]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-agent/src/inference.rs#L225-L560
[G22]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_compaction.rs#L184-L295
[G23]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/context_mgmt/mod.rs#L29-L225
[G24]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/session.rs#L40-L370
[G25]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/reply_parts.rs#L245-L375
[G26]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_exit_on_error.rs#L15-L33
[G27]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/recipe/mod.rs#L43-L130
[G28]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-agent/src/subagent.rs#L57-L290
[G29]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/subagent_handler.rs#L36-L287
[G30]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_subagent.rs#L15-L148
[G31]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/tests/reconstruction_isolation_lifecycle.rs#L18-L38
[G32]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose-agent/src/events.rs#L9-L18
[G33]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/session/session_manager.rs#L2198-L2255
[G34]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/state_machine/ops_steer.rs#L46-L98
[G35]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/acp/server.rs#L1876-L1957
[G36]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/acp/server_factory.rs#L85-L233
[G37]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/acp/server.rs#L2103-L2241
[G38]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/acp/server/load_session.rs#L381-L429
[G39]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/platform_extensions/mod.rs#L154-L172
[G40]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/platform_extensions/code_execution.rs#L22-L335
[G41]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/reply_parts.rs#L184-L207
[G42]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/agents/platform_extensions/javascript.rs#L27-L429