Skip to main content

Building an agent from parts

A new agent is not written from scratch. It is one or two work shapes, plus a shelf of shared parts every agent already has, tied together by a contract the owner agrees to in a short interview.

Example screen with made-up data.

Where you see it​

The owner sees a conversation, then a new agent on the Office with a face, a goal, a number, and a plan already approved. Behind it is a folder in the vault (the folder of plain text files that holds everything) named after the agent. Its agent.md is the contract. The owner can edit it directly.

What happens, step by step​

Say the bakery owner says: "I want something that keeps my workshops full."

  1. First, the four-kinds test. Is this started by a clock, an event, a person asking, or the agent's own judgment? Only the last one becomes an agent. A fixed list of steps becomes a cheaper routine instead.
  2. Research first. Before any contract, Claude looks up how others do this job and writes what is worth taking and what to avoid.
  3. Name the shapes. One or two, with a share of time. Here: Filler, mostly, with some Chaser.
  4. The interview. The questions are rows in the logbook, asked one at a time: the result, the number, what it may never do, its tools and people, how often it wakes, how the job splits, and who does each step. Then any extra questions the shapes add.
  5. Write the folder. agent.md (the contract), memory.md (what it learns), scoreboard.md (its number over time), craft.md (what makes a good one), a face, and colors for the office picture.
  6. Set the first wake before anything else. This stops the agent from waking up before its plan exists.
  7. Fill the plan. The shapes' starter steps and numbers go in through the plan door, named in the owner's words, each with its who-does label.
  8. Sign. The owner signs the contract, and that one act approves every starter step. A budget, if any, is typed on the Office's Settings tab.

The shared parts​

These are built once and every agent gets them. The agent does not have to know how they work.

PartWhat it does for every agent
The wake wallThe agent cannot do anything until it has read its checklist: contract, plan, memory, recent history, inbox, and what is new on the forum.
The room wallThe same wall when the owner opens a chat with the agent.
Decision captureA decision made in a chat is written to the plan, the inbox, or memory the moment it lands.
Email intakeThe agent never reads a raw email. A tool-less model fills a form about it, and the agent gets the form.
The deleted folderThe agent never truly deletes. It moves things aside with a reason.
The send guardEvery message to a real person goes through one checked door.
The Office rowEvery agent shows up on the page the same way, with no extra work.

What powers it​

PartWhat it does
add-resident-agent skillThe step-by-step setup Claude follows.
logbook.py interview showReads the interview questions, which are editable rows.
Resources/Agents/archetypes/The 17 shapes: starter plans, numbers, guardrails, wake rhythms.
Resources/Agents/modules/The shared parts, each with a plain page and a builder's page.
logbook.py planWhere the starter steps and numbers are written, and where the plan is approved.

Why it works this way​

Why the first wake is set first. One new agent was copied onto the box and woke up seven seconds later. It had no checklist and no steps yet. It spent 25 turns and $2.24 before anyone noticed. It did no harm, but the order changed: set the wake time first, then build the rest.

Why the interview is short. One pass through the questions, then stop. A long, open chat produces a vague contract, not a better one.

Why one signature. The owner read the steps in the interview and signed a contract that describes them. Asking the same yes again for each step was the wrong shape. Only steps the agent adds later need a new stamp.

Why parts, not code. A new kind of job should be set up, never coded. If a new agent needed new engine code, the design would be wrong.

Connected to​