Agents
One Silo agents
Who this is for
These pages are reference documentation for three audiences: teams deploying custom agents inside their organization, people self-hosting a Buzz-style agent on their own hardware, and partners we work with directly. One Silo is not a self-serve agent platform — if you want to build a commercial product on this surface, talk to us.
The model — five nouns
Connection
Every agent rides on its own connection — the same governed identity every MCP client gets. Rate limits, quotas, the security pipeline, and audit apply to agent tool calls exactly as they do to a human-driven app.
Memory grants
Silos attach to the agent per-silo, read-only or read-write, managed by the owner in the dashboard. The agent never grants itself anything.
Service grants
Connected services (Notion, GitHub, Google, …) are granted tool-by-tool to the agent's connection, so an agent can act on your systems only where the owner said so.
Model policy
Each agent pins its compute: a cloud model from the catalog (subject to org allowlists) or the owner's own self-hosted node. The contract is invariant; placement is policy.
Transports
Slack, synchronous invoke, and webhooks drive the same runtime with the same gates. A transport is an entry point, never a bypass.
Governance is the point
Everything an agent does is attributable and bounded:
- Permissions — silo and service access are explicit grants the owner manages in the dashboard, revocable at any time. Nothing is implied by pairing.
- Audit — every tool call an agent makes lands in the same audit log as every other connection, per call, per tool, per silo.
- Org policy — org admins can disable agents for members, constrain which models agents may use, and approve, establish, or suspend member agents from the enterprise dashboard. Policy is enforced at configuration time and again at answer time.
- Metering— agent turns count against the owner's plan as interactions per model class, the same budget the rest of Silo uses. Tokens are recorded for bookkeeping, never as the gate. Agents running on your own node don't consume cloud interactions.
- Confirmation— memory-replacing writes require owner confirmation in the dashboard. An agent can surface that state; it can never approve on the owner's behalf.
Transports
An agent answers wherever its owner wired it, and every path runs the same governed turn — org policy first, then the plan gate, then the tool loop, then usage recording:
- Slack — install the agent into a workspace from the dashboard; mentions and DMs become agent turns.
- Invoke — a synchronous API call by the owner:
POST /api/v1/agents/{id}/invoke. - Webhook — a revocable trigger token external systems can call without owner credentials:
POST /api/v1/agents/hooks/{token}.
Where to go next
- Pairing & credentials — connect a self-hosted agent (OAuth 2.1 + DCR) or mint a non-interactive key for a server-deployed one.
- Memory & compute — the MemoryStore contract, write semantics, and the OpenAI-compatible compute endpoint.
- MCP quickstart — the tool surface agents (and every other client) speak.