<h2 id="table-of-contents">Table of contents</h2>
<ul>
<li><a href="#a-warning">A warning</a></li>
<li><a href="#why-an-org-chart-for-ai-agents">Why an org chart for AI agents</a></li>
<li><a href="#the-agents">The agents</a></li>
<li><a href="#the-org-chart">The org chart</a></li>
<li><a href="#pai-the-executive-assistant">Pai: the executive assistant</a>
<ul>
<li><a href="#agent-invocation-via-bash">Agent invocation via Bash</a></li>
<li><a href="#dry-run-mode">Dry-run mode</a></li>
<li><a href="#adversarial-loops">Adversarial loops</a></li>
<li><a href="#logging">Logging</a></li>
</ul>
</li>
<li><a href="#the-wiki-layer">The wiki layer</a></li>
<li><a href="#pai-in-action">Pai in action</a>
<ul>
<li><a href="#the-dry-run">The dry-run</a></li>
<li><a href="#the-real-run">The real run</a></li>
<li><a href="#the-adversarial-demo">The adversarial demo</a></li>
</ul>
</li>
<li><a href="#watching-them-work">Watching them work</a></li>
</ul>
<h1 id="a-warning">A warning</h1>
<p>As of 2026-03-11, this is a "Hey this is neat" post and not a "this works really well!"
one. I found the process of building and testing this really fun, but I've also been
using this approach for basically no time at all and I'm sure a bunch of the things I'm
trying here are just going to straight up not work the way I want in the long run. I'll
be iterating on it a lot. The bot-wiki is meant to be kept up to date and that + the
code are probably the right places to check (or just ask me) how things are working
later on in time.</p>
<h1 id="why-an-org-chart-for-ai-agents">Why an org chart for AI agents</h1>
<p>Because it's cool, mostly. Also I hope it will work really well. But mostly, it's cool.</p>
<p>I've defined a team of Claude Code agents that each have a named
role, themed around being a virtual agent company. Any of them
work fine on their own:</p>
<pre><code class="language-bash">claude --agent cmo -p "What are my top 5 posts by pageviews?"
</code></pre>
<p>The benefit is persistent context. Each agent definition carries
its goal, tools, rules, and domain knowledge. I don't re-explain
what the CMO does every time I invoke it. The definition is the
context.</p>
<p>The challenge is coordination. When a request spans multiple
agents, someone has to decide which agents to call, in what
order, and how to stitch the results together. That's robot
work, not a good use of human time. I also don't want to be
the medium for shared context, copying output from one agent
into another's prompt.</p>
<p>I repurposed my OpenClaw agent
<a href="/openclaw-linear-skill.html">Pai</a> into an orchestrator. Pai
decomposes multi-agent requests and invokes the right agents
in sequence. The C-suite agents (CMO, CFO, CTO, CDO, CSO) each
own a domain and can sub-orchestrate their own subagents. The
CMO delegates to SEO, the CFO delegates to Cost Tracker, and
so on. The top-level/C-Suite agents also work as antagonistic loop orchestrators of
their own, I like to think of it as them enforcing high standards.</p>
<h1 id="the-agents">The agents</h1>
<table>
<thead>
<tr>
<th>Agent</th>
<th>Role</th>
<th>Model</th>
<th>Key Tools</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pai</td>
<td>Orchestration</td>
<td>Sonnet</td>
<td>Bash, Linear MCP</td>
</tr>
<tr>
<td>CMO</td>
<td>Traffic and growth</td>
<td>Sonnet</td>
<td>GA4 Analytics MCP</td>
</tr>
<tr>
<td>CFO</td>
<td>AI spend</td>
<td>Sonnet</td>
<td><a href="/openrouter-ai-tools.html">OpenRouter MCP</a></td>
</tr>
<tr>
<td>CTO</td>
<td>Delivery, blockers</td>
<td>Sonnet</td>
<td>Linear MCP, Bash</td>
</tr>
<tr>
<td>CDO</td>
<td>Knowledge management</td>
<td>Sonnet</td>
<td>Wiki read/write, Bash</td>
</tr>
<tr>
<td>CSO</td>
<td>Security and privacy</td>
<td>Sonnet</td>
<td>File tools, Bash</td>
</tr>
<tr>
<td>AR</td>
<td>Agent onboarding, mediation</td>
<td>Sonnet</td>
<td>File tools, Bash</td>
</tr>
<tr>
<td>Publisher</td>
<td>Blog content pipeline</td>
<td>Sonnet</td>
<td>Bash, file tools</td>
</tr>
<tr>
<td>SEO</td>
<td>Search audits</td>
<td>Sonnet</td>
<td>GA4, WebSearch</td>
</tr>
<tr>
<td>Cost Tracker</td>
<td>Spend reports</td>
<td>Haiku</td>
<td>OpenRouter MCP</td>
</tr>
<tr>
<td>Librarian</td>
<td>Wiki read/write</td>
<td>Haiku</td>
<td>Wiki file tools</td>
</tr>
<tr>
<td>Privacy Auditor</td>
<td>Flag confidential data</td>
<td>Haiku</td>
<td>File tools</td>
</tr>
<tr>
<td>Researcher</td>
<td>Gather sourced facts</td>
<td>Sonnet</td>
<td>WebSearch, Read</td>
</tr>
<tr>
<td>Writer</td>
<td>Draft posts from briefs</td>
<td>Sonnet</td>
<td>Read, Write</td>
</tr>
<tr>
<td>Fact Checker</td>
<td>Verify claims</td>
<td>Haiku</td>
<td>WebSearch, Read</td>
</tr>
<tr>
<td>Reviewer</td>
<td>Style and structure</td>
<td>Haiku</td>
<td>Read, Grep</td>
</tr>
<tr>
<td>QA</td>
<td>Production readiness</td>
<td>Sonnet</td>
<td>Bash, Playwright</td>
</tr>
</tbody>
</table>
<p>Each C-suite agent owns a domain and has subagents for
specialized work. SEO reports to the CMO. Cost Tracker
reports to the CFO. The Librarian reports to the CDO. The
Privacy Auditor reports to the CSO. AR (Agent Resources,
the HR department) handles agent onboarding and role boundary
mediation.</p>
<p>The Publisher is its own sub-org with a four-stage content
pipeline: researcher, writer, fact-checker, and reviewer.
QA runs after the pipeline to verify the post actually
builds, renders, and links correctly before it goes live.
QA uses <a href="/playwright-mcp.html">Playwright MCP</a> to take screenshots
and inspect the rendered page.</p>
<p>Every agent connects to real
<a href="https://modelcontextprotocol.io/">MCP</a> servers. No mocks. The
CMO queries real GA4 data. The CFO pulls real OpenRouter bills.</p>
<h1 id="the-org-chart">The org chart</h1>
<p>This is accurate as of 2026-03-12. The
<a href="/wiki/projects/agent-team/org-chart.html">bot-wiki org chart</a>
stays up to date as agents are added or reorganized.</p>
<pre class="mermaid">
graph TD
    Kyle["Kyle"]
    Pai["Pai — Executive Assistant"]
    CMO["CMO — Grow Readership"]
    CFO["CFO — Optimize Spend"]
    CTO["CTO — Delivery"]
    CDO["CDO — Knowledge"]
    CSO["CSO — Security"]
    AR["AR — Agent Resources"]
    Publisher["Publisher — Content Pipeline"]

    SEO["SEO Subagent"]
    CostTracker["Cost Tracker"]
    Librarian["Librarian"]
    PrivacyAuditor["Privacy Auditor"]

    Researcher["Researcher"]
    Writer["Writer"]
    FactChecker["Fact Checker"]
    Reviewer["Reviewer"]
    QA["QA"]

    Kyle --> Pai
    Kyle --> CMO
    Kyle --> CFO
    Kyle --> CTO
    Kyle --> CDO
    Kyle --> CSO
    Kyle --> AR
    Kyle --> Publisher

    Pai -.->|orchestrates| CMO
    Pai -.->|orchestrates| CFO
    Pai -.->|orchestrates| CTO
    Pai -.->|orchestrates| CDO
    Pai -.->|orchestrates| CSO
    Pai -.->|orchestrates| AR
    Pai -.->|orchestrates| Publisher

    CMO --> SEO
    CFO --> CostTracker
    CDO --> Librarian
    CSO --> PrivacyAuditor

    CMO -.->|reads/writes| Librarian
    CFO -.->|reads/writes| Librarian
    CTO -.->|reads/writes| Librarian

    Publisher --> Researcher
    Publisher --> Writer
    Publisher --> FactChecker
    Publisher --> Reviewer
    Publisher --> QA
