Give the Agent a Contract
Before an AI system is allowed to act, define what it owns, what it can touch and when it must stop.
The enterprise conversation about AI is moving from assistance to execution. Recent research shows that leading companies are no longer using AI only to answer questions. They are connecting agents to internal context, software and repeatable workflows so they can complete actual work. At the same time, governance is struggling to keep pace with the number of agents entering the organization. (OpenAI, BCG)
This changes the central implementation question. It is no longer simply, “Which model should we use?” It is, “What authority should this system have?”
Companies usually answer that question indirectly through technical permissions. An agent receives access to a database, a shared drive or a customer platform. But access is not the same as responsibility. A person may understand that a price should not be changed without approval, that an unusual refund requires investigation or that a customer record must never be inferred from incomplete information. An agent only knows those boundaries if they have been made explicit.
Every production agent therefore needs something resembling a contract.
The contract should define the work the agent owns, the information it may use, the actions it may perform and the conditions that require human intervention. It should also identify the person responsible for its performance. “The AI did it” cannot become an organizational dead end.
This does not require beginning with an elaborate governance platform. A useful agent contract can fit on one page:
- Purpose: What specific outcome is the agent responsible for?
- Inputs: Which sources may it read, and which sources are authoritative?
- Actions: What may it create, modify, send or approve?
- Limits: What must it never do?
- Escalation: Which conditions immediately return the work to a person?
- Evidence: What record must it preserve so its actions can be reviewed?
- Owner: Who monitors its results and can suspend it?
The practical conclusion is simple: do not deploy an agent merely because it can perform a task. Deploy it when the organization can describe its authority as clearly as it would describe the responsibilities of a new employee.
The agent does not need more autonomy first. It needs a better-defined job.
