AI-103 courseLesson 10 of 18 · 15 min
Multi-Agent Solutions and Workflows With Approvals and Safeguards (AI-103)
XUtilHub Team ·
Exam skills covered
- Design workflows, tool-augmented flows, and multistep reasoning pipelines
- Implement orchestrated multi-agent solutions
- Build autonomous or semiautonomous workflows with safeguards and approval flow controls
- Integrate monitoring into deployed agents, evaluate agent behavior, and perform error analysis
Some problems are too big or too varied for one agent: a support system that handles billing, technical and sales questions, or a review process that needs legal, financial and security checks. Multi-agent solutions split the work between specialised agents and orchestrate them. This lesson covers orchestration patterns, workflows, safeguards and monitoring.
Single agent first
Multi-agent designs add latency, cost and new ways to fail. Use one agent with a few tools when it can do the job reliably. Reach for multiple agents when:
- Tasks need different instructions, tools or permissions (a refund agent shouldn't have HR tools)
- One agent's prompt and tool list grow so large that quality drops
- Steps can run in parallel
- Different teams own different parts
Orchestration patterns
| Pattern | How it works | Example |
|---|---|---|
| Sequential | Agents run in a fixed order; each refines the previous output | Draft → fact-check → edit → translate |
| Concurrent (fan-out / fan-in) | Agents work on the same input in parallel; results are aggregated | Legal, financial and security review of one contract |
| Handoff | An agent transfers control to the best specialist, which then owns the conversation | Triage agent → billing agent |
| Group chat | Agents discuss in a shared thread, managed by a chat manager | Brainstorm and critique a design |
| Manager / magentic | A manager agent plans, assigns tasks to workers, tracks progress and re-plans | Open-ended research task |
Also common: agent as a tool, where a main agent calls another agent like a function and keeps control (the "connected agents" idea).
Workflows: deterministic structure around agents
Not everything should be decided by a model. Workflows define steps, branches and loops explicitly, and use agents where judgment is needed:
- Foundry workflows let you build multi-agent and human-in-the-loop flows visually (or as YAML) in the Foundry portal, then run and version them like agents.
- Microsoft Agent Framework (the successor to Semantic Kernel and AutoGen for agents) is an open-source SDK for Python and .NET. It provides agents, graph-based workflows with typed messages, the orchestration patterns above, checkpointing, and OpenTelemetry tracing.
Conceptually, a sequential workflow in Agent Framework looks like this:
from agent_framework import SequentialBuilder
workflow = SequentialBuilder().participants([writer, reviewer, translator]).build()
async for event in workflow.run_stream("Write a product announcement for our new API."):
... # stream intermediate outputs and the final result
Class names in fast-moving SDKs change, so focus on the idea: declare the participants and the pattern, and let the framework route messages.
Tool-augmented flows and multistep reasoning pipelines follow the same idea: break a problem into explicit steps (retrieve, analyse, draft, verify), each one a model call, tool call or rule, instead of hoping one prompt does everything.
Safeguards for autonomous and semi-autonomous workflows
The more autonomy, the more guardrails you need:
- Approval steps (human-in-the-loop): pause before high-impact actions such as payments, emails to customers or deleting data. The workflow waits for an approve or reject event, then continues.
- Limits: maximum turns or iterations, timeouts, token and cost budgets
- Scoped permissions: each agent has its own identity and only its own tools
- Validation: check tool arguments and outputs with code (amount ≤ limit, recipient is internal)
- Escalation: hand off to a person when confidence is low or the user asks
- Checkpointing: save workflow state so long-running work can resume after failure or approval delays
- Kill switch: a way to stop a misbehaving agent quickly
Semi-autonomous is the usual enterprise choice: agents do the work, people approve the risky steps.
Monitoring, evaluation and error analysis
Deployed agents need the same observability as any service, plus agent-specific views:
- Traces show each agent turn, handoff, tool call, latency and token use, so you can see where a run went wrong
- Agent evaluators (intent resolution, task adherence, tool call accuracy) run on recorded conversations
- Error analysis: group failed runs by cause (wrong handoff, bad tool arguments, missing knowledge, loop hit the limit), fix the most common cause, re-evaluate
- Alerts on failure rate, average turns per task and cost per task
Example: billing questions keep landing with the technical agent. The traces show the triage agent's instructions don't mention invoices. Add examples to the triage instructions, re-run the handoff evaluation set, and confirm the routing accuracy improves.
Key takeaways
- Prefer one agent until specialisation, permissions or parallelism justify more.
- Patterns: sequential, concurrent, handoff, group chat, manager (magentic), plus agent-as-tool.
- Workflows (Foundry workflows, Microsoft Agent Framework) add deterministic structure, checkpoints and human steps.
- Safeguards: approvals, limits, scoped identities, validation, escalation. Monitor with traces, agent evaluators and error analysis.
Next lesson: tuning, reflection and observability.
Check your understanding
Exam-style questions on this lesson. Get them all right to mark the lesson complete.
Finished reading?