As enterprises connect AI agents across applications and business processes, a critical question emerges: how can they preserve authority, verify completion, and recover when something fails?
The next step I propose is accountable execution: every delegated task should carry explicit permissions, acceptance criteria, and evidence of what actually happened.
Here is how that approach could be implemented with Pega. This is an architectural proposal, not a claim that every control is a built-in product feature.
Start with the business case, not the agent
Pega Blueprint supports application design by suggesting case types, life cycles, business rules, data objects, and personas.
Use that foundation to define a process such as customer refund resolution, with stages for intake, validation, approval, execution, and verification. Then assign agents only to activities that benefit from interpretation or judgment.
An intake agent could interpret the customer’s message. A research agent could gather relevant account information. Neither should automatically receive permission to approve or issue a refund.
In this design, the Pega case retains the business owner, approvals, task status, and references to authoritative records. Agent conversations support the work; they do not replace its official record.
Give each assignment an enforceable contract
Instead of instructing an agent to “resolve the refund,” define a narrower assignment:
Review the approved account records, identify relevant transactions, and return a recommendation with supporting references. Do not change the account or initiate payment.
Store the assignment’s permitted tools, accessible records, output format, deadline, retry limit, and escalation conditions as structured configuration.
Enforce these restrictions through workflow checks and authorization at the services performing the actions—not merely through instructions to the model.
This follows an important principle in A2A’s enterprise guidance: implementing systems remain responsible for authorization, including restrictions on data and actions.
A recommendation is not approval. Delegation must not silently convert one into the other.
Connect capabilities without transferring unrestricted authority
Pega’s architectural guidance describes Agent2Agent, or A2A, as supporting agent collaboration, while Model Context Protocol, or MCP, connects AI applications with tools and data.
Use those connections selectively. A research agent might access transaction history through an approved tool and return findings to the case. The workflow would then evaluate the recommendation against business rules and route exceptions to an authorized reviewer.
Each receiving service should independently validate the caller’s identity and permitted action. Connecting two agents should not give either unrestricted access to the other’s systems.
For delayed actions, recheck whether the approval and relevant information remain valid before execution.
Verify the outcome outside the agent’s response
An agent saying “refund completed” is not sufficient evidence that the correct transaction occurred. Anthropic’s evaluation guidance similarly distinguishes an agent’s transcript from the actual resulting state of its environment.
For our illustrative refund workflow, require confirmation from the payment system: the transaction identifier, account, amount, and required completion status must match the approved request.
Record this confirmation alongside the approval and policy version in the case. This creates an evidence receipt: a traceable record of authorization, execution, and verification.
The receipt does not guarantee that every judgment was correct. It makes the action inspectable and its completion testable.
Only move the case to resolved when its defined acceptance criteria are satisfied. Missing or conflicting evidence should trigger an exception, not a confident summary.
Design recovery before expanding autonomy
Design-time governance should be supported by runtime monitoring and recovery. NIST’s AI Risk Management Framework Playbook includes incident response, human override, and mechanisms for deactivating systems when necessary.
In this implementation, set limits on retries, execution time, and resource use. Before retrying a payment, check whether the original request already succeeded. Use a unique operation identifier with duplicate-prevention support in the receiving service.
When the result remains uncertain, pause the action and assign an accountable person to investigate.
Begin with agents that make recommendations. Permit automatic execution only for clearly defined, tested, lower-risk scenarios. Higher-risk actions should follow appropriate approval requirements.
Improve the workflow without letting it rewrite its authority
Operational evidence should inform improvements, but agents should propose changes rather than independently alter business policy.
Test proposed changes against normal cases, missing information, conflicting results, unauthorized requests, and interrupted operations. Capability and regression evaluations should both be part of this process.
I would measure success through verified completion rates, exception frequency, human rework, and cost per verified outcome—including retries and corrective work.
The objective is not to maximize agent activity. It is to complete the business obligation correctly, with proportionate controls.
The next step is to make accountability survive every handoff.
Agents contribute intelligence. The workflow preserves authority. Independent checks establish what happened. People remain responsible for consequential decisions and unresolved exceptions.
That is how enterprise AI moves from connected agents to accountable execution.