One-person ops stack.

You have no team. Your agent fleet is your team.

Most modules in this publication assume team context: review cycles, pattern libraries, governance. As a solo operator, half of that doesn't apply and the other half applies differently. This module is specifically for you.

Today we map your actual workflow. Identify the three-to-five agents that would give you the most leverage. Build the first one.

By the end of 90 minutes:

• A map of your operations with each task tagged for automation potential.
• A prioritized list of three to five agents to build.
• The first utility agent shipped: a task you hate, automated.
• A folder structure for your personal fleet that compounds over time.

Solo operators consistently over-plan and under-build. The instinct is to design the perfect agent system first. Don't. Build one agent. Use it for a week. Build the second.

Prereq: Module 010. The background-agent pattern is what unlocks solo leverage.

Thinker on your fleet as your team.

Every solo operator does four kinds of work. Map them, and your agent fleet designs itself.

The four quadrants

The Q2 sweet spot

Agents belong in Q2. Work that matters and is happening but doesn't need you personally.

Examples for most solo operators:

• Monthly metrics report (data to narrative).
• Customer email triage (classify, draft replies for routine).
• Daily log summarization (what did I do today).
• Meeting notes to action items.
• Newsletter drafting from a content brief.
• Lead classification (which inbound emails are actually qualified).

All of these: routine, rules-based enough to prompt, low-stakes per run. Each one could save 2-5 hours a week.

The three-to-five fleet

Most solo operators max out at three to five agents in regular use. Beyond that, you hit maintenance overhead and the marginal returns drop.

The optimal fleet for most:

1. A daily summarizer (Module 010 pattern).
2. An inbox triage agent (Module 008 pattern).
3. A weekly metrics report (Module 009 pattern).
4. A content drafter for whatever content you produce regularly (Module 012 patterns).
5. One wild-card for whatever niche task eats your time.

You don't need all five on day one. You need one that works. Add the second a month later. By month six, you're at three or four and you're getting real leverage.

The non-fleet: tasks that look like agent work but aren't

Some things feel like good agent candidates but usually aren't worth the build for a solo operator:

• One-off tasks. If you'll do it three times total, just do it.
• Highly variable tasks. Each instance is different. No pattern for the agent to follow.
• High-stakes tasks. Customer contracts, financial decisions. Review overhead eats the savings.
• Tasks that require systems access you don't have. Building the integration is more work than doing the task manually.

Ask before building each agent: will I use this 50 times in the next year? If not, skip it.

The compounding asset

Your agent fleet is infrastructure that compounds. Each agent you build and tune makes the next one easier to build. The patterns become familiar. The harness is shared. The memory system is in place.

Year one: three agents, modest leverage.
Year two: five agents, significant leverage.
Year three: maybe seven, at which point your operations look radically different from year one.

This is only true if you build. It's not true if you plan.

Talker on writing agents that fit your specific workflow.

Solo agents should sound like you. Not like a tutorial. Not like a generic assistant.

The "you, specifically" rule

Most agent prompts are written for hypothetical users. Yours should be written for you, specifically. Your context, your vocabulary, your quirks.

Example, generic daily summarizer:

You are a daily summarizer. Read the log file and produce three
bullets.

Example, same agent for a specific solo operator:

You are Aycee's daily summarizer. Aycee writes dev logs in
/tmp/dev-log.txt throughout the day. You read that file and
produce a three-bullet summary in a bias-to-action tone (she
hates fluff). Focus on shipped work over meetings.

The specific version produces better output because it has specific context. Your name. Your style preferences. Your hates.

The voice sample

For any agent that produces text you'd use or send, include a voice sample in the prompt.

My writing style:
- Short declarative sentences.
- Specific numbers over adjectives.
- I don't hedge ("I think maybe...").
- Technical terms used correctly, not for flourish.
- Active voice.

Example of my recent writing:
"The deploy pushed Friday. It broke auth for ~4% of users for
90 minutes. Fixed with a config flag. Real cause: a race in
session validation, being addressed in next sprint."

One example + stylistic notes. The agent pattern-matches. Output sounds more like you.

The "what to skip" rule

Most agents generate too much. Solo operators don't have time to read. Tell the agent explicitly what to skip.

Do not include:
- Background context I already know.
- Caveats or disclaimers.
- "It is worth noting that..." or similar.
- Summary paragraphs before the actual content.
- Meta-commentary on the task.

Go straight to the substance.

This negative specification saves thousands of tokens across a year. Solo operators need terse output far more than teams need it.

