Skip to main content
Integrations · Goose
Goose is an open-source agent framework where the agent consists of a “recipe” of instructions, parameters, and a response schema, declared in YAML. Guild runs that recipe as a real agent without a line of SDK code. You supply recipe.yaml, Guild validates it at build time, derives typed input and output schemas from it, and runs it on a governed platform your whole team can call.

Bring your recipe

One YAML file in, a governed, versioned, callable agent out.

Book a demo

See how teams run and govern Goose recipes in production.

​
Your recipe is your agent’s DNA

A Goose recipe declares what the agent does, including instructions, acceptable parameters, and answer schemas. And that declaration is exactly what Guild needs. Parameters become a typed, validated input schema. A response json_schema becomes the output schema. The description becomes how your team finds it.
That file, unchanged, is a Guild agent with an interface other people and other agents can call.

​
How it works

1

Initialize

guild agent init --name my-goose-agent --agent-type goose. Or start from the web editor, which validates recipe.yaml as you type.
2

Drop in your recipe

Replace the template recipe.yaml with yours. Guild validates the whole file at build time and reports every issue at once, so a recipe that builds is a recipe that runs.
3

Save and run

Your recipe is now a versioned agent: typed inputs, a declared output schema, and a runtime anyone on the team can call. Publishing a new version is deliberate, and versions are immutable.

​
Declaration in, governance out

Guild treats the recipe as the contract, and the platform enforces the rest. The model and provider are platform-controlled, so a recipe cannot pin its own: every model call routes through Guild’s gateway under your policies, with spend attributed to the agent that made it. A recipe that declares its own extensions fails the build with a clear error instead of running half-wired in production. Credentials never enter the recipe, the container, or the prompt; they resolve server-side after the policy check. And when something misbehaves, any session can be stopped mid-run. Two-thirds of organizations with agents had an agent-related incident last year. The recipes were rarely the problem. The runtime underneath them was.

​
Frequently asked questions

No. You supply your recipe.yaml as it is. Guild validates it at build time and derives the agent’s typed input and output schemas directly from it. No SDK code is required.
description, instructions, prompt, parameters, response and skills are honored. title, version, author and activities are ignored. extensions, settings, sub_recipes and retry are rejected at build time with an error naming the field.The authoritative table is in Goose agents.
A recipe that declares extensions fails the build, on purpose. Running a recipe without the extensions it expects produces confusing behavior, so Guild tells you at build time, the earliest possible moment. Reusable capability comes through Guild skills instead.
No, and that is the point. Provider and model are platform-controlled: calls route through Guild’s gateway under your model policies, with spend attributed per agent. Your admins decide what models run, not each recipe file.
Stop any session mid-run. Disconnecting a credential immediately denies calls from sessions that are already running.

​
Bring your first recipe

One YAML file in, a governed, versioned, callable agent out. Running in minutes.

Bring your recipe

Start from the web editor or the CLI.

Book a demo

Walk through governance with the team.
Also runs on Guild: OpenClaw · GitHub · Slack · Splunk Read: the Goose launch post · Docs: Goose agents · Glossary: AI agent runtime · Agent control plane
Last modified on October 16, 2026