Goose: The Extension-First Rust Agent with LLM-Based Adversary Inspection

What makes Goose different

Goose occupies a unique position in this agent set: it is a Rust-native, extension-first runtime with a security model that uses a second LLM to review tool calls. The architecture is deliberately minimal at the core — tools come from extensions, security comes from a layered inspector stack, and learning happens through a recipes and skills system.

Architecture overview

Goose is built as a Cargo workspace with multiple crates. The main goose crate contains the core agent runtime, tool inspection pipeline, provider system, and extension manager. Key crates:

The agent core: agent.rs

The main Agent struct in src/agents/agent.rs (~2,500 lines) handles the complete agent loop. The key design patterns:

// From src/agents/agent.rs — the inspection stack setup
fn create_tool_inspection_manager(
    permission_manager: Arc<PermissionManager>,
    provider: SharedProvider,
) -> ToolInspectionManager {
    let mut manager = ToolInspectionManager::new();

    // Add security inspector (highest priority - runs first)
    manager.add_inspector(Box::new(SecurityInspector::new()));
    manager.add_inspector(Box::new(EgressInspector::new()));

    // Add adversary inspector (LLM-based review, enabled by ~/.config/goose/adversary.md)
    manager.add_inspector(Box::new(AdversaryInspector::new(provider.clone())));

    // Add permission inspector (medium-high priority)
    manager.add_inspector(Box::new(PermissionInspector::new(...)));

    // Add repetition inspector (lower priority - basic repetition checking)
    manager.add_inspector(Box::new(RepetitionInspector::new(None)));

    manager
}

Multi-mode security: GooseMode

Goose implements four distinct operating modes defined in src/config/goose_mode.rs:

The SmartApprove mode uses a particularly elegant pattern: it calls permission_manager.apply_tool_annotations(&tools) which reads the MCP ToolAnnotations.read_only_hint field. Tools with read_only: false are automatically added to the "ask_before" list in the smart-approve permission config.

The LLM-based AdversaryInspector

The AdversaryInspector in src/security/adversary_inspector.rs is the most distinctive security component in Goose. It activates when you place an adversary.md file in your Goose config directory (~/.config/goose/adversary.md).

adversary.md format

tools: shell, computercontroller__automation_script
---
BLOCK if the command exfiltrates data or is destructive.
ALLOW normal development operations.

The frontmatter specifies which tools to review (defaults to shell and computercontroller__automation_script). The rules below the --- separator are passed to the LLM for judgment.

How it works

1. When a tool call targets a listed tool, the inspector formats the tool call with its arguments
2. It extracts the original task from the conversation and recent user messages
3. It fires a separate LLM call (using the same provider) with the tool call, task, and user rules
4. The LLM responds with ALLOW or BLOCK and a reason
5. If BLOCK, the tool is denied with the LLM's explanation shown to the user

// From src/security/adversary_inspector.rs — the LLM review prompt
let system_prompt = "You are an adversarial security reviewer, protecting the user \
    in case the other agent is rogue. An AI coding agent is about to execute a tool \
    call. Your ONLY job: decide if this tool call is safe given the user's task and \
    rules. Respond with ALLOW or BLOCK on the first line, then a brief reason on \
    the next line.";

let user_message = format!(
    "The user's original task: {}\n\n\
     Recent user messages (oldest first):\n{}\n\
     The tool call to review:\n```\n{}\n```\n\n\
     Rules:\n{}\n\n\
     Respond with a single word on the first line: ALLOW or BLOCK\n\
     Then on the next line, a brief reason.",
    original_task, history_section, tool_description, rules
);

Provider system: 15+ providers across 35+ modules

Goose's provider architecture in src/providers/ is extensive. The providers/mod.rs exports 35+ provider modules:

The canonical/ directory contains auto-generated model mapping data: canonical_models.json maps canonical model names to provider-specific model identifiers, and provider_metadata.json contains per-provider capabilities and limits.

Extension system and MCP

Goose's extension system is implemented in src/agents/extension_manager.rs and enables dynamic loading of MCP servers and custom tools. Extensions can be stdio-based (spawned as child processes) or embedded via Docker.

MCP client implementation

The McpClient in src/agents/mcp_client.rs implements the MCP client protocol using the rmcp crate. It handles:

• Connection management and session tracking
• Tool listing and calling with proper request context
• Notification forwarding (progress, logging, etc.)
• Resource and prompt management
• Working directory synchronization across MCP sessions

Tool execution pipeline

The tool execution flow in src/agents/tool_execution.rs and src/agents/agent.rs follows this sequence:

Sub-agent execution

Goose implements sub-agent execution in src/agents/subagent_handler.rs with a comprehensive system:

// From src/agents/subagent_handler.rs — sub-agent prompt context
pub struct SubagentPromptContext {
    pub max_turns: usize,
    pub subagent_id: String,
    pub task_instructions: String,
    pub tool_count: usize,
    pub available_tools: String,
}

// Template from src/prompts/subagent_system.md:
// "You are a specialized subagent within the goose AI framework,
// created by AAIF (Agentic AI Foundation). You were spawned by
// the main goose agent to handle a specific task efficiently."

The sub-agent supports final_output mode where it runs until it produces structured output matching a JSON schema, then stops. This is useful for extracting structured data from complex tasks.

Shell tool: platform-aware execution

The shell tool in src/agents/platform_extensions/developer/shell.rs (~980 lines) is one of the most platform-aware shell implementations in this set:

Recipe and skill framework

Goose's recipe system enables converting chat conversations into reusable automation workflows. Defined in src/recipe.rs and prompted via src/prompts/recipe.md:

Context compaction and memory management

Goose implements context compaction in src/context_mgmt/mod.rs. The compaction triggers when context usage exceeds a configurable threshold (default: GOOSE_AUTO_COMPACT_THRESHOLD).

• Tool pair summarization: Repeated tool call/response pairs are summarized to reduce context size
• Session naming: Goose auto-generates session names using the provider when not disabled
• MOIM injection: inject_moim() in src/agents/moim.rs injects a message-of-instructions before the latest assistant message, sourced from extension-collected hints

Key differences from other agents

File count and codebase size

Goose's Cargo workspace contains multiple crates with substantial source:

Notable engineering decisions

Key files reference

My assessment