The Architect Pattern: Building Task Infrastructure for an AI Agent Team

I run a team of 9 AI agents on a self-hosted Kubernetes cluster. Henry orchestrates. Kit writes code. Petra researches. Thane guards security. Margaux documents. Declan handles social. Callum analyzes trends. Sentinel monitors. And now Wren triages the board.

They coordinate through Mission Control, a Node.js Express sidecar running alongside the main OpenClaw pod, backed by JSON persistence on a PVC. I track my own work through Life-Hub, a FastAPI personal dashboard with 157 MCP tools, SQLite storage, and an HTMX frontend.

The problem: nobody was managing the board itself. Henry, the Chief of Staff agent, had accumulated 68% of all open tasks because there was no triage process, no hygiene enforcement, and nobody whose job was board health. Tasks went stale. Acceptance criteria were missing on 16 of 18 high-priority items. Due dates didn't exist on 30 of 31 open tasks. Six “critical” tasks were actually meta-tasks about organizing the backlog: priority inflation masking real urgency.

So I built the infrastructure to fix it. In one session.

Starting Point: Two Disconnected Systems

The architecture looks like this:

Mission Control (Node.js, port 3456)     Life-Hub (FastAPI, port 8000)
├── /api/tasks     (agent work)          ├── /api/v1/actions  (personal tasks)
├── /api/projects  (agent projects)      ├── /api/v1/goals    (long-term goals)
└── data/tasks.json (PVC persistence)    └── /mcp/            (157 MCP tools)

Mission Control uses string IDs (mmshj7css36c), status values backlog/in-progress/review/done, and priority low/medium/high/critical. Life-Hub uses integer IDs from SQLite, status open/in_progress/done, and priority 1-5 where 1 is highest. The chief-of-staff framework uses P1-P4.

Three systems, three priority scales, no translation layer. This is how P2 ends up mapped to “medium” instead of “high”: it intuitively feels like the middle, but P2 means “important, same-day” in my framework.

The Skill: Operational Playbook

I created a Claude Code skill called task-board-manager: not strategy (that’s the chief-of-staff skill), but operations. The exact API mechanics for reading, writing, and maintaining task data across both systems.

The skill encodes:

• Priority mapping table: P1→critical, P2→high, P3→medium, P4→low, with Life-Hub equivalents. Explicit, not guessable.
• Task schema: every MC field documented with its type, valid values, and defaults
• Triage methodology: structured sweep with specific staleness thresholds (24h for in-progress, 48h for review, 14 days for backlog P2+)
• Board hygiene checklist: 8 items from “close done-but-not-marked-done tasks” to “ensure every P1/P2 has acceptance criteria”
• Cross-system coordination: how Life-Hub goals decompose into MC agent tasks, how agent outputs create personal follow-ups, and the linkage pattern (source field references LH goal, goal_id links LH actions back)
• Agent routing table: which agent gets which type of work
• Triage report template: Board Summary, Critical Findings, Stale Work Analysis, Board Hygiene Issues, Life-Hub Cross-Reference, Recommended Actions

Benchmarking: Does the Skill Actually Help?

I ran 3 test scenarios, each with and without the skill (6 total runs via subagents), then graded against specific assertions:

Eval 0: Create a Task

“Create a task for Kit to build a PowerShell script that audits stale Conditional Access policies. P2, due next Friday.”

The baseline actually won this one: 100% vs 83%. The baseline correctly mapped P2 to high; the skill mapped it to medium because I hadn’t included an explicit priority mapping table yet. Both produced quality acceptance criteria and proper schema. Lesson: for simple CRUD, the model already knows how to read a JSON schema and create matching objects. Skills don’t help much here.

Eval 1: Board Triage

“Triage the task board: what’s stale, what’s blocked, what needs attention?”

The skill crushed it: 100% vs 57%. Both found the HYSA deadline risk and the Henry bottleneck. But only the skill-guided run caught:

• 10 critical/high tasks missing acceptance criteria
• 150 of 219 done tasks without closure notes
• Duplicate cron-generated tasks indicating a dedup bug
• Specific agent reassignment suggestions using the routing table
• Life-Hub cross-reference with the specific MCP tools that would be used

The baseline missed Life-Hub entirely. It only looked at one system.

Eval 2: Cross-System Goal Decomposition

“I want to pass my CISSP by September. Break that down into tasks for me and the agents.”

Again 100% vs 57%. The baseline produced more tasks (30 MC tasks vs 10), but lacked operational precision: no acceptance criteria on any of them, no cross-system linkage via source/goal_id fields, and no specific MCP calls documented. The skill-guided run produced fewer but complete tasks, plus 24 explicit MCP calls for Life-Hub (create_goal, add_milestone x6, brain_dump + update_action pairs for all study items).

Overall

The skill adds ~23% more accuracy at ~16-21% more cost. The value is concentrated in cross-system awareness and structured methodology, exactly where institutional knowledge lives.

I fixed the priority mapping gap the eval exposed, added the triage report template, and documented the goal decomposition workflow.

The Agent: Wren Ashford

A skill without an owner is documentation. I needed someone whose job was the board.

Wren Ashford (codename “The Architect”) was already a placeholder in the agent roster. I onboarded her for real with a full workspace:

SOUL.md defines her personality: methodical, terse, no-nonsense. She thinks in priorities, dependencies, and definitions of done. She doesn’t tolerate vague tasks or stale work. Her communication style is structured tables and checklists, not prose. The task-board-manager skill is her operational playbook.

Her capabilities span both systems:

• Mission Control API at http://mission-control:3456/api/tasks
• Life-Hub API at http://life-hub.life-hub.svc.cluster.local:80/api/v1/actions
• Full triage methodology with staleness thresholds
• Task CRUD, reassignment, and cross-system coordination

