Skip to main content
Smith is Guild’s built-in support agent. It replaces the legacy dashboard as the default landing experience when you open a workspace, putting chat front and center so you can start working immediately.

​
What Smith does

Smith is always available in every workspace. You can ask it to:
  • Answer questions about Guild features, agents, and configuration
  • Help you build, debug, and publish agents
  • Walk you through setting up integrations and triggers
  • Troubleshoot errors in your sessions or agent code

​
Starting a conversation

When you open a workspace, Smith’s chat interface is the first thing you see. Type a message and press Enter to begin. You can also open Smith at any time from the left sidebar by clicking the Smith icon (the chat bubble at the top of the nav).

​
Switching agents

Smith is the default agent, but it is not the only one. Use @mention to route a message to a different agent without leaving the chat interface. See Agent mentions.

​
Workspace context

Smith has read access to your workspace configuration — installed agents, triggers, integrations, and recent sessions — so it can give context-aware answers without you having to copy-paste configuration details.

​
Software Factory commissioning

Smith can commission a Software Factory for you, so you do not have to wire up its repository, runtimes, labels, agents, contexts, and triggers by hand. When you ask Smith to build a Software Factory, it runs the blueprint_software_factory skill, which drives the setup end to end and stores every configuration value as a workspace variable. Storing configuration this way lets the same blueprint run in any workspace.

​
Workspace variable contract

Smith reads and writes thirteen workspace variables that hold the Factory’s configuration instead of pinning values in agent code. These variables cover four areas:
  • Repository — the repository the Factory operates on, such as FACTORY_REPOSITORY.
  • Coding runtime — the runtime the Factory uses to make code changes, such as FACTORY_RUNTIME_ENVIRONMENT.
  • Read-only runtime — the runtime the Factory uses for read-only inspection.
  • Control labels — the labels that coordinate Factory work, such as FACTORY_LABEL_AUTO.
Because the configuration lives in workspace variables, you can reuse the same Factory blueprint in another workspace by setting that workspace’s variables. See Workspace variables.

​
Two-phase commissioning

Smith commissions a Factory in two phases:
  1. Bootstrap Proposal — Smith proposes the Factory setup, including the runtime environment and setup script, and presents it for your approval.
  2. Create, Verify, Configure, and Assemble — after approval, Smith creates the runtime, verifies it, configures the workspace variables and labels, and assembles the Factory agents, contexts, and triggers.
Smith uses the public guildai~github-repository-manager@1.0.0 agent to set up and operate repository labels.
Labels, variables, Factory agents, contexts, and triggers stay unreachable until runtime environment verification passes. Env Verify must report a structured pass and confirm container cleanup before Smith commissions any Factory component.

​
Bounded runtime repair loop

If the setup script fails, Smith runs a bounded runtime repair loop instead of stopping. Smith coordinates with Bootstrap to propose a replacement script, presents it to you, and waits for your explicit approval before it modifies the runtime environment. The loop runs at most two repair rounds. If the runtime still does not verify after the second repair, Smith stops rather than retrying indefinitely.

​
Safety limits

Smith includes internal protections that stop a single conversation from looping or running up cost:
  • Unsupported integration stop. When you ask Smith to set up credentials for a service it cannot resolve to a supported integration, it stops after one discovery pass, names the unsupported service as the blocker, and does not retry.
These limits apply on top of the platform-wide execution limits.