Bring Your Own Agent: Guild Now Runs Goose

The best AI agent is often one you've already built.

Maybe you have a local agent running in production today — reviewing pull requests, generating summaries, triaging support tickets. It works. You trust it. But it lives on someone's laptop, or in a pipeline with no visibility, no typed interface, and no way for the rest of your team to use it. Getting it into a proper platform feels like a rewrite.

It isn't. Not anymore. Not with Guild.

An agent is a reusable unit of AI work. It takes structured input, does something — reasons, retrieves, writes, calls tools — and returns a result. Unlike a one-off prompt, an agent is a thing you can invoke, share, compose, and version.

The difference between "a prompt I run sometimes" and "an agent my team depends on" is usually just a matter of structure: a defined interface, a place to live, and the infrastructure to run it reliably. That's the gap Guild fills.

Guild is the platform layer and control plane for agents. It hosts them, manages their typed input and output schemas, routes calls to them, and lets you compose them — wiring one agent's output into another's input, or calling a library of shared agents from inside your own organization.

When you publish an agent to Guild, you get versioning, a validated interface, and a runtime that other agents and users can call. The Agent Hub is where that library will live: a catalog of agents your organization has built, ready to be discovered and used.

The question has always been: how much work does it take to get an agent to successfully deliver what you’re after? For agents built with the Guild SDK, the answer is "write some TypeScript." But for agents that already exist, or that you'd rather define without writing code, here at Guild, we wanted the answer to be closer to "almost nothing."

Goose is an open-source AI agent framework created at Block and now a project of the Linux Foundation's Agentic AI Foundation (AAIF). Its recipe format lets you define an agent entirely in YAML: the system prompt, the default message, typed parameters, and an optional structured output schema. It's declarative, readable, and portable. A Goose recipe runs on Goose's desktop app, in CI, or anywhere the Goose CLI runs.

Guild now runs Goose recipes natively; if you have a recipe.yaml, you have a Guild agent.

A Goose recipe is a YAML file that describes everything an agent needs to do its job:

• instructions — the system prompt, rendered as a Jinja template
• prompt — the default opening message, also a template
• parameters — typed inputs that callers supply, available as template variables
• response — an optional JSON Schema defining the structured output

Here's a simple example — a code reviewer with a configurable language and focus:

That's the whole agent. No SDK, no build step, no TypeScript. The parameters become a typed input form; the templates render at runtime with whatever the caller supplies.

To publish a Goose recipe as a Guild agent, place recipe.yaml at the root of your agent's version files and push.

Guild validates the recipe at build time, not at runtime, when it's too late. It checks that every template variable is a declared parameter, every declared parameter is used, defaults coerce cleanly to their declared types, and the response schema is valid JSON Schema. If anything is wrong, the build fails with explicit errors before the agent ever runs.

This is intentional. A recipe that declares a Goose extension expects the agent to have it. Running silently without it produces confusing behavior — the wrong answer at the wrong moment. Guild rejects unsupported fields at build time, so authors find out immediately rather than in production.

On success, Guild derives typed input and output schemas from your recipe and persists them on the version. Those schemas are the contract: callers know exactly what to send and what to expect back. The rest of the platform, routing, or composition, treats your Goose agent identically to any other.

A recipe alone is a self-contained LLM agent. But most real agents need to do more, such as calling an API, delegating work to a specialist, or asking the user a follow-up question. For that, you add a guild.yaml alongside your recipe.yaml.

guild.yaml is where you declare dependencies. Here's an example that wires in a GitHub integration, a shared research sub-agent from the Agent Hub, and a built-in tool to prompt the user for clarification:

That's all there is to it. A few YAML files and you have a working agent with connections to external services, internal tools, and subagents.

Each declared integration, sub-agent, and built-in becomes a tool that the agent can call. The research agent in that example might itself be a Goose recipe, a Guild SDK agent, or anything else saved in your organization. The recipe doesn't need to know or care.

This is where "no code required" compounds. You can assemble an agent that calls real APIs, delegates to specialized agents, and handles interactive flows — all from YAML.

If you're already running Goose recipes in production, the path to Guild is short. The recipe file you have today is valid input. Guild adds build-time validation, typed schemas, versioning, and the full platform runtime on top of it, without asking you to rewrite anything.

The tradeoff is explicit and narrow: Guild doesn't support every Goose feature. Extensions, provider settings, sub-recipes, and retry configuration are rejected at build time with clear errors. If your recipe uses those fields, you'll know immediately and can decide whether to adapt it. What Guild supports covers the large majority of practical recipes.

The result is an agent that was already working — now running with a defined interface, composable with the rest of your organization's agents, and governed the same way everything else on Guild is.

You can get started using Goose today. Join us at our upcoming webinar on using Goose, Wednesday July 29th, 2026.

You built it. Guild runs it. Read our docs to learn more, or jump in and get started today.