Getting a client to sign off on an agent design (before you build it)

Client sign-off on an agent design means a named person on the client side has read it, turn by turn: the flows, the example turns, the paths where things go wrong, and what each system call does, and has approved one specific, versioned copy of it, on the record. A nodding room at the end of a workshop is only the raw material for sign-off, and it has a shelf life of about a week.

If you deliver agents for a client, you carry the gap between what the client believes they asked for and what the build actually does, and when that gap surfaces in month four, you either absorb the rework or open a change-request argument that costs the relationship. Written approval of the design, before the build starts, is the cheapest insurance either side can buy.

Why does workshop agreement evaporate?

Three forces erode it, and none of them involve bad faith.

The first is memory. People remember conclusions, not decisions. Six weeks after the workshop, everyone recalls that the refund flow was “sorted”, and each attendee has quietly reconstructed a different version of what sorted meant. Nobody is lying; they are filling gaps with what they would have decided.

The second is attendee churn. The sponsor who nodded in the kickoff is rarely the operations lead reviewing the build at UAT. Agent projects run long enough that stakeholders join mid-engagement, and a new stakeholder inherits the project without inheriting the agreement. To them, every past decision is an open question.

The third is prose. The summary document says the agent will “handle refund requests empathetically and escalate where appropriate”, and every reader supplies their own meaning for empathetically and appropriate. Vague prose feels agreed precisely because there is nothing in it concrete enough to disagree with. The disagreement is still there; it has just been postponed to the most expensive possible moment.

What makes a design sign-off-able?

A design is sign-off-able when the client can read the thing they are approving, end to end, without a translator. In practice that means three tests.

They read the example turns: what the customer says, and how the agent’s answer would land in the chat window. A flowchart of boxes labelled “refund intent” invites approval of a shape; a transcript invites approval of behaviour. Clients argue with an example turn in ways they never argue with boxes, and you want that argument now.

They read the failure paths. The happy path is the least contentious part of any design, which is why it is the only part most decks show. What the agent says when the refund is declined, the API times out, or the customer demands a human is where the commercial and legal risk lives, and it is the part clients most need to see before they approve. We made the longer argument in the happy path is not a design.

They read what the tools do. If a turn depends on a system call, the client should see which system, whether it reads or writes, and what the agent says when it fails. Clients routinely discover what integrations they actually have this way; better in review than two days before go-live. The full anatomy of a design that passes these tests is in our conversation design template.

What does a real approval consist of?

Approval that survives month four has four mechanical properties, and each one closes a specific escape hatch.

A named approver. Until one person with the authority to bind their side gives the approval, “the client approved it” is a rumour. Naming them upfront also flushes out the awkward discovery that nobody on the client side actually holds that authority, which you want to learn in week two.

A versioned design. The approval attaches to version 12, not to “the design”, which is a moving target. If the design keeps changing after approval with no marker, the approval means nothing.

A record of what exactly was approved. Who approved, which version, when. This is the line between “I remember you agreeing” and pointing at a timestamp.

A diff when it changes. Designs change after approval; that is normal and healthy. What keeps the approval alive is showing the approver precisely what moved since the version they signed off, turn by turn, so re-approval is a five-minute read instead of a fresh review of the whole document. Without a diff, every change quietly voids the agreement.

What happens when the client says “that’s not what we agreed”?

A familiar scene: month four, UAT. The client’s operations lead, who joined in month two, watches the agent tell a customer their refund will land in five to ten working days and stops the session: the agent must never promise a timeline, that was agreed from the start.

Without an approved design, this is relationship arithmetic. You believe the timeline was agreed in the workshop; you cannot prove it. Push back and you spend goodwill accusing the client of misremembering. Absorb it and you have taught everyone that “we never agreed that” is a free rework coupon. Absorbing it is the path of least resistance, and the margin on the engagement quietly bleeds out one absorbed change at a time.

With an approved design, it is a lookup. Open the approved version, find the turn, and there it is: the five-to-ten-day timeline, approved by their head of support on March 3rd. The discussion stops being an argument about whose memory is right, which has no good outcome, and becomes a change request: requirements evolved, here is the turn, here is what changing it touches, here is the cost. Five minutes, and both sides stay on the same team. The record protects the client just as much when the drift runs the other way.

How do you run the approval conversation?

Do not email the design with “any comments, else we’ll proceed” and count silence as a yes. Silence is deferred disagreement. Run approval as an event.

Book a session with the named approver and walk the design, reading turns aloud, dwelling longest on the sad paths. Ask closed questions: “this is how it handles a declined refund: do you approve it, or change it?” Open questions invite musing; closed questions produce decisions. Make agreed edits in the design during the session, in front of them, so what they approve is what they just watched being corrected. Then request the formal approval the same day, while the walkthrough is fresh. A week’s gap between agreement and approval is where sign-offs go to die.

What if the client won’t decide?

Refusal to approve is information, and the right move depends on which kind you are looking at.

They lack the authority. Your named approver turns out to need legal, or brand, or their boss. Find the real approver and re-run the walkthrough with them; do not accept a proxy approval that will be disowned later.

The decision feels too big. Shrink it. Approve path by path, or approve the design for a pilot scope only. A stack of small, reversible approvals moves faster than one monolithic one, and it builds the approval habit for the engagement.

They genuinely disagree internally. Support and legal want the agent to handle refunds differently, and no document has ever forced the question before. This is the design doing its job: surfacing in review a conflict that would otherwise have surfaced in production. Mark the turn as open, record who owns the decision, and keep the rest of the design moving. An explicit “undecided, blocking, owned by X” is a perfectly good thing to get approved.

How this works in Klate

A Klate design moves through draft, review, and approved. You send the approval request to any email address: the approver opens a secure link, reads the design read-only, and approves in one click, with no account and nothing to install, so the “I’m not creating an account for this” objection never comes up. Every phase change lands on an append-only timeline, approved designs lock against edits until someone deliberately reopens them, and version history shows what changed in each version, turn by turn. More on the delivery workflow on our consultants page.

The habit costs one meeting per design: put the example turns in front of a named approver, get a versioned yes, and diff every change after it. To see what a sign-off-able design looks like for your next agent, write the first one in Klate.