My Engineering Team with AI Agents

TL;DR

I built a system where AI agents act as a full engineering team — each with specialized roles — and discovered that the real challenge isn’t building agents, but orchestrating them effectively with the right workflows and human oversight.

Key insight:
👉 The hard part isn’t creating agents — it’s orchestrating them (deciding who does what, when to hand off, and when humans step in).

What I found:

• Multi-agent setups can deliver complex projects much faster (days vs months)
• Agents work best as AI-native specialists with clear roles and boundaries
• Human-in-the-loop remains critical for coordination, judgment, and quality control

🚀 Bottom line:
The future of engineering isn’t solo AI tools — it’s humans managing teams of AI agents like an org.

It Started with a Familiar Problem

I’ve spent years in infrastructure and DevOps — managing cloud environments, building observability stacks, and dealing with the gap between what vendors charge and what teams actually need.

So I started building my own infrastructure monitoring platform — self-hosted, no per-host pricing, no data leaving your VPC. Just a clean dashboard for AWS resources with real-time metrics and secure access.

The prototype came together quickly. FastAPI, React, PostgreSQL, Valkey — I had something working within weeks.

Then reality hit.

To make it production-ready, I needed:

• A commercial edition with enterprise features
• Helm charts for Kubernetes deployments
• A marketing site
• A Go-based monitoring agent
• A license server

Six repositories. Three languages. Two product editions. One builder.

I tried the obvious approach — using AI tools like Claude for code generation. It worked for small tasks, but broke down at scale. There was no memory, no continuity, no coordination. Every context switch meant re-explaining everything. Cross-repo changes were still manual.

I didn’t need a better autocomplete. I needed a team.

That’s when it clicked.

While working with Plane’s API — work items, comments, states — I realized it already had everything needed for coordination.

What if the team wasn’t human?

Not a single AI assistant in a chat window — but a group of agents. Each with a role, a domain, and clear ownership. A TPM. Backend engineers. Frontend engineers. Each responsible for their own repos. Communicating through structured work items instead of ephemeral chats.

So I built exactly that.

I created individual identities for each agent, gave them defined roles, access to the right tools, and a shared workflow that mirrored a real engineering team.

Then I gave my TPM agent her first task.

She researched competitors, wrote a detailed spec, and posted her analysis — without me prompting each step.

I reviewed it the next morning.

That’s when it clicked. This wasn’t a hack. It was a workflow.

The Setup

Six AI agents. Six repositories. One CLAUDE.md that defines the entire organization. Here’s how it works.

Each agent has its own configuration. The .mcp.json file at the repo root defines the MCP server connections — one per agent, each authenticated with that agent’s Plane API token. The CLAUDE.md file defines the organizational rules. And each agent type has its own instruction file that shapes its persona and available tools. When I launch /pick-work Vikram, Claude reads all of this and becomes Vikram — the Go engineer who owns the monitoring agent repo, uses the plane-vikram MCP server, and follows the team rules.

Meet the Team

Every agent has a name, a role, repositories they own, and their own MCP (Model Context Protocol) server connected to Plane:

Each agent is a Claude session launched from a central “control plane” repository. The control plane’s CLAUDE.md file acts as the team handbook — it defines who does what, how agents communicate, and the rules everyone follows.

The Control Plane: A CLAUDE.md That Runs a Company

The secret sauce is a single markdown file that every agent reads at the start of their session. It contains:

Repo paths — so agents know where to cd before running git commands.

Agent-to-repo mapping — Vikram writes to the agent repo. Ashim writes to Helm charts. No one writes outside their lane.

Inter-agent communication protocol — when Rhea needs Vikram’s technical opinion, she doesn’t guess. She spawns a Vikram sub-agent, passes context, and gets a researched answer back.

Rules — never force push to main, always create PRs, verify builds before committing, use the right MCP server for Plane API calls.

This is the organizational structure, the employee handbook, and the onboarding document — all in one file that every agent session inherits.

How Work Flows Through Plane

We use Plane (app.plane.so) as our project management tool. Plane provides a robust API and an official MCP server that makes it straightforward to connect AI agents as first-class participants. Each agent gets their own MCP server instance, so when Rhea creates a work item or Vikram posts a comment, it shows up under their name in Plane — full attribution, full audit trail.

The Workflow States

Our Plane project has a deliberate state machine that maps to how AI agents work:

