When the Workers Stop Being Human

In this article

1. The stand-up was the first clue
2. Then I realized I had made another assumption
3. Going back to SAFe with a different question
4. The analogy also started fighting back
5. I also had to admit that computer science was here first
6. The strangest inversion came from teams
7. A production example made the argument less abstract
8. I tried the same lens outside SAFe
9. The labels are less important than the mistakes they prevent
10. Which parts should actually become executable?
11. Back to the original diagram
12. References

A few weeks ago I was looking at one more diagram of a multi-agent AI system. There was a planner in the middle, several specialist agents around it, an evaluator, an orchestrator and, somewhere near the edge, a human approval step. Nothing particularly exotic anymore, but I caught myself staring at the picture longer than I expected because the structure felt familiar. One component decided what needed to happen, others specialized, another coordinated, someone checked the result, and somewhere there was a boundary beyond which the system was no longer allowed to proceed on its own. I had seen that logic many times before, just not in AI.

My first reaction was basically: this looks like SAFe. I have spent enough time around large transformation programs to recognize the pattern. Product decisions sit in one place, technical direction in another, teams do the work, somebody coordinates across them, integrated reviews make sure the pieces still fit, and governance determines what can proceed without escalation. Human organizations have spent decades trying to coordinate lots of people who each see only part of the picture, and AI agents suddenly seemed to have a version of the same problem.

For a moment I thought the article had almost written itself. Take a familiar enterprise operating model, map the roles and see what happens: Product Owner becomes Product Agent, System Architect becomes Architecture Agent, RTE becomes Orchestrator, Scrum Master becomes some kind of Flow Agent. It was neat, familiar and, as it turned out, much too easy. Then I started researching it, and the simple version collapsed almost immediately. There are already direct attempts to run SAFe with AI agents.¹ Researchers have been borrowing from human organizational design for multi-agent systems for more than twenty years.² Current work is already turning concepts such as organizational roles, accountability and coordination protocols into machine-readable configuration,³ while other teams are training orchestration itself so that the coordinator can choose workers, context and communication patterns dynamically instead of following a fixed human-designed structure.⁴

That changed the article for me. The interesting discovery was not that organizational design could be applied to agents; that was already happening. What surprised me was that I had started with the wrong question. I went in asking how much of SAFe could be transferred to AI agents and came out asking why I was assuming that the framework should transfer at all. Human organizations are not clean designs. They contain useful solutions to real coordination problems, but they also contain workarounds for human memory, psychology, calendars, politics, fatigue and decades of organizational history. If we start turning operating models into software without separating those things, we may automate the baggage together with the useful parts.

The stand-up was the first clue

The daily stand-up was the example that made the problem obvious. If I ask whether an AI agent needs a daily stand-up, the answer is almost comically easy: of course not. The agent does not need to stand in a circle every morning and explain what it did yesterday. But the meeting itself was never the important part. Underneath it is a coordination need: the actors need enough visibility into each other's state to detect blockers, resolve dependencies and notice when their plans are drifting apart. Changing the actor from a person to software removes the meeting, but it does not automatically remove the need for synchronization.

Once I looked at the stand-up that way, the same distinction started showing up almost everywhere. An architecture review may happen in a meeting, but its deeper purpose is technical coherence and an independent decision boundary. A steering committee may be a calendar event, but underneath it sits authority over consequential choices. A system demo may look like a presentation, yet its real value is integrated evidence that individually completed pieces actually work together. Even a retrospective is easier to understand once you separate the conversation from the feedback loop that changes how future work is performed.

The interesting discovery was not that organizational design could be applied to agents. The surprise was that I had started with the wrong question.

At some point I wrote three words in my notes: Need -> Mechanism -> Implementation. That turned out to be much more useful than the role mapping I had started with. The need is the coordination problem, the mechanism is how the organization addresses it, and the implementation is the concrete human form that mechanism happens to take. A meeting can disappear while synchronization survives; a role can disappear while authority survives; a ceremony can disappear while the requirement for evidence remains. Once those layers were separated, the transfer problem became much less fuzzy.

