Autonomous to Do What?

Let's take a really common thing leaders say: "Take care of this customer." You already understand that it comes with limits. I didn't tell you to rewrite their contract, change our banking instructions, or promise whatever makes them happy. Some of those boundaries live in policies and access controls. Others live in experience and the understanding that you should probably ask before doing something expensive.

Now give that instruction to an AI agent. It can read the account history, look up a policy, and work toward a resolution. But we still need to ask what we've authorized it to do on our behalf.

What are we actually delegating?

"Is this AI autonomous?" sounds like a straightforward question. I don't think the answer tells us much until we name the action.

Take a billing dispute. An agent might summarize the account history and recommend a credit. A person reviews the recommendation and performs the transaction. We've delegated analysis, while keeping the decision and the financial action with an employee.

Then we might let the system determine whether the dispute qualifies under company policy, while a person still approves the credit. Later, we might allow the agent to issue credits within defined limits. The interface could look almost identical in all three cases. Behind it, the business has made very different decisions about authority.

The same agent might categorize tickets on its own, require approval before changing a contract, and have no permission to change payment instructions. Those are permissions attached to particular actions. A model's ability to suggest a sensible outcome doesn't automatically give it permission to make that outcome happen.

The harness has work to do

The harness is the software around the model that coordinates context, tool calls, and execution. It can apply fixed permission rules before a tool runs, rather than leaving those rules to the model's interpretation. Whether those controls work depends on what we've built and what the systems behind its tools permit.

For the billing agent, I want the refund tool to enforce which accounts it can touch and what amounts it can issue. A transaction cap alone doesn't control total activity, so limits need to cover repeated actions, too. When a request falls outside the approved scope, the workflow needs to pause and reach someone who's authorized to decide.

Prompts matter, but telling an agent "don't issue an unauthorized refund" isn't the same as giving it a tool that refuses one. Those permissions need enforcement through the identities, policy checks, and tools around the model. Someone also needs to own them: why they exist, what evidence supports them, and who can change or revoke them. And by the way, experience matters here. Someone who's handled these disputes for years can help define where the agent should stop and ask.

That responsibility extends across handoffs. If one agent says a charge might qualify for a credit, a later summary shouldn't turn that into "approved." The agent issuing refunds may have permission to issue eligible credits, but this particular transaction still needs the evidence and approval required by policy. We have to govern the whole workflow, including what gets lost between its parts.

A person clicking Approve isn't the whole control

This is usually where the human-in-the-loop conversation starts. And for the record, I prefer human-led. People should decide what we're trying to accomplish, what the agent's allowed to do, and when it needs to ask. They don't need to approve every action to remain responsible for those decisions.

When a person does need to review an action, I want them to have enough information and time to decide. They should be able to see the relevant account details, which policy applies, and what action they're approving. Hundreds of opaque requests an hour don't leave much room for judgment, however reassuring the approval screen looks.

Routine actions with limited consequences may run within tested boundaries. More consequential actions may need individual review. Decide that deliberately, rather than assuming an approval button makes every workflow safe.

A good demo shows us a successful case. Before release, I'd want to see what happens when the agent requests a refund outside its permissions, receives conflicting information, or can't obtain the approval it needs. The operating record should show what the system actually did.

And someone needs a practical way to intervene. Revoking access can stop future actions; it doesn't unsend confidential information or guarantee that a transaction can be recalled. If the business comes to depend on the workflow, it also needs a workable fallback when that workflow stops.

Start with one consequential action

You don't have to resolve every AI governance question before making progress. Start with one workflow your business wants to improve. Identify the highest-consequence action the agent could take, and decide whether it's prohibited, requires approval, or can happen within specific limits. Name the person who can authorize that arrangement, then test the boundaries before expanding them.

I want businesses to be able to delegate more useful work to AI. If you're considering an AI agent for your business, bring us the workflow. We can work through where an agent could help, what it should be allowed to do, and where a person still needs to decide.