Over the past year, working with AI-powered development tools has taught me that what started as an “AI harness”—a simple wrapper around an LLM—has evolved into something more industrial: a software factory. A harness is about capability; a factory is about repeatability, auditability, and team ownership.
This post describes the architecture I’ve settled on for teams running on agentic engineering. It’s not a framework or library—it’s a way of composing existing tools (Taskfile, Claude/Claude Code, tmuxinator, Jira) into a coherent system where humans and AI agents work together predictably, capture team knowledge, and scale from one developer to a small team.
The Stack: Three Layers
Layer 1: Control Plane — Taskfile as Entrypoint Registry
Taskfile is the command palette for your team. Every repeatable operation—whether human or agentic—starts as a task. Why Taskfile? It’s language-agnostic, human-readable, and git-tracked. When a new team member joins, they run task --list and immediately see what the team automates. When an AI agent runs a task, both the human and the agent follow the same playbook—no hidden scripts, no implicit assumptions.
Taskfile becomes your control plane contract: “these are the operations this codebase supports, and they work this way.”
Example structure:
task ci— composite: runs all quality gatestask feature:new— scaffolds a new feature with teststask feature:review— AI-assisted code review
Layer 2: Agentic Platform — Persona-Driven Agent Systems
Claude (or any agentic platform) becomes the execution substrate. But the key insight is treating the LLM not as a monolith, but as a system of specialized agents.
Each agent is a “persona”:
- Code Architect — designs new modules, reviews system design
- Test Harness — writes tests, maintains coverage thresholds
- Debugger — investigates regressions, traces root causes
- Docs Keeper — maintains CLAUDE.md, updates architecture docs
- Linter — enforces style, runs pre-commit gates
In Claude Code, these are skills—specialized tools or Claude APIs with specific system prompts. A human or a parent agent delegates work to the right persona by invoking the skill or subagent.
The breakthrough: team-specific business rules live in the personas. Your linter config, your pre-commit hooks, your test philosophy, your security stance—all of these become learned context in the agent’s system prompt or in documented CLAUDE.md files that the agent reads. New team members and AI agents both learn the same way: by reading your docs and observing the tasks.
Layer 3: Developer Harness — Tmuxinator for Multi-Pane Sessions
Tmuxinator defines the developer’s runtime environment. It’s not just a convenience—it’s how the team codifies “here’s where the work lives.”
When you run task dev, the entire workspace assembles: code editor pane, watch processes, services, dev servers. Every team member sees the same layout. An AI agent running in this environment sees the same signals (output streams, exit codes) that a human would.
This is the tactile feedback loop: watchers re-run tests and linters on save; a failing test immediately appears in a visible pane; the developer or agent sees the result and can act.
Orchestration: Jira + Work Tracking
Your work tracking system (Jira, Linear, GitHub Issues) is the job queue. The human (or a parent agentic orchestrator) assigns tasks from the queue:
- Jira ticket → human reads and understands scope
- Task is delegated to the right agent persona or taken directly by the human
- Agent runs within the harness (tmuxinator + tasks)
- Output is captured and linked back to the ticket
The human in the loop decides:
- Is this task suitable for an agent? (Does it fit a known persona?)
- Which persona should own it?
- Is the result correct? (Did the test pass? Does the code make sense?)
The human on the loop means the human monitors but doesn’t manually intervene—the agent and the harness work autonomously within bounds.
Data Plane: Git Sub-repos for Output
Here’s where control plane and data plane separate.
Control plane (your main repo):
- Taskfile.yml
- .pre-commit-config.yaml
- .tmuxinator/
- CLAUDE.md (team playbooks, business rules)
- Source code, tests, config
Data plane (git sub-repo):
- AI-generated documents (architecture sketches, design reviews, research notes)
- Output from code-review runs
- Agent transcripts, run logs
- Datasets, training examples, decision records
Why separate? The control plane is stable, high-signal—it’s what you commit to and ship. The data plane is volatile, exploratory—it’s the scratch work, the drafts, the “let me try this” outputs. By isolating them:
- You can garbage-collect data plane without affecting reproducibility
- You don’t bloat your main repo with agent logs
- You can share data plane findings (e.g., research on a bug) without committing them to the product
- It’s clear what is “team knowledge” (control plane) vs. “team artifacts” (data plane)
Why This Architecture Scales
For one developer: The harness is your personal quality gate. Taskfile reminds you what to do; tmuxinator keeps your workspace organized; Claude Code is your copilot.
For a team: Everyone follows the same tasks, the same persona system, the same pre-commit gates. New hires run task --list and cat CLAUDE.md and start productive immediately. Agents onboard the same way.
For a mature practice: You accumulate team-specific knowledge in CLAUDE.md, task definitions, and persona prompts. That knowledge compounds—each agent invocation learns from prior decisions, test failures, code reviews. The data plane becomes a searchable archive of “we tried this, it worked” or “we tried this, it failed—here’s why.”
The Missing Piece: Observability
As your agentic practice matures, you’ll want to track:
- Which personas are invoked most?
- Which tasks fail most often?
- Which pre-commit gates catch the most issues?
- How much latency does an agentic workflow add vs. a human?
For now, the heuristic: if it’s in Taskfile, you can measure it. If it’s in CLAUDE.md, you can audit it.
Conclusion
An AI harness was about having capability. A software factory is about embedding capability into your team’s daily practice—so reliably that humans and agents become interchangeable units in a system that knows how to ship.
Taskfile, agent personas, tmuxinator, and git-tracked business rules are the infrastructure. They’re the difference between “we deployed an AI agent once” and “our team ships with AI agents every day.”