SRE
Incident triaging
On-call engineer asks "what broke?" Bolt routes to the SRE team's
triaging agent. It correlates alerts, recent deploys, and runbook
guidance, then proposes next steps.
Documentation · Mode 2 · Rolling out
Agents.
Bolt is an extensible, governed agentic platform, and most queries never touch a model. When the question has a known shape, Bolt answers it deterministically, on-device, with no LLM in the loop. When reasoning is needed, Bolt is the superagent your users talk to: it handles tasks on its own when it can, and delegates to specialized agents your teams ship when they're a better fit. Local, Remote, or System: Bolt discovers them, routes to them, and composes them as subagents.
The architecture
Bolt at the top. Subagents below.
Your SRE team ships an incident-triaging agent. The Bolt admin enables it for engineering. Now any engineer asking about an incident is routed to that agent automatically. Multiply by every team, every persona, every domain. One interface, every team's expertise one routed query away.
UX Design
Design review
A PM asks "is this flow accessible?" Bolt routes to the design
team's review agent. It runs heuristics, references your system,
and flags issues against your design guidelines.
Data
Data quality checks
An analyst asks "is this dashboard right?" Bolt routes to the data
team's quality agent. It traces lineage, validates row counts, and
highlights drift since the last verified snapshot.
Security
Threat hunting
A SOC analyst asks "is this alert real?" Bolt routes to the
security team's threat-hunt agent. It pulls related telemetry,
checks IOCs, and recommends an action.
Legal
Contract review
A salesperson asks "can we accept these terms?" Bolt routes to
legal's contract agent. It compares against your playbook, flags
deviations, and suggests fallbacks.
Finance
Expense and policy
An employee asks "can I expense this?" Bolt routes to finance's
policy agent. It checks your written policy, your manager's
approval limits, and the team's budget state.
The user does not need to know which agent handled their query. They talk to Bolt. Bolt decides.
Bolt is the top-level agent the user interacts with. It can answer directly when the question is in its lane: pick the right App, hit Retrieval, call the LLM with your tools. When a specialized agent is a better fit, Bolt delegates and treats it as a subagent. Identity, ACLs, and the audit chain follow the call through the chain.
Most agent platforms ask you to migrate every agent your teams write into their runtime. Bolt does the opposite. Build agents wherever makes sense for your team. Publish them, or wrap services you already run, or define them in the Bolt admin. Bolt becomes the supervisor: it discovers the agents, routes user queries to the right one, composes calls when a single agent isn't enough, and records the whole chain.
The runtime
A durable conductor, not a fire-and-forget call.
Bolt runs durable background agents over a bearer-authenticated API. Submit a run, then stream it, steer it, snapshot it, or cancel it while it works. Runs survive process restarts and pick up exactly where they left off.
Submit, stream, steer, cancel
Post a run to
/v1/agent/runs and watch it live. Stream
tokens as they arrive, send steering input mid-run, snapshot the
current state, or cancel. The run is a first-class object you control,
not a request you fire and forget.
Suspend and resume, durably
A run can suspend on a timer, an inbound webhook, a peer message, or a
long-running subprocess, then resume exactly where it left off. Runs
survive process restarts, so work in flight is never lost.
A verifiable A2A peer
Bolt speaks the A2A protocol as a peer other systems can trust. It
publishes a signed agent card backed by a JWKS endpoint, so peers
authenticate it cryptographically before they route work to it.
Sandboxed subprocess execution
When an agent shells out, it runs inside an allowlist-gated sandbox.
Agents never run arbitrary code: only the commands you've allowed,
inside the boundary you've drawn.
Three flavors
Local, Remote, System.
Bolt does not force one way of building agents. Define one in-app, sync a directory your team publishes to, point at an existing service, or enable a bundled one. All four paths produce an Agent that Bolt can route to.
Flavor 1
Local agents
Define an agent in the Bolt admin, or sync a directory your team
publishes to (~/.bolt by default). Each agent gets a
name, description, system prompt, trigger keywords, max iterations,
and scope (Personal or Organization). Bolt runs the agent loop
with your model. Your tokens, your bill.
Best when your engineering or ops team is shipping specialized internal agents and wants them auto-discovered.
Flavor 2
Remote agents
Already have an agent service? LangChain, an OpenAI Assistant, a Slack bot, an internal agent platform, a vendor product. Point Bolt at it as a Remote agent. Bolt becomes the launcher, identity, ACL, and audit layer. Your existing service does the reasoning. Zero migration.
Best when you have AI investments you don't want to rewrite.
Flavor 3
System agents
Three bundled agents ship with Bolt today: Meeting Prep (structured briefings for upcoming meetings), Email Drafter (responses by analyzing thread context and tone), and Research Assistant (deep research across web and enterprise knowledge).
Best when you want value on day one without authoring anything.
Routing
How Bolt picks the right agent.
Build as many specialized agents as your teams want. Bolt routes user queries to the right one automatically. Authors declare what their agent is for; the router does the matching.
Trigger keywords
Each agent declares a comma-separated list of keywords. When a user
types or @mentions one of them, Bolt routes the query to that agent.
Simple, predictable, deterministic.
Skills
Agents declare the skills they expose (a domain, a verb, a capability).
Bolt matches user intent against the skill registry and picks the
best-fit agent for the task.
Scope
Personal agents are visible only to their author. Organization
agents show up for everyone (or for ACL-matched personas). Your IdP
groups decide who sees what.
Explicit invocation
The user can always override. Slash commands, chip selection, and
direct mentions skip the router and target a specific agent.
Discovery and composition
Publish once. Compose freely.
Bolt is built so that engineering teams ship agents the same way they ship code: a manifest in a directory, a sync, a working agent. Once an agent is registered, other agents can call it as a subagent.
Publish from your repo
Drop an agent manifest into the Bolt sync directory and the next
sync picks it up. Versioning lives in your repo. Org-wide
distribution is one push.
Discovery is automatic
Local agents are visible to the user (and the router) as soon as
they're synced. Remote agents register once and stay reachable.
System agents ship enabled.
Subagents and composition
An agent can call another agent as a tool. A coordinator can fan
out to specialists. A specialist can defer to a higher-context
agent. Identity, ACLs, and the audit chain follow the chain.
System events as triggers
Agents fire on user queries and on system events: new email,
calendar invite, alert, webhook, watch result. The same agent,
two front doors.
Architectural commitments
What holds across every agent.
Whichever flavor, whichever team built it, whichever model it uses, the platform guarantees are constant.
Bring your own model
OpenAI, Anthropic, Google, local Ollama, on-prem open-weight. The
LLM is at the boundary, not at the core. Bolt does not host or
fine-tune your model. Remote agents may use their own model
entirely. Bolt does not constrain you.
Tools come from the same place as Apps
Local agent tools are the same MCP and HTTP calls Apps use. One
manifest format, two execution modes. An Agent can call any tool
any App could call, gated by the same ACLs. Remote agents reach
their own tools, but identity carries through.
PII masks at the LLM boundary
For local agents, tools see real values; the model sees redacted
ones. The masking contract is enforced before the prompt is built
and verified after the response comes back. For remote agents, the
same contract is honored at the wire.
Audit chain captures every step
Every routing decision, every reasoning turn, every tool selection,
every tool call, every subagent invocation. The same chain Apps
and Retrieval use. Remote and subagent calls are recorded with the
requesting user's identity through the full chain.
Supervision sees status, never content
Operator oversight exposes operational metadata only (a run's status
and what it's waiting on), never the prompt, title, result, or
conversation content. It's off by default, scoped to your org, and
every access is itself audited.
Decision rule
When to reach for an Agent.
Use an Agent when the question doesn't have a known shape. If you could write the query as a fixed flow ("get my Jira tickets, then join against Linear, then summarize"), it's an App. If the question is "what should our team prioritize this sprint and why," it's an Agent.
Agents cost tokens. That's not a bug. It's the budget knob you control: the customer decides which queries deserve a model and which don't. On most agent platforms every query goes through an LLM, whether reasoning is needed or not. On Bolt you opt in.
The platform wedge is composition. Most agent products want to be the one agent your team uses. Bolt assumes you'll have many, each specialized for a domain, and provides the substrate that lets them be discovered, routed to, and composed.
Get started
Build many. Route smart. Compose freely.
Open the Bolt admin under Core Setup, Agents to define a Local agent, point at a Remote one, sync from a directory your team publishes to, or enable a System agent. Anything you author once becomes a tool any other agent can call.