The Problem
Teams need an AI agent that can actually execute work on a local machine—writing files, running commands, testing code—rather than just suggesting edits in an IDE. Most AI coding tools stop at code completion. Goose targets the gap between "here's a suggestion" and "the task is done."
What This Does
Goose is a Rust-based CLI and desktop agent that automates engineering tasks end-to-end. The core logic lives in crates/goose-cli/src/, with commands for sessions, recipes, project tracking, and configuration. The crates/goose-acp/ directory implements the Agent Client Protocol (ACP)—a transport layer with HTTP and WebSocket adapters that lets goose talk to any LLM provider.
The agent supports multi-model configuration, MCP server integration, and a recipe system (crates/goose-cli/src/recipes/) for reusable workflows. It ships with scenario tests using recorded LLM responses (crates/goose-cli/src/scenariotests/recordings/) to verify behavior without live API calls. The repo includes a Docker build, GitHub Actions CI with 50+ workflows, and tooling via Hermit (bin/hermit.hcl).
How To Use It
Setup: Build from source using Cargo. The workspace is defined in Cargo.toml with three crates: goose-acp, goose-acp-macros, and goose-cli. A Dockerfile exists for containerized builds, and BUILDINGDOCKER.md documents that path. Prebuilt binaries are available per the README.
cargo build --release or docker build -t goose .
Configuration: Goose uses interactive setup via goose-cli/src/commands/configure.rs. You'll need API keys for your chosen LLM provider (Anthropic, OpenAI, Azure, etc.). Provider-specific configs are referenced in crates/goose-cli/src/scenariotests/providerconfigs.rs. The CLI supports a --config flag or interactive prompts.
Running it: The entry point is crates/goose-cli/src/main.rs. Invoke the binary directly:
./target/release/goose or goose session start
Commands are organized in crates/goose-cli/src/commands/—session, recipe, configure, project, schedule, and gateway.
Real-World Use
A team uses goose to automate a release process. They define a recipe that: checks out the release branch, runs the test suite, bumps the version in Cargo.toml, updates the changelog, and opens a PR. The agent executes each step, reports failures, and can be re-run with a different LLM provider if one hits rate limits. The scenario test framework lets them validate the recipe against recorded responses before running it live.
Code Health & Issues
Med - Repo hygiene: bin/ contains vendored binaries (.pkg files for cmake, node, rustup) committed to the repo. This bloats the repository and raises supply-chain concerns. Med - CI complexity: 50+ GitHub Actions workflows create maintenance overhead. Several (goose-issue-solver.yml, goose-pr-reviewer.yml) use goose itself for automation—meta, but increases CI runtime and failure surface. Low - Python script at .github/scripts/pr-review-mcp.py sits outside the Rust ecosystem, adding a second language to maintain. Low - .husky/pre-commit and .intersect/ config suggest local tooling that isn't documented in the README.
The codebase otherwise looks solid: 36 test files, a lockfile (Cargo.lock), CI, license (Apache 2.0), and security policy are all present. No obvious secrets or config leaks in the file listing.
The Bottom Line
Goose is a mature, well-engineered agent platform with real autonomy features and a thoughtful test strategy. It's best suited for teams that want a self-hosted, provider-agnostic agent they can extend and customize. The vendored binaries and heavy CI footprint add maintenance cost, but the core architecture is sound. If you need an agent that can actually finish tasks rather than suggest code, this is worth evaluating.