An AI agent can prepare a quotation, update a record and send an email. Put those three tools together and the demonstration looks like a complete business process. But one question is still unanswered: who allowed it to make a commitment on the company’s behalf?
I think this is where the conversation about enterprise agents needs to become more precise. We spend a lot of time asking whether an agent can do the work. We also need to ask whether it may do the work, under which conditions, and who can stop it.
Being able to calculate a price does not confer the authority to approve a discount. Access to customer information does not settle whether it may be sent to an external service. The ability to edit a rule does not include the right to approve that rule.
A connection gives an agent reach. It does not give it a mandate.
Start with the job, not the tool list
Consider an illustrative quotation assistant for a manufacturer. Its job is to prepare an internal draft for a sales engineer. It can read approved cost information and the relevant drawing revision. It can identify missing inputs and explain its calculation. None of that requires permission to send a binding offer to the customer.
Now suppose somebody adds an email connector. Has the job changed? Technically, the agent can do more. Organisationally, it should still have the same bounded assignment unless a responsible person explicitly changes it. Otherwise a technical configuration change has quietly become a delegation of business authority.
That is why I would begin with a short description of the job: its purpose, the people responsible for it, its permitted actions, its limits and its escalation route. The connector list comes after that.
Capability, tools and authority are different things
Capability describes a kind of work an agent can perform. A tool provides an interface through which it can perform an operation. Authority concerns the actions it is permitted to take in a particular context. Treating these as interchangeable makes an agent easier to demonstrate and harder to manage.
“May use email” is not a sufficient description of an assignment. Prepare a draft or send it? To an internal reviewer or an external customer? For which project, using which information, until when? Does sending require a separate approval? Reading, exporting, changing and communicating information are different acts, even when they happen through the same application.
Responsibility needs the same precision. The person maintaining a connector is not automatically the person entitled to approve a commercial commitment. A business sponsor is not automatically the owner of every dataset the agent can reach. A useful definition makes those boundaries visible to the people involved.
This is part of why we are building ADL
At IndustrialMind, we are developing ADL, the Agentic Definition Language, to make business definitions explicit and connected. For governance, the important connection is between the work an agent is supposed to do, the context and information it uses, the policies that constrain it, and the evidence of what happened.
ADL distinguishes a Capability from a Tool, and a Decision from an Action. Its Policy construct can express permissions, obligations, prohibitions, limits, approval and evidence requirements. These distinctions let a team discuss the assignment without reducing it to a prompt and a collection of credentials.
But a definition is not an enforcement mechanism. Writing “requires approval” does not cause an API to reject an unapproved request. That check belongs in the consuming application, identity and permission systems, connectors and execution paths. If credentials allow the agent to bypass the controlled route, the policy text does not close that gap.
For me, this is an essential boundary: validating a definition is not evidence that its controls work. The target environment has to demonstrate both the allowed path and the refusal path.
Human review has to mean something
I do not think governance means putting a human approval button in front of every small operation. It means identifying where judgment and responsibility matter, then giving the reviewer enough information and real authority to exercise them.
For the quotation assistant, an approval should identify the version being approved, its assumptions, the intended recipient and the external action it permits. If the price or terms change, the earlier approval should not silently carry forward. The reviewer needs to be able to question the evidence, reject the proposal or send it back for revision.
A person who sees only a green “approve” button, without the relevant context or time to evaluate it, is not a convincing control. The presence of a person in a diagram is not the same as meaningful oversight.
An agent also needs a way out
A useful question before enabling an agent is: what would it take to stop this assignment tomorrow?
The answer should cover more than changing a status in a directory. New work may need to stop. Scheduled jobs and in-flight tasks need attention. Credentials and delegated permissions need to be revoked where appropriate, and the connected systems need to confirm the result. Historical decisions and evidence should remain available to the people entitled to review them.
The sponsor may leave. An authorization may expire. The purpose of the work may change. An external system may behave unexpectedly. These are ordinary reasons to review an assignment, not exotic edge cases.
Stopping an agent also cannot undo everything it has already done. An email that has been sent or a physical action that has occurred may require follow-up or a compensating action. Deleting the agent’s record is not a substitute for dealing with those consequences.
Trust grows through explicit changes
I would rather start with a useful, narrow assignment than broad access justified by a promising demonstration. A read-only agent that organises evidence for a human decision can already have a meaningful job. Broader authority can follow when the business has evidence that it should.
In our ADL governance approach, an agent can propose an improvement; it cannot approve its own governing changes, release them, weaken its guardrails or grant itself new authority. Better performance is a reason for people to consider a change, not permission for the agent to make that change itself.
The practical test is simple: can the team explain who allowed this agent to do what, on which basis, within which limits—and show how those limits are checked and how the assignment ends?
That is the kind of trust I want us to build. Not confidence that the agent will always make the right choice, but clarity about the choices it is allowed to make and the people responsible for them.
Editorial note: This is my design perspective as co-founder and CEO of IndustrialMind.ai. ADL is under development. The quotation assistant is illustrative, not a customer case. The runtime controls and lifecycle practices described here are requirements to implement and verify, not a claim that every capability is available in the current product.