I did not begin with a four-box model, but four recurring patterns kept appearing as I went through the examples. Some coordination needs seemed largely indifferent to whether the actor was human or machine. Completion still had to mean something, dependencies still had to be managed, failures still needed a response, and somebody still had to define the point beyond which the system was no longer allowed to act on its own. I started calling these Invariant, not because every system needs the same organization, but because the underlying coordination problem survives the change of actor.

A second group behaved differently. The need survived, but the human mechanism looked increasingly artificial once the worker became software. A two-day planning event might become continuous dependency synchronization, a review meeting might become an automated evidence gate, an escalation chain might become routing based on confidence, impact or permission, and a retrospective might become trace analysis followed by a workflow change. I called these Translated because the function remains while the human form changes.

Then there were mechanisms whose underlying purpose really did depend on human properties: career development, recognition, social belonging, some forms of motivational coaching, working-hour coordination and vacation planning. Those I put into Human-specific, but that pile became smaller the longer I worked on it. Psychological safety is clearly a human phenomenon, for example, but one of the functions behind it is preserving dissent. Recent coordination work documents minority-view collapse as a failure mode and, in one controlled study, observed behavior consistent with alignment pressure suppressing correct minority signals.⁵ So the emotion disappears, while a related coordination problem remains. Motivation produced the same complication: agents do not want promotions, but objective design and incentive alignment certainly do not vanish. Even fatigue turned out to have an awkward machine cousin in long execution chains, context limits and accumulated error. The useful test became not "does the human symptom disappear?" but "does the function disappear?"

The fourth group appeared only after I stopped trying to find a human equivalent for everything. Agent systems bring their own problems: choosing which model should handle a task, deciding how much context it should see and which tools it may call, controlling inference cost, managing persistent memory, tracking prompt or skill versions, dealing with malformed outputs and deciding when a workflow has burned enough tokens or compute without getting anywhere. I called those Agent-native. There are loose human analogies for some of them, but model routing is not staffing and a token budget is not a working day. These are problems we get specifically because the worker is software.

The question is not whether the human symptom disappears. It is whether the function disappears.

By then the original question had changed quite a lot. I was no longer asking whether a role survives. I was asking what sits underneath the role, whether that function still exists after the actor changes, and whether the implementation should remain human-shaped at all.

Then I realized I had made another assumption

Everything above quietly assumed that the problem should be solved by multiple agents in the first place. That assumption is easy to miss because "multi-agent" currently sounds more advanced than "single agent," but an organization has a cost. Every additional actor introduces another context boundary, inference, handoff and opportunity for one component to misunderstand or amplify an error from another. A 2026 study across seven benchmarks found that a strong single-agent implementation could match homogeneous multi-agent workflows while using inference more efficiently.⁶ That does not make single-agent systems universally better, but it does make "more agents" a design choice rather than a maturity level.

So I added a question before the rest of the analysis even begins: does this problem actually benefit from having more than one independent actor? There are good reasons why the answer may be yes. The task may require genuinely different capabilities, parallel execution, independent verification, permission separation, context isolation or fault containment. You may deliberately want different objectives to remain in tension instead of collapsing them into one optimizer, or the task may simply be too large for one execution path. But if none of those conditions apply, building a little simulated department may be organizational theater rather than architecture.

That was a useful correction because it put a boundary around the whole analogy. Before asking what kind of organization an agent system needs, perhaps we should first ask whether it needs an organization.

Going back to SAFe with a different question

By then SAFe no longer looked like a blueprint. It looked like something useful to take apart, which was actually more interesting. SAFe exposes a lot of coordination machinery very explicitly: planning, product authority, technical direction, team execution, synchronization, integrated review, improvement, budgeting and governance.⁷ It is also large enough to contain plenty of human ceremony and inherited assumptions, so it gives the transferability question something difficult to work on.

I went through the framework again, but instead of asking for the agent equivalent of each role, I asked what problem the mechanism was solving, whether that problem still existed, whether the mechanism itself still made sense, which part depended on humans being human and what new constraints appeared because the workers were agents. The table below is basically those notes cleaned up enough to be readable. The SAFe descriptions are grounded in Scaled Agile's current framework; the transfer classifications are my interpretation.⁷

Several rows changed my thinking more than the others.

PI Planning was easier than I expected

