Frameworks, MCP, and Multi-Agent Systems

You don't have to build all this from scratch. A few tools matter, and one standard is quietly changing everything.

• LangGraph: think of your agent as a flowchart where some steps are the model deciding what's next. Its superpower is durable pause-and-resume: a step can pause for an approval and wait days, surviving restarts: then continue. That is exactly the shape of an approval workflow, which is why it fits IAM so well.
• LangChain: a big library of connectors and helpers; useful for wiring, but read what its convenience wrappers actually send (they can bloat your prompt).
• Copilot Studio. Microsoft's low-code agent builder. You trade control over the loop for enterprise plumbing (Teams, sign-in, data policies). The pattern that works: use it as the friendly front door, and have it call your real code agent for anything with state or writes.
• MCP (Model Context Protocol): the big one. Instead of building a custom integration for every combination of AI × system, you wrap each system (identity platform, ticketing, GitHub) in one MCP server, and every AI client can use it. It turns an M×N integration mess into M+N. Treat each server as a security boundary with its own limited credentials.
• Microsoft Agent Framework (MAF). Microsoft's newer, protocol-first successor unifying Semantic Kernel and AutoGen, built around A2A (agent-to-agent communication) and MCP for cross-runtime interoperability. It's becoming the foundation under Copilot Studio's agent layer: if you're already on Entra ID and Azure, this is where Microsoft is pushing governance and identity integration, and it's worth watching even if you're not ready to adopt it yet.

The meta-advice: start with the simplest thing that works: often a couple hundred lines over the raw API, and reach for a heavy framework only when durable state and approvals are the actual problem. Your lasting assets are your evals, prompts, tool definitions and traces; frameworks are swappable plumbing around them.

Many agents working together

Sometimes one agent isn't enough and you split the work across several. There's a standard cast, and, crucially, the roles map onto a familiar security idea:separation of duties.

Some architectures split what the table above merges: a Planner Agent decides what should happen: breaking a goal into an ordered plan, while a separate Orchestrator executes that plan, coordinating the other agents and re-routing when a step fails. Smaller systems fold planning into the Orchestrator's job, like the table above; bigger ones split them because a plan is worth reviewing (by a human, or a Reviewer agent) before anything starts executing. Both terms show up in vendor docs: worth knowing which one a given system means. A quarterly access review is a clean example: the Planner decides the shape of the run (pull entitlements → group by risk → route to managers → escalate anything stale after 5 days), and the Orchestrator is what actually runs that plan and babysits it to completion.

Notice the pattern: researchers read, workers write, reviewers check, the orchestrator coordinates. That's separation of duties enforced bywhat tools each agent is allowed, not by a promise in a prompt.

But multi-agent is not free. A well-known figure: one production multi-agent research system used about 15× the tokens of a single chat. It only paid off because the task genuinely split into independent parallel pieces. The honest rule is single-agent until proven otherwise, and the most common legitimate reason to split is simply to keep a messy 200-step investigation out of the main agent's context, returning only a clean summary.

When you do split, the hard part is the contract between agents. Most multi-agent failures are communication failures. "Research vendor X" is a bug; "Return{pricing, deployment_options[], compliance[]}for vendor X, at most 10 searches, cite sources" is an interface. Force structured results with explicit confidence and gaps, so a worker can't quietly return a plausible-but-empty answer that the orchestrator then builds on.