docsbuild agentsagent folder anatomy

Agent folder anatomy

Everything an agent is — its identity, its memory, how it connects — lives in one directory. Edit it, the agent changes. Copy it, the agent travels.

Every agent on a Cast server is a single directory under ~/.cast/agents/ by default (override with CAST_AGENTS_DIR — see Runtime options). The directory IS the agent — not a manifest pointing elsewhere, not a database row with files alongside. Inside, the subfolders split into four zones by writer and lifetime. That split tells you what's portable, what's local to this install, what the server writes for you, and what the agent writes for itself.

The four zones

BlueprintBlueprint — what the agent IS
Identity, channels, props, optionally a service. The unit of authorship. Copy blueprint/ into a fresh install and the agent behaves the same.
ConfigConfig — how it's wired into this install
The model, the ACL, per-extension credentials. Not portable on purpose — per-install decisions and per-machine secrets.
StateState — what the server records
Conversation log (agent.db), attachments, tasks, identity roster. Server-managed — read when debugging, never hand-edit.
RuntimeRuntime — what the agent and extensions write
memory/ and home/ are the agent's working storage. shared/ and ext/ are extensions' publish-to-agent outputs and private state. All mounted into the container.

Everything else under the folder is process scratch — recreated on each run, safe to ignore.

💡 TIP
Most blueprint and config edits hot-reload — change a file, the next message picks it up. Service code is the exception: restart the service to pick up changes there.

The manifest

manifest.json at the top of the folder holds the agent's identifying metadata. Required: spec (schema version) and name (the agent's alias — the folder name on disk is independent). Optional standard fields: pubkey, description, status: "draft". Additional keys pass through untouched, so generators can stash provenance metadata without coordinating with the server.

manifest.json
{
  "spec": "1.0.0",
  "name": "morning-briefing",
  "description": "Curates morning emails.",
  "pubkey": "0a3f...8e2c"
}

What the container sees

The agent runs inside a container, and the container is a sandbox. The LLM only sees what's mounted in. Everything else on disk — config/, blueprint/service/, the bus, the host filesystem — is invisible from the agent's side.

Inside the containerMounted fromAccess
/identityblueprint/identity/read-only
/assetsblueprint/assets/read-only
/memorymemory/read-write
/home/agenthome/read-write
/sharedshared/ext/read-only
/attachmentsstate/attachments/read-only
/stagingper-conversation staging/read-write
🔒 SECURITY
The mount table IS the security boundary. A secret in config/ext/email/.env is invisible to the agent — only the extension code (running on the host) sees it. A secret in home/ or memory/ is right there in the agent's filesystem, available to any tool the agent invokes. When in doubt about a credential, config/.

The folder map

Not exhaustive — the load-bearing entries, with their zone in the right margin.

agents/my-agent/
├── manifest.jsonalias, pubkey, spec version
├── secrets/
│ └── agent.keyEd25519 private key — never mounted to any container
├── blueprint/
│ ├── identity/
│ │ ├── prompt.mdcore persona
│ │ ├── whoami.mdstructured identity facts
│ │ └── skills.mdtool guidance
│ ├── channels/
│ │ └── <name>/
│ │ ├── channel.jsonidle timeout, lifecycle, log policy
│ │ ├── prompt.mdchannel-specific instructions
│ │ ├── bootstrap.mdrestore working state
│ │ └── cleanup.mdpersist before close
│ ├── props/
│ │ ├── settings.jsonprofile, env overrides
│ │ ├── capabilities.jsondisabled tools, extension config
│ │ └── schedule.txtdeclarative cron messages
│ ├── service/optional: persistent host process
│ └── assets/optional: static reference data
├── config/
│ ├── agent.jsonmodel, network mode, timezone
│ ├── acl.jsonagent + human access grants
│ └── ext/<name>/operator overrides + .env per extension
├── state/
│ ├── conversations.jsonl
│ ├── tasks.json
│ ├── agent.dbmessage log + FTS5
│ ├── attachments/content-addressed blob store
│ └── identity-roster.json
├── memory/agent-writable, mounted
├── home/agent-writable, mounted
├── shared/extension → agent publishing
└── ext/extension private runtime
  • Conversations — what actually runs inside the container, and how the conversation tuple bounds isolation.
  • Channels — the concept behind each blueprint/channels/<name>/ folder.
  • Authoring blueprints — the contents of blueprint/ as authoring surfaces: identity, channels, props, the system prompt that ties them together.
  • Writing services — when blueprint/service/ earns its keep, and the trust model that comes with it.