I assumed PI Planning would be mostly human overhead because two days of synchronization, dependency conversations, capacity arguments and risk discussions look very human. Once I removed the event itself, however, most of the underlying problem was still there. A large distributed system still needs shared intent, dependency visibility, compatible assumptions, some notion of capacity or budget and a way to recognize when execution should stop and a decision should move upward. Agents can exchange that state much faster than people, but speed does not eliminate the coordination requirement.

The difference is that the agent version does not need to inherit the calendar. Planning could become continuous, event-driven or rerun only when a meaningful dependency or assumption changes. A human might appear only when the resulting plan crosses a risk, investment or authority threshold. Calling that "AI PI Planning" would probably confuse more than it explains. It is simply the planning function after removing the human workshop.

Iterations turned out to be less obviously human

My first instinct was that iterations were another artifact of human work. People organize around weeks, need predictable review points and benefit from manageable chunks of work, while an agent does not care that it is Friday afternoon. Then I ran into research on long-horizon LLM tasks. In controlled RL settings, increasing horizon length created instability even when the researchers separated reasoning complexity from horizon length, while reducing the effective horizon through higher-level actions and verifiable subgoals improved stability and performance in the tested environments.⁸

That research does not prove that agents need Scrum, and it certainly does not prove that they need two-week sprints. The paper is about training dynamics and controlled agent tasks, not enterprise planning cadence. But it made me stop treating bounded work as purely human. There may be at least three different things hidden inside an iteration: the calendar cadence people work to, the length of the execution chain itself, and how often the system gets checked. The first may weaken or disappear while the other two remain technically useful. An agentic system may not need to stop after two weeks, but it may still need a rule that prevents cost, uncertainty or unverified execution from accumulating beyond a threshold.

RTE became more interesting once I stopped calling it an orchestrator

This was the role I expected to map most cleanly. RTE becomes Orchestrator Agent, and the diagram almost draws itself. The Conductor work made that mapping look much too static. The Conductor dynamically divides problems, selects workers, controls which previous outputs each worker can see and changes the coordination topology based on the task.⁴ A simple problem can use fewer workers, a harder one can use more, and different tasks can produce different structures entirely.

That made the team itself look like a runtime variable rather than a permanent organization. The part of the RTE role that survives therefore looks more like a coordination function than a permanent agent role. It also exposed another distinction I had been glossing over: deciding what happens next is not the same authority as deciding what is acceptable. Routing authority is different from product authority, architecture authority, verification authority or the authority to make an irreversible business commitment. Human organizations often separate those powers informally through roles and reporting lines; an agent system has to make the separation technically real.

The Scrum Master showed me that some things really can disappear

The Scrum Master was useful because the role contains functions that are genuinely human: coaching, facilitation, helping people change behavior, working through team conflict and maintaining motivation. Those do not need a digital imitation simply because the rest of the process has become agentic. A transfer test that preserves everything would not be doing much useful work.

At the same time, the whole role did not vanish. Flow can still become unhealthy, handoffs can fail repeatedly, verification can create rework, context can be lost and a workflow can develop a bottleneck. The agent version looked less like an "AI Scrum Master" and more like good telemetry: where work waits, which outputs keep getting rejected, which agent-tool combinations create rework and where the system is spending money without getting a better result. The visible role disappears, but one of its underlying functions becomes more technical.

System Demo almost looked disposable until I asked why it existed

Agents do not need to sit in a room and watch a product walkthrough, so the human implementation is easy to discard. The reason for the demo is harder to discard because local completion is cheap. Every component can pass its own checks and every specialist can report success while the integrated system still fails. That is a coordination problem, not a human one.

The translated version may therefore be much less theatrical: run the end-to-end scenario, collect the evidence, compare it with the acceptance criteria and send only the unresolved high-impact cases to a person. The presentation disappears, while the demand for integrated proof remains almost unchanged.

Guardrails were where the analogy started becoming architecture

Human organizations usually express guardrails as policies: spend within this range, escalate beyond this level, use these standards, do not access that information. People are expected to interpret the rules and behave accordingly. Agent systems can make some of those boundaries literal. A tool can be unavailable, a deployment can stop when evidence is missing, a transaction can require another authority, a workflow can hit a hard budget and an exception can route automatically to a person.

