Meet Smith: How Guild's Meta-Agent Works

Guild is an agent-orchestration platform, and that means there's lots of surface area to learn: agents, workspaces, triggers, integrations, credentials. For a new user, the gap between "I have an idea" and "it's running" can feel wide.

Smith is how we close that gap. Smith is Guild's built-in assistant, and it's the first thing you see when you open a workspace. Instead of landing on a dashboard full of settings, you land in a chat. You describe what you're trying to do, and Smith helps you do it — no forms to fill out first.

This post covers what Smith is, what you can ask it for, and — for the engineering-minded — how it actually works underneath.

Smith replaces the old dashboard as the default landing experience. Whenever you don't have an active session, opening a workspace takes you straight to Smith's chat. Type a message, press Enter, and you're working.

New accounts start in a short onboarding tour rather than a wall of welcome modals and setup surveys. The tour introduces the platform and hands you a few starter prompts. Pick one and it runs immediately, so you get to see an agent work before you configure anything.

Smith is always one click away after that, too — the chat bubble at the top of the left sidebar opens it in any workspace.

Smith is there to help you actually build on Guild, not just to answer questions. You can ask it to:

• Tell you more about Guild features, agents, and configuration
• Help you build, debug, and publish your own agents
• Walk you through setting up integrations and triggers
• Troubleshoot errors in your sessions or agent code

Because Smith has read access to your workspace configuration — the agents you've installed, your triggers and integrations, your recent sessions — it can give answers that fit your actual setup, instead of asking you to paste in configuration details every time.

Smith is itself a Guild agent

The interesting part is what's behind that chat box. Smith isn't a bespoke service bolted onto the product — it's a Guild agent, running on the same runtime as everything else you build. That was a deliberate choice, and it shapes the whole design.

Running Smith as a normal agent means it inherits the runtime's state management, versioning, and tool model for free, and it means the team ships improvements to Smith by publishing a new version, exactly the way you'd ship a new version of your own agent.

A skill-driven brain

Smith doesn't carry one giant prompt describing every operation it can perform. It starts with a compact index of primitive skills — things like discovering your platform state, creating a workspace, configuring an agent, wiring credentials, creating a trigger, writing workspace context, and handing you off. When Smith decides it actually needs one, it calls a tool to load that skill's full instructions on demand.

This progressive disclosure keeps Smith's working context small and focused: it reads the detailed playbook for creating a trigger only when it's about to create a trigger. The skills are atomic building blocks, and Smith composes them to fit whatever workflow you described.

Setup is a contract: discover, plan, approve, execute, hand off

When you ask Smith to build something, it doesn't start creating things. It follows a guided-setup contract. First it discovers live state — which account and workspace to use, whether a suitable published agent already exists, which integrations and credentials the workflow will need. Then it asks only the questions that genuinely block the plan (which repository? what schedule and timezone? which Slack channel?), and presents a concrete roadmap: the account, the agent it will install or build, the credentials required, the trigger that will run, and where you'll be handed off.

Nothing is created until you approve that plan. Every state-changing operation — creating a workspace, installing an agent, requesting a credential, creating a trigger — is gated behind explicit approval of a concrete plan. Read-only discovery is always allowed; mutations are not, until you've said go. If you asked only to look around ("just check whether I have a PR-review agent"), Smith reports what it found and stops, rather than sliding into building something you didn't ask for.

The proxy is the security boundary

Giving an LLM real platform powers carries risk, so it's worth being precise about how it's contained.

Smith isn't a privileged side channel. It runs on the same control plane as every other agent in Guild, and reaches the platform through the same credential and permission system those agents already use. It has no special API key and no service account. Its tool calls go through an internal proxy that resolves the real user behind the conversation and re-issues each call as that user, with exactly the permissions you have and no more. Smith can't read anything you couldn't read or change anything you couldn't change.

On top of that, the proxy enforces a strict allowlist. Only a curated set of platform-setup routes — a few dozen, covering account and workspace discovery, the agent catalog, integrations and credentials, triggers, sessions, and usage and audit reads — are reachable. Anything off the list returns a 403. So the boundary is defined in one place, and it's defined by what's explicitly permitted, not by what someone remembered to block.

This is also why some statements about Smith are true only within Smith's own context. A rule like "you can only read the workspace you created" is a privacy rule scoped to Smith's reserved organization — it's not how the broader product works. Inside Smith, it's part of keeping each user's setup conversation isolated.

Grounded answers, not guesses

When you ask a factual product question — what Guild supports, how a feature works, whether a capability exists — Smith doesn't answer from memory. It's routed to search the public documentation, fetch the relevant page, and answer from what that page establishes, citing the docs URL. Knowing an answer from training isn't treated as evidence; the docs trail is. That keeps Smith's product claims honest and checkable.

Then it gets out of the way

Smith's job ends at a handoff. Once setup is complete, it opens your first real workspace session with a warm-start orientation message and steps aside. From there the workspace assistant and the specialized agents you installed do the actual work — reviewing the PRs, posting to Slack, running the digest. Smith builds the machine; it doesn't run it.

Handing an assistant real context and real work only helps if it behaves predictably. Alongside the approval gating above, Smith has a few built-in limits that keep any single conversation from spinning:

• A turn budget. Smith works through at most 20 model turns per message you send. If a request would run past that, Smith stops, saves its progress, and tells you — rather than quietly retrying forever.
• A duplicate-response stop. If Smith arrives at the same final answer twice, it stops instead of repeating itself.
• An unsupported-integration stop. If you ask Smith to set up credentials for a service it can't match to a supported integration, it does one discovery pass, tells you plainly which service is the blocker, and stops instead of guessing.

The through-line is simple: Smith should always either make progress, ask a real question, or tell you clearly why it can't.

Most people don't want to learn a platform's topology before their first automation. Putting a knowledgeable agent at the front door turns setup into a conversation — and building that agent on the same runtime, behind the same permissions you already have, means it's powerful without being a new attack surface. Smith can reach across the accounts you administer to help you connect a service, and it can't reach anywhere you couldn't already go yourself.

Smith is Guild's bet that an agent platform should greet you with an agent. Open a workspace, say what you're trying to do, and let Smith help you build it. Try it out yourself and get started building today.