</pre>
<p>It being my blog and virtual team, I get to sit at the top. Every agent is directly
invocable by me, but ideally I don't need to do that often.</p>
<p>Solid lines mean "reports to." Dashed lines from Pai mean
"orchestrates." Dashed lines to the Librarian mean "can
read/write wiki through."</p>
<p>The Privacy Auditor is the gatekeeper. Any agent writing
content that will end up in git or on the internet should
check with the Privacy Auditor first. It scans for leaked
analytics data, spend numbers, secrets, and anything else
that shouldn't be public. This came from a scare where one of my agents with access
to mildly confidential data referenced it in content that
would have been public. I feel strongly that all agent flows
need a privacy step at minimum, and ideally agents should
have purposefully curtailed access to sensitive data.</p>
<p>Pai is structured as a peer to the other top-level agents, and orchestrator. I can
still run <code>claude --agent cmo</code> whenever I want. Pai is for when a request spans
multiple agents and I don't want to do the routing myself.</p>
<p>The Librarian is an experiment in context management and
shared state. Any agent can talk to it directly to persist
notes, plans, or evidence to the wiki. I already built a
<a href="/wiki-rag.html">RAG system</a> over the wiki. Once the wiki
gets big enough that agents can't skim it all, I'll have
them query the RAG index instead. For now, the agents just
use git and local file storage for wiki access. The CDO
owns the wiki strategy, but the Librarian does the actual
reading and writing.</p>
<h1 id="pai-the-executive-assistant">Pai: the executive assistant</h1>
<p>Agent definitions live in <code>.claude/agents/</code>. Here's Pai's
frontmatter:</p>
<pre><code class="language-yaml"># .claude/agents/pai.md
name: pai
description: >-
  Pai — Executive assistant that orchestrates
  multi-agent workflows