That is where the operating model starts becoming executable, which sounds attractive until you remember that a bad policy can also become executable. An unnecessary approval can become permanent and a historical workaround can become a runtime rule. Code gives a bad rule consistency; agents give it scale. So even here the more interesting question is not whether an operating model can be encoded, but which parts are precise, legitimate and stable enough to deserve encoding in the first place.

The analogy also started fighting back

At this point it would have been easy to stop with a very comfortable story: organizations have spent decades solving coordination problems, agents now have coordination problems too, so we already have a useful library of answers. The more research I read, the less comfortable that conclusion became, mainly because human-looking structure can create a false sense of safety.

Suppose I create three agents called Planner, Worker and Reviewer. I have not necessarily created three independent perspectives. If they use the same underlying model, the same retrieval, the same initial framing and the same assumptions, they may simply fail together. Multi-agent research explicitly identifies correlated errors and alignment pressure as failure risks.⁵ That means "separation of duties" has to become much more literal in an agent system. Independence may depend on who has authority, what information each agent sees, which models or tools they use, which data they can access and even whether the reviewer is allowed to see the producer's conclusion. Human organizations sometimes get a degree of independence almost accidentally by putting different people into different roles; software may have to engineer it deliberately.

Central orchestration creates a related problem. It is powerful precisely because one actor can decompose, route and integrate a lot of work, but that same leverage can amplify a bad framing decision. A coordinator can decompose the wrong problem beautifully, specialists can execute it well, and a verifier can validate against the wrong acceptance criteria. The system can be coherent and still be wrong. That is why I now hesitate when I see a multi-agent diagram with one large central brain and many smaller boxes around it. The picture looks organized, but visual organization and good governance are not the same thing.

Code gives a bad rule consistency; agents give it scale.

Consensus has the same trap. Several agents agreeing does not automatically increase confidence if they share the same training priors, retrieval, anchor or blind spot. In human organizations we spend a lot of effort trying to create independent challenge; in agent systems that independence may need to become an explicit architectural property. Machine speed also changes the cost of getting this wrong. Human processes are frustratingly slow, but that slowness is also friction. A bad assumption may take hours or days to move through a human organization; an agent workflow can turn it into analysis, design, code and deployment preparation very quickly.

That was the point where "human in the loop" started to feel like the wrong level of detail. Reversibility seemed more useful. A draft, a simulation or a test environment is usually cheap to undo. Releasing money, deleting production data, changing a regulatory filing or committing a price change to thousands of customers is a different kind of action. Instead of putting an approval icon after every third box, it may make more sense to let the system move quickly inside a reversible region and place a hard authority boundary before the point where consequences become difficult to reverse.

I also had to admit that computer science was here first

There is an obvious objection to this whole line of thinking: distributed systems already know about topology, synchronization, retries, timeouts, consensus, failure handling, leader election, queues and backpressure. A computer scientist could look at an "agent operating model" diagram and reasonably ask whether management people are rediscovering distributed systems using more expensive vocabulary.

The objection is fair, and the historical record makes it stronger rather than weaker. A 2004 paper was already combining human organizational concepts with distributed intelligent-system design and mapping mechanisms such as supervision, mutual adjustment and standardization into multi-agent structures.² So I do not think organization theory replaces distributed-systems thinking, nor do I think it should try.

What became interesting to me was the point where the questions diverge. Distributed systems are excellent at asking whether processes can coordinate, messages can arrive, state can converge, failures can be recovered and operations can complete. Organizations add a different set of questions: who is actually allowed to decide, who can commit the organization, which decisions can be delegated, who owns an exception, what evidence is enough to accept risk and what the system may be technically capable of doing but still not allowed to do. The moment an agent can do something consequential rather than just produce text, both sets of questions start appearing in the same architecture.

An orchestrator may be technically capable of calling a production tool without having authority to deploy. A model may find a cheaper path that the organization is not allowed to use because it exposes restricted data. A workflow may discover that skipping verification improves throughput without having authority to redefine what counts as acceptable risk. This is where organizational design still earns its place for me: not instead of software architecture, but as part of the same design problem once software starts receiving real decision rights.

