---
title: "Habitats"
description: "An agent is a git repo — config, skills, and memory, versioned."
order: 36
duration: "10 min"
chapter: "09-running-agents-in-production"
type: lesson
---

## The system changes how the org works

The fourth transition goes beyond automation. The system does not just do work — it observes how work gets done, identifies patterns, and proposes changes.

Cornwall Market: the bookkeeping agent has been categorizing transactions for three months. It notices that a particular vendor's pricing has increased 15% over that period — something that was invisible when Sarah processed invoices one at a time. The system surfaces this: "Pacific Foods unit prices have increased 15% since January. Three items — olive oil, canned tomatoes, and paper towels — account for most of the increase. Consider requesting updated pricing or evaluating alternative suppliers."

Sarah confirms this is worth investigating. She calls Pacific Foods, renegotiates the paper towel pricing, and tells the agent: "Flag Pacific Foods for quarterly price monitoring going forward."

That correction feeds back into the system's knowledge. The agent updates its own rules. Next quarter, it will proactively check Pacific Foods pricing trends without being asked.

This is not automation. This is organizational adaptation. The system proposes. Humans decide. Corrections feed back in. The organization and the system co-evolve.

## A persistent home for your agent

A habitat is a persistent agent container. The architectural insight: **an agent is a git repo.** Not metaphorically. The repo literally IS the agent. It contains the configuration, tools, skills, memory, and credentials the agent needs to operate. Git gives you everything else for free — version history, rollback, audit trails. When the agent modifies its own skills, the diff shows exactly what changed.

You do not deploy agents. You deploy repos.

Create a `config.json`:

```json
{
  "name": "bookkeeping-agent",
  "model": "claude-sonnet-5",
  "agents": [
    {
      "name": "categorizer",
      "description": "Categorizes transactions using Cornwall Market rules",
      "tools": ["quickbooks-query", "file-read", "file-write"]
    }
  ],
  "skills": ["categorization"],
  "tools": [
    "quickbooks-query",
    "telegram-send",
    "file-ops",
    "web-search",
    "self-modify"
  ],
  "memory": ["context.md", "decisions.md"],
  "stimulus": {
    "channels": ["telegram"],
    "schedule": "0 8 * * 1"
  }
}
```

The key fields:

| Field | What It Does |
|-------|-------------|
| **name** | Agent identity — persists across sessions |
| **model** | Which model powers the agent |
| **agents** | Sub-agents for specialized tasks — each with their own tool subset |
| **skills** | Markdown instructions the agent loads at startup |
| **tools** | Available tool set — including `self-modify` |
| **memory** | Files the agent reads and writes across sessions — persistent context |
| **stimulus** | What triggers the agent — channels and schedules |

The `self-modify` tool is what completes the distillation pipeline. Remember the progression from Chapter 01: conversation → Project / CLAUDE.md → SKILL.md → MCP server. Now add the final step: the agent updates its own skills based on corrections.

The full pipeline is now: **conversation → Project / CLAUDE.md → SKILL.md → MCP server → self-modifying agent**. Knowledge starts as something you say, gets captured as notes, gets formalized as a skill, gets exposed as a tool, and finally becomes part of a system that improves itself. Every step increases the formality, the automation, and the reliability. The agent does not just use its instructions — it refines them.

<div class="exercise">
  <div class="callout-label">Try This</div>
  <p>Create a <code>config.json</code> for a habitat relevant to your work. Think about what skills it needs, what tools it should have access to, what memory files it should maintain, and what should trigger it. You do not need to configure every field — start with name, model, skills, and tools. Add channels and schedules when you are ready.</p>
</div>

## Check your understanding

Answer in your own words — write it down before opening the key. Your tutor grades against the criteria and generates fresh variants on retries.

**Q1.** "An agent is a git repo." Unpack what that buys you operationally — and why the self-modify capability should never be enabled without it.

<details>
<summary>Answer key — attempt every question first</summary>

## Answer key

### Q1

**Model answer:** The repo IS the agent: config, skills, memory, and tools versioned together. Git gives you history, rollback, audit trails, and diffs for free — you deploy repos, not mysteries. Self-modify means the agent edits its own instructions; without version control those edits are invisible and irreversible — with it, every self-modification is a reviewable diff.

**Pass criteria:** repo-as-agent with at least two git dividends; self-modify justified by diff/rollback auditability

</details>


**Next:** [Corrections That Stick](/mastering-claude/09-running-agents-in-production/37-corrections-that-stick/)