The personal shortcut

Put your workflow-specific shortcuts in the prompt:

Terminology:
- "ship day" = the day I release to production
- "ops block" = my Monday operations time block
- "the list" = my weekly priority list in Notion

Now when your notes mention "ship day" or "the list," the agent knows what you mean. No explanation needed. Your language; your agent.

A full solo agent prompt

# Identity
You are Aycee's daily summarizer.

# Capability
You read /tmp/dev-log.txt and produce a three-bullet summary of
the day's activity.

# Voice
Short declarative sentences. No hedging. Specific over vague.
Active voice. No preamble.

# Rules
- Focus on shipped work over meetings.
- Lead with the biggest thing shipped, if anything.
- If nothing shipped, lead with biggest decision or blocker.
- Never caveat. Never disclaim.

# Format
Day ({date}):
- [most important thing]
- [second most important]
- [third most important]

# Escape hatch
If /tmp/dev-log.txt is empty, reply:
Day ({date}): (no log entries)

Six sections. Every one tailored to a specific operator. Another operator would rewrite half of it. That's the point. Your agent, your voice, your workflow.

My writing style:
- [trait 1]
- [trait 2]
- [trait 3]
- [what I avoid]

Example of my recent writing:
[paste 2-3 sentences you wrote this week]

Rememberer on shared memory across your personal agents.

Your agents should share a common memory. No agent starts from zero.

The shared context file

One file, one place. Call it ~/.bot/me.md:

# Me

## Who I am
Aycee, solo founder of Example Co. SaaS analytics tool.

## What I'm working on
- Core product: dashboard at example.com
- New feature: integration with Provider X (launch May)

## My communication style
[voice sample from Talker]

## My vocabulary
- "ship day" = release day
- "ops block" = Monday operations time
- [other terms]

## My tools
- Notion (notes, priorities)
- Stripe (billing data)
- PostHog (analytics)

## My don'ts
- Don't start emails with "I hope this finds you well"
- Don't use the em-dash (long one)
- Don't include "Let me know if you have any questions"

This file is the common context for every agent you build. Each agent's prompt includes a reference: "Read ~/.bot/me.md for context about the operator. Apply that context to every output."

The shared agents folder

~/.bot/
  me.md                  (shared context)
  agents/
    daily-summarizer.md
    inbox-triage.md
    weekly-report.md
    ...
  outputs/
    daily-summary/
    inbox-triage/
    weekly-report/
  logs/
    runs.jsonl

Every agent lives in the same place. Outputs go to parallel folders. Logs aggregate. Adding a new agent is a one-step process, not a greenfield setup.

The meta-memory

Keep a file of "things I learned while building agents":

~/.bot/notes.md

## 2026-04-10
Discovered that the summarizer prompt is much better if I tell
it to focus on "what I shipped" rather than "what I worked on."

## 2026-04-15
Added voice sample to all agents. Output noticeably less generic.

## 2026-04-22
Inbox triage: agent kept classifying angry-but-not-cancelling as
"cancellation." Added rule: "only classify as cancellation if the
email explicitly says cancel, quit, or downgrade."

These notes become a lessons-learned file. When you build the fourth agent, you draw on patterns from the first three. The compound effect is what turns solo agent development from hobby to leverage.

What NOT to share

Keep these separate per agent:

• Per-task configuration. The specific file paths, data schemas, output formats for each agent.
• Per-agent tuning history. "I tightened this rule on 2026-04-10" belongs in the agent file itself.
• Task-specific memory. The last 5 briefings from the daily-briefing agent shouldn't bleed into the triage agent's context.

Shared memory is for who-you-are state. Task-specific memory stays task-specific.

The backup discipline

Your ~/.bot/ folder is valuable. Lose it and you lose the compounding work.

Two backups:

• Git repo (even a private one). Push after every meaningful change.
• Cloud backup (iCloud, Dropbox, whatever you use for other files).

Both are free. Both take minutes to set up. Without them, you're one laptop disaster away from starting over.

Doer.

Build your first utility agent. The rule: pick a task you personally hate.

mkdir -p ~/.bot/agents ~/.bot/outputs ~/.bot/logs
# Create the shared context file
cat > ~/.bot/me.md << 'EOF'
# Me
[Your name, role, context]

## My voice
[3-5 traits]

## My don'ts
[Things to avoid]
EOF

---
name: [task-name]
description: [What it does, when to use it. Specific to your workflow.]
tools: Read
---