model: sonnet
tools:
  - Bash
  - Read
  - Glob
  - Grep
  - Write
  - mcp__linear-server__list_issues
  - mcp__linear-server__list_projects
</code></pre>
<p>The body of the definition has four key sections.</p>
<h2 id="agent-invocation-via-bash">Agent invocation via Bash</h2>
<p>Pai invokes other agents with
<code>claude --agent &#x3C;name> -p "prompt"</code> through the Bash tool.
Each call is a fresh session. Agents don't share memory or
context with each other.</p>
<p>This is the main tradeoff. Fresh sessions mean no shared
state, but Pai bridges the gap by reading output from one
agent and passing relevant parts into the next agent's prompt.</p>
<p>The alternatives I considered:</p>
<ul>
<li><strong>Shared memory / message bus.</strong> Tools like LangGraph or
CrewAI give agents shared state. More powerful, but more
moving parts. I wanted something I could debug by reading
a bash script.</li>
<li><strong>Single mega-agent.</strong> One agent definition with all the
tools. Simpler, but the context window fills up fast and
the agent loses focus. Splitting by role keeps each
session lean.</li>
<li><strong>MCP-based orchestration.</strong> Route through an MCP server
that manages agent sessions. Interesting, but overkill
for a blog. I'd rather build on <code>claude --agent</code> which
already works.</li>
<li><strong><a href="https://github.com/steveyegge/beads">Beads</a>.</strong> A
structured task memory for AI agents, backed by Dolt
(version-controlled SQL). I looked into it, but it's
more of an alternative to Linear than to the wiki. It
solves task tracking and agent handoff, not knowledge
management. I like Linear for tasks and markdown files
for knowledge.</li>
</ul>
<p>I went with the dumb approach: Bash calls and text passing.
It's easy to understand, easy to debug, and the wiki handles
long-term memory. If I outgrow it, I'll upgrade.</p>
<h2 id="dry-run-mode">Dry-run mode</h2>
<p>Add <code>--dry-run</code> to your message and Pai outputs the
orchestration plan without executing anything. Which agents,
what prompts, what order, how it would synthesize.</p>
<p>Useful for checking that Pai will do what you want before it
burns tokens on three agent calls.</p>
<h2 id="adversarial-loops">Adversarial loops</h2>
<p>For requests that need critique or review between agents:</p>
<ol>
<li>Agent A produces output</li>
<li>Agent B critiques it</li>
<li>Agent A revises based on feedback</li>
<li>Up to 3 rounds or until the reviewer approves</li>
</ol>
<p>CMO proposes blog topics, CTO reviews technical feasibility,
CMO revises. The back-and-forth produces better output than
either agent alone.</p>
<h2 id="logging">Logging</h2>
<p>Every orchestration run appends a timestamped entry to
<code>pai-log-YYYY-MM-DD.md</code>. Agent name, prompt summary, result
status, and a one-line synthesis.</p>
<h1 id="the-wiki-layer">The wiki layer</h1>
<p>Each agent has a page in the
<a href="/bot-wiki.html">Bot-Wiki</a> that documents its goal, tools,
subagents, and example prompts.</p>
<pre><code class="language-text">agent-team/
├── index.md          # org chart and coordination model
├── pai.md            # orchestration agent
├── cmo.md            # traffic and growth
├── cfo.md            # AI spend
├── cto.md            # delivery and blockers
├── cdo.md            # knowledge management
├── cso.md            # security and privacy
├── publisher.md      # blog pipeline
└── phase-2.md        # future async architecture
</code></pre>
<p>The wiki is the shared memory layer.</p>
<p>Every agent session is stateless. The CMO doesn't remember
what the CTO said last week. But if the CTO writes its
findings to the wiki through the Librarian, the CMO can
read them next time it runs. The wiki is how agents share
context across sessions.</p>
<p>The Librarian (a Haiku subagent under the CDO) handles
all wiki read/write operations. Any agent can invoke it
directly with <code>claude --agent librarian -p "..."</code> to
persist notes, plans, evidence, or whatever else needs to
survive between sessions. The CDO owns the strategy:
what gets documented, how pages are structured, when
content is stale.</p>
<p>This is cheaper than giving every agent write access to
the full file system. The Librarian runs on Haiku, knows
the wiki format, and won't accidentally clobber unrelated
files.</p>
<p>In time I may have the CFO tweak the models the agents use to manage costs, too.</p>
<h1 id="pai-in-action">Pai in action</h1>
<h2 id="the-dry-run">The dry-run</h2>
<p>I asked Pai for a quarterly health check with <code>--dry-run</code>:</p>
<pre><code class="language-bash">claude --agent pai -p "Give me a quarterly health check. \
  How's traffic trending, what am I spending on AI, and \
  are there any blocked issues? --dry-run"