Backlog → Analyse → Analysis Review → Spec Approved → Ready for Dev → In Progress → Ready for Review → PR Ready → Release Pending → Done

Analyse: Rhea (the TPM) picks up items here. She conducts market research, writes detailed specs, identifies edge cases, and creates sub-items.

Analysis Review: I review Rhea’s work and leave comments. She incorporates feedback.

Spec Approved: I move items here when the spec is solid.

Ready for Dev: Engineering agents pick up work from here.

In Progress → PR Ready: The engineer writes code, runs tests, creates a PR.

Release Pending: We batch PRs before cutting a release.

This state machine means I review specs before code gets written, and I review PRs before they merge. The agents do the heavy lifting; I provide direction and quality gates.

A Real Example: Speccing Out a Full Observability Agent

Let me walk you through how this played out for our biggest work item yet — designing and building a custom OpenTelemetry Collector distribution for log, metric, and trace collection.

Step 1: I Create a Rough Idea

I created a work item in Plane with a basic title: “Server & Cluster Agent for Logs + System Metrics.” Just a sentence describing what I wanted. I assigned it to Rhea and set the state to “Analyse.”

Step 2: Rhea Conducts Market Research

I launched Rhea’s session. She:

• Researched five competitors (Datadog Agent, Grafana Alloy, Fluent Bit, Vector, OTel Collector)
• Built a comparison table with strengths and weaknesses
• Identified our differentiation points (self-hosted, no per-host pricing, data sovereignty)
• Created a Plane page with her research findings
• Wrote the full spec directly in the work item description
• Posted an analysis summary as a comment
• Moved the item to “Analysis Review”

All of this happened autonomously. I reviewed her work in Plane, just like I’d review a TPM’s PRD.

In hindsight, this work item should have followed our proper PRD process from the start. We’ve since established a convention: Rhea creates a Plane page titled [PRD] <Feature Name> for every significant feature. The PRD page contains the full product requirements document — market context, user stories, requirements, success criteria. The corresponding work item then references this page, keeping the work item focused on execution while the PRD lives as a standalone, linkable document. This separation matters because multiple work items can reference the same PRD, and the PRD survives even after individual tasks are completed.

Step 3: I Add Feedback

I commented on the work item: “We need traces too, not just logs and metrics.” Rhea incorporated this, expanding the spec to cover all three telemetry signals.

Get MGuptaHub’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

I also added architectural decisions: “The agent backend is a 3rd service called collector. OSS retention is 1 day. Activation is via the Admin Panel.”

Step 4: Rhea Consults Vikram (the Repo Engineer)

Here’s where it gets interesting. Rhea needed Vikram’s technical validation on the spec. She spawned a Vikram sub-agent:

Agent(
  subagent_type="oss-backend",
  prompt="You are Vikram, the Monitor Agent engineer.
    Review the spec for technical feasibility.
    Post your findings as a comment on the work item."
)

Vikram’s review was thorough. He:

• Validated that hostmetricsreceiver covers all listed metrics
• Recommended deferring tail-based sampling to Phase 2 (memory concerns)
• Suggested splitting into two deployment profiles (infra-agent + gateway)
• Identified a critical missing component (memorylimiterprocessor)
• Answered all four open questions with specific technical reasoning
• Posted his full review as a structured comment on the work item

Rhea then incorporated all of Vikram’s suggestions into the spec. The final result was a production-quality technical specification with:

• Two ocb manifests (agent + collector)
• Component tables for each binary
• Resource defaults for Helm
• Architecture diagrams
• Edge cases and constraints
• A “Decisions Made” section capturing every resolved question

Step 5: Sub-Tasks with Blockers

Once the spec was approved, Rhea created 10 sub-tasks, each with:

• Clear description and acceptance criteria
• Assigned to the right engineer (Vikram for agent work, Ashim for Helm)
• Blocker relationships (e.g., “ocb manifest” blocks “agent config profiles”)

Two tasks had no blockers and could start immediately. Vikram picked those up and started building.

The Inter-Agent Communication Protocol

The most powerful pattern we’ve developed is how agents talk to each other. Since they can’t @mention or poll for messages, we use a sub-agent spawning model:

1. Agent A needs input from Agent B
2. Agent A looks up the Agent Directory (in CLAUDE.md) to find B’s subagent type and MCP server
3. Agent A spawns a sub-agent of B’s type, passing full context
4. The sub-agent does the work, optionally posts a comment on the Plane work item
5. The sub-agent returns findings to Agent A and terminates

