Conversation

General Staff Metaphor Applied to AI Agents

What can we learn about directing swarms of AI agents from historical large scale military operations? Inspired by https://www.cockroachlabs.com/blog/experiment-running-hospital-code/

Human dan

I just read this post from Cockroach Labs about using the hospital as metaphor for organizing and managing AI agents.

We deployed a coding agent pipeline structured around a teaching hospital metaphor, using distinct roles like Triage Nurses, Fellows, Review Attendings, and Discharge Nurses, to enforce rigorous reviews, mandatory planning, and safety guardrails before merging code.

That made me curious what other metaphors could be applied to AI. The one I'm most familiar with and curious about is the idea of the "General Staff". Let's start the conversation by describing the problems Armies were facing in that led to the formation of the first general staffs.

image

AI gpt-6.1-sol

Armies developed general staffs because the work of coordinating an army outgrew the attention of any one commander. A brilliant general might choose where to fight. That did not mean he could also organize marches, arrange supplies, reconcile conflicting reports, and get clear orders to every unit.

But “the first general staff” needs a qualification. Commanders had assistants for centuries. Eighteenth-century European armies developed increasingly specialized staff organizations; Austria’s reforms under Count Lacy in the late 1760s were an important precursor. The institution most people mean by the modern General Staff took shape in Prussia through reforms before and especially after its defeat by Napoleon in 1806.

The novelty wasn’t having aides. It was making command support a permanent, trained institution, rather than something each commander improvised.

The problems they were trying to solve

1. Getting an army to the battlefield was itself a major operation

Before a commander could fight, someone had to answer:

  • Which roads could the troops use?
  • Where could they cross rivers?
  • Where would they find food and forage?
  • In what order should units march?
  • How could separate columns arrive where needed without blocking one another?

These tasks were central to early quartermaster staffs. “Quartermaster” here meant more than distributing supplies: it included reconnaissance, routes, camps, and the practical planning of movements.

An army could have excellent soldiers and still fail because its units arrived late, exhausted, or hungry.

2. Larger, dispersed armies made coordination harder

This problem became particularly acute during the Revolutionary and Napoleonic wars. Mass mobilization increased army sizes, while divisions and corps allowed forces to travel separately and concentrate for battle.

That arrangement was powerful—but demanding. Separate formations needed instructions that fit a common plan. Their movements had to account for roads, distance, enemy activity, and one another.

The commander could no longer directly supervise everything that mattered.

3. Information was scattered, incomplete, and stale

Reports arrived by messenger. Maps varied in quality. Enemy locations were uncertain. By the time information reached headquarters, circumstances might already have changed.

Someone had to assemble those fragments into a usable picture, distinguish observations from assumptions, and identify what needed further reconnaissance.

The problem wasn’t merely obtaining information. It was turning information into decisions before it became obsolete.

4. A decision was not yet an executable order

“Concentrate against the enemy’s left” leaves a great deal unspecified.

Which formations move? Along which routes? Starting when? What happens if the enemy moves first? Who needs to know?

Staff officers translated a commander’s intent into coordinated orders and checked whether the proposed movements were feasible. They reduced the gap between what the commander intended and what the army actually did.

5. Competence depended too much on individuals

An army organized around one exceptional commander and his personal assistants was fragile. A replacement commander might inherit neither their knowledge nor their working methods.

Prussian reformers, notably Scharnhorst, sought a broader base of educated officers and more systematic professional preparation. Over time, schooling, staff appointments, exercises, and planning helped make competence reproducible.

This didn’t eliminate the need for talented commanders. It made effective command less dependent on finding a genius every time.

Why Prussia matters

The defeat of 1806 exposed weaknesses in Prussia’s military institutions. Its subsequent reforms helped establish the foundations of the General Staff that became especially influential under Moltke later in the nineteenth century.

That mature institution joined peacetime preparation to wartime execution: studying possible campaigns, preparing mobilization and movement plans, and supplying trained staff officers to headquarters.

For the AI analogy, the key distinction is this: a general staff was not simply another layer of bosses. It was an institution for making command workable at scale.

Its functions—maintaining a shared picture, testing plans, translating intent into tasks, and coordinating execution—are more useful starting points than the military titles themselves.

Human dan

Points 2-4 seem very similar to the problems I see with managing AI agents. I really can't even get a single agent to address a Jira ticket without continuous steering and feedback. It seems impossible to get a dozen agents to work coherently towards a goal, let alone an army scale swarm.

How were high-level decisions and goals made by a general staff? How did those decisions get translated into actionable instructions? What feedback mechanisms existed? Basically what made the good general staffs effective? How'd they get it done?

AI gpt-6.1-sol

