Block Open-Sourced Goose. Half the Company Uses It Weekly. The Interesting Part Is the Recipe File. — Vantage Academy

Block Open-Sourced Goose. Half the Company Uses It Weekly. The Interesting Part Is the Recipe File.

By Haim Ari · 2026-05-26T14:00:00

Block built Goose — an open-source CLI agent — and pushed it across its own engineering org. The pattern that scaled wasn't the model or the prompt, it was a small YAML file that any engineer can author. Here's the architecture, the recipe format, and a copy-paste walkthrough you can run on your own machine in ten minutes.

Block — the company behind Square, Cash App, and Afterpay — released Goose in early 2025 as an open-source AI agent. A year later it has 44k+ stars on GitHub, 368+ contributors, and 2,600+ forks. The project recently moved from block/goose to the Agentic AI Foundation under the Linux Foundation, which means it's no longer governed by a single company.

The adoption story inside Block is the part most coverage glosses over. Public reporting puts it at roughly 60% of the company's ~12,000 employees using Goose weekly, with around 4,000 of 10,000 employees in active use across 15 different job profiles — engineering, sales, design, product, customer success. That breadth is the thing. The same tool is being used by an engineer fixing a flaky test and by a product manager pulling a Jira ticket.

What lets one tool serve both is the recipe.

What Goose Actually Is

Goose is a local agent. It's a Rust binary that runs on your machine, talks to an LLM provider of your choice, and uses MCP servers as its tools. The interface is a CLI (goose) and a desktop app. The architecture has three pieces:

• A core agent loop — plan, call tools, evaluate, repeat until done.

• A provider abstraction — point it at Anthropic, OpenAI, Gemini, Mistral, xAI, or a local model running under Ollama, Docker Model Runner, or Ramalama. 25+ providers are supported.

• An extension system built on MCP — every tool the agent uses is an MCP server.

That last point matters more than it looks. Because tools are MCP servers, an extension is a configuration entry, not a code change. Adding GitHub access is a line in a config file. Adding a private internal API is a line in a config file. The agent itself stays the same.

!Goose architecture overview

The piece that turns this from "yet another agent CLI" into something a 12,000-person company can adopt is the recipe.

The Recipe Is a YAML File

A recipe is a YAML document that bundles instructions, required extensions, parameters, and the actual prompt into a single shareable file. Anyone can write one. Anyone can run one. The command is one line:

``bash

goose recipe run review-pr

The recipe behind that command might be 30 lines of YAML. It defines what tools the agent gets, what input it needs, and what it's supposed to do step by step. The agent doesn't decide which tools to load — the recipe does. The agent doesn't free-form its way through the task — the recipe gives it a sequence with checkpoints.

A real one looks like this:

`yaml

name: review-pr

recipe:

version: 1.0.0

title: Review a Pull Request

description: |

Pull a GitHub PR, read the diff, surface risk areas,

and post a structured review comment.

settings:

goose_provider: anthropic

goose_model: claude-sonnet-4-20250514

parameters:

• key: pr_url

input_type: string

requirement: required

description: The GitHub PR URL to review.

instructions: |

You are reviewing {{ pr_url }}.

Track progress in ./scratchpad.txt using checkboxes.

Stop and surface anything you are unsure about — do not guess.

prompt: |

Fetch the PR diff and the list of changed files.

For each file, identify: behavior changes, new dependencies,

missing tests, anything that looks rushed.

Group findings by severity: must-fix, should-fix, nit.

Post a single review comment with the grouped findings.

Mark the scratchpad complete.

extensions:

• type: builtin

name: developer

timeout: 300

bundled: true

• type: stdio

name: github

cmd: npx

args: ["-y", "@modelcontextprotocol/server-github"]

env_keys: ["GITHUB_TOKEN"]

A few things to notice about the shape of this file.

The parameters block makes the recipe a function. pr_url is required and becomes {{ pr_url }} in the instructions. You don't write a new recipe per PR — you write one recipe and call it with different inputs.

The extensions block is the MCP surface. Two extensions here: developer (built-in, gives shell + file access) and github (a stdio MCP server that the recipe pulls in by name). Goose installs nothing globally to make this work. The extension is loaded for this recipe and discarded when the run ends.

The prompt is numbered. Goose treats numbered steps as a planning skeleton. The agent doesn't have to reinvent the workflow on every run because the recipe encodes it.

Why Block Chose This Shape

This is the part that explains the adoption number. A YAML file is a thing a product manager can author....