An AI agent should execute a customer agreement only when its authority, approved terms, and stopping conditions were defined before the deadline arrived. If the team cannot explain exactly what the agent may sign, change, or reject, the signature should wait for a human.
At 4:47 on a Friday afternoon, Kweku had thirteen minutes to make that call.
Kweku is a composite founder, drawn from a pattern I have seen in small SaaS teams operating across Accra, Berlin, and the US. He had six employees, a shrinking runway, and a buyer whose procurement lead was leaving for the weekend at five. On his laptop sat a customer agreement that could cover the next payroll cycle. Beside it, an AI agent had completed the company details, checked the commercial terms against the approved proposal, and placed the signature field where it belonged.
One button remained: allow the agent to execute.
The contract contained one unresolved sentence
The headline terms looked right. The annual amount matched the proposal. The payment schedule matched the version Kweku had approved that morning. The customer name, address, and start date were correct.
Then the agent flagged a sentence in the liability section.
The buyer had changed the wording after the last review. The new clause appeared to extend responsibility beyond the service Kweku’s company actually controlled. The agent classified the change as material, but it also estimated that the rest of the agreement matched the approved position.
At 4:49, the procurement lead sent a short message: “Can we close this before I leave?”
Kweku could let the agent sign and preserve the deal’s momentum. He could stop the process and risk losing the buyer’s internal approval window. There was no comfortable option hiding between those two.
The bad ending was concrete. If he delayed, the contract might return to another approval queue on Monday, or disappear into it. If he signed, he could accept a liability his company could not afford.
This is where teams often confuse speed with readiness. The agent had done useful work. It had found the changed clause faster than Kweku would have during a rushed final read. That capability did not answer the decision in front of him.
Execution authority needs a smaller boundary
Kweku had originally given the agent a broad instruction: execute agreements when the commercial terms match an approved proposal.
That sounded precise when he wrote it. Under pressure, its gaps became obvious.
A customer agreement contains more than commercial terms. Liability, data handling, termination rights, renewal language, governing law, and service commitments can each change the risk carried by a small company. An agent that confirms the price while overlooking the legal perimeter can complete the workflow and still damage the business.
At 4:52, Kweku rewrote the authority rule.
The agent could execute only when every clause matched a previously approved template, all variable fields fell within named limits, and no material language had changed. Any exception required human approval. Silence counted as a stop.
That last sentence mattered. Agents should fail closed around commitments that are expensive to reverse. A missing answer cannot become permission because the buyer is waiting.
This resembles the authority problem in Ama’s unsupported engineering work. Work can begin quickly once a system receives permission, but unclear ownership leaves the founder carrying consequences nobody explicitly accepted.
The useful output was the refusal
At 4:55, the agent produced a short exception report. It identified the changed clause, showed the approved wording beside the buyer’s version, and withheld execution.
Kweku sent the procurement lead a precise reply. He accepted the commercial terms, identified the single clause requiring correction, and attached replacement wording. No general request for “more time.” No fresh negotiation across the whole agreement.
Then he waited.
For four minutes, the contract remained unsigned. The buyer could still close the laptop and leave. Kweku had protected the company, but he did not yet know whether he had protected the sale.
At 4:59, the revised agreement arrived.
The disputed wording had been restored. The agent compared the document with the approved template, confirmed that no other material text had changed, and returned the execution request to Kweku. He approved it himself.
The signature landed after five.
The lesson was not that a human must click every button forever. Kweku’s mistake was waiting until a live contract to decide where machine authority ended. He had automated the visible task before defining the decision boundary beneath it.
A similar gap appears in eSignature products when the happy path works but an overlooked action exposes what the workflow actually permits. Esi’s print button made that product-readiness problem visible.
Write the refusal before granting permission
Before an agent can commit your company, write down the conditions that force it to stop. Start with the irreversible outcomes: accepting liability, changing price, promising delivery, transferring funds, deleting data, or sending a binding message.
Then define three things in plain language: which documents or actions the agent may handle, which values it may change, and which deviations require a person. Test the boundary with an altered clause, a missing field, conflicting instructions, and a deadline designed to create pressure.
The strongest test is simple: can the agent explain why it refused?
On Monday morning, Kweku did not begin by celebrating the signed contract. He added the changed clause to a small set of exception tests and ran them against the new authority rule. The agent stopped every time.
Only then did he let it near the next agreement.
Comments
No comments yet.