Skip to main content
An agent is the central resource in Agent Loadout. Each one belongs to your organization and carries everything it needs to act independently: a dedicated email inbox, a credential vault, and optionally one or more Linux machines. You create an agent once, equip it with the resources it needs, and hand a scoped token to whatever AI client will drive it. The client changes; the agent and its history stay.

​
What an agent has

Every agent comes with a set of resources that it owns and accumulates over time.

Inbox

A dedicated email address on loadout.email (or your own domain on Pro). The agent sends and receives mail, tracks conversations, and maintains its own unread state.

Vault

Encrypted storage for logins, API keys, and TOTP secrets. Credentials are scoped to the agent, shared across all agents, or held at the organization level.

Machines

On-demand Ubuntu VMs the agent can create, run commands on, and stop. Machines are feature-flagged and must be enabled in your workspace.

Tokens

One or more scoped access tokens that identify the agent to any MCP client or REST caller. Each token grants only the capabilities you chose at issuance.

​
The Equipment tab

Open any agent in your dashboard to see its Equipment tab. This is the single view of everything the agent currently owns:
  • Inbox address — the email address clients can pass to send_message or display to users
  • Status — whether the agent is active or paused
  • Vault entries — the count of credentials stored under this agent
  • Machines — any VMs currently associated with the agent, with their state and size
The Equipment tab is also where you equip or unequip resources before issuing a token to a new client.

​
Organization ownership

Agents belong to the organization, not to whoever created them. That means:
  • Any organization member with the right role can view, edit, or revoke an agent’s resources.
  • Tokens, inbox history, vault entries, and audit logs all stay in the org when a team member leaves.
  • Billing, limits, and pooled allowances apply at the org level across all agents.
This design makes it safe to hand an agent’s token to a third-party AI client — the client gets exactly the capabilities listed on the token, and the organization retains full ownership of everything the agent touches.

​
Agents in API calls

Every API call is made in the context of whichever agent the token belongs to. The bearer token you pass — either to the MCP server or to the REST API — is how the platform knows which agent is active. You never need to pass an agent ID separately in most calls; it is derived from the token. When you do need to reference an agent by ID (for example, when issuing a new token via the org key API), use the ID shown on the agent’s settings page:
The get_agent MCP tool returns the identity of the agent behind the current token — useful for confirming which agent a client is connected to before it starts acting.

​
Next steps

Tokens & Permissions

Learn how to issue scoped tokens, understand the full capability list, and follow least-privilege best practices.