Building for Stage 3: Architecture for Autonomous Agents at Enterprise Scale

Setting the Stage

In Article 1, we showed that enterprises are moving faster than expected through three stages of agent maturity. In Article 2, we explained why the existing stack - OAuth 2.1, OpenID Connect, MCP, SaaS connectors - reaches the limits of what it was designed to do.

Article 2 raised a critical question: These standards were built around human-centric security models: "Who are you? What systems can you access? What permissions do you have?" But Stage 3 enterprises need to answer a different question:

This article explores what a Stage 3 architecture needs to accomplish to answer that question. It's not about replacing OAuth or OIDC. It's about extending them with a capability designed specifically for autonomous agents operating at machine speed, where a single unauthorized action can propagate quickly across interconnected systems.

The Fundamental Shift: From Access Credential to Verifiable Authority

Today's systems issue tokens that establish a holder has been granted access or permissions. But a token generally does not, by itself, establish the complete chain of authority behind a specific transaction or whether that transaction falls within the conditions of that authority.

Stage 3 requires a different model. Instead of "here's a credential that proves I'm authorized," the system needs "here's proof of exactly what I'm authorized to do, by whom, under what constraints, and whether this transaction falls within those constraints."

This isn't an abstraction - it's a concrete architectural difference.

How It Works: Delegation, Policy, and Context

Imagine Sarah, Director of Accounts Payable, delegates authority to an agent with specific boundaries:

• Agent can approve payments under $5,000
• Agent can approve up to 4 payments per vendor per month
• Agent can approve payments to pre-approved vendors only
• Agent must not approve total spend over $200,000 to all vendors in a single day

This delegation is structured as a verifiable credential - a data structure that specifies who delegated the authority (Sarah), what agent received it, what constraints apply, when the delegation is valid, and a cryptographic signature proving Sarah authorized this. From Sarah's perspective, she simply defines these policies in an enterprise UI (integrated with Ping, Okta, Entra, or similar identity systems), and the cryptographic signing happens transparently in the background.

The key difference: the credential doesn't just say "agent is approved." It encodes the constraints themselves. The system can now make decisions at transaction time by checking: Does this specific payment fall within the constraints Sarah actually delegated?

A Concrete Example

Sarah's agent processes a $1,000 invoice from TechSupply Co. The system evaluates the transaction against both Sarah's delegated authority and real-time state (tracking aggregate limits across concurrent transactions to prevent race conditions):

• Is the agent authorized? Yes.
• Amount under limit? Yes.
• Vendor on approved list? Yes.
• Payment count within monthly limit? Yes (tracked in real time).
• Aggregate spend within daily limit? Yes (verified against current ledger state).

All conditions met: payment approved automatically.

Now imagine a different scenario. A new vendor not on the approved list submits an invoice. Same agent, same amount, same policy - but one constraint fails (vendor not approved). The transaction routes to a human approver. The system identifies which constraint was violated and escalates accordingly.

The power here is that the enterprise defined this routing logic once, in business terms they understand. The system then enforces it consistently across thousands of transactions.

Why This Matters: Autonomy Without Blind Approval

This architecture solves a critical problem enterprises face today:

"Approve everything and hope agents don't make mistakes, or require human approval for everything and eliminate the benefit of automation."

The answer isn't binary. Stage 3 enterprises need autonomy within defined authority. Let agents run freely within policy. Escalate exceptions to humans. Keep humans accountable for what agents do on their behalf.

The Green/Yellow/Red routing model captures this:

• Green Lane: All constraints satisfied. Agent acts autonomously.
• Yellow Lane: Some thresholds approaching limits. Flag for review.
• Red Lane: Outside agent authority. Escalate to human.

This is what enterprises mean when they talk about Stage 3 authority. Not "can the agent access the system?" but "what is the agent authorized to do right now, under these conditions?"

The Agent-to-Agent Problem

The architecture extends naturally to agent-to-agent delegation. Suppose Sarah's procurement agent needs to hand off work to an analysis agent to verify a new supplier.

The procurement agent doesn't hand over its token. Instead, it creates a signed credential documenting what it has already verified and delegating only the specific next step to the analysis agent. The analysis agent performs its task, signs off on what it found, and the chain is complete.

The audit trail now shows: Sarah delegated to Agent A, which delegated specific work to Agent B. No ambiguity about who authorized what. No copied tokens creating confusion about execution authority. Each step is documented and cryptographically linked.

With traditional bearer-token models, possession of the token generally doesn't reveal the delegation chain through which the authority was originally granted. With verifiable credentials, the delegation chain is encoded cryptographically. Any system can trace the execution path back to the original delegator and verify that each step was legitimate.

Integration with Existing Infrastructure

Here's the critical insight: this architecture must work with what enterprises have already built.

OAuth, API tokens, and existing connectors don't go away. They remain the entry point. The architecture adds a thin authorization layer that sits between the incoming request and the system of record. At that decision point, the system evaluates the transaction against the delegated authority and business policy.

This approach matters because it determines whether an architecture actually gets deployed. Systems requiring wholesale architectural migration take years. Systems solving a specific problem while working with existing infrastructure get adopted quickly.

The opportunity isn't to replace OAuth or OIDC. It's to extend them with transaction-level authority evaluation.

Why Cryptographic Verification Works

Two practical reasons stand out:

First: independent verification. If every authorization decision requires calling a central database, you've created a bottleneck and a single point of failure. With cryptographically signed credentials, systems can verify the provenance and integrity of authority without relying on a central authorization database for every decision.

Second: auditability. Sarah can't later claim she didn't authorize something if the credential is signed by her keys. The log of which transactions passed which policy checks can't be altered without breaking signatures. This is essential for regulated industries where audit trails are legal requirements.

Scope: Enterprises and Domains

While the Sarah/TechSupply Co. example is payment authorization, the architectural principle applies broadly. Insurance claim approvals, healthcare treatment authorization, logistics shipment release, contract review workflows - all can be governed by the same model: policy expressed in business terms, evaluated at transaction time, with cryptographic proof of the outcome.

The pattern is: delegation + policy + context = decision. Stage 3 enterprises need this across every domain where autonomous agents operate.

The Architectural Conclusion

Articles 1 and 2 identified the market and the gap. This article describes what a Stage 3 architecture accomplishes.

It lets enterprises delegate bounded authority to agents, define that authority in business vocabulary, evaluate transactions at decision time, and maintain cryptographic proof of every decision. It keeps humans in the authority chain. It works with existing infrastructure. It doesn't require architectural revolution.

Organizations that figure out how to deploy agents with this kind of architecture will achieve real Stage 3 maturity - agents operating autonomously at machine speed, constrained by business policy that humans define and can adjust, with verifiable proof that every transaction remained within authority.