BYOA (Bring Your Own Agent)

• BYOA — Bring Your Own Agent — is the model where teams take agents built somewhere else and run them on Guild's control plane instead of starting from scratch.
• Guild supports multiple agent architectures out of the box: TypeScript with the Guild SDK, Goose recipes (Block's YAML format), and Guild Native Markdown-only agents.
• The value of BYOA is not the porting itself. It is that once an agent runs on Guild, it inherits Guild's runtime: workspace credentials, governance, sessions, versioning, and observability.
• Most existing agents adapt cleanly. Agents already using standard patterns (a system prompt, tool calls, a defined input and output shape) map onto one of Guild's supported types with minor changes.

BYOA stands for "bring your own agent." It is shorthand for the model where an organization does not build every one of its AI agents from scratch on a single platform. Instead, agents originate wherever it made sense to build them — a hackathon prototype, an open-source recipe, an internal tool a team already runs, a partner-built agent — and get brought onto Guild for production execution and governance.

The premise is straightforward. The interesting engineering in an agent is the behavior: the prompt, the tools, the parameters, the flow. That behavior is portable if the surrounding architecture is. Guild's role in a BYOA world is to be the production home for agents you did not necessarily build there.

Guild supports multiple agent architectures

The reason BYOA works on Guild is that Guild is not opinionated about how an agent is defined. It supports three agent types out of the box: TypeScript agents using the Guild SDK, Goose recipes (Block's declarative YAML format), and Guild Native agents defined in Markdown. Most existing agents map cleanly onto one of these.

Fork an existing agent

guild agent init --fork owner~agent-name

If the agent you want to bring is already on Guild (under another owner), forking creates a copy under your account that you can then modify, publish, and run. This is the simplest BYOA path.

Init from scratch and paste your logic

If the agent lives outside Guild — a recipe you wrote in Goose, a TypeScript agent from a boilerplate, a prompt you refined in a chat interface — init the matching Guild agent type and move your logic into the scaffolded files. Existing prompts become PROMPT.md (Guild Native) or the instructions field of a recipe. Existing tool calls become Guild SDK tool declarations. Existing parameters become recipe parameters or Zod schemas.

Governance takes over once it runs

Once the agent runs on Guild, it inherits everything: it lives inside a workspace, respects workspace credentials, generates a session on every run, follows the Saved / Validated / Published lifecycle, and shows up in guild agent list, guild session list, and Insights.

Rewriting is where good agents go to die

Asking a team to rewrite an agent from scratch because they changed platforms is how good agents stop existing. BYOA reframes the question: keep the agent, change what runs it. That is a much easier ask, and it is the one that actually gets said yes to.

The value is the runtime, not the framework

Most agent frameworks solve the same building problem: how do you define an agent's behavior. Guild's value is in the running problem: how do you deploy, govern, observe, and manage agents in production. BYOA is the model that lets an organization stop thinking about framework decisions as vendor decisions.

It lowers the switching cost of the runtime

If moving to Guild required rewriting every agent, most organizations would never move. Because Guild supports multiple agent architectures and portable formats like Goose recipes, the switching cost is small enough that the decision becomes about whether Guild's governance and observability are worth having — not whether the migration is feasible.

It matches how real teams already work

Real teams have agents from many places: a proof-of-concept a data scientist built, a helper a support lead scripted, an open-source recipe someone forked. BYOA is the model that acknowledges this reality instead of pretending every agent should originate on one platform.

Not every agent will fit exactly

Some existing agents rely on framework-specific features that Guild's supported types do not honor 1:1. Goose recipes with extensions or sub_recipes are rejected on Guild, for example. When that happens, the fix is usually to restructure the agent, not to change platforms — Guild is opinionated about what it will run for reasons that map to production safety.

Credentials do not come along automatically

An agent brought from elsewhere brought its logic, not its credentials. Guild credentials are managed at the organization level and connected in Settings before an imported agent's tools can call anything. If the source agent used API keys stored in a .env file, plan on reconfiguring those the Guild way.

BYOA is a starting point, not a permanent state

Ported agents usually get restructured over time as teams take advantage of Guild-specific patterns: workspace context, skills, LLM preferences, hybrid code+LLM patterns. The BYOA move gets the agent running; the ongoing improvement is what makes it feel native.

Consider whether Guild Native is a better shape

For prompt-driven agents with no code logic, moving from a TypeScript-heavy agent to a Guild Native Markdown-only agent often makes the agent simpler and more maintainable. BYOA is not just about porting — sometimes it is about simplifying at the same time.

Guild is a control plane for AI agents, a place to build, deploy, and govern the agents your teams run in production. BYOA is what makes Guild practical for organizations that already have agents — the question is not whether to rewrite them, it is how to run them.

• The agent types guide covers the three architectures your existing agent can map onto.
• Goose recipes are one of the easiest existing agent formats to bring across.
• Talk to us about a full BYOA plan for your team.