Fred · Swift platform · Capabilities, for teams & architects

One Switch For Everything An Agent Can Do

A tool. A whole specialist agent. Both are a capability — same catalog, same switch. A whole application — its own UI, its own backend, its own agents — is turned on the same way, but it isn't a bigger capability. It's a different, sibling kind of feature.

Fred · September 2026 · verified against branch swift
Engineering detail: docs/swift/design/CONTROL-PLANE-PRODUCT-CONTRACT.md §17 and the CAPAB-01 team deck

The idea, in one line

A capability is anything an agent can use — turned on with one switch.

A search tool. A document editor. A whole specialist agent, ready to use. It doesn't matter which — granting one to a team is the same click, in the same place.

Every capability has a name, a description, and one switch a platform or team admin controls.
That switch is enforced the same way everywhere — the same permission check, whether it gates a tool or an entire agent.
This deck walks through what's shipped today, why the switch matters, and how it relates to the platform's other admin-activated features — agents, models, and applications.

Shipped today · 1 of 2

Tools your agents can use — one switch each

Document access shipped Semantic search over your team's document library (RAG) — the agent cites what's actually in your files, not what it remembers.

Writable document shipped Co-write a document with the agent in a side-by-side editor, and export it to Word or Markdown when it's ready.

PowerPoint generator shipped Upload your own template — the agent extracts the right values from the conversation and returns a finished deck.

Three very different features. One shape underneath: a capability with a name, a description, and a switch.

Shipped today · 2 of 2 — the new part

Whole agents now live in the same catalog

Specialist agents — Mindmap, Document Comparison, a SQL expert, a general assistant — now show up as entries in the exact same capability catalog as the tools on the previous slide, behind the exact same admin switch.

Fred · Administration › Capabilities

Capability	Team Alpha	Team Beta	Team Gamma
Document accesstoolsearch & cite the document library
PowerPoint generatortoolfill slide decks from a template
Mindmapagentvisualize a transcript or document as a knowledge map
SQL expertagentquery structured/tabular data sources

Same screen, same switch, same permission model — whether the row is a tool or a whole agent.

Why this matters

The switch is the security boundary

Flexibility

Give Finance the PowerPoint generator and Document access, nothing else.
Give the Platform team the SQL expert and Mindmap, not Finance's tools.
Composing a team's agent lineup is a handful of clicks in an admin screen — not a deployment, not a code change.

Security

Nothing is available to a team unless it was explicitly granted — enforced the same way (one permission check) whether it's a tool or a whole agent.
A capability a team was never granted isn't just hidden in the menu — it isn't reachable by that team's agents at all.
One model to audit, one model to reason about — not a different story for tools than for agents.

One lever, two payoffs: teams get exactly the surface they need — and nothing they don't.

Shipped now · a different kind of feature

An application is not a bigger capability

Worked example: "Move to cloud" could be a whole team-owned application — its own UI, its own backend, its own agents if it has any. It's switched on the same way a capability is. It is deliberately not modeled as one.

Capability

Something an agent uses, or a whole agent itself — kind="tool" or kind="agent" in the same catalog.
Lives inside an agent's own turn: a tool call, or the agent's own reasoning.
No container image of its own — it runs inside the platform's existing agent pods.

Application

A complete product: one or two container images, built and deployed on its own release cycle — Fred compiles none of its code.
Rendered in its own sandboxed panel; the app and the host talk only over a closed postMessage protocol.
May contain its own agents internally — but from the platform's point of view, it is one product, not a set of capabilities.

Same admin gesture — one switch, one per-team grant — for two genuinely different things. That's deliberate: an application doesn't reuse the capability id space, because "capability" stays reserved for what an agent uses, never for what a team hosts.

Take away

One admin gesture, several sibling kinds of feature

Capability a tool or a whole specialist agent — Document access, Mindmap, SQL expert — shipped

Application a complete team-owned product — its own UI, backend, agents — shipped (Integrated Applications Framework)

Model which LLM a team or a call is routed to — shipped

Corpus a source of knowledge a team enables, increasingly self-updating — in progress

None of these is a bigger or smaller version of another. What they share is the gesture: a named, described, per-team switch a platform admin controls. What they don't share is a type — a capability is what an agent uses; an application is what a team hosts. Keeping that boundary sharp is what makes each one simple to reason about on its own.

Engineering detail: docs/swift/design/CONTROL-PLANE-PRODUCT-CONTRACT.md §17 and the CAPAB-01 team presentation deck