I wrote that AI isn’t the bottleneck anymore, your brain is. This is the practical follow-up: the rules I actually use to run around ten AI agents in parallel without my attention becoming the traffic jam.

The setup

On a normal day, a lot of work happens that I don’t do myself:

  • Coding agents (Claude Code and Codex) implement features and fixes in parallel, each in its own isolated copy of the codebase.
  • Scheduled jobs run overnight: checking on in-flight work, preparing briefs, flagging what changed.
  • Research and writing agents draft comparisons, summarize sources and prep documents.

On a busy day that’s about ten streams of work moving at once. The output problem is solved. What isn’t solved, by default, is that every one of those streams ends by coming back to me.

The first time I tried to keep up with all of it, I failed in an instructive way.

Rule 1: one screen in the morning, sorted by what needs me

My first morning catch-up was a complete, chronological report of everything every agent did overnight. It was accurate. It was also useless: a wall of “this ran, then this happened” that scattered my attention before the day had started.

So I rewrote the rule. The morning digest is not a report of what happened. Its only job is to spend my first, narrowest window of attention on what matters most. It fits on one screen, hard cap, and everything goes into exactly three buckets:

  • Today: things that expire or have a slot today. A meeting to prep for, a deadline.
  • Decide: decisions only I can make, each written as one line with a suggested default and the cost of taking it, so I can answer the whole queue in one reply.
  • FYI: everything else, in a single line. Not a smaller paragraph. One line.

Anything that doesn’t fit is withheld until I ask. That last part felt wrong at first. It turned out to be the most important part.

Rule 2: separate direction from doing

The tempting failure with good AI is to let it do everything, including deciding what to do. I split the roles instead:

  • I set direction: what we’re building, why, and what “done” means.
  • One agent directs and reviews. It scopes the work, writes a clear brief, and then reviews the result strictly: reads the actual changes, reruns the checks, verifies claims instead of trusting summaries.
  • Another agent implements from that brief.

Implementation is cheap now. Judgment isn’t, so judgment is what I protect, both mine and the reviewer’s.

Rule 3: every handback is a contract

Agents finishing silently is worse than agents not finishing. A crashed run or a plan stranded in a chat log is work that looks done and isn’t.

So every piece of agent work has to hand back in the same shape: what was done, the evidence (a pull request, a test result), and the one thing it needs from me, written as a request, not a log. “Fixed the bug, tests pass, please just review the diff” beats three paragraphs of what it tried.

All of it lands in Sharick, so the morning digest reads from a single queue instead of from ten different tools.

Rule 4: batch, don’t trickle

Five small approvals spread across an afternoon cost five context switches. The same five in one pass over coffee cost one.

Two habits make batching work:

  • Agents hold until something is settled. No pushing half-finished work for review, no “quick question” pings for things that can wait for the next pass.
  • Once something is handed off, it’s frozen. If I’ve been asked to review something, the agent doesn’t keep changing it underneath me. Follow-up work starts fresh. I enforce this mechanically, not by memory, because I’ve been burned by changes landing on something I’d already approved.

Rule 5: know what never gets delegated

Some things come back to me because they should:

  • Direction: is this the right thing to build at all?
  • Relationships: anything a real person will read in my name.
  • Money and commitments: anything irreversible.
  • Taste: whether it’s actually good, not just finished.

The goal isn’t to remove myself from the loop. It’s to make sure that when the loop reaches me, it’s for one of these.

What still breaks

This system is better than what I had, not solved.

  • Things go stale quietly. A finished piece of work waits for review, the world moves, and by the time I look, it needs redoing.
  • Context reloads still hurt. Even a perfect one-line decision needs me to remember why the work exists. The better the context attached to the decision, the cheaper this gets, but it’s never free.
  • Silence is hard to see. The digest is good at showing what came back. It’s worse at showing what should have come back and didn’t.

That last one is the frontier. An assistant that notices absence, the reply that never came, the job that stopped reporting, is what I mean by attentive.

Why I’m building Sharick

Everything above started as my own duct tape: a file of rules, a morning routine, a handback format. Sharick is the version of that I want for everyone running more agents than they can personally watch: one place that holds the context, sorts what comes back into today, decide and FYI, and routes my decisions back out.