Introduction

Agentfleet is a platform for composing AI agents into auditable, identity-aware workflows. You define what should happen (steps bound to real tools), who does it (an agent with its own registered identity), and Agentfleet handles the execution: model calls, tool calls, token exchange, retries, and observability. The same agents can also hold conversations with people, through assistant profiles.

Why Agentfleet?

Most agent frameworks give an LLM a bag of tools and a long-lived API key. That works for demos and fails audits. Agentfleet takes a different position:

• Every step runs under a delegated identity. Before a step calls a resource, Agentfleet exchanges the initiating user's token for a short-lived agent token scoped to exactly that resource and the step's tool scopes (RFC 8693 token exchange). The issued token records both the user (sub) and the agent (act.sub), so downstream systems always know who asked and who acted.
• Tools are real, discovered, and scoped. Tools come from MCP servers you register as resources. Each tool carries an OAuth scope, and the exchange requests only those scopes — least privilege by construction. Risky tools can require a person's confirmation before they run.
• Every request is authorized. A policy decision point decides each API call, permission by permission, and keeps every tenant to its own data.
• Changes are versioned and evidenced. Workflows are published as immutable versions, runs are pinned to the version they started on, and eval suites gate the move to automatic changes.
• Everything is observable. Runs record every model call (tokens, latency, cost), every tool call, and a cross-step context channel with provenance (was this value a tool output, model text, or caller input?).

The building blocks

Concept	What it is
Agent	An AI worker with its own identity registered in your identity provider.
Resource	An MCP server (an API surface) the platform can call.
Tool	A callable operation imported from a resource, with an OAuth scope.
Step	A reusable unit of work: an instruction plus an allowlist of tools — or a deterministic transform, or a sub-workflow.
Workflow	Steps in order, with an editable draft and published versions.
Workflow design	Conditions, for-each loops, parallel groups, waits and sub-workflows.
Workflow package	A workflow and what it depends on, exported from one environment and imported into another.
Run	One execution of a workflow version by an agent, with inputs and full telemetry.
Schedule / Trigger	Fire a workflow automatically — on a cron cadence, an inbound event, or a webhook.
Eval suite	A scored, repeatable test suite over a workflow, with experiments to compare models and prompts.
Assistant profile & chat	What an assistant chats with, and the conversation threads people hold with it — in the console or a portal widget.
Model provider	The LLM configuration (provider, models, pricing, lifecycle) agents use.
Usage & data governance	Budgets and limits on model spend, chat retention, and which data each model may receive.

How a run works

1. You queue a run: pick a workflow (its latest published version by default), pick an agent (or use the workflow's default agent), and supply inputs.
2. When a step first calls a resource, Agentfleet exchanges a token — your identity delegated to the agent, restricted to that resource and the step's tool scopes.
3. The agent's model reasons over the step instruction and the accumulated run context, and calls the step's tools with the delegated token. A tool that requires confirmation pauses the run until a person decides.
4. Outputs are promoted into the run context (toolResult_1, modelResponse_1, …) so later steps can use them.
5. The run completes (or fails, with the reason recorded), and every call is available in the run view.

Ready? Head to Getting Started.