The strangest inversion came from teams

Human organizations spend enormous effort trying to stabilize teams because people build trust, learn how each other thinks, develop shared language and accumulate tacit knowledge. They also have bounded cognitive load, which is one reason frameworks such as Team Topologies care about how stream-aligned, platform, enabling and complicated-subsystem responsibilities are divided.⁹ I assumed some version of that stability would transfer naturally to agents.

Newer orchestration research kept suggesting the opposite possibility. A system can choose a different team for every task: one worker for something simple, several specialists for a hard problem, an independent verifier for a risky one, a cheaper model for routine work and a stronger model only where uncertainty justifies the cost. The team no longer has to look like a permanent org chart at all; it can be assembled differently for each piece of work.

For a while I summarized that as "stable governance invariants, dynamic execution topology," but even that started to feel too rigid. Why should governance be stable forever? Authority can expand after reliability is demonstrated, and progressive governance guidance already recommends increasing autonomy after validated performance while maintaining least-privilege boundaries.¹⁰ Risk changes, context changes, novel workflows become routine and routine workflows encounter unusual cases. The distinction I find more accurate now is that governance should change deliberately, while the execution structure can change dynamically. Both can evolve, but changing who may approve a transaction or what evidence counts should not happen accidentally because the optimizer found a faster route.

A production example made the argument less abstract

Around the same time, I read Yuval Yeret's account of the agentic development lifecycle being introduced at Next Insurance. The detail that caught my attention was not what they changed, but what they deliberately left alone. Quarterly planning stayed, sprint planning stayed, roadmaps stayed and the broad split between product and engineering remained. What changed first was who wrote the artifacts. Requirements work was decomposed into skills, and product and engineering people increasingly worked on the skills and context that produced the documents instead of manually producing every document themselves.¹¹

That is almost the reverse of the usual AI transformation story, where after one good demo everybody suddenly wants a new workflow, a new operating model and preferably a new organization by Monday. Here the outer process stayed relatively stable while the actor inside it changed, which gave the organization a chance to see which parts of the process became wrong only after the new capability appeared.

Governance should change deliberately, while the execution structure can change dynamically.

The human role moved too, but it did not disappear. The agent could produce more of the PRD, but a person still approved it; it could create the technical design, while a human review remained before coding; it could automate review work, yet consequential changes still had a human boundary before production.¹¹ "Human in the loop" does not tell us much about that arrangement. The interesting questions are where the person sits, what authority they retain and what evidence reaches them.

Recent management research has started using the term managerial altitude for a related problem: how far above execution should human oversight sit as agents manage more of the work below.¹² I like the term, but the transferability exercise made me ask something underneath it. If the human moves upward, what has to become explicit below? If a person no longer writes every requirement, how is intent represented? If they no longer review every design, which architecture constraints need to become enforceable? If humans only handle exceptions, how does the system recognize an exception?

The higher the human moves away from the actual production of the artifact, the less the organization can rely on the informal control that existed simply because a person touched the work. Something has to replace that control, whether it is a rule, a verifier, telemetry, a permission boundary or another human. That makes "AI replaces work" only part of the story. The control system around the work is changing too.

I tried the same lens outside SAFe

I still worried that I was seeing exactly what I wanted to see. Maybe the four categories only worked because SAFe is conveniently full of the mechanisms I had already decided to look for, so I tried the same trick on a few other operating models. Not enough to claim validation, but enough that the idea should become uncomfortable if it broke immediately.

Incident response was the first. A serious incident may have an incident commander, technical operators, communications roles, shared state, escalation and post-incident learning; Google's SRE model makes those separations quite explicit.¹³ The environment is completely different from SAFe: there is no sprint, the team is temporary and the objective is urgent stabilization. Yet the same decomposition appears. Situation awareness survives while the conference bridge may not. Command authority may survive while the human incident-commander role changes form. Escalation survives while the phone tree disappears. Post-incident learning survives while the meeting itself can become trace reconstruction and policy change.

SRE gave me another example in error budgets, which already sit halfway between management policy and executable architecture. They convert a reliability objective into an explicit risk allowance that can change release behavior when the budget is exhausted.¹⁴ That is close to what I imagine some agent governance becoming: not a manager saying "be careful," but a measurable boundary that changes what the system is allowed to do.

