Your AI Agents Are Flying Blind
Orchestration Is the New Portal.
The industry is building orchestration frameworks because every API response is a dead end. Agents complete an action, get JSON, and figure out next steps from scratch. Orchestrators are the new custom portals: scaffolding around broken infrastructure.
"Orchestration frameworks exist because responses do not carry navigation intelligence. You build workflow graphs, decision trees, and agent hierarchies to compensate for the fact that every API response expects you to figure out the rest yourself. That is not a workflow problem. That is an affordance problem."
— Martin Gee, Founder & CEO, IdentityRM
Your agent provisions a user.
The response carries the result. Nothing else. The agent is on its own.
Now what?
The user exists, but has no role. No group memberships. No application entitlements. The agent knows the action succeeded. It does not know what should happen next. It does not know what can happen next.
So it guesses. Or it stalls. Or it calls an orchestration framework — LangChain, LangGraph, CrewAI — that tells it what to do because the response did not.
This is why the industry is building orchestration layers. Not because orchestration is inherently valuable, but because every API response is a dead end. The agent completes an action, gets JSON back, and has to figure out the rest from scratch. Every single time.
And every agent that provisions a user, assigns a role, or approves an access request is exercising delegated administrative authority. These are not scripts running API calls. They are administrators — flying blind.
Scaffolding is not architecture.
The Dead End Problem
Every agent faces the same three questions after every action:
- What should I do next? — The success path. The operation worked. What is the logical follow-up? Assign a role? Add to a group? Trigger a downstream workflow?
- What do I do if something goes wrong? — The recovery path. The operation failed, or partially succeeded. What are the available remediation steps? What am I allowed to retry?
- What am I not allowed to see? — The security boundary. Are there resources, roles, or operations outside my scope? How do I know if I am approaching a boundary I cannot cross?
No API answers these questions. Not REST. Not GraphQL. Not MCP. The response carries the result of the action and nothing else. The agent is left with a payload and no map.
So what do you build? An orchestration layer. A workflow graph that hardcodes the answers to those three questions for every action, every error condition, every scope boundary. LangChain calls them “chains.” LangGraph calls them “state machines.” CrewAI calls them “crews.” The names change. The pattern does not.
When every response is a dead end, orchestration becomes the glue.
And the glue becomes the product. The orchestration layer accumulates business logic, error handling, scope enforcement, retry strategies, and institutional knowledge. It becomes the thing that actually knows how your IAM processes work. Not your identity platform. Not your MCP server. The orchestration layer.
Sound familiar?
The Orchestrator Is the New Portal
If you have read Boulevard of Broken Dreams, you recognise this pattern. Twenty years of enterprises building custom admin portals — not because portals are valuable, but because identity platforms were too complex for anyone except the identity team. Portals were compensation. Scaffolding around platforms that should have solved the problem themselves.
Orchestration layers are the same pattern, one generation forward.
A LangChain sequence that provisions a user, assigns a starter role, adds group memberships, and triggers a welcome notification. Hardcoded to one IdP, one HR source, one set of default roles. Six months later the company reorganizes, the HR system migrates to Workday, and the chain silently provisions users into roles that no longer exist. Nobody rewrites the chain. They build a second one next to it.
A LangGraph state machine that walks an agent through quarterly access reviews: pull entitlements, compare to policy, flag exceptions, route approvals. Works for one certification campaign. Breaks when audit requirements change. Gets forked into a second graph. Then a third.
A CrewAI hierarchy where a "manager" agent delegates to specialist agents: one for Entra, one for Okta, one for ServiceNow. Each specialist has its own prompt engineering, its own retry logic, its own scope handling. The engineer who tuned the prompts takes a new job. Within a month the Okta specialist is granting admin roles it was never supposed to touch, and nobody can explain why because the logic lives in a prompt template, not a policy.
Same economics. Same lifecycle. Same failure modes.
| Custom Portals (2000s–2020s) | Orchestration Layers (2025+) | |
|---|---|---|
| Built to compensate for | Platforms too complex for business users | Responses too bare for autonomous agents |
| Hardcoded to | One org structure, one IdP | One workflow, one tool set |
| Breaks when | Company reorganizes | Requirements change, APIs evolve |
| Maintained by | The developer who left | The prompt engineer who left |
| Accumulates | Custom RBAC, UI logic, tribal knowledge | Custom chains, state graphs, agent prompts |
The boulevard of broken portals becomes the boulevard of broken orchestrators. Different scaffolding. Same underlying failure: the platform did not carry enough intelligence to make the scaffolding unnecessary.
That is not a workflow problem. That is an affordance problem.
The Navigation Model
Don Norman coined the term “affordance” in design: a property of an object that tells you how to use it. A door handle affords pulling. A flat plate affords pushing. The design communicates the next action without requiring a manual.
API responses have no affordances. They carry data — what happened. They do not carry navigation — what should happen next. The orchestration layer is the manual you write because the door has no handle.
Same provisioning call. Same user. But this time, the response carries navigation intelligence.
Assign starter role, add to group, notify manager
Resolve SoD conflict, permitted retry steps
Out-of-scope resources invisible, not denied
The response navigates. No chain, no graph, no middleware. The agent knows what to do next.
This is what IdentityRM calls Contextual Agent Navigation — three navigation surfaces built into every MCP response. The agent never guesses, never leaks, never stalls.
| Orchestration Layer | Contextual Navigation | |
|---|---|---|
| Navigation source | External workflow graph | Response itself |
| Business logic lives in | Chain/graph definitions | Domain intelligence layer |
| Maintained by | Prompt engineers, developers | Platform (self-describing) |
| Adapts when requirements change | Rebuild the graph | Navigation updates automatically |
| Security enforcement | Middleware, guard rails | Built into every response |
What disappears: workflow graphs, decision trees, agent hierarchies, retry logic, scope-checking middleware. Not because those problems go away — but because the response solves them at the source.
Responses Should Navigate
The industry spent twenty years building portals around identity platforms. Now it is building orchestrators around agent protocols. Same pattern: scaffolding that accumulates business logic, tribal knowledge, and technical debt — because the underlying system returns data without direction.
Your agents are flying blind because every response they receive is a dead end. Fix the response, and the orchestrator becomes scaffolding you can remove.
IdentityRM embeds Contextual Agent Navigation into every MCP response — success paths, recovery paths, and security boundaries built into the protocol. No orchestration layers required. See the platform or request a demo.
Previously: Boulevard of Broken Dreams — the twenty-year history of custom admin portals that orchestration layers are now repeating.
