I Was Tired of Juggling My Agents, So I Hired a Middle Manager

Here's a pattern I've seen many engineers fall into over the past few months. It starts innocently: you're working on a feature and have a few agents going. They are planning, reviewing, researching. You branch out. Now you've got agents on bugs from the backlog. You embrace git worktrees, tmux, background agents. You reach for things like the Codex app or Conductor to keep it all together.

And it works. You're shipping more code than ever. But at some point you notice where all your time is going: coordinating agents, sequencing work, checking output, nudging things along, telling an agent to open a PR. The actual coding is a solved problem.

Every engineer always: "standup is the worst part of my day"

Anthropic: "But what if instead of doing standup once, your entire day could be running standup with five claudes over and over and over"

— George Mayer (@GeorgeMayer) February 25, 2026

Then it hits you. You're not an IC anymore. You've become a manager. Your reports crank out code but don't offer much beyond that. Your brain is fried from context-switching across a dozen conversations. You need to hire a middle manager.

The Middle Manager

me juggling multiple claude codes

The vision is simple: I talk to one guy for each of my projects. I tell him what needs to be done and he manages the logistics. He's persistent. I onboard him once, tell him how I like to work, and he remembers across sessions. He lasts for days. His memory compacts over time, and he has a longer-term memory file he can reference. He gets better the longer he runs.

A manager is really an intelligent event bus. I describe what I want, rattle off a list of tasks, and the manager figures out how to dispatch them. It can hire workers, route messages between them, and parallelize where it makes sense. I can have it spawn a planning agent first, then break the plan into parallel work. Or I can just fire off a bunch of bug fixes and let it handle the rest. It surfaces the things that need my attention and takes care of things that don't.

What I Actually Built

I want to be honest here. You might be reading this and think I have Claude Code psychosis. If you squint, this looks like Steve Yegge's Gas Town, which I think is more art project than real engineering tool. But I aimed to build something a bit more restrained. You're still engineering, still reviewing, still responsible. You just have a management layer handling the dispatch. Think of it like having an agent that uses Conductor for you.

the management ui

What I ended up building looks a bit like this:

• A daemon that runs on my machine, tracks running agents, and facilitates message passing. It has an interface for managing different agent types (Codex / Pi) and tools that let agents talk to each other.
• A Conductor-style UI (forked from the defunct agent runner I worked on: terragon-oss).
• A manager agent built on top of Mario Zechner's wonderful pi. The manager can spawn workers and has a tool to message me directly. It's event-driven and never blocked, always ready for the next message.

When you first boot up, it asks you to onboard it (in the style of OpenClaw's hatching).

onboarding my manager

You proceed by telling them how you work, what they are working on, how you do things around here (like a real new employee). Congrats. You've just hired a middle manager.

My Managers

Up until this point things have been a little abstract. It might be illustrative to go over how I use my middle managers.

I have a middle manager for each project. The workflow I've onboarded them with looks like this:

• My main manager is Claude Opus (personality hire)
• Code changes and planning go to Codex workers
• UI-heavy work goes to an Opus worker
• All work happens in worktrees
• A dedicated "merger" agent merges changes, and workers notify it when they're ready
• Sometimes a reviewer agent gets involved before merging
• Long-running task TODOs are tracked in my Obsidian vault

A big benefit of this is I get to talk to my personality hire (Claude Opus) all day while Codex does the actual coding.

Parallelizing the Little Things

The killer part of this flow is how I prompt all of the little fixes while working on a project. I mostly just stream-of-thought into the middle manager via voice and dump a bunch of work on it at once. It breaks things up and spawns workers accordingly.

a vomit of work for the agent to figure out how to fix

From there I can either have a couple of PRs for myself to review when done or just ask them to be sent to the merger when done.

The Merge Queue

When vibe coding, the agentic merge queue is the real star of the show. Having a single serialization point where branches get merged, conflicts get resolved, and tests pass keeps agents from clobbering each other. This is my more sane approach to having a bunch of agents work on the same codebase.

Obsidian for Task Tracking

For bigger tasks, I work with the manager and a planning agent to draft a TODO list with dependencies, stored in Obsidian. Both the agent and I can track progress. I can look at the file, edit it to steer things, and the agent updates it as work completes. I really like bringing your own task management to agents rather than some bespoke system. It makes the whole process more legible.

Obsidian keeping track of my todos

Vibe Coding vs. Production

This workflow really shines for vibe coding. I've mostly moved to it for side projects where I care more about getting the thing working than about code quality. I'm constantly chatting with my manager about some side project while doing other work. For example, I used it to build a clone of wisprflow that supports ChatGPT OAuth when my wisprflow sub ran out.

There was a feedback loop where I would use my transcription app and when I ran into new features I would send them to my manager and it would constantly build and install the new version to my applications directory.

This is a project I probably wouldn't have even attempted if I wasn't able to make this process as seamless as I did. It truly felt like I had hired a team of contractors to implement this for me.

my vibe coded wisprflow

There's a real tradeoff here: you're ceding control to the model. If you want to review every line of code, that bottleneck will eat any management efficiency gains. In this way it is also like hiring a team of contractors. It can be hard to control for code quality.

For my production projects (ones with paying customers), I've been experimenting with using this flow for small fixes. I keep a daily branch, let agents fork off it and merge back in, and do one big manual review at the end of the day before merging to main.

Where Is This All Going?

i imagine the next breakout coding product is something that sticks a single orchestrator you talk with in front of cloud, parallel agents.

it's too mentally taxing to keep a high # of parallel agents in the air by yourself. plus brutal merge conflicts.

— Vincent van der Meulen (@vincentmvdm) February 26, 2026

I have no doubt this is closer to what agentic development environments will look like in a couple months from now. A persistent manager that knows the codebase, the product, the ongoing work, the future plans, and handles the grunt work of dispatching agents. We should be more focused on the actual work being done instead of the meta-work of managing parallel agents.

I'm not convinced that this workflow is 100% production ready yet. We might need to wait for the next generation of models for this to really click. That being said, I recommend that everyone vibe code their own workflow like this and give it their own spin. It really helps you grapple with the chaos of micromanaging multiple agents and worry more about the what of building instead of the how. Granted there is a time and place for each, but using this workflow was eye-opening to me. I truly felt more like a software gardener than engineer. I was planting a seed, watering, and pruning my project and watching it grow.

If it is helpful, you can check out my version of it here.