Her rules are hard constraints:

• Never bulk-close tasks: verify each individually
• Every P1/P2 task needs acceptance criteria
• Every closure needs a closureNote
• Don’t assign to “team”: every task needs one clear owner
• Escalate to Steven for budget decisions, external commitments, or P1 priority overrides

I added routing rules to ORCHESTRATION.md so Henry delegates board work to Wren, and recurring heartbeat tasks for daily stale checks and a weekly Friday full triage sweep. She runs on Sonnet (cost-effective for structured analysis work).

Deployment was straightforward: update the ConfigMap in home-ops/apps/openclaw/agent-workspace-files.yaml with her SOUL.md and HEARTBEAT.md, change her model from Opus to Sonnet in configmap.yaml, bump the config hash annotation to trigger a pod restart, push, and let Flux reconcile.

The Live Triage

With the skill built and Wren configured, I ran a live triage against the actual board. The findings were worse than I expected.

Board state: 281 total tasks: 250 done, 17 in-progress, 14 backlog.

Critical findings:

1. HYSA deadline risk: Task mmwv6u4jmvy1 (set up a high-yield savings account for K) due 2026-03-31, 4 days away, still in backlog, assigned to Henry. Henry cannot open a bank account.
2. Assignment bottleneck: Henry held 21 of 31 non-done tasks (68%). Kit, Thane, Callum, Declan, and Sentinel had zero active tasks. All work was funneling through one agent.
3. Priority inflation: 6 of 8 “critical” tasks were meta-tasks about organizing the backlog. Process overhead masquerading as urgent deliverables.
4. Missing structure: 16 of 18 high/critical tasks had no acceptance criteria. 30 of 31 had no due date. Nobody knew what “done” looked like or when it was due.
5. Documentation gap: 150 done tasks (60%) had no closure notes. The audit trail was effectively blank.

I fixed 21 tasks in one pass:

Henry’s share dropped from 68% to 39%. The board now has work distributed across 9 assignees instead of 1.

The Follow-Through: Six Features

A one-time triage is a band-aid. I needed permanent infrastructure. So I built six features to make the board self-sustaining.

1. MC Task MCP Tools

Eight new MCP tools in Life-Hub’s MCP server, backed by a new mc_client.py async HTTP proxy:

create_mc_task      — Create a Mission Control task
list_mc_tasks       — List with optional status/assignee filters
update_mc_task      — Update any task fields
close_mc_task       — Close with required closure note
get_mc_board_summary — Status counts, assignment distribution
triage_mc_board     — Full structured triage with findings
check_mc_stale_tasks — Check staleness thresholds, send ntfy notification
suggest_agent_tasks_for_goal — LLM-powered goal decomposition

This is the force multiplier. The task board is no longer locked behind JSON files or direct API calls: any Claude session or OpenClaw agent can manage it through MCP. The mc_client.py handles snake-to-camelCase key mapping, graceful degradation when MC is unreachable, and all the HTTP plumbing.

Configuration is a single env var: MISSION_CONTROL_URL=http://mission-control.openclaw.svc:3456. When unset, all MC features gracefully no-op.

2. Stale Task Notifications

A new module (mc_notifications.py) that checks the board against staleness thresholds and sends a consolidated ntfy push notification. One ping, not one per task. Priority 4 (high) if any critical or imminent deadline items, priority 3 otherwise.

Exposed as both a REST endpoint (POST /api/v1/mc/check-stale) for cron triggers and an MCP tool (check_mc_stale_tasks) for interactive use.

3. Quick Task Skill

A Claude Code skill for fast-path task creation from natural language. Say “Kit: audit CA policies, P2, due Friday” and it parses the assignee, title, priority, and due date, generates acceptance criteria, and writes the task. No confirmation prompt: just create and report.

4. Today Page Widget

The Life-Hub dashboard’s today page now includes a Mission Control board summary card: open task counts with color-coded status badges, assignment distribution with progress bars, stale task warnings, and upcoming deadline alerts. Board health is visible every morning without running a triage. Gracefully hidden when MC isn’t configured.

5. Auto-Suggest Agent Tasks

An MCP tool that takes a Life-Hub goal, feeds it to an LLM with the agent routing table as context, and returns suggested MC tasks with appropriate agent assignments, acceptance criteria, and due dates. “Pass CISSP by September” becomes specific, actionable tasks for Petra (research exam changes), Margaux (create study materials), Wren (set up progress check-ins), and Sentinel (monitor timeline).

The suggestions are returned as dicts matching the MC task schema, ready to pipe directly into create_mc_task.

6. Friday Triage Cron

A scheduled remote trigger that runs every Friday at 17:00 UTC (11 AM Mountain). It clones the openclaw-workspace repo, reads the committed tasks.json, runs the full triage methodology, and produces a structured report. The analysis covers the same checklist Wren uses: status counts, staleness thresholds, missing acceptance criteria, assignment bottlenecks, and prioritized recommendations.

The Architect Pattern

This is what I call the Architect pattern, as opposed to the Slumlord who patches things reactively and moves on:

1. Build the operational layer: a skill encoding schemas, mappings, methodology, and cross-system coordination patterns
2. Assign an owner: an agent with the skill as their playbook and clear authority boundaries
3. Run the first pass: a live triage to establish baseline and surface immediate problems
4. Fix what’s broken: act on findings, don’t just report them
5. Build the infrastructure: MCP tools, notifications, dashboards, crons that make the system self-sustaining

The whole arc, from “nobody manages the board” to “Wren runs weekly triages, stale tasks trigger phone notifications, the dashboard shows board health, and any agent can manage tasks through MCP”, happened in one session.

The board isn’t just cleaner. It’s managed.