Goose: Block's MCP-native agent and its recipe system
Every agent eventually grows a plugin system. Goose did it backwards: it adopted someone else's standard as the plugin system and built the agent around it. Extensions in Goose are just MCP servers (including the built-in ones), and that single decision explains most of what is interesting about Block's agent.
MCP-first, not MCP-also
Most coding agents added MCP support later, as one integration among many. Goose was designed around it: the way the agent reaches your shell or your editor is the same protocol as the way it reaches your issue tracker or an internal deploy system. If something exposes an MCP server, it's a Goose extension: no bespoke plugin API, no waiting for a vendor to bless your integration. If MCP is still a fuzzy acronym for you, start here; Goose is the tool that makes the case for it most concretely.
The flip side is structural: Goose's ceiling is set by the MCP ecosystem, and so is its floor. A flaky server makes a flaky agent, and the agent takes the blame. Vetting the servers you attach matters more here than in any other tool.
Recipes: the session you can hand to someone
The signature idea. A recipe packages an agent workflow (the instructions, the extensions it needs, the parameters it takes) into a file you can version, share, and re-run. The one-off session becomes an artifact: triage the overnight bug reports, draft release notes from merged PRs, audit a new dependency. A teammate runs your recipe and gets your workflow, not a screenshot of your prompt. Recipes take parameters, can call other recipes, and can run on a schedule. That quietly turns a chat tool into an automation platform.
A recipe is the difference between an agent trick you performed once and a workflow your team runs every Tuesday.
Treat recipes with the discipline you'd give code, because that is what they're becoming: reviewed, versioned, owned. The arguments in prompts as code apply verbatim here.
Dogfooded at company scale
Goose's other differentiator isn't a feature; it's a customer. Block open-sourced the agent it deploys across its own workforce. That's engineers, and, tellingly, plenty of people who aren't. You can feel that pressure in the product: a desktop app for people who will never open a terminal, and recipes as the unit of rollout instead of "everyone gets good at prompting". Most open agents are built for their maintainers. Goose is built for the maintainers' coworkers, which is a usefully different constraint.
Where it wobbles
The honest list. Goose is model-agnostic, so it pays the same tuning tax as every open agent: it drives whatever model you configure and is optimized for none of them. The desktop and CLI surfaces don't always feel like one product. And recipes, for all the packaging, are still prompts underneath: parameterized nondeterminism, not scripts. A recipe that works nine times will get creative on the tenth, and its output needs the same review habits as any other agent work.
Within the open CLI landscape, Goose is the least code-centric tool on the map, and that is exactly its niche. If your unit of value is a repeatable workflow that crosses systems (code, tickets, docs, internal APIs), it's the open agent shaped for the job. If you just want edits in a repo, pick something lighter. Steal the recipe idea either way.