Designing Agent Conduct

Part 2 of a three-part technical series on experience orchestration. Part 1: One Intent, Four Contracts. Part 3: The Runtime Beneath the Experience.

Every team shipping an agent is designing its conduct. Most of them just aren't doing it on purpose.

When an agent decides whether to ask a clarifying question, that's an interaction design decision. When it proceeds without confirmation, that's a permission model. When it says "I think" instead of "I'm 70% confident," that's uncertainty language. When it gives up and routes you to a human who has none of the context, that's an escalation design — a bad one. These choices usually live in a system prompt, where nobody reviews them, nobody tests them, and they change every time someone edits a paragraph.

In the protocol described in Part 1, those choices live in the AX binding: a contract attached to every intent. This article is the design guide for filling one in.

Six decisions per intent

An AX binding is six declared decisions. None of them are optional, because every one of them gets made at runtime whether you declare it or not.

interface AgentBehavior {
  clarificationStrategy: "ask_once" | "confirm_before_act" | "assume_safe_default" | "escalate_ambiguous";
  permissionModel: "implicit" | "explicit_confirm" | "explicit_per_intent" | "audit_only";
  uncertaintyLanguage: string;       // how confidence is expressed, e.g. "state_confidence"
  escalationPath: {
    triggerConditions: string[];
    targetRoleOrChannel: string;
    handoffMessageTemplate: string;
  };
  explainabilityTemplate: string;    // what the agent says about what it will do
  fallbackBehavior: string;          // what happens when it cannot proceed, e.g. "escalate"
}

The guidelines below take them one at a time.

1. Clarification strategy

The first question an agent faces is whether it understands well enough to act. There are four answers, and choosing between them depends on two things: how ambiguous the intent is, and how costly it would be to act on the wrong interpretation.

Guidelines:

• Don't let model confidence choose the strategy. A model can be confident and wrong. Choose the strategy from the intent's stakes, then let confidence trigger escalation within it.
• Ask once means once. If an agent needs a second clarifying question, the intent is probably two intents, or it belongs in escalate_ambiguous.
• Confirm the consequence, not the command. "Cancel your subscription?" is a command echo. "Your subscription ends March 31 and your data is deleted 30 days later — continue?" is a confirmation.
• Defaults need a visible way out. assume_safe_default is only safe if the override is as easy to reach as the action was.

2. Permission model

Clarification is about understanding. Permission is about authority: whether the agent may act on what it understood.

Guidelines:

• audit_only is not a permission model in disguise. It's an observability choice. If an action would need a yes from a person, logging it afterward doesn't make it acceptable.
• Confirmation is a budget. Every unnecessary confirmation trains people to approve reflexively, which is how the necessary one gets approved without being read. Spend explicit_confirm where the consequence justifies it and nowhere else.
• Permission should match reversibility, not importance. An important but trivially reversible action can be implicit. A minor but irreversible one usually can't.

3. Uncertainty language

Uncertainty language is how the agent expresses what it doesn't know. It's declared per intent because the right register differs: stating a numeric confidence can be exactly right for a fraud review and alienating in a consumer conversation.

Guidelines:

• Calibration beats reassurance. If the agent says it's confident, it should be right that often. Confidence language that doesn't track accuracy destroys trust faster than no confidence language at all.
• Say what the uncertainty is about. "I'm not sure" is useless. "I'm not sure which of your two accounts you mean" is actionable.
• Uncertainty should change behavior, not just wording. Below a declared threshold, the escalation path triggers. An agent that says it's unsure and proceeds anyway has told you it's reckless.

4. Escalation path

Every AX binding declares where the agent goes when it can't or shouldn't continue: the conditions that trigger escalation, the role or channel it routes to, and the message the person hears during the hand-off.

Guidelines:

• Pass the intent and the partial context. The receiving person or channel should get what the agent already knows — the intent, what was established, what was attempted, and why it stopped.
• Name the trigger. "Confidence below threshold," "sensitive intent," and "customer asked for a human" are different situations, and the receiver handles them differently.
• Write the hand-off message as carefully as any interface copy. It's the moment the person is most likely to feel dropped.
• Escalation is a feature, not a failure. Measure how precise escalations are — how many genuinely needed a human — rather than trying to minimize how many happen.

5. Explanation and trust signals

The explainabilityTemplate is what the agent says about what it's going to do or has done. How much it reveals is set by the OX contract's transparencyLevel — summary, full, or explainable (step by step) — and the identity layer decides which trust signals apply.

Three trust signals did most of the work:

• explain_before_act — say what will happen before it happens.
• confirm_sensitive — pause for an explicit yes on sensitive intents, regardless of the default permission model.
• show_lineage — make it possible to see where a decision, and the rule behind it, came from.

Guidelines:

• Explanation belongs before the act. An explanation afterward is an apology or an audit record. Both matter, but neither is consent.
• Default to summary; earn full. Most people need to verify, not to read the reasoning chain. Offer depth on demand, and require it where the cost of error is high.
• Emotional posture is part of the explanation. The OX contract declares it — neutral, reassuring, apologetic. A cancellation delivered with a cheerful posture is a design defect, even if every fact in it is correct.

6. Fallback behavior

The last decision is what happens when the agent can't proceed at all: the tool fails, the data is missing, the policy says no. Undeclared, the fallback is improvisation — which for a language model means a confident-sounding answer that doesn't do anything.

Guidelines:

• Every intent declares a fallback. Common choices are to escalate, to retry within the OX contract's recovery pattern, or to stop and say plainly that the action didn't happen.
• Never fall back to a different intent silently. If "cancel" can't complete, offering "pause" may be helpful — but only as an explicit offer, never as a substitution.
• Say what didn't happen. The worst fallback leaves the person believing an action succeeded.

Sensitive intents

Some intents deserve stronger conduct no matter how the rest of the product is configured. The protocol tagged them in the registry and attached extra governance.

Note that an intent can sit in more than one category. cancel_subscription is financial and destructive, and it inherits the stricter conduct of both.

Hard boundaries and advisory ones

The most important design decision isn't in any single binding. It's deciding which rules the agent can never cross and which are strong suggestions.

The line I drew then still seems right:

• Hard: the intent must exist in the registry; resolution output is deterministic and can't be overridden at runtime; sensitive intents require confirmation and audit.
• Advisory: governance rules suggest fixes; fixes auto-apply only when explicitly marked safe; overrides are permitted and recorded.

Where I'd push harder now is on how much belongs in the first list. Anything that moves money, touches health data, or can't be undone should be a hard boundary enforced outside the model, not an instruction inside it.

And a boundary only counts if something checks it. Declared conduct is a start; enforced conduct is a registry plus a rule. Compile the intent contracts into an index, and a validator can run rules like this on every generated screen, with no model in the loop: an intent tagged destructive must sit inside the destructive-confirmation pattern, never on a bare button. That one rule does more for the person on the other side than a paragraph of instructions ever will.

Putting it together

Here's the conduct for three intents from the same product, side by side. Same agent, same model, three different characters.

The balance check should feel instant and invisible. The upgrade should feel deliberate and safe. The cancellation should feel respectful and final. None of that comes from the model. It comes from declaring conduct per intent and holding the agent to it.

You are no longer designing buttons. You are designing conduct.

Next in the series: The Runtime Beneath the Experience — how contracts are measured, how drift is caught, and what happens when consequences get serious.