You are [Your Name]'s [task-specific] agent.

Context: Read ~/.bot/me.md for who this operator is and how they communicate.

Task: [Exact task]

Rules:
- [Rule 1, using your vocabulary]
- [Rule 2]
- [Rule 3]
- Apply the voice from me.md to every output.
- No preamble. No disclaimers. Substance only.

Format:
[Exact shape of the output]

Escape hatch:
[What to do if the input isn't what you expected]

What you built

Your first fleet-ready agent. Lives in your shared folder. Uses your shared context. Outputs match your voice.

This is the foundation. Every future agent you build slots in next to this one. The shared context evolves. The fleet grows. By month three, you have three agents that all feel like extensions of you, because they literally read the same context file.

Rookie on the three ways solo fleets go wrong.

Three ways solo operator fleets go wrong.

Failure 1. Agent sprawl

You get excited. You build an agent for every task. By month three, you have twelve agents. By month six, you can't remember what half of them do and you've stopped using most.

Root cause: built agents for possibility, not necessity.

Fix: three-to-five agents is the right number for most solo operators. Cap yourself. If you want to build a sixth, first kill one that you haven't used in 30 days. This constraint forces prioritization.

Failure 2. No interfaces between agents

Your daily-summarizer produces output. Your weekly-reporter could use that output. But you haven't connected them, so you manually copy-paste. You have agents; you don't have a system.

Root cause: each agent was built in isolation.

Fix: standard output locations. The daily summary writes to ~/.bot/outputs/daily-summary/YYYY-MM-DD.md. The weekly reporter reads from that folder. Agents don't talk to each other directly; they leave files for each other. Simple. Works.

Failure 3. Accumulating cruft

Your prompts grow. Every time something goes wrong, you add a rule. After six months, your daily-summarizer prompt is 80 lines long. Most of those lines exist because of something that happened once and won't happen again.

Root cause: growth by accretion without pruning.

Fix: quarterly prune. Every three months, go through each agent's prompt. For each rule, ask: "when did I add this? Has the problem happened again since?" Rules that prevented a one-time failure usually aren't earning their place.

The solo operator's discipline

Three habits that keep the fleet healthy:

• Weekly use. If you don't use an agent for a week, understand why. Maybe the task disappeared. Maybe the agent isn't good enough. Either way, take action.
• Monthly tune. Thirty minutes per agent. Read recent outputs. Tune the prompt. Prune dead rules.
• Quarterly audit. Which agents are still earning their place? Retire the ones that aren't.

Three habits. Together, they're the difference between a fleet that compounds and a fleet that decays.

Manager, lightly modified for solo context.

Team discipline doesn't quite apply to you. But some of it does, adapted.

You are owner, reviewer, and support

A team has a prompt author, a reviewer, and a support rotation. You're all three. That's fine, but it means:

• You can't just trust your own prompts because you wrote them. The bias makes self-review weak.
• You have no colleague to page when something breaks.
• The fleet's reliability depends entirely on you not getting sick, traveling, or switching contexts.

Two mitigations:

• Every agent has a one-page runbook in ~/.bot/runbooks/. What it does, how to stop it, what to check when it breaks. For future-you, who won't remember.
• Build a "travel mode" toggle: one script that pauses all non-essential agents. You flip it before vacation. Flip back when you're home. Reduces the chance of coming back to a costly pileup.

Your own code review

When you change an agent's prompt, commit with a message that explains why. Even though only you'll ever read it. Even though nobody's reviewing.

git commit -m "summarizer: cut verbose-opening rule. It made outputs too formal."

Six months from now, you'll be looking at this agent wondering why a particular rule exists or why it was removed. The commit history is your own future reference. Spend 10 seconds on the message.

The one-page runbook pattern

For every agent, one markdown file with:

# [Agent name]

## What it does
One paragraph.

## How to run it
The exact command.

## How to stop it
The exact command.

## Where the inputs come from
File paths or systems.

## Where outputs go
File paths.

## Common issues
- [Issue]: [fix]
- [Issue]: [fix]

## Last audit
YYYY-MM-DD. [who] reviewed. No changes.

Takes 15 minutes to write. Pays off every time you come back to an agent you haven't touched in a month.

You don't need the CI/CD pattern

Teams need eval suites wired into CI. You don't really. Running evals manually when you change a prompt is enough.

What you DO need: a simple script that runs your evals on demand. ~/.bot/scripts/eval.sh that iterates over every agent and runs its eval cases. You run it when you change something. No fancy infrastructure; just a habit.

The leverage check

Once a month, calculate: how much time did my agents save this month?

Rough estimate is fine. "Daily summarizer: 15 min/day × 22 days = 5.5 hours. Inbox triage: 20 min/day × 22 = 7 hours. Report pipeline: 2 hours/week × 4 = 8 hours. Total: 20 hours saved this month."

Write this number down. Watch it over time. It should grow as your fleet matures. If it's flat or declining, something's off.

Chief on solo cost monitoring.

Solo operators watch cost differently. No procurement team, no budget meetings. Just you and the bill.

The monthly check

First of every month, check your LLM provider's dashboard. What did you spend last month?

For most solo operators running 3-5 agents with modest usage, this should be $20-100/month. If you're seeing $300+, investigate:

• Which agent is driving the cost?
• Did anything change in the prompt or the trigger?
• Is there a runaway happening you didn't notice?

Set a hard alarm

Most LLM providers let you set a spending alert. Set one at 2x your expected monthly spend. If you hit it, something's wrong, investigate immediately.

This is the solo version of team cost governance. It's also more important for solos, because a runaway agent can eat your personal budget before you notice in a way that a team's runaway might get caught by someone else.

The cost-per-use metric

For each agent, know roughly what one run costs.

• Daily summarizer: ~$0.01 per run.
• Inbox triage: ~$0.02 per email.
• Weekly report: ~$0.15 per report.
• Content drafter: ~$0.25 per draft.

Now you can predict costs. 100 emails triaged today = $2. A report this week = $0.15. If actual cost is way off from predicted, something changed.

Trim quarterly

Module 007's trimming habit applies. For a solo operator, trim twice a year minimum. An hour each time. Pays for itself in reduced bills.

The expensive agent question

Before building any agent, ask: "what would one run of this cost?"

If the answer is "I don't know," don't build it yet. Figure out what's going in (input tokens), what's coming out (output tokens), how many LLM calls per run. Estimate. Then decide if the cost is justified by the time saved.

Most solo operators don't do this math and occasionally build agents that turn out to be surprisingly expensive per use. Ten minutes of estimation avoids that.

The three governance items for solo operators

1. Monthly spend review. Ten minutes on the first of each month.
2. Hard spending alert at 2x expected. Set once, catches drift forever.
3. Quarterly trim. An hour, twice a year.

Three habits. Zero infrastructure. Prevents the "I built agents and now my personal AI bill is shocking" story.

Founder wraps it.

Year one of solo agent building has a shape. Here's the playbook.

Months 1-2: One agent

Build your first agent. Probably the daily summarizer, because it's safe and the returns are immediate.

Use it every day. Tune it weekly. By the end of month two, you trust it. You built the habit of using it without thinking.

Months 3-4: Two agents

Add a second agent. Pick based on where your time is actually going, not what sounds cool.

By now you have the shared folder structure. The new agent slots in. You reuse the voice sample, the runbook template, the output structure. It takes a third of the time to build compared to the first.

Months 5-6: Three agents

Add the third. Usually it's a report pipeline of some kind, because by now you're seeing the data-to-narrative opportunity everywhere.

At three agents, you have a fleet. You're saving 10+ hours a month. The compounding effect starts to feel real.

Months 7-9: Tune, don't build

Resist the urge to add a fourth right away. Spend three months making the first three great.

• Better prompts. Better output quality.
• Better integration. Fewer manual steps.
• Better monitoring. You know when things break.

This is the boring part. It's also where the compounding becomes real. Three excellent agents saving you 15 hours a month is way better than six mediocre ones saving you 8.

Months 10-12: Fourth and fifth agent

By now you know exactly what would give you more leverage. You've tuned your existing three to a high standard. The fourth and fifth agents come naturally, solving real pains you've noticed.

By month twelve, you have a fleet that has transformed your operations. Future you looks back at year-ago you, who was doing all of this by hand, and can't quite imagine going back.

The one agent rule

One agent, used, is worth ten agents planned.

When in doubt, build. You can't think your way to a useful fleet. You have to ship one, use it, learn what works, ship the next.

The one rule you'll break

At some point, usually around month four, you'll get excited and try to build three agents at once. You'll spend a weekend setting it up. None of them will be great. You'll feel behind.

Step back. Pick one. Ship it. Use it for two weeks. Then pick the next.

The pace matters. One-at-a-time is slow but compounding. All-at-once is fast but brittle. Solo operators win with the first pace.