The Multi-Threaded Operator
How to govern agent work without losing judgment
If agents are eating the org chart, the next question is who becomes more valuable inside the new one. The answer is not the person who generates the most output. It is the person who can govern many streams of execution and still own the decision.
The argument
Section titled “The argument”The first mistake is opening five AI windows and calling it leverage. That is parallel guessing.
The scarce skill is not prompting. It is governing many execution threads without losing judgment.
A Multi-Threaded Operator starts with the decision, runs the pre-mortem, decomposes the work, routes tasks, manages concurrency, verifies outputs, synthesizes results, and owns the commitment.
Agents make execution abundant. Operators make it useful. The reason this matters is that agents do not fail evenly: some outputs are useful, some are wrong, and the dangerous ones are often polished enough to travel downstream.
The future belongs to barrels who can become multi-threaded without losing judgment.
The question changed
Section titled “The question changed”The old productivity question was simple: how much can one person do?
That question still matters, but it is no longer enough. The better question is: how much execution can one person responsibly govern?
The word responsibly does most of the work. Anyone can generate drafts, summaries, tests, tickets, mockups, research notes, and dashboards. That is not the scarce skill. The scarce skill is turning a real objective into coordinated streams of work, then deciding what is allowed to become real.
A Multi-Threaded Operator (MTO for short) is not a multitasker. Multitasking is usually task switching with better branding. The operator designs the work system. They know which parts can run in parallel, which parts need domain review, which outputs can be trusted, and which decisions should stay slow.
Taste is part of judgment, but not a substitute for it. The operator needs taste, domain knowledge, skepticism, and ownership.
From barrel to multi-threaded barrel
Section titled “From barrel to multi-threaded barrel”Keith Rabois has a useful metaphor for company velocity: barrels and ammunition. In his framing, a company can add ammunition, but the number of important things it can do at once is constrained by the number of barrels. A barrel is the person who can take an idea from conception to live, pull people with them, and operate with enough autonomy that the company gets another real line of force [1].
AI changes the metaphor. Agents make ammunition abundant: drafts, research, test scaffolds, summaries, variants, and first-pass analysis. That makes barrels more important, not less.
When execution becomes abundant, the barrel’s job gets harder: decide which targets matter, launch multiple streams of work, keep those streams from contaminating each other, verify the outputs, and own the final commitment. The old barrel could drive one initiative from idea to shipped outcome. The Multi-Threaded Operator can govern several execution streams without losing judgment.
That is the AI-era upgrade: not more prompting, but more governed throughput.
The handoff changes
Section titled “The handoff changes”I have started to notice this in my own work.
Over the last month, I have been writing more embedded software and chip-design-related code myself with agents. Not because I want to replace the people who own those domains. I do not. The leads still have the judgment. They still know which assumptions are dangerous, which details are being hand-waved, and what can actually survive review.
What changed is the handoff. The old version was to take a rough idea to a team member and ask them to explore it. With agents, I can often do the messy first pass myself: write a rough implementation, test a small path, sketch the design, identify assumptions, and find where the idea breaks.
Then I go to the relevant lead with something more useful than a prompt for exploration. I bring an artifact: here is what I tried, here is what failed, here is what I think might be true, and here is what I need you to check.
This is not delegation disappearing. It is delegation moving up the stack. That is what agentic leverage looks like when it is working: not fewer experts, but better use of experts.
Start with the decision, then run the pre-mortem
Section titled “Start with the decision, then run the pre-mortem”The operator’s job is not to write clever prompts. The operator’s job is to design a loop: decision, context, pre-mortem, decomposition, routing, execution, verification, synthesis, and commitment.
Most bad agent workflows begin with an artifact request: write this memo, analyze this market, generate this code, summarize these calls. Those requests can be useful, but they are not where the work should start.
The operator starts with the decision. “Analyze this market” is not a real objective. “Decide whether we should enter this market in the next 12 months, given our distribution, gross margin target, regulatory exposure, and current team capacity” is closer. The difference is not polish. It is direction.
Then the operator runs the pre-mortem.
Assume this failed. What killed it?
A pre-mortem is not pessimism. It is architecture. Before launching threads, the operator imagines that the project, design, deployment, or recommendation has already failed, then works backward to identify the plausible causes. Gary Klein popularized this method as a way to surface risks before a project is already committed [2].
For embedded software, maybe the failure is a timing edge case, reset path, undefined state, sensor assumption, or rollback problem. For chip design, maybe the setup assumed ideal conditions, ignored package parasitics, missed process corners, or under-modeled layout coupling. For a funding conversation, maybe the market-size claim is fragile or the model hides the assumption investors will attack.
The pre-mortem tells the operator which threads to launch, which risks to test, which experts to pull in early, and which outputs should never become inputs without a gate. Without it, agents will still produce memos, tables, risks, and summaries. The organization will feel busy.
But busy is not the same as closer to a decision.
Decompose, route, and manage concurrency
Section titled “Decompose, route, and manage concurrency”After the pre-mortem, the operator breaks the work apart around the risks that matter. For product, that might mean customer evidence, usage data, technical feasibility, pricing, launch risk, and support impact. For code, it might mean repository context, dependencies, implementation plan, tests, edge cases, documentation, and rollback. For hardware, it might mean design exploration, constraints, simulation setup, verification artifacts, compliance review, and signoff.
The point is not to create more steps. It is to expose the shape of the work and place risk where someone can see it.
Then comes routing. Not every task belongs with an agent. A model is useful for language, synthesis, exploration, critique, and first-pass structure. A script is better when the task is deterministic. A database is better when the question needs ground truth from records. A simulator is better when the claim has to survive physics. A human expert is better when the output depends on tacit knowledge, taste, liability, customer trust, or irreversible commitment.
The novice asks: can AI do this?
The operator asks: what is the cheapest reliable way to get this part of the work to the required standard?
Cheap but unreliable is not cheap. It is deferred cleanup.
The operator also manages a concurrency budget. Parallel execution increases throughput, but it also increases review load. Every additional thread creates another stream of assumptions, outputs, and possible errors. At some point, the operator stops supervising the work and starts skimming it.
The right question is not: how many threads can I launch?
The right question is: how many threads can I review properly?
For low-risk exploration, run more threads. For high-risk commitment, reduce concurrency. Bring the expert closer. Make the checks explicit. Slow down before the output becomes real.
Verify before outputs become inputs
Section titled “Verify before outputs become inputs”Verification is the center of the work.
This is the part people underestimate because the output often looks finished. A weak assumption enters upstream. An agent expands it into a spreadsheet. Another turns the spreadsheet into a memo. Another turns the memo into a recommendation. The recommendation becomes a meeting note. The meeting note becomes a decision.
By the time someone questions the original assumption, the organization has already built on top of it.
This is the failure mode: error propagation.
The operator places gates before outputs become inputs. A verification gate asks: what must be true for this output to be valid? Where did the data come from? Which assumptions are carrying the conclusion? What would an expert object to? What edge case breaks this? What source would disconfirm it? What part sounds persuasive but has not been proven?
Verification is not asking another model, “Is this right?” That can help, but it is not enough. Verification means knowing the domain well enough to identify what has to be checked.
If you cannot verify the work, you cannot responsibly govern the workflow. You are not operating. You are outsourcing belief.
In an RF review, an agent might rank a candidate block first because the simulated response looks clean under ideal source and load assumptions. The table is polished. The plot is persuasive. But the operator checks the setup before that output becomes an input to signoff. Was the target impedance environment actually used? Were package parasitics included? Were the right process corners swept? Were layout coupling effects modeled, or merely assumed away?
If the answer is no, the candidate does not advance. The agent optimized inside the wrong boundary. The gate catches that before the mistake becomes downstream consensus.
Synthesize, do not average
Section titled “Synthesize, do not average”Parallel work creates many outputs. Most people summarize them. Operators synthesize them.
A summary says: here is what each thread produced.
A synthesis says: here is what we now believe, here is what changed, here is what remains uncertain, and here is the decision this supports.
Agents are good at producing more surface area: more options, more drafts, more risks, more objections, more variants. The operator has to compress that surface area into a decision.
Not every thread deserves equal weight. The customer evidence may matter more than the competitive scan. The simulation may overrule the brainstorm. The legal constraint may kill the clever idea. The expert review may invalidate three polished outputs.
Synthesis is not democratic. It is weighted judgment.
Mechanically, the operator does not need a complicated scoring system. A simple decision ledger is enough: claim, source, confidence, decision weight, failure mode, reviewer, and status. The point is not to make judgment mathematical. The point is to make authority visible.
If the operator cannot explain why one output had authority and another did not, they have summarized the work, not synthesized it.
Three modes of agent work
Section titled “Three modes of agent work”Most failures happen because people use the same level of trust for different kinds of work. Operators separate agent work into three modes: exploration, draft, and commitment.
| Mode | Purpose | Rule |
|---|---|---|
| Exploration | Generate candidates, variants, objections, hypotheses, and failure modes | Do not commit |
| Draft | Turn direction into artifacts: memos, specs, tests, plans, review checklists | Mark status clearly |
| Commitment | Make work real: ship, sign off, send, merge, fund, freeze, or promise | Reduce concurrency and verify assumptions |
Exploration is where agents shine. The goal is search, not truth. Draft mode is useful because the blank page is expensive, but a draft can look more complete than the underlying thinking. Commitment mode is where the standards change.
The operator should mark outputs with their status: unverified, partially checked, ready for expert review, or ready to commit. Without those labels, teams confuse polish with readiness.
Fast exploration is good. Fast commitment is how you get hurt.
A design review makes this concrete
Section titled “A design review makes this concrete”Software can hide bad judgment for a while. Hardware invoices it.
That is why chip design is the cleanest place to understand the Multi-Threaded Operator. A bad memo can be rewritten. A bad slide can be deleted. A bad prototype can be abandoned. A bad chip comes back from the fab as physical evidence that the workflow failed.
Deep-learning inverse design has shown that certain RF and sub-THz design workflows can move from manual, template-driven iteration toward minute-scale synthesis, opening up design spaces that traditional approaches had difficulty reaching [3].
Imagine a design lead evaluating six candidate RF blocks before a review. The weak version is simple: ask an agent to summarize the options, ask another to draft a review doc, ask a third to make the slides, and walk into the meeting with more material than before.
That is not operating. That is decoration.
The operator version is different. One thread summarizes the target constraints. A second compares candidate topologies. A third prepares the simulation plan: which corners matter, which parasitics need extraction, which electromagnetic effects cannot be hand-waved, and which measurement assumptions are being smuggled in. A fourth drafts a failure-mode checklist. A fifth prepares the review artifact, explicitly marked as draft mode.
Then the operator starts killing work. Two candidates die because the assumptions do not survive the first gate. One is held for more simulation because the performance depends on a fragile condition. Two go forward as exploration paths. One becomes the proposed direction, but only after the operator traces the assumptions, checks the simulation setup, and gets expert review on the risks that matter.
The agents produced useful work. They did not own the design. They did not own signoff. They did not decide what becomes silicon.
The operator did.
That is the pattern: exploration can be parallel. Commitment needs ownership.
The decision log
Section titled “The decision log”The decision log is where speed turns into organizational memory.
Every important workflow should end with a short record: what we decided, who owns it, what evidence mattered, what assumptions we are relying on, what failure modes we anticipated, what would make us revisit the decision, what was machine-generated, and what was human-verified.
The decision log does not need to be long. In practice, one page is often enough. The point is memory and accountability. When an agent-assisted workflow moves quickly, teams remember the output but forget the assumptions. A polished memo becomes a recommendation. The recommendation becomes consensus. Consensus becomes “what we decided,” even if no one can reconstruct why.
A decision log interrupts that drift. It preserves the reasoning before it gets laundered into confidence.
The career implication
Section titled “The career implication”The person who only completes tasks will compete with agents. The person who governs agents can compound through them.
The junior analyst who only makes first drafts is exposed. The analyst who frames the question, pressure-tests assumptions, and identifies the decision becomes more valuable.
The engineer who only implements tickets is exposed. The engineer who maps the system, evaluates generated code, catches edge cases, and owns the production outcome becomes more valuable.
The manager who only asks for status is exposed. The manager who defines priorities, removes handoffs, sets review gates, and makes accountable decisions becomes more valuable.
The operator’s advantage is not that they work more hours. It is that they turn judgment into a system.
The future belongs to barrels who can become multi-threaded without becoming careless.
What the operator knows
Section titled “What the operator knows”The operator is not the person with the busiest dashboard. The operator is the person who knows what should run, what should stop, and what should never leave human hands.
Agents can execute.
The operator decides what execution is allowed to become.
That is the scarce skill.
Related
Section titled “Related”This essay is the individual-level companion to Agents Are Eating the Org Chart. That essay argues that agents are changing the structure of companies. This one argues that the scarce person inside that structure is the operator who can govern execution without losing judgment.
References
Section titled “References”[1] Keith Rabois on the Role of a COO, How to Hire and Why Transparency Matters https://review.firstround.com/keith-rabois-on-the-role-of-a-coo-how-to-hire-and-why-transparency-matters/
[2] Performing a Project Premortem https://hbr.org/2007/09/performing-a-project-premortem
[3] Deep-learning enabled generalized inverse design of multi-port radio-frequency and sub-terahertz passives and integrated circuits https://www.nature.com/articles/s41467-024-54178-1