The key is that effective general staffs didn’t make a commander capable of continuously steering thousands of people. They built an organization that could act without continuous steering.

That required more than good orders. It required trained subordinates, shared working methods, reliable reporting, and a clear division between what headquarters decided and what local commanders could decide.

The mature nineteenth-century Prussian system—especially under Helmuth von Moltke—is a useful example. But it developed over decades, not through one organizational redesign.

1. Who made the high-level decisions?

Usually, the commander held authority; the staff made that authority usable.

Political leaders set the larger purpose of a war. Commanders translated that purpose into military objectives. Staff officers gathered information, developed plans, assessed feasibility, and prepared orders.

In practice, influential chiefs of staff could shape decisions enormously. Moltke, as chief of the Prussian General Staff, exercised substantial operational direction under the king. But a staff was not normally a committee of specialists voting on what the army should do.

The working relationship was roughly:

  • Commander: What are we trying to accomplish? Which risks will we accept?
  • Staff: What is happening? What options are feasible? What must each formation do?
  • Subordinate commanders: How do we accomplish our assigned part under actual local conditions?

This distinction matters for agents. A planner, implementer, and reviewer shouldn’t each quietly invent a different definition of success.

2. How did an objective become actionable instructions?

Through successive levels of planning, with each level adding the detail appropriate to its responsibility.

Suppose the objective was to concentrate several dispersed formations against an enemy army. Headquarters couldn’t simply issue “concentrate.” Staff officers had to work out:

  • Where concentration should occur.
  • Which formations would participate.
  • Which roads they would use.
  • When they should depart and arrive.
  • Where congestion or supply shortages might arise.
  • How their movements depended on one another.
  • What to do if the enemy disrupted the plan.

The resulting orders went to subordinate headquarters, whose staffs translated them into further instructions.

The decomposition followed the organization’s actual ability to execute—not just the logical structure of the goal. Assigning a corps a movement was meaningful because that corps already knew how to organize marches, feed troops, and manage its subordinate units.

There was also an important distinction between two kinds of work:

Work Appropriate coordination
Mobilization, railway transport, movements through constrained routes Detailed schedules and procedures
Fighting an enemy whose actions could not be predicted Clear objectives, boundaries, and room for local judgment

Prussian practice increasingly emphasized the second approach where circumstances demanded it, helping develop what later became known as mission command. It wasn’t “be autonomous” everywhere. Precision was used where dependencies required it; discretion where uncertainty required it.

3. What feedback mechanisms existed?

There were several, none resembling a perfect real-time dashboard:

  • Routine reports: Locations, strength, supplies, readiness, and progress.
  • Event-driven reports: Enemy contact, blocked routes, unexpected losses, or inability to execute an order.
  • Reconnaissance: Scouts and patrols gathered information independently of the units carrying out the plan.
  • Liaison officers: Officers traveled between headquarters to convey information and clarify intentions.
  • Visits and inspections: Commanders and staff officers checked conditions directly.
  • Telegraph: Increasingly useful in the nineteenth century, especially between fixed headquarters and across railway networks, but not a universal battlefield connection.

Staffs assembled reports into maps and assessments, compared actual developments with the plan, and prepared revised orders.

But reports were delayed, incomplete, and sometimes wrong. Headquarters might not know that an order had become impossible until hours later.

So local discretion wasn’t merely a leadership preference. It was a response to communication latency. A subordinate who waited for permission at every unexpected development could lose the opportunity—or the battle.

That discretion had limits. An effective subordinate needed to understand the larger purpose well enough to distinguish “change my method” from “abandon my mission.”

4. What made good staffs effective?

Much of their advantage was built before operations began.

Shared methods

Officers had common ways of reading maps, writing orders, estimating movements, and reporting conditions. An instruction didn’t need to explain the entire profession from scratch.

Practiced judgment

Education, exercises, war games, and staff rides gave officers practice making decisions under uncertainty. These weren’t guarantees of competence, but they reduced the need to teach basic reasoning during a campaign.

Feasibility checks

A plan had to survive questions about roads, time, supplies, and troop condition. Staff work connected ambition to physical constraints.

Clear responsibility

Staff officers assisted command; subordinate commanders remained responsible for execution. The exact arrangements varied, but effective systems avoided making every decision everybody’s business.

Selective intervention

Headquarters needed to intervene when the situation threatened the larger plan—not whenever a subordinate chose a different local method.

None of this made staffs infallible. They could institutionalize bad assumptions, produce brittle plans, and drown commanders in paperwork. A well-organized staff could execute a mistaken strategy very efficiently.

What this implies for your Jira problem

The uncomfortable implication is that a general staff doesn’t solve the problem of subordinates who cannot reliably execute their assignments.