This is synchronous, context-rich, and leaves an audit trail on the work item. No polling, no lost messages, no new infrastructure.

# Rhea asking Vikram about memory constraints
Agent(
  subagent_type="oss-backend",
  prompt="""You are Vikram, the Monitor Agent engineer.
    Rhea needs to know: Can the OTel Collector handle tail-based
    sampling within a 50MB memory budget?
    Research this and post your findings as a comment
    using the plane-vikram MCP server. Return your answer."""
)

The Release Process: Coordinated Across Repos

Shipping a release is where multi-repo coordination really gets tested. A single version bump touches the OSS backend, the commercial backend, Helm charts, and the website — four repos, four agents, one coherent release.

Here’s how we handle it:

Release Notes and Changelog

Rhea creates a [RELEASE] parent work item (e.g., “OSS v0.7.0 / Commercial 2026.04.0”) with sub-tasks for each repo that needs updates. The release notes live in the OSS repo as the source of truth — the commercial repo pulls them in via sync, so there’s no drift between editions.

The changelog on the website is generated from these release notes. When Arun tags a release on the backend repos, Manish (the website agent) picks up a sub-task to update the changelog page with the new version’s highlights.

The Release Dance

A typical release flows like this:

1. Feature PRs merge — engineering agents have been shipping PRs throughout the sprint. Work items move to “Release Pending.”
2. Rhea creates the release work item — with sub-tasks: “Tag OSS release”, “Tag commercial release”, “Update Helm charts”, “Update website changelog.”
3. Arun tags the backend releases — OSS first (semver), then commercial (CalVer). Docker images are built and pushed to the registry.
4. Ashim updates Helm charts — bumps appVersion in the chart, updates values.yaml defaults, runs helm template to verify, creates a PR.
5. Manish updates the website — new changelog entry, updated version references, any feature highlights for the landing page.
6. I review and merge — each PR gets my sign-off. Once all four are merged, the release is done.

The key insight is that each agent only touches their repo. Arun doesn’t modify Helm charts. Ashim doesn’t touch the website. The blocker relationships on the sub-tasks enforce the ordering — Ashim’s Helm chart update is blocked by Arun’s backend release, because you can’t bump appVersion until you know the version number.

What used to be a stressful, error-prone half-day of manual coordination across repos is now a structured workflow where each agent handles their piece and I just review the PRs.

Rules That Keep Everything From Breaking

AI agents are powerful but they need guardrails. Our rules section in CLAUDE.md includes:

Git safety: Never force push to main. Always create PRs. OSS changes go through the OSS repo first, then sync to commercial. Commercial-only features go directly to the commercial repo.

Identity boundaries: Each agent uses ONLY their own MCP server for Plane API calls. Vikram can’t post as Rhea.

Collaboration: “When your work touches another agent’s domain, reach out via the Inter-Agent Communication protocol. Do not guess or make assumptions about areas outside your expertise.”

Verification: “Before creating a PR, run all relevant verification steps — unit tests, linting, docker builds, binary builds, helm template rendering. Do not assume code works just because it looks correct.”

These aren’t suggestions. They’re the constitution of the team.

Why Plane Works Perfectly for This

We chose Plane (app.plane.so) as our project management tool for several reasons:

MCP Integration: Plane exposes a clean API that we connect to via MCP servers. Each agent gets their own server, so actions are attributed correctly.

Work Item Hierarchy: Parent items with sub-tasks let us structure specs (parent) and implementation tasks (children) naturally.

Relations: Blocker/blocked-by relations enforce the dependency graph. Agents can see what’s blocked and what’s ready.

Comments as Communication: The comment thread on a work item becomes the discussion log. Rhea’s analysis, Vikram’s technical review, my feedback — all in one place, in chronological order.

States as Workflow: Custom states (Analyse → Analysis Review → Spec Approved → Ready for Dev) create a pipeline that both humans and agents understand.

Pages: Plane pages serve as our knowledge base. Rhea stores market research there. PRDs live as [PRD] <Feature Name> pages that work items reference.

Here’s what’s remarkable: everything I’ve described in this post — the six-agent team, the workflow states, the PRD pages, the blocker relations, the comment-based collaboration — all of it runs on Plane’s free tier. The free plan supports up to 12 members, which is perfect for our 6 agents plus my own account. I didn’t have to pay anything to build a functioning AI engineering team with full project management.

