how it worksagents-as-folders

Your agent is a folder

A directory on disk: three separated concerns, three owners, one workflow loop that runs through them.

A folder on disk

bash
agents/my-agent/
├── blueprint/        # who the agent is — instructions, skills, channels
├── config/           # how it runs — model, keys, integrations, who's allowed in
├── memory/           # what it has learned, kept across conversations
├── home/             # the agent's working scratch
├── sessions/         # per-conversation transcripts (server-managed)
├── state/            # runtime state (server-managed)
├── service/          # optional cron triggers and custom tools
└── ext/              # extension caches and credentials

That's a real agent. The whole thing. You can cp -r it, git it, zip it, email it to a friend. There's no database row, no cloud account. The folder is the agent.

But the folder is not undifferentiated. It's three separated concerns, each owned by a different actor, each with a different access boundary.

Blueprint: who the agent is

The blueprint is the agent's identity: its instructions, skills, channels, props. This is what a developer composes. It holds no secrets, no personal data, no memory. You can hand it to a friend and they can run their own copy with their own settings.

At runtime, the blueprint is mounted read-only. The agent can read all of it (it has to, to know who it is), but it cannot rewrite a single byte. Not because we ask nicely, but because the harness doesn't mount it writable. The thing that says "you are a careful researcher" is, mechanically, not editable from inside the agent.

bash
blueprint/
├── prompt.md         # who am I, what do I do
├── channels.txt      # cli, web, email, telegram, …
├── skills/           # tools I can call
├── manifest.json     # ACL, channel routing
└── service/          # optional code that runs alongside

Configuration: how the agent runs

The configuration is everything an operator decides about deploying the blueprint: which model, which API keys, which transport tokens, which hosts the network allowlist permits, which humans are allowed in as admins.

These files never reach the agent. Your API keys, your transport tokens, your allowlist. The agent has no path to read them, even if instructed to. The secrets you put here stay where you put them.

That separation is what lets the same blueprint be shared, copied, or version-controlled without leaking anything. You publish the blueprint, and you keep the configuration.

Working files: what the agent does, and remembers

memory/, home/, state/, sessions/. These are the agent's working life. What it jots down, what survives across conversations, what the server keeps for bookkeeping.

The agent can read and write memory/ and home/. That's where self-learning happens. Each session, the agent updates its memory with what it learned about its participants, the work it just did, the conventions emerging. Next session, it reads that memory before responding. It gets better over time, and what it's learned is sitting in a plain markdown file you can open.

state/ and sessions/ are server-managed, opaque even to the agent itself. They exist for replay, recovery, and auditing, not for the agent's own use. Self-learning lives in memory, where you can see it.

Develop · Refine · Run

The same three surfaces map to three phases of work that flow into one another.

This loop is only safe because the surfaces are separated. The agent learns in its own working files, its identity is held still in the blueprint, and the developer can read both and refine without colliding. Self-learning becomes safe (the agent can't rewrite who it is) and inspectable (you can read what it's learned, in plain text).