The proposal arrived at the design authority of Langkloof Financial Cooperative, a fictional regional financial-services cooperative, with a framework already chosen. Langkloof had a growing queue of onboarding cases that could not be completed automatically: a blurred identity document, a proof of address in a different name, a field agent's handwritten note that a member had no fixed address. The delivery team wanted to handle these with a "crew" of five role-based agents, each with a persona: a document specialist, a compliance reviewer, a member-experience agent, a risk analyst and a manager agent to coordinate them.
The demonstration worked. The question Nomvula, the lead architect, asked was not about the framework. It was this: when the risk analyst and the member-experience agent disagree about a case, who decides, how do we know, and how does the conversation stop?
Nobody could answer from the design, because the design was the framework's default. That is the problem this article addresses. A framework is an implementation of one or more orchestration patterns. Choosing it first means accepting its answers to questions the architecture should have asked.
Start from the lowest level that works
Microsoft's Azure Architecture Center guide AI agent orchestration patterns (dated 12 February 2026, checked on 5 November 2026) opens with advice that is easy to skip. It describes three levels of complexity: a direct model call, a single agent with tools, and multi-agent orchestration. It says to use the lowest level that reliably meets the requirement, notes that each level adds coordination overhead, latency and cost, and describes a single agent with tools as often the right default for enterprise use cases.
CloudNala has made the same argument in other forms. Use a workflow until the unknown forces an agent shows how to locate the one uncertain step in a process, and Multi-agent is an organisational choice sets out when a split into several agents earns its place. This article assumes you have done that work and still need more than one model-driven component. The question is then which pattern, and on what grounds.
The patterns, described by who is in control
The same guide names five multi-agent patterns. It is a useful vocabulary because it is not tied to any product. Here they are, described by the thing an architect needs to know: who chooses what happens next.
- Sequential. Agents run in a fixed order, each working on the previous one's output. The guide notes that the choice of which agent runs next is defined in the workflow, not by the agents. Control sits in code.
- Concurrent. Several agents work on the same input at the same time, and their results are combined. Control usually sits in code, which decides who runs and how results are aggregated, although the guide notes the orchestrator can also select agents dynamically.
- Group chat. Agents contribute to a shared conversation, and a chat manager decides who speaks next. Control sits with the manager, which may itself be a model.
- Handoff. Each agent decides whether to handle the task or pass it to another. Control moves with the task, and no single component sees the whole path unless you build one that does.
- Magentic. A manager agent builds and revises a task plan for open-ended problems, and the guide notes that agents in this pattern typically have tools that make direct changes in external systems. Control sits with a model that is also writing the plan.
Frameworks tend to make one of these natural. Graph-based frameworks make explicit state machines easy. Role-based crew frameworks make group chat and delegation easy. Workflow engines make sequential and concurrent patterns easy. None of that is a reason to choose a pattern. It is a consequence of choosing a framework.
Six control requirements to settle first
Before anyone opens a framework's documentation, write down answers to six questions. They are the requirements the pattern must satisfy.
- Who may choose the next step? Code, a model inside defined limits, or a model with no fixed path. In regulated processes, the default should be code.
- Where does state live, and who can read it? A shared conversation is state. So is a task ledger. If a member's identity document passes through it, that state has a retention and access obligation.
- How does the work stop? A fixed end, a budget, a confidence threshold or a hand-over to a person. A pattern without an explicit stop condition is a cost and reliability risk.
- What authority does each component have? Read-only, propose, or act. Agent capability is not agent authority explains why these must be set outside the prompt.
- How will it be tested? Fixed cases, a labelled set per component, or traced scenario runs. The pattern decides which of these is possible.
- Who approves the outcome? For onboarding at Langkloof, a member is accepted or declined by an onboarding officer. No pattern changes that.
Each pattern answers these differently, and some answer them badly for particular work. A group chat has no natural stop condition. A handoff chain makes it hard to say who owned the final outcome. A magentic manager is hard to test with fixed cases because its plan changes from run to run.
What Langkloof chose
The architects took the onboarding exception queue and worked through the six questions.
The steps could be listed. Every exception case needed the same three checks: is the identity document legible and consistent, does the proof of address support the stated address, and what did the branch or field agent record about the case? The order did not matter, and none of the checks needed the others' results. Only the final recommendation depended on all three.
That pointed to a coded workflow with a concurrent step. Three narrow, read-only agents run in parallel, each with one question, a tool budget and a typed output. Code aggregates the three findings with fixed rules. A clear pass or a clear decline goes to the onboarding officer's queue with a recommendation; anything mixed goes with the three findings side by side and no recommendation at all.
The proposal's five-persona crew was not rejected because crews are bad. It was rejected because, for this work, it answered the control questions poorly. The manager agent chose who spoke next, so the path differed between runs. The member-experience persona and the risk persona argued in free text, so disagreement was resolved by whichever spoke last. There was no stop condition beyond a turn limit. And the compliance persona had been given a tool that could update the member's status, which nobody had intended.
The chosen design also kept one thing from the proposal: separate agents for the separate checks. That split was justified on the grounds Multi-agent is an organisational choice describes, and on one the Microsoft guide itself gives for multi-agent designs: scenarios that need distinct security boundaries for each agent. It applied here because each check reads different data with different access rules. The address check reads utility-bill images. The branch-notes check reads free text that may contain sensitive personal information. Keeping them separate kept each agent's access narrow.
A decision table
| If the requirement is... | Prefer | Be wary of |
|---|---|---|
| A known sequence of transformations | Sequential workflow | Handoff, because it hides the path |
| Independent checks on the same input | Concurrent, with coded aggregation | Group chat, because agreement becomes conversational |
| Routing to the right specialist with an unclear entry point | Handoff with a recorded route and a single owner of the outcome | Unbounded handoff chains |
| Debate or maker-checker review of a draft | Group chat with a fixed round limit and a named approver | Letting the chat produce the final decision |
| Open-ended investigation where the plan itself is unknown | Magentic, read-only, with a budget and a human gate before any action | Write access in early stages |
| Any of the above in a regulated decision | Code owns transitions; a person owns the outcome | Patterns where a model decides who decides |
Choose the framework after this table, by asking which one implements the selected pattern with the least surprise: explicit state, inspectable traces, enforceable tool permissions and a way to stop. A framework that makes your chosen pattern awkward is the wrong framework for this work, however popular it is.
Failure modes
Pattern by persona. Naming agents after job titles invites the assumption that they should behave like a team of people, with discussion and judgement. Name them after their single question instead.
Implicit state. In group chat and magentic patterns, everything said becomes context for everyone. Decide what each agent may see.
The orchestrator becomes the authority. A manager agent that chooses which specialist runs is making decisions. If those decisions affect a member, they need the same evidence and review as any other.
Accountability across hops. Every handoff is a place where context or ownership can be lost. Delegation does not remove accountability gives a checklist for each arrow in the design.
Unbounded loops. Set iteration limits and budgets in code. The agent loop in plain English explains why a loop without them is not a design.
Key points
- A framework implements orchestration patterns. Choosing it first means accepting its answers to your control questions.
- Use the lowest level of complexity that works: a direct model call, then a single agent with tools, and only then multi-agent orchestration.
- Settle six control requirements first: who chooses the next step, where state lives, how work stops, what authority each part has, how it is tested and who approves the outcome.
- In regulated work, let code own the transitions and a named person own the outcome, whatever pattern runs inside.
- Split agents where access or responsibility genuinely differs, not to mirror an org chart.
Next: Part 3, Power Platform code apps: production starts before the first component. All parts are on the series page.
How CloudNala can help
CloudNala helps teams choose orchestration patterns on control grounds before they commit to a framework. We work through your process with you, settle who chooses each step, where state lives, how work stops and who approves outcomes, then shortlist frameworks that implement the chosen pattern cleanly, so that the design authority approves an architecture rather than a demonstration.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Practice Review or write to us at consult@cloudnala.co.za