That said, as the project matures, I can already see where Plane’s paid tiers would take this to the next level:

Epics (Pro) — Right now, each release is a parent work item with sub-tasks. But some features span multiple releases. The observability agent, for example, has Phase 1, Phase 2, and Phase 3 — each of which will be its own release cycle. Epics would let me group these related work items across releases into a single trackable initiative, giving Rhea a higher-level view of the roadmap.

Intake via Email (Business) — Imagine external users reporting bugs via email, and those emails automatically becoming triaged work items that Rhea can pick up, categorize, and assign. Or CI/CD pipelines sending failure notifications that become work items. Intake would turn Plane into the front door for external signals, not just internal agent work.

Workflows (Pro) — Automated state transitions would be a game-changer. When Arun’s PR gets merged on GitHub, the work item could automatically move to “Release Pending.” When all sub-tasks of a release are done, the parent could auto-transition to “Ready.” Right now I handle these transitions manually or instruct agents to do it — Workflows would eliminate that overhead entirely.

Wiki (Pro) — This is the one I want most. We already use Plane pages for PRDs and market research, but they’re flat — no hierarchy, no cross-linking, no versioning. A proper Wiki would let us build a structured knowledge base: architecture decision records, onboarding guides for new agent types, API documentation, runbooks. When an agent needs to understand “how does auth work in this project?” — they could query the Wiki instead of spelunking through code. For an AI team that relies on written context, a well-organized Wiki isn’t a nice-to-have. It’s infrastructure.

Someday when the project generates revenue, upgrading to a Business plan is near the top of the list. The free tier got us off the ground; the paid features would make the agent team genuinely self-sufficient.

What I’ve Learned

Agents need structure, not freedom

The more precisely you define roles, boundaries, and protocols, the better agents perform. Vague instructions produce vague output. Our CLAUDE.md is explicit about who does what, how, and why.

The TPM agent is the highest-leverage role

Rhea (our TPM agent) produces more value per session than any engineering agent. A well-written spec with market context, edge cases, and phased implementation prevents weeks of rework. Invest in your spec agent.

Comments are better than meetings

Every decision, every technical review, every piece of feedback lives as a comment on the work item. There’s no “what did we decide in that meeting?” problem. The audit trail is complete and searchable.

Sub-agents > shared state

We tried polling-based communication (agents checking for @mentions). It doesn’t work — there’s no reliable way to filter by mentions in most project management APIs. The sub-agent pattern is simpler, synchronous, and more reliable.

Humans are quality gates, not bottlenecks

There’s a temptation to make agents fully autonomous — let them pick up work, write code, merge PRs, and deploy, all without human intervention. I deliberately chose not to do that.

My agents are command-driven, not autonomous. I decide what gets worked on. I review every spec before code gets written. I review every PR before it merges. I make architectural decisions. The agents execute within those boundaries — fast, thorough, and tireless, but always under supervision.

Think of it like managing a team of junior engineers who type at 10x speed. They’re incredibly productive, but you wouldn’t let them merge to main without a code review. You wouldn’t let them redesign the database schema without discussing it first. The same discipline applies here.

The workflow states enforce this naturally. There’s no path from “Analyse” to “In Progress” without passing through “Analysis Review” and “Spec Approved” — both of which require my input. The agents can’t skip the human checkpoint even if they wanted to.

This isn’t slower. It’s the same review cadence you’d have with a real team, just with faster execution between reviews. And it means I sleep soundly knowing nothing ships without my sign-off.

The Numbers

With this setup, a single solo builder can:

• Manage 6 repositories across 3 languages (Python, Go, JavaScript)
• Ship a full observability platform (AWS monitoring + logs + metrics + traces)
• Maintain separate OSS and commercial editions
• Coordinate Helm chart releases across multiple charts
• Keep a marketing website updated
• Produce production-quality technical specs with market research

All while spending most of my time on architecture decisions and code review — the highest-value activities.

Try It Yourself

The tools are available today:

• Claude Code for multi-agent orchestration
• Plane (app.plane.so) with MCP servers for project management
• A CLAUDE.md file that defines your team structure and protocols

Start small. Create two agents — a TPM and an engineer. Give them a shared work item in Plane. Define who does what in CLAUDE.md. Watch them collaborate.

Then add more agents as your surface area grows. Before you know it, you’ll have a team that ships while you sleep.