MKmknichel

Parallelize More With Passive Agents

May 31, 2026 · Mark Knichel

When coding agents first arrived, I thought it would be effortless to spin up an agent for every task that I can think of. I began spinning up agents for bug fixes, new features, technical debt cleanup, or any other random idea that I had. I expected agents to be able to complete the code and put up a mergeable pull request.

In reality, I created a massive headache for myself that left me overwhelmed and drained at the end of the day. Each agent would simultaneously ask me for high context decisions, throw out complex permission prompts, make a lot of mistakes, or go down paths where I had no idea what it was doing. Each agent needed attention, but my attention was maxed out. Juggling all of that left me stressed, and the tasks actually took longer than if I had just done one at a time manually. It wasn't working for me.

To save my sanity, I scaled back to just one or two active agent sessions at a time. That worked, but I couldn't help but think that there must be a better way to leverage agents.

The answer wasn't to run more tasks. It was to change how I scheduled the agents. I invested more work upfront in knowledge and plans to turn work into passive agent tasks. This helped improve my sanity, and it has made me a more productive engineer.

Managing multiple active agents drains your brain

Popular advice these days is that you can run a dozen agents at a time, leave them overnight, and they have solved all of your problems by the next day.

If you aren't running 12 agents that build three SaaS products while you're at the beach, you're going to be left behind. Here is how run an entire army of agents to do my work while I sleep…

  • @productivitymaxxer

In reality, while coding agents are incredible, they are not able to execute a full product on their own. They still need a person to guide them to the best solution. Managing multiple agents forces you to rapidly context switch and this results in a worse outcome.

In psychology, context switching has been shown to cause cognitive overload and severely degrade performance. A context switch can cost 200 milliseconds to several seconds per switch, depending on task complexity. Research shows that frequent switching between moderately complex engineering tasks causes a 25% to 40% drop in overall cognitive efficiency compared to sequential processing. Additionally, you can only manage 3-4 working memory slots at a time, so if you're using them with what's happening with one agent, you are dropping those slots for every other agent. You will forget items and miss important details, and start to stress yourself trying to stay on top of everything.

Parallelize passive agents, not active agents

To scale the number of agents without frying your brain, you need to change the types of tasks that you give agents at the same time. To avoid context switching and manage your cognitive load, you can divide agents into two types: Active and Passive.

Active Agents (high touch, low concurrency)

An active agent is one that requires your working memory slots to manage. The agent can't safely execute on its own because it doesn't have enough context or guardrails to make sure it completes the task correctly.

To manage an active agent, you must deeply understand the current state, monitor its progress, and constantly course correct. Because biology doesn't allow people to multi-task well, you can only manage 1-2 active agents at the same time. If you start any more, you will cross your cognitive threshold and overwhelm yourself.

Passive Agents (high concurrency, low touch)

A passive agent is one that can complete its task on its own with minimal oversight from you.

Passive agents have been frontloaded with all the correct information and constraints so that you don't have to babysit them. Think of a passive agent like a new software engineer: an active agent is one where they are off implementing on their own, while a passive agent is one where the design doc has already been approved by the TL and all the coding guidelines and test criteria have already been defined.

There are two primary ways that you can structure a passive agent:

  • Highly Defined Plan: You invest time upfront to build a rigorous plan of what needs to be done, how it will be tested, and when the agent knows it's done. Since the task is deterministic, you can let the agent chew through the plan and you'll know that it will get pretty close to what you are looking for.
  • Research and Information Gatherer: You assign an agent to exploring and consuming information without producing any specific artifact. Searching and analyzing content can take up a lot of time, but since it is read only, there is no blast radius. This is a very effective way to research how to implement a system, learn new codebases, or understand complex problems that require a lot of new knowledge.

Frontload work to turn active agents to passive ones

To convert an active agent into a passive one, you must decouple decision making phase from the execution phase.

Rather than interacting with an agent's choices in real time while it executes, you frontload all the planning ahead of time. You complete a "mindmeld" with the agent so that you are both on exactly the same page before a line of code is written. Spending 10 minutes to plan requires significantly less energy than babysitting an agent through an unguided entire implementation, and it eliminates the context switching and back and forth loops that drain you.

My Passive Workflow

I've restructured my workflow with coding agents to focus on these principles:

Maintain a long lived knowledge base directory.

  • Inspired by Andrej Karpathy's approach to personal knowledge curation, I maintain long lived research sessions that store everything in an ~/.agents/docs directory.
  • I extract information from code, Slack, Linear, Notion, and interactive chats.
  • Over time, this has become a highly knowledgeable and personal intelligence layer that informs a lot of what I learn and how I plan tasks.

Plan for multiple tasks at the same time

  • Instead of tackling tasks sequentially, I use the knowledge base and exploratory agent sessions to plan out entire projects at the same time.
  • Once the agent and I have agreed on what needs to be done, we discuss how to break it down into separable tasks and execution order so multiple features can be done simultaneously. Once this is solid, I use the Linear MCP to create all the issues for the entire project.
  • Since the agent has all the knowledge base knowledge, it can write highly detailed specifications so that agents with no context can pick up and implement the task correctly.

Set guardrails

  • To confidently let the agent run in the background without constant interaction, you have to make sure it has the right guardrails: what files it can modify, what permissions it has or doesn't have, and what verification it has to run to know if it's correct.

Reality check: passive tasks eventually become active

This workflow doesn't mean that you will never need to look at a passive agent. A task from a passive agent will eventually become an active task at some point.

  • The 95% polish (the tech lead review): Agents are very good at getting a feature to 90-95% of the way there. However, the last 5-10% still requires an expert review and polish pass to make sure it's correct. This requires an active working memory slot, so you must take time away from other active agents to engage on this.
  • Course Correction: Agents will eventually go off the rails, hit an environment issue, or discover new information that you need to take into account. When this happens, carve out time so that you can focus more deeply on this without being distracted by other active agents.

Conclusion

Making this sift has felt much better for me. By making a distinction between what requires active context and what can be made passive, I can focus much better. At the end of the day, I end up with more energy and less stress.

Investing in the knowledge base and spending time on planning hasn't just boosted productivity, but it's also made me a better engineer. It has forced me to design better systems ahead of time, anticipate problems before any code is written, and deeply understand our systems.

If you find yourself in this situation, try to scale back to one or two active threads and focus more on how you can utilize agents passively. Pay more upfront, and you'll get more in the long term.