</code></pre>
<p>Pai planned three parallel agent calls:</p>
<blockquote>
<p><strong>Agent 1, CMO:</strong> Pull a quarterly traffic report for
kyle.pericak.com. Total sessions and users for the quarter
vs prior quarter, top 5 posts by pageviews, traffic channel
breakdown.</p>
<p><strong>Agent 2, CFO:</strong> Pull OpenRouter AI spend for Q1 2026.
Break it down by model and by month. Flag any month-over-month
spikes > 20%.</p>
<p><strong>Agent 3, CTO:</strong> Review all open Linear issues and flag any
that are blocked, stalled (no update in 14+ days), or missing
an assignee.</p>
</blockquote>
<p>It also laid out the synthesis plan: group results by theme
(traffic, spend, delivery), cross-reference findings, and
call out any cross-domain issues.</p>
<p>No agents ran. No tokens burned. I could review the plan and
adjust before committing.</p>
<h2 id="the-real-run">The real run</h2>
<p>Same request without <code>--dry-run</code>. Pai invoked three agents
and synthesized everything into one report.</p>
<p><strong>Traffic</strong> (from CMO): GA4 only had a week of data. The
site is new enough that there's no meaningful baseline yet.
Almost entirely direct traffic, organic search barely
registering. CMO recommended connecting Search Console and
revisiting in 30 days.</p>
<p><strong>AI spend</strong> (from CFO): well under budget with no pressure.
OpenRouter's API only surfaced account-level totals, no
per-model breakdown. CFO noted the biggest future lever is
routing non-reasoning tasks to flash-tier models.</p>
<p><strong>Delivery</strong> (from CTO): most issues done or in backlog,
one in progress (this blog post). No hard blockers, but
three dependency chains worth watching:</p>
<ol>
<li>RSS feed is high priority but hasn't started. Four
distribution issues are gated on it.</li>
<li>CMO and CFO baseline runs haven't started. They gate
two future blog posts.</li>
<li>This post has an open PR to close.</li>
</ol>
<p>Pai wrote a log entry automatically:</p>
<pre><code class="language-markdown">## 21:30 — Quarterly health check

