Goose / Goose Recipe

• Goose is Block's open-source AI agent framework. Recipes are the declarative YAML format Goose uses to describe an agent's behavior.
• Guild supports Goose recipes as a first-class agent type. A recipe.yaml file at the root of your agent runs on Guild without any TypeScript.
• Guild honors a subset of Goose recipe fields (description, instructions, prompt, parameters, response) and rejects the ones it cannot safely support (extensions, settings, sub_recipes, retry).
• Use Goose agents when you already have a Goose recipe, or when you want to describe agent behavior in portable declarative YAML with parameters and Jinja-templated prompts.

Goose is an open-source AI agent framework maintained by Block. It gives developers a declarative way to describe agent behavior — the instructions, the parameters the agent takes, the response shape it produces — in a YAML file rather than in imperative code. The recipe is the unit of Goose: one file describes one agent.

Recipes are portable. The same recipe.yaml can run in a local Goose runtime, in a shared team environment, or on any platform that speaks the recipe format. Guild is one of those platforms.

The framework grew out of the observation that most agent scaffolding is repetitive: same prompt shape, same parameter definitions, same response schema. A declarative format lets teams describe agents without rewriting the scaffolding each time.

Initialize a Goose agent

guild agent init --name my-goose-agent --agent-type goose

Guild scaffolds an agent directory with a template recipe.yaml at the root. Replace the template with your recipe and save.

The recipe format

A minimal recipe describes an agent with instructions and (optionally) a prompt:

description: Review code with a configurable focusinstructions: You are a {{ language }} reviewer focused on {{ focus }}.prompt: Review the code provided below.parameters:  - key: language    input_type: select    requirement: required    description: Language under review    options: [python, typescript]  - key: focus    input_type: string    requirement: optional    default: best practices    description: Review focus area

The instructions and prompt fields are Jinja templates rendered against the recipe's parameters at session start. See the Jinja templates glossary entry for the syntax details.

What Guild honors and what it rejects

Guild processes a specific subset of Goose recipe fields. Anything Guild cannot safely support is rejected at build time with a clear error rather than silently ignored. The high-level shape:

• Honored: description (required), instructions, prompt, parameters, response (json_schema becomes the output schema).
• Ignored: title (Guild uses the agent name), version, author, activities (Goose desktop-only).
• Rejected: extensions, settings (provider and model are platform-controlled), sub_recipes, retry, and any unknown field.

At least one of instructions or prompt must be present. If neither is there, the recipe is invalid.

No build step

Like Guild Native agents, Goose agents skip the build validation step because there is no code to compile. After initialization, the agent transitions immediately to READY.

Declarative is easier to review

A recipe.yaml file is a description, not a program. Anyone on the team can read it, understand what the agent does, and propose changes. That is a huge governance advantage over agents whose behavior lives in a mix of code and prompt files.

Parameters make one recipe cover many use cases

A parameterized recipe with Jinja-rendered instructions covers many variants of the same shape: a code-review recipe that works for Python, TypeScript, or Go depending on a single parameter; a report-generation recipe that adapts to the audience passed in at session start.

Portability beyond Guild

Because the recipe format is Goose's, not Guild's, a recipe you write for Guild can run in a Goose runtime elsewhere with minor adjustments. That is a real hedge against platform lock-in for the recipe layer of your agent stack.

Guild adds governance and runtime

Guild adds what Goose does not itself provide: the workspace boundary, credential scoping, session logging, versioning, observability. You get the declarative recipe format plus the production runtime.

Rejected fields are rejected on purpose

Guild rejects extensions, settings, sub_recipes, and retry because silently ignoring a declared field would produce confusing behavior. A recipe author who declared an extension expects the agent to have it. If Guild cannot support the extension, the safe answer is to say so at build time.

Provider and model are platform-controlled

The Goose settings field is rejected because Guild controls provider and model selection through LLM preferences and model policies. This is deliberate: an organization's model policies should not be overridden by a recipe field.

At least one of instructions or prompt

A recipe with neither instructions nor prompt is rejected. The distinction: instructions become the system prompt (persistent role definition), prompt becomes the default initial message (the opening turn).

The full Goose recipe reference is at block.github.io/goose/docs/guides/recipes/recipe-reference for canonical field definitions.

Guild is a control plane for AI agents, a place to build, deploy, and govern the agents your teams run in production. Goose recipes are one of the three agent shapes Guild supports, giving teams a declarative YAML option alongside TypeScript and Guild Native Markdown.

• The Goose agents guide covers the full recipe processing pipeline.
• Recipes use Jinja templates in their instructions and prompt fields.
• Sign in at app.guild.ai to init your first Goose agent.