As AI agents move from helping people draft work to taking action across systems, organizations need something more precise than a list of use cases. They need an explicit agreement about outcomes, authority, access and oversight.
I use the term four contracts as a practical management lens. They are not necessarily legal contracts. They are documented commitments that connect each agent to a business purpose and make its boundaries understandable to business, technology, risk and operations teams.
The outcome contract
What result is this agent responsible for improving? Define the workflow, baseline, expected benefit, full operating cost, measurement period and accountable business owner.
Evidence: business KPI, baseline, review cadence.The decision contract
What may the agent recommend, decide or execute? Specify approval thresholds, exceptions, hand-offs and when a human decision is mandatory.
Evidence: decision-rights matrix and escalation path.The access contract
Which data, tools and systems can the agent use, and for what purpose? Apply least privilege, clear identities, sensitive-data controls and revocation.
Evidence: permissions inventory and access logs.The assurance contract
How is the agent evaluated, monitored, challenged and stopped? Define quality thresholds, incident handling, traceability, accountability and human override.
Evidence: evaluations, monitoring and rollback plan.The framework in practice
Consider a hypothetical agent that resolves routine customer-service requests. A traditional implementation discussion asks which model to use and how to integrate it with the service platform. The four-contract discussion begins earlier and continues further.
- Outcome: Improve first-contact resolution and customer experience without increasing risk or cost to serve.
- Authority: Permit routine responses and approved account actions, but require human approval for sensitive changes and disputes.
- Access: Restrict the agent to the minimum customer records and actions needed for the specific case.
- Assurance: Monitor failure patterns and exceptions; record interventions; be able to suspend automated action safely.
This example is illustrative, not a case study or a claim of measured benefit.
These contracts must remain live
Approving an agent once is not enough. Its permissions, models, tools, workflows and business context can change. Each contract therefore needs an owner, evidence and a trigger for reassessment.
- Before deployment: record the expected outcome and baseline; approve the decision boundaries, least-privilege access and evaluation criteria.
- During operation: review business KPIs alongside exception rates, interventions, cost per completed outcome and access activity. An agent can meet a technical quality threshold and still fail to improve the business process.
- When something changes: reassess after a new tool connection, expanded permission, material model update, changed business rule or significant incident. Changes in authority and access should not silently inherit an old approval.
- When evidence disappoints: narrow the scope, require additional human approval, redesign the workflow or suspend the agent. The ability to stop is part of responsible scale, not a sign that deployment has failed.
The practical test is whether a business leader can answer, at any point, what the agent is doing, why it is permitted to do it, what value it is producing and who can intervene.
Five questions I would put to an executive team
- Which end-to-end process outcomes justify agent deployment, rather than an isolated automation?
- Who can change the process and is accountable for the value?
- What is the boundary between advice, delegated action and human authorization?
- How do we know the agent's access still matches its legitimate task?
- What evidence would convince us to scale, revise or stop the agent?
How this fits existing standards
This working model is intended to complement, not replace, established risk-management and security guidance. The US NIST AI Risk Management Framework and its Generative AI Profile offer structured ways to consider AI risks across the lifecycle. An organization still needs to apply applicable laws, sector rules and internal control requirements.
The distinct focus of this proposal is operational evidence at the workflow level, especially ownership of realized business outcomes and full unit economics. It should be read alongside existing approaches such as the World Economic Forum and Capgemini AI Agents in Action playbook, rather than as a replacement for those established approaches. It is a proposal for discussion and refinement, not a tested industry standard.
From a pilot to an operating decision
Take the hypothetical customer-service agent above. A pilot might demonstrate accurate responses to routine questions. The decision to scale is different: the organisation needs evidence of end-to-end resolution, clear approval limits for account changes, monitored access to customer information, and an agreed response when the agent cannot proceed safely.
The four contracts are designed to make that scaling decision explicit. They do not guarantee safety, compliance or return on investment. Their value is in helping executives ask the same operational questions before and after deployment, rather than handing each concern to a different team and hoping the pieces align.
Where it needs to evolve
I am seeking independent critical feedback on this framework, including questions about originality, full workflow economics and the limits of delegated accountability. There are open questions around how agents share responsibility across a chain of actions, how to audit rapidly changing permissions and how to assign the economics of shared models and infrastructure. These are research questions, not problems solved by naming four boxes. I am developing them further in the research agenda.
Related references
The four-contract structure is a proposed perspective by Alper Benli. It does not imply endorsement by NIST or any employer.