| Agent | Prompt Summary | Result |
|-------|---------------|--------|
| cmo | 90-day traffic trend | success |
| cfo | 90-day AI spend | success |
| cto | Blocked/stalled issues | success: 3 clusters |

**Synthesis:** Early launch phase, minimal spend,
no hard blockers but three dependency chains.
</code></pre>
<h2 id="the-adversarial-demo">The adversarial demo</h2>
<p>I asked Pai to have the CMO propose blog topics and the CTO
review feasibility:</p>
<pre><code class="language-bash">claude --agent pai -p "The CMO wants to propose 3 new \
  blog topics. Have CTO review feasibility."
</code></pre>
<p>CMO proposed three posts:</p>
<ol>
<li><strong>Give Your Agents a Memory</strong> - wire agents to read/write
wiki context on startup</li>
<li><strong>Agents That Run Themselves</strong> - scheduled execution with
cron and cost guardrails</li>
<li><strong>Teach Your CTO Agent to Review PRs</strong> - GitHub Actions
workflow that fires the CTO agent on every PR</li>
</ol>
<p>CTO reviewed each one:</p>
<ul>
<li>Post 6 (wiki memory): needs groundwork. Wiki is read-only
from agents today. A write protocol means git commits from
within agent sessions.</li>
<li>Post 7 (scheduling): blocked. Phase 2 prerequisites from
the wiki aren't met. PER-37 and PER-38 haven't started.</li>
<li>Post 8 (PR review): needs groundwork. Most self-contained,
but <code>.github/workflows/</code> doesn't exist yet.</li>
</ul>
<p>CTO's recommended ship order: complete PER-37 and PER-38
first, then post 6, then post 8, then post 7 last (after
the others prove stability).</p>
<p>The interesting thing here is the cross-referencing. The CTO
pulled the same PER-37/PER-38 dependency from the health
check. It flagged the same blocker from two different angles
without being told about the first run.</p>
<h1 id="watching-them-work">Watching them work</h1>
<p>I got bored waiting for the agents to finish doing their thing so I made them all
post status updates to a local file. I <code>tail -f</code> the file and watch them work. It's
neat. Eventually I think I might plug them into some chat app or something instead so
it looks more like people talking to each other. I think
that'd be fun.</p>


Kyle Pericak

"It works in my environment"

Categories

Tags