Daniel sent in a prompt that's basically a production diary entry. He's been running this podcast's agentic pipeline and he noticed something about how it's structured. There's a manager agent sitting above the script writer, the reviewer, the text-to-speech handoff. It handles failover, decides whether to pull from EXA-AI for general research or fire up a breaking-news pipeline, and generally shepherds the whole production from end to end. He says it earns its keep, but he wants to know what these things are actually called across frameworks, what failure patterns to watch for, and how to write system prompts that don't create brittleness when you add orchestration layers. So today we're talking about the agent nobody sees. The one that manages the ones that do the work.
And it's a pattern that's showing up everywhere now. LangGraph calls it a supervisor, CrewAI calls it a manager agent, AutoGen calls it an orchestrator. The naming isn't standardized but the concept is convergent. You have a supervisory layer that doesn't generate content and doesn't execute tools directly. It reads state, decides which sub-agent to invoke, evaluates the result, and either loops or terminates.
So it's not a router. A router is stateless. Packet comes in, packet goes out, the router doesn't remember the last packet or care what the next one looks like.
Right. The manager agent is stateful. It sees the full conversation history, the outputs of every sub-agent that's run so far, and it's making decisions based on accumulated context. That's the distinction. A simple chain goes Agent A to Agent B to Agent C and stops. A managed pipeline goes manager inspects state, chooses Agent B, inspects the result, maybe loops back to Agent A, maybe calls Agent C, maybe terminates. It's the difference between a recipe and a chef.
The chef analogy works. A recipe is linear. You do step one, step two, step three. A chef tastes the sauce halfway through and decides it needs more salt, even though salt wasn't in the next step.
And the frameworks all support this natively now. LangGraph has a supervisor pattern documented in their multi-agent tutorials. You define a supervisor agent that receives the full state graph, decides which agent to call next, and loops until a termination condition fires. CrewAI lets you set a manager agent parameter on a crew, which spawns a default manager that coordinates task assignment. AutoGen uses an orchestrator role for the same purpose.
Three frameworks, three names, same idea. What I find interesting is that none of them call it the same thing, which tells you the pattern emerged from practice rather than being designed top-down.
It did. People built linear pipelines, they broke, they added a decision layer, and then the framework authors said oh, we should probably support that natively. LangGraph's StateGraph makes it explicit. You define nodes for each sub-agent, you define a supervisor node that routes between them, and you define a FINISH node as the termination condition. The supervisor's system prompt is where the routing logic lives.
And that's where the brittleness first appears.
That's where everything first appears. The system prompt for the manager agent is the most consequential piece of text in the entire pipeline, and it's the one people write last, usually in five minutes, usually without testing edge cases.
Let's talk about how it breaks. You mentioned three failure patterns.
Three that I've hit repeatedly. The first one is supervisor hallucination. The manager routes to an agent that doesn't exist, or invokes a tool that isn't in its tool set, because the system prompt is underspecified. You write something like route to the appropriate agent and the manager invents an agent called data_analysis_specialist that you never defined. It's not making things up maliciously. It's trying to be helpful and you gave it a blank check.
So the fix is enumerating the available agents explicitly in the prompt.
Yes, and not just their names. Their capabilities, their input formats, their output formats, and the exact conditions under which each one should be called. You can't say call the researcher for research tasks. You say call the researcher agent when the query requires factual grounding from external sources, the query contains a specific question about a real-world entity, or the user explicitly asks for current information. The more precise the boundary, the less room for hallucination.
What's the second failure pattern?
Infinite delegation loops. The manager keeps passing between sub-agents without ever hitting the termination condition. It goes researcher to writer to reviewer to researcher to writer to reviewer, and each handoff adds more context to the state, and eventually you hit the context window limit or your API bill makes you cry.
I've seen that one. It's because the stop condition is too vague. Something like terminate when the task is complete.
Which is meaningless to a language model. Complete according to what criteria? Complete because the output is good enough? Complete because you've looped three times? The model doesn't know what complete means unless you define it. LangGraph's StateGraph handles this with an explicit FINISH node. The supervisor can only terminate by routing to FINISH, and the conditions for routing to FINISH have to be spelled out in the system prompt. You can say something like route to FINISH when the draft has been reviewed at least once and all review comments have been addressed, or after a maximum of three delegation cycles, whichever comes first.
The maximum delegation count is underrated as a safety mechanism. Just hardcoding you may delegate at most three times prevents the infinite loop even if everything else in the prompt is ambiguous.
It's the circuit breaker. It doesn't guarantee good output, but it guarantees the pipeline stops. And sometimes that's what you need at two in the morning when you're trying to figure out why production is burning money.
Third failure pattern.
State bloat. The manager accumulates the full output of every sub-agent call. Every research summary, every draft, every review comment. After three or four loops, the context window is packed with redundant information, and the manager's routing decisions degrade because it can't see the signal through the noise.
This is the one that creeps up on you. It doesn't fail loudly. It just gets stupider over time.
And it's hard to debug because the early outputs look fine. The first delegation is sharp, the second is reasonable, the third is a little off, and by the fifth the manager is routing the writer agent to research tasks and the researcher to formatting tasks. The state has become a landfill and the manager is picking through garbage.
How do you fix it?
Summarization. After each sub-agent call, you don't pass the full output back to the manager. You pass a structured summary. The researcher found three relevant sources, the key finding is X, the confidence is medium. Not the entire ten-page research document. LangGraph lets you define a state schema where you control exactly what gets passed between nodes. If you're not using that feature, you're building a context bomb.
Daniel's pipeline has a concrete example of the routing problem. The manager decides between EXA-AI grounding for general research and a breaking-news pipeline for time-sensitive stuff. If the system prompt doesn't clearly define what counts as breaking news, the manager either defaults to one path or oscillates between them.
And that oscillation is worse than picking the wrong path consistently. If it always defaults to EXA-AI, you get stale news on breaking stories but the output is coherent. If it oscillates, you get an episode that pulls half its facts from a real-time news API and half from a general knowledge base with a six-month cutoff. The contradictions are visible to the listener.
What does the threshold look like in practice?
You need concrete criteria. A recency threshold. If the query contains a date within the last seven days, route to breaking news. Source authority. Reuters and AP are breaking news sources. A blog post from last Tuesday is not. Topic classification. Geopolitics, financial markets, disaster response go to breaking news. Cooking recipes and battery chemistry do not.
The source authority one is interesting because it means the manager needs to know something about the credibility of sources, not just their recency. A conspiracy theory posted ten minutes ago is recent but it's not news.
Right. And that's where the system prompt gets hard. You're encoding editorial judgment into a text prompt. You're saying this is what we consider authoritative, this is what we consider noise. It's a value judgment disguised as a routing rule.
Every system prompt is a value judgment disguised as a routing rule. That's the whole job.
Fair. Let me talk about CrewAI's manager agent, because it fails differently. CrewAI lets you set manager_agent equals true on a crew, and it spawns a default manager that coordinates task assignment. The failure pattern there is manager as bottleneck. The default manager has no domain knowledge. It sequences tasks in the order they were defined, not based on intermediate results.
So it's a manager that manages but doesn't understand what it's managing.
If you define tasks as research, then draft, then review, the default manager runs research, then draft, then review. Even if the research comes back empty and the draft should be skipped. Even if the review finds a critical error and the whole thing should loop back to research. It's a sequential process masquerading as orchestration.
That's worse than no manager at all. At least without a manager you know you're running a linear chain and you design for that. With a fake manager you think you have dynamic routing but you don't.
CrewAI does have a hierarchical process option that's more dynamic. You can define a custom manager agent with its own system prompt and domain knowledge. But the default is the sequential one, and a lot of people never move past the default.
Because the default works for demos. You build a three-agent crew, it runs in order, the demo looks great, you ship it, and six months later you discover it's been doing the same linear sequence regardless of input.
The demo-to-production gap is real, and manager agents are where it's widest. A demo pipeline with five agents and a manager looks impressive. A production pipeline with five agents and a manager has five times as many failure modes as a linear chain.
So if those are the failure patterns, what are the patterns that work? Let's talk about what makes a manager agent actually earn its keep.
Three things. First, explicit routing criteria with concrete thresholds. Not if the query is time-sensitive but if the query references an event dated within the last seven days, route to breaking news. Not if the output needs improvement but if the reviewer agent flagged more than two issues, loop back to the writer. The manager shouldn't be interpreting vague adjectives. It should be checking measurable conditions.
The measurable condition is the difference between a manager and a gambler.
Second, include a fallback agent in the routing graph. A default sub-agent that handles anything the manager can't classify. If the manager encounters a query that doesn't match any of the routing criteria, it routes to the fallback instead of hallucinating a new agent or freezing.
What does the fallback agent do?
It depends on the pipeline. In Daniel's case, the fallback might be a general-purpose research agent that does a broad search and returns whatever it finds, with a flag that says this wasn't routed through the normal channels, treat with caution. The point is that the pipeline doesn't break. It degrades gracefully.
The graceful degradation is the part people skip. They design for the happy path where every query cleanly matches a routing rule, and then production throws something weird at the manager and the whole thing collapses.
Third, the manager as state machine pattern. Instead of prompting the manager to decide what to do next as an open-ended question, you structure its system prompt as a finite set of states with explicit transition rules. INIT to RESEARCH to DRAFT to REVIEW to FINISH. The manager isn't generating novel actions. It's selecting from a predefined graph. LangGraph's StateGraph makes this explicit. You define the nodes, you define the edges, and the manager's job is to choose which edge to traverse based on the current state.
That reduces hallucination because the action space is bounded. The manager can't invent a new state. It can only choose from the states you defined.
And if none of the states fit, it routes to the fallback. The combination of a bounded action space and a fallback agent eliminates most of the hallucination failures.
What about the visual orchestration tools? LangGraph Studio, Semantic Kernel's planner, anything where you're drawing the graph instead of coding it. Daniel asked about visual versus code-based approaches.
Visual tools introduce a different failure pattern. I call it visual overspecification. When you draw the graph, you tend to hardcode edges that should be dynamic. You draw a line from RESEARCH to DRAFT because that's the obvious flow, and now the manager can't route from RESEARCH back to INIT if the research comes back empty. The visual tool nudges you toward static routing because drawing a dynamic edge is harder than drawing a static one.
The tool shapes the thinking. If you're writing code, you naturally think about conditional logic. If you're drawing boxes and arrows, you naturally think about fixed flows.
And the best practice is to use the visual tool for the skeleton. Which agents exist, what tools they have, what the state schema looks like. But let the manager's system prompt define the dynamic routing logic. The visual tool shows you the map. The system prompt is the navigation.
The map is not the territory, and the territory changes with every query.
There's another dimension here that I think is under-discussed. When does a manager agent actually earn its keep? Daniel said his earns its keep, and I believe him, but that's not true for every pipeline. The threshold I use is three conditions. The manager is worth the complexity when the pipeline has more than three sub-agents, when sub-agents share state and need conflict resolution, or when the pipeline must handle heterogeneous input types.
Below those thresholds, you're adding orchestration overhead for no benefit. A two-agent pipeline with a manager is a three-agent pipeline where one of the agents does nothing but point at the other two.
And that pointing agent can still hallucinate, can still loop infinitely, can still bloat the state. You've added a failure pattern without adding capability.
The heterogeneous input types one is interesting. Daniel's pipeline has that. Breaking news versus evergreen research are fundamentally different input types that require different grounding strategies. Without a manager, you'd need to build that decision into every agent, and they'd all need to agree on the criteria.
That's the coordination problem. If the writer agent and the researcher agent have different ideas about what counts as breaking news, you get inconsistent behavior. The manager centralizes that decision. One prompt, one set of criteria, one source of truth about routing.
Centralizing the decision is also what makes the manager a single point of failure. Every sub-agent depends on the manager's routing decision being correct. If the manager routes wrong, nothing downstream can fix it.
Because the sub-agents don't know they got the wrong assignment. The writer agent receives a routing decision and writes. It doesn't know it should have been routed to the breaking-news pipeline instead. It just does its job with the information it was given.
Which brings us to something I want to dig into. The manager is the most dangerous node in the pipeline because when it fails, it fails upstream of everything else.
You budget for the writer producing bad copy. You have a review step. You budget for the researcher finding bad sources. You have a grounding check. But when the manager routes to the wrong agent, there's no second opinion. It's a single point of failure by design.
Hilbert, you've been sitting on something.
Hilbert: I spent six months in two thousand three as a middleware architect for a logistics company. We thought we could route packages with a single decision tree. We had a manager layer. A human one. Guy named Carl sat in a booth and decided which conveyor belt got which parcel. Carl quit. We replaced him with a rule-based system that immediately started routing refrigerated goods to the shredder.
To the shredder.
Hilbert: The shredder was for cardboard. Refrigerated goods are not cardboard. The system didn't know the difference because nobody had put that in the rules. Carl knew the difference because Carl had eyes and a lunch break and a basic understanding of what a refrigerator is.
How long did it run before someone noticed?
Hilbert: About four hours. The shredder jammed. That's what stopped it. Not the rules, not the monitoring, not the supervisor. The shredder jammed on a pallet of frozen fish and the whole line backed up.
So the failure was detected by the physical world, not by the orchestration layer.
Hilbert: The orchestration layer was perfectly confident. Every routing decision was logged, every parcel had a timestamp, every rule fired correctly. The system was operating exactly as designed. The design was wrong.
This is the thing about manager agents. When they fail, they fail confidently. They don't hedge. They don't ask for help. They route the refrigerated goods to the shredder and log a successful transaction.
Hilbert: You're all talking about system prompts and state graphs and fallback agents. But the real failure pattern is that nobody budgets for the manager's failure pattern. You budget for the writer agent producing bad copy. You have a review step. You budget for the researcher agent finding bad sources. You have a grounding check. But when the manager routes to the wrong agent, there's no second opinion.
Carl at least had a supervisor.
Hilbert: Carl had a supervisor. The rule-based system didn't. And your manager agent doesn't either.
So you're arguing for a meta-manager. A second manager that audits the first manager's routing decisions.
Hilbert: I'm not arguing for anything. I'm telling you what happened to the frozen fish.
But the logic of what you're saying is that you need a manager for the manager. And then a manager for that manager. It's recursion all the way down.
Hilbert: At some point you need a human in the loop. Or you accept that occasionally the frozen fish goes to the shredder.
And the question is whether occasional frozen fish in the shredder is acceptable for your use case. For a podcast pipeline, maybe it is. The worst case is a bad episode. For a logistics company, the worst case is four hours of destroyed inventory and a jammed shredder.
Hilbert: The inventory was insured. The shredder was not.
What did the shredder cost to replace?
Hilbert: Twelve thousand dollars. Plus three days of downtime. The frozen fish was about four hundred dollars wholesale. The expensive part was the machine.
The shredder was the expensive part. Of course it was.
There's something here about the cost structure of manager agent failures. The direct cost of a bad routing decision is often small. Wrong agent called, wrong output produced. But the indirect cost, the jammed shredder, the degraded state that corrupts future decisions, the context window filled with garbage that makes every subsequent routing decision worse. That's where the real damage accumulates.
And it accumulates silently. The pipeline doesn't crash. It just produces worse and worse output until someone notices.
Hilbert: Carl noticed. Carl always noticed. That's why we hired Carl.
What happened to Carl?
Hilbert: He opened a bait shop. Still sends me a Christmas card.
The bait shop detail is going to sit with me. But the point Hilbert's making is that the manager agent's failure pattern is uniquely dangerous because it's upstream of all other quality checks. And the fix isn't obvious because the fix requires either a human in the loop or an infinite regress of -managers.
The recursion problem is real. But I think there's a middle ground. You don't need a full -manager. You need a monitoring layer that checks the manager's output against simple heuristics. Did the manager route to an agent that exists? Did it exceed the maximum delegation count? Did it produce a routing decision that contradicts the routing decision it made for a similar query ten minutes ago?
Anomaly detection, not a second manager. You're not auditing the decision quality. You're auditing the decision consistency.
Right. And if the monitoring layer flags something, you don't try to fix it automatically. You escalate to a human. Or in an automated pipeline, you fall back to a safe default. Route to the general-purpose agent. Skip the breaking-news pipeline. Produce a lower-quality but coherent output instead of a high-quality but potentially wrong one.
The safe default is the fallback agent we talked about earlier. It's the same pattern at a different layer. The manager has a fallback for unclassifiable queries. The monitoring layer has a fallback for suspicious routing decisions.
And both of those are cheaper and less complex than a -manager that's trying to second-guess every decision in real time.
Hilbert: We tried anomaly detection on the conveyor system. After the shredder incident.
Did it work?
Hilbert: It flagged seventeen thousand anomalies in the first week. Most of them were packages that were slightly heavier than the average for their size. The system couldn't tell the difference between a routing error and a package that someone had overstuffed.
The false positive problem. Anomaly detection is easy. Useful anomaly detection is hard.
Hilbert: We turned it off after two weeks. Hired another Carl instead.
Two Carls.
Hilbert: Carl and Mike. Mike was Carl's brother-in-law.
The human solution scales linearly with the number of conveyor belts. The automated solution scales exponentially with the number of edge cases. At some point the lines cross and hiring another Carl is cheaper than fixing the anomaly detector.
Which is why I keep coming back to the system prompt. The manager agent's system prompt is where you encode your Carl. It's where you put the judgment, the edge cases, the things that Carl knew without being told. And the quality of that prompt determines whether your manager is Carl or the shredder.
The prompt is the Carl. That's the best summary of this entire discussion.
And we're still learning how to write it. The manager's system prompt is the most consequential piece of text in the entire pipeline, and the practice of writing it is maybe two years old. We're in the alchemy phase. People are sharing prompts on forums, trying things, failing, trying again. There's no textbook.
That's going to change. As multi-agent systems scale, the manager pattern will become a first-class primitive in every framework. LangGraph already treats it as one. The supervisor tutorial is front and center in their documentation. CrewAI's manager agent parameter is a one-line flag. The frameworks are betting that this pattern matters.
And the challenge is that the frameworks can give you the scaffolding. The state graph, the routing nodes, the termination conditions. But they can't write the system prompt for you. They can't encode your domain knowledge. They can't be Carl.
That's the question we're going to leave hanging. At what point does the manager agent need a manager? And if the answer is never, what does that say about the limits of agentic autonomy? I don't think there's a clean answer, and that's what makes this pattern so interesting.
The misconception I keep running into is that a manager agent is just a router. It's not. It's a stateful decision-maker that accumulates context, evaluates intermediate results, and chooses paths through a graph. Calling it a router is like calling a chef a timer.
And the other misconception is that adding a manager reduces brittleness. In practice, it introduces a single point of failure upstream of every sub-agent. You trade the brittleness of a linear chain for the brittleness of a centralized decision node. Whether that trade is worth it depends on whether your pipeline needs dynamic routing badly enough to accept the shredder risk.
For Daniel's pipeline, with heterogeneous input types and a real branching decision at the top, it earns its keep. For a two-agent chain that always runs in order, it's overhead with extra steps.
If you want to see how this podcast's manager agent is actually implemented, system prompt and all, we put it in the book. The link's on the website, my weird prompts dot com. All the revenue keeps this experiment running. And if you're building your own agentic pipeline and hitting these exact failure patterns, email the show at show at my weird prompts dot com. We collect war stories.
Thanks to Hilbert Flumingtop for producing, and for the frozen fish. This has been My Weird Prompts. We'll be back soon.