Team Topologies produced the opposite kind of test because its structures are heavily influenced by human cognitive load and the need for clear interaction modes between stream-aligned, platform, enabling and complicated-subsystem teams.⁹ Some of that rationale does not transfer directly, but the enabling function may. An agent system may still need shared tools, reusable skills, retrieval infrastructure, model routing and constrained interfaces so that every worker does not have to understand the entire environment. The human team may disappear while the enabling mechanism remains.

That was enough for me to keep the four categories, although definitely not as a taxonomy of the universe. I find them more useful as a way to expose assumptions that would otherwise sneak into the architecture unnoticed.

The labels are less important than the mistakes they prevent

There is a funny problem with naming things: the moment you give four categories capital letters, somebody will quite reasonably assume you have invented a framework and start trying to put everything neatly into one box. That would be exactly the wrong use. A Scrum Master is not "Human-specific"; parts of the role are. An iteration is not "Invariant"; some of its functions may be. A Product Owner is not "Translated"; the role bundles value decisions, clarification, context, sequencing and accountability.

The point is the decomposition, not the classification of the job title. The same is true over time. A human approval may be necessary while a workflow is new and become unnecessary after thousands of reliable cases. A stable agent team may be useful today because shared context is expensive and become unnecessary when orchestration improves. An agent-native constraint may eventually disappear into infrastructure and stop being a visible design choice at all.

So I do not see Invariant, Translated, Human-specific and Agent-native as a maturity model. Agent-native is not "better," Translated is not "more advanced," and Human-specific is not obsolete while humans still participate in the system. For me the categories are useful only as long as they keep forcing one question: what assumption am I importing without noticing?

Which parts should actually become executable?

This may be the question I care about most now. A lot of current AI work is moving in the direction of executable organizations: roles become instructions, policies become rules, approval rights become permissions, workflows become orchestration and context becomes configuration. The direction is real, and current research is already treating organizational structure and accountability as machine-readable design variables.³

Parts of that make enormous sense. If an agent should never access payroll data, I would rather enforce the restriction than put it in a prompt. If a deployment requires test evidence, I would rather make the evidence a condition than ask the agent to remember testing. If a transaction above a threshold needs another authority, I would rather make that separation structural.

At the same time, real organizations also run on ambiguity, conflicting objectives, tacit knowledge, exceptions, judgment and, yes, politics. Sometimes those things are signs of a badly designed organization; sometimes they exist because the formal model is incomplete. Making an operating model executable gives us consistency, but it also removes some of the friction through which humans notice that a rule no longer fits reality.

I do not think that is an argument for keeping everything manual. It is an argument for being very careful about where the boundary sits. Permissions, tool scopes, data boundaries, required evidence, budgets, termination conditions, logging, routing and some approval rules are obvious candidates for executable control. Intent, ethical tradeoffs, novel exceptions, conflicting stakeholder interests and the meaning of acceptable risk are much harder. Maybe those become more machine-readable over time as well, but I would want that transition to happen deliberately rather than because the software found a faster way around an inconvenient human step.

Back to the original diagram

When I go back to the planner, specialists, evaluator, orchestrator and human approval box that started all of this, the picture looks much less obvious than it did the first time. I initially thought I was looking at a new kind of organization, then briefly thought I was looking at SAFe rewritten in software, and then the research dismantled both simple stories.

More agents are not automatically better. A role name does not create authority, a reviewer is not automatically independent and a human approval is not automatically meaningful control. At the same time, a meeting can disappear while its coordination function survives, and a mechanism created for humans can contain something surprisingly universal underneath it. A framework may therefore contain both ideas worth carrying forward and assumptions we should never encode into software.

That is why I no longer find the AI org chart itself very interesting. What seems more useful is taking the org chart apart and asking what problem each mechanism was solving, whether that problem survives when the actors change, what should be translated, what should disappear and what new controls appear simply because the new worker is software. Sometimes the answer may even be that the task did not need a team at all.

I started by looking at agent architecture and ended up looking differently at organizations. The question I am still left with is the one that only appeared after the original idea fell apart:

