You can engineer around the composition problem. Until you can’t.
In Part 1, we explained the 0.95^10 problem — why multi-agent systems fail predictably.
In Part 2, we showed the four-layer architecture that makes them reliable — IntakeOps, Operational Intelligence Layer, Neuro-Symbolic Controller, and Task-Specialized Models.
But here’s what we didn’t say: you can build all four layers with prompting alone.
No fine-tuning. No custom training. Just careful prompt engineering, smart context management, and lots of iteration.
We know, because that’s how we started. And it works — to a point.
This post is about that point, the prompt engineering limits in multi-agent systems.
The Prompting Playbook
When you’re building multi-agent systems, prompting is the obvious starting point.
For IntakeOps: „You are a data validation agent. Check if the input matches this schema. If not, return an error.“
For the Operational Intelligence: „Given this context from the knowledge base, answer the user’s question. Cite your sources.“
For the Controller: „You are a routing agent. Based on the user’s request, decide which specialist agent should handle it. Choose from: [list].“
For TSLMs: „You are a summarization agent. Summarize the following ticket in 3 bullet points.“
This works. We shipped production systems built this way. Real customers, real data, real value.
Prompting gets you from 0 to 1.
Where Prompting Excels
Let’s be fair to prompting. It has real strengths:
Speed to prototype. You can build a working multi-agent system in days. No training infrastructure. No dataset curation. Just iterate on prompts until it works.
Flexibility. Change the behavior by changing the prompt. No retraining, no redeployment. Ship a fix in minutes.
Model-agnostic. Switch from GPT-4 to Claude to Llama. The prompts mostly transfer. You’re not locked in.
Observability. The prompt is the logic. You can read it, debug it, explain it.
Dropbox built Dash — their AI search product — with specialized agents and careful context engineering. It works at scale. Prompting isn’t a toy.
Where Prompting Breaks
But prompting has ceilings. We hit them. Everyone hits them.
Ceiling 1: Consistency
Prompts are suggestions, not guarantees.
„Always return valid JSON“ works 95% of the time. The other 5% breaks your pipeline.
„Never reveal PII“ works until the model decides the user’s request is an exception.
„Route to Agent B for billing questions“ works until the model interprets „Can you help me with my bill?“ as a general question.
The failure mode: You can’t enforce behavior with prompts. You can only request it.
We added validation layers, retry logic, output parsing. It helped. It didn’t solve.
Ceiling 2: Context Window Economics
Every agent needs context. The routing agent needs to understand the request. The specialist agent needs domain knowledge. The validation agent needs the schema.
As systems grow, context grows. You’re stuffing more into every prompt:
- System instructions
- Few-shot examples
- Retrieved knowledge
- Conversation history
- Output format specifications
The failure mode: You hit the context window. Or you pay for tokens you don’t need. Or you truncate something important.
We spent weeks optimizing context. What to include, what to summarize, what to drop. It’s engineering, not intelligence.
Ceiling 3: Handoff Fragility
This is the big one.
Agent A finishes its task. It outputs a response. Agent B receives that response as input.
With prompting, you control what A outputs. You control what B expects. But you can't guarantee they match.
A outputs: B expects:
Both agents are „correct." The handoff fails.
The failure mode: Every interface between agents is a potential break point. And you're maintaining all of them with string matching.
We wrote prompt after prompt: „Output in exactly this format." „Parse the previous agent's response." „Handle missing fields gracefully."
It's whack-a-mole. Fix one handoff, break another.
Ceiling 4: Compound Errors
Remember the 0.95^10 problem? Prompting doesn’t solve it. Prompting is it.
Each prompted agent is 95% reliable. Maybe 98% with great engineering. Chain ten of them and you’re back to 60-80% system reliability.
The architecture from Part 2 — validation gates, deterministic routing, explicit state machines — catches errors at boundaries. But the errors still happen. You’re catching them, not preventing them.
The failure mode: You’ve built a sophisticated error-handling system around fundamentally unreliable components.
The Effort Curve
The first 80% comes fast. Prompts work. System works. Ship it.
The next 10% is harder. Edge cases. Failure modes. Context optimization.
The last 5% is asymptotic. You’re spending weeks to gain percentage points. And you’re not sure if you’re gaining or just overfitting to your test cases.
This is the wall.
What Prompting Can’t Do
The fundamental issue isn’t engineering effort. It’s optimization target.
When you prompt a model, you’re asking it to do a task. „Summarize this.“ „Route this.“ „Validate this.“
The model optimizes for task completion — as it understands the task, from the prompt.
What you actually need:
Handoff optimization. „Produce output that makes the next agent’s job easier.“
Graceful degradation. „When uncertain, fail in predictable ways.“
System-level reliability. „Optimize for the whole chain succeeding, not just your step.“
These aren’t in the prompt. They’re not in the model’s training objective. You can’t request them into existence.
The Dropbox Lesson
Dropbox Dash is impressive. Specialized agents, context engineering, production scale.
But read between the lines of their engineering blog posts:
- Careful prompt versioning and A/B testing
- Extensive context window management
- Complex fallback hierarchies
- Constant iteration on edge cases
They’re not hiding some secret technique. They’re doing the same things we did. Better, probably — they have more engineers.
But they’re still on the same curve. Still hitting the same ceiling. Still engineering around a fundamental limitation.
Prompting scales with engineering effort. It doesn’t transcend the reliability ceiling.
What Actually Solves This?
Two things:
1. Architecture (what we covered in Part 2)
Deterministic control flow, validation gates, explicit state machines. These catch errors at boundaries and make failures debuggable.
Architecture raises the ceiling. It doesn’t remove it.
2. Training for composition
Train models not just for task performance, but for handoff quality. Make „did my output enable the next component?“ part of the objective function.
This is an open research problem. One we’re actively working on.
When to Use Prompting
Prompting isn’t bad. It’s appropriate for certain stages:
| Stage | Prompting? | Why |
|---|---|---|
| Prototype | Yes | Speed to learning |
| Single-domain MVP | Yes | Good enough, ship fast |
| Multi-domain production | Partially | Architecture needed, prompts for flexibility |
| High-reliability systems | Minimally | Training becomes necessary |
Start with prompting. Know when you’ve hit its limits.
The Honest Assessment
Our production systems still use prompting. A lot of it.
IntakeOps validation? Prompted. Routing decisions? Prompted. Output formatting? Prompted.
The architecture from Part 2 wraps around these prompted agents. It catches their failures. It enforces constraints they can’t guarantee. It makes the system reliable despite unreliable components.
But we’re not pretending this is the end state.
Prompting is scaffolding. Eventually, you need structure.
Summary
Prompting gets you far. Then it doesn’t.
| Ceiling | What Happens |
|---|---|
| Consistency | Prompts suggest, don’t guarantee |
| Context economics | You pay for tokens or lose information |
| Handoff fragility | Every interface is a break point |
| Compound errors | 0.95^10 still applies |
Architecture catches these failures. Training might prevent them. Prompting alone can’t solve them.
We’re artiquare. We build reliable multi-agent AI for German industry.
Open source: github.com/artiquare/caa
