CIO published a framework this week that gave the agentic enterprise its first clear architectural diagram. Micro agents execute narrow tasks. Macro agents orchestrate workflows. But the governance layer - who defines outcomes and authorization scope - is unnamed.
As someone who's been building and governing agent workflows for the past year, I want to walk through what this architecture actually looks like in practice, and why the governance gap matters more than most engineering teams realize.
The Architecture
The micro/macro split is intuitive if you've built any multi-agent system.
Micro agents are scoped tight. One tool, one task, one output format. Think: "validate this CSV against the schema," "summarize this PR," "check this deployment status." They're the functions in your agent pipeline.
Macro agents chain micro agents into workflows. They handle sequencing, error routing, and state management across a multi-step process. "Process this customer onboarding end-to-end" is a macro agent job.
If you're a developer, this maps to something you already know: micro agents are microservices, macro agents are orchestrators. The patterns are similar. The failure modes are too.
The Governance Gap
Here's what CIO flagged and what I've experienced firsthand: nobody defines the contract between the human and the macro agent.
In a microservices architecture, you have SLAs, API contracts, and monitoring. In a macro agent architecture, you need the equivalent:
Outcome contracts - not "process the onboarding" but "new customer reaches first value milestone within 48 hours with zero manual intervention." The macro agent optimizes for whatever you define as done. If your contract is vague, the agent's behavior will be unpredictable.
Authorization scope - this has been my biggest learning. Most agent failures I've seen aren't capability failures. They're scope failures. The agent could do the thing, but nobody specified whether it should.
A simplified example of what authorization scope definition looks like in practice:
agent: onboarding-orchestrator
type: macro
authorization:
can_access:
- customer_profile (read)
- onboarding_checklist (read/write)
- notification_service (write)
cannot_access:
- billing_system
- admin_settings
- customer_communications (direct)
escalation:
trigger: confidence_score < 0.7
action: queue_for_human_review
scope_boundary:
max_actions_per_run: 50
timeout_minutes: 30
requires_approval: [delete_*, modify_billing_*]
This looks like infrastructure config. It is. But someone needs to decide what goes in each field, and that decision is a project management decision, not an engineering decision. What the agent can touch, when it escalates, what requires human approval - scope and risk decisions.
Why Authorization Scope Is the Most Overlooked Governance Tool
I posted about this on social media this week and it was my highest-engagement topic by far. The reason: developers building agent systems are hitting authorization failures in production and realizing nobody defined the boundaries before deployment.
The pattern I keep seeing:
- Team builds agent with broad capabilities
- Agent works great in testing (controlled environment, predictable inputs)
- Agent goes to production and immediately does something nobody expected
- Team scrambles to add guardrails after the fact
Sound familiar? It's the same pattern as deploying a service without rate limiting. The fix is the same too: define the boundaries before deployment.
The difference is that service boundaries are well-understood engineering practice. Agent authorization boundaries are not. There's no equivalent of an API gateway for agent scope. Yet.
AWS Agent Registry: First Infrastructure
AWS launched Agent Registry in preview this week, and it's the first serious infrastructure play for this problem.
What it provides:
- Centralized registry for discovering and cataloging agents
- Approval workflows for deployment
- Ownership records and accountability chains
- Semantic search across agent inventories
- MCP server integration
For developers, this is a service registry with governance features. For the person defining what agents are allowed to do (whoever that turns out to be), it's the first production-grade tool for the job.
The gap: Agent Registry handles discovery and lifecycle management. It doesn't handle runtime authorization scope. You still need to define and enforce what each agent can do during execution. That's a layer on top that doesn't exist as a product yet.
Edge Cases Are the Real Trust Audit
I had a conversation with an agent tool maker on Product Hunt this week. Asked how they handle edge cases. The response: "it's the hardest part."
Edge cases in agent deployment are different from edge cases in traditional software. In traditional software, edge cases produce errors. In agent systems, edge cases produce confident-looking wrong actions. The agent doesn't crash - it does something unexpected with full confidence.
The governance response: define edge case behavior in the authorization scope. What happens when input is ambiguous? When the API times out? When the agent's confidence is low? These need explicit handling, not default behaviors.
The PM-Shaped Hole
I keep coming back to this: the governance decisions in agent architecture are project management decisions wearing engineering clothes.
Outcome contracts are acceptance criteria. Authorization scope is project scope. Lifecycle management is portfolio governance. Approval workflows are change management.
The tooling is developer-facing right now. AWS Agent Registry's documentation assumes you know what an MCP server is. But the decisions being encoded in that tooling are PM decisions.
Whether PMs claim this work or engineers do it by default will depend on who moves first. The architecture is published. The infrastructure is shipping. The governance decisions are being made now, with or without project management input.
What does authorization scope look like in your agent deployments? Drop a comment — I'm curious whether teams are defining this upfront or retrofitting it after the first production incident.
Top comments (0)