When the workers stop being human, which parts of management disappear, and which parts turn out never to have been about humans at all?

References

1. 1. Clément Cazaud, "Agentic SAFe: running the Scaled Agile Framework with AI agents," Poesis, August 15, 2026. https://poesis.cloud/insights/agentic-safe/ ↩
2. 2. Chris J. van Aart, Bob Wielinga, and Guus Schreiber, "Organizational building blocks for design of distributed intelligent system," International Journal of Human-Computer Studies 61(5), 2004, pp. 567-599. https://doi.org/10.1016/j.ijhcs.2004.03.001 ↩
3. 3. Huan Chen, Xiang Song, Jian Jin, Pan Ren, and Liang-Jie Zhang, "Toward an Organizational Science of Multi-Agent LLM Systems: Decoupling Who, How, and Which Algorithm," arXiv:2607.25446, 2026. https://arxiv.org/abs/2607.25446 ↩
4. 4. Stefan Nielsen, Edoardo Cetin, Peter Schwendeman, Qi Sun, Jinglue Xu, and Yujin Tang, "Learning to Orchestrate Agents in Natural Language with the Conductor," The Fourteenth International Conference on Learning Representations (ICLR), 2026; arXiv:2512.04388. https://arxiv.org/abs/2512.04388 ↩
5. 5. Maksym Nechepurenko and Pavel Shuvalov, "Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems: An Information-Controlled Empirical Study on Prediction Markets," arXiv:2605.03310, May 2026. https://arxiv.org/abs/2605.03310 ↩
6. 6. Jiawei Xu et al., "Rethinking the Value of Multi-Agent Workflow: A Strong Single Agent Baseline," arXiv:2601.12307, 2026. https://arxiv.org/abs/2601.12307 ↩
7. 7. Scaled Agile, Inc., current SAFe guidance, including PI Planning, Release Train Engineer, System Demo, Inspect and Adapt, Lean Budget Guardrails, and Essential SAFe. https://framework.scaledagile.com/pi-planning/ ; https://framework.scaledagile.com/release-train-engineer/ ; https://framework.scaledagile.com/system-demo/ ; https://framework.scaledagile.com/inspect-and-adapt/ ; https://framework.scaledagile.com/guardrails/ ; https://framework.scaledagile.com/essential-safe/ ↩
8. 8. Sunghwan Kim, Junhee Cho, Beong-woo Kwak, Taeyoon Kwon, Liang Wang, Nan Yang, Xingxing Zhang, Furu Wei, and Jinyoung Yeo, "On Training Large Language Models for Long-Horizon Tasks: An Empirical Study of Horizon Length," Proceedings of the 43rd International Conference on Machine Learning, PMLR 306, 2026; arXiv:2605.02572. https://arxiv.org/abs/2605.02572 ↩
9. 9. Team Topologies, "Key concepts and practices for applying a Team Topologies approach to team-of-teams org design." https://teamtopologies.com/key-concepts ↩
10. 10. World Economic Forum, in collaboration with Capgemini, AI Agents in Action: Foundations for Evaluation and Governance, November 27, 2025. https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/ ↩
11. 11. Yuval Yeret, "Don't Redesign Your Process Yet. Change Who Writes the Artifacts," August 22, 2026, reporting on Shay Mandel's description of the agentic development lifecycle at Next Insurance. https://yuvalyeret.com/blog/change-who-writes-the-artifacts-before-your-process/ ↩
12. 12. "Managerial altitude: Where should humans stand when AI agents manage AI agents?," Business Horizons, available online September 8, 2026. DOI: 10.1016/j.bushor.2026.09.001. https://doi.org/10.1016/j.bushor.2026.09.001 ↩
13. 13. Google, Site Reliability Engineering, "Managing Incidents" and the Incident Management Guide. https://sre.google/sre-book/managing-incidents/ ; https://sre.google/resources/practices-and-processes/incident-management-guide/ ↩
14. 14. Google, Site Reliability Engineering, "Embracing Risk" and "Production Services Best Practices." https://sre.google/sre-book/embracing-risk/ ; https://sre.google/sre-book/service-best-practices/ ↩