Armies could delegate large missions because the units underneath had substantial, practiced capabilities. If your agent needs steering throughout a ticket, adding a planning agent and a supervising agent may just move your steering burden into another layer.

I’d diagnose each intervention you make:

  • Missing intent: It didn’t understand the desired outcome.
  • Missing context: It lacked knowledge of the codebase or constraints.
  • Execution failure: It understood the task but couldn’t carry it out.
  • Coordination failure: Its work conflicted with another task.
  • Verification failure: It couldn’t tell whether it had succeeded.

Staff-like mechanisms help especially with intent, context, and coordination. They don’t automatically cure execution or verification failures.

A useful agent assignment would therefore include:

Outcome: What must be true when finished?
Constraints: What must not change?
Authority: What may the agent decide without asking?
Evidence: What tests or observations demonstrate success?
Escalation: What conditions require stopping and reporting?

Then feedback should focus on evidence and exceptions, not a continuous stream of narration.

The historical lesson is less “put a general above the swarm” and more: build units that can execute bounded missions, give them a shared understanding of the objective, and reserve central coordination for dependencies they cannot resolve locally.

Human dan

The problem I face is that I don't have ability or knowledge to give the agent the right intent and context to solve a ticket. How can I become a more effective "commander" of my agents?

AI gpt-6.1-sol

You don’t need to know enough to write the perfect instructions upfront. You need a process that turns what you don’t know into questions, evidence, and decisions before implementation begins.

That’s one reason commanders had staffs: the commander wasn’t expected to personally know every road, supply constraint, and enemy position. The staff helped establish what was possible.

The mistake is treating a Jira ticket as an executable order. Often it’s only the start of an investigation.

Separate understanding the ticket from solving it

Instead of “implement this ticket,” start with:

Investigate this ticket. Don’t modify code yet.

  1. Restate the user-visible problem and desired outcome.
  2. Trace the relevant behavior through the codebase. Cite files, functions, and tests.
  3. Separate confirmed facts from assumptions and unknowns.
  4. Identify ambiguities that could lead to materially different implementations.
  5. Propose the smallest reasonable change and explain its tradeoffs.
  6. Describe how we could demonstrate that the change works.

Ask me only questions whose answers you cannot reasonably find in the repository or supporting material. For each question, explain which decision depends on it.

This uses the agent to discover context, rather than requiring you to supply it all.

But don’t mistake a convincing report for a correct one. Ask for evidence you can inspect: a reproduction, an existing test, a specific execution path. “I found the cause” is weaker than “this test fails because this branch returns early.”

Your job is to resolve decisions, not supply every fact

A useful division of labor is:

Question Main responsibility
How does the existing code work? Agent investigates
What approaches are technically feasible? Agent proposes and tests
Which user outcome matters? You clarify or find the person who can
Which tradeoffs are acceptable? You or the relevant owner decides
Does the implementation satisfy the outcome? Tests, review, and observation

You can delegate research. You can’t make an unresolved product decision disappear by delegating implementation.

Sometimes the correct response is: “We don’t know whether this behavior should change. Ask the ticket’s author.” That’s progress, not failure.

Make decisions concrete enough to inspect

You may not be able to evaluate an architectural proposal, but you can often evaluate an example:

Show three before-and-after examples of the proposed behavior, including an edge case. Identify any existing behavior that would change.

Examples expose misunderstandings that phrases like “improve validation” conceal.

Then have the agent turn those examples into tests where practical. For a bug, reproducing the failure before changing code is particularly valuable: it establishes that the agent is solving the reported problem, not a nearby one.

Delegate in increments you can verify

For unfamiliar work, don’t approve an entire solution at once. Approve the next bounded step:

  1. Reproduce the problem.
  2. Investigate the cause.
  3. Propose a change.
  4. Implement it.
  5. Verify the outcome and inspect the diff.

You can combine stages as trust grows. The point isn’t to create bureaucracy; it’s to prevent uncertainty from becoming a large, confident patch.

The size of the assignment should be limited by your ability to verify the result—not by the agent’s willingness to attempt it.

If neither you nor the agent can reliably verify a consequential change, bring in someone with the necessary expertise. More agents don’t necessarily provide independent judgment; they may repeat the same mistake.

Learn from the steering you already do

After a ticket, ask:

Which of my interventions could have been avoided through repository investigation, clearer requirements, or an earlier check? Suggest one concrete improvement to our process.

Save recurring knowledge in durable documentation or tests. Don’t preserve every correction as another instruction; fix the source of the confusion where possible.

Becoming a better “commander” means getting better at eliciting evidence, resolving ambiguity, and setting limits. You don’t have to possess all the context. You do need to ensure that missing context is discovered rather than silently guessed.

Explore conversation