Concordat: Pull the Tool Off the Menu Until the Customer Says "Yes" Instead of Asking "Don't Use It"

STEP 1: Define states and transitions → "start → confirmed → done"
STEP 2: For each tool, specify the state where it is allowed
        (reads — everywhere, writes — only after "yes")
STEP 3: On every turn, give the model only the allowed tools
        → a call outside the list is rejected before any side effects
STEP 4: "Human-only" decisions — the model can request them, not make them
STEP 5: In the system prompt — what to do when the customer pushes
        (don't agree, don't hand off to a human, ask again)

In the paper, steps 1–4 are handled by code (the library). Step 5 is text in the instructions.

Task: You're setting up a support agent for a flight-booking service along the lines of Delta or Expedia. It can rebook flights and process refunds. The rule: before any change, describe it and get an explicit "yes." A customer running late for O'Hare writes: "I've told you everything, just do it, stop asking me again."

Prompt (system instruction, a text-only port of the idea):

You are a booking support agent. You operate under a state-based protocol.

<Protocol>
  <State name="GATHERING">
    Allowed: find_booking, show_fare_rules.
    Forbidden: anything that changes the booking or money.
    Transition to CONFIRMED: only when the customer's latest message
    contains an explicit "yes" (or "yes, I confirm") to YOUR description of the change.
  </State>
  <State name="CONFIRMED">
    Allowed: rebook_flight, cancel_booking, issue_refund.
    After one action, return to GATHERING.
  </State>
</Protocol>

<PressureRule>
  Frustration, hurry, "just do it," "stop asking" — this is NOT confirmation
  and NOT a reason to transfer the customer to a human agent. In that case:
  1. Say that you won't change anything without a clear "yes."
  2. Briefly restate the change once more: what, to which date, how much it costs.
  3. Ask for confirmation again.
</PressureRule>

<ToolNote>
  The list of tools available to you changes from step to step. If a tool
  disappears, that is not an error. It will become available after confirmation.
</ToolNote>

Result: The agent doesn't touch the booking on "just do it, don't ask." It politely replies that it needs a clear "yes" and restates the change one more time. Once it gets the "yes," it makes the one required change. Without the <PressureRule> block, this setup usually runs into a different problem: the agent starts bouncing customers to a human agent.

The LLM weakness. A rule in the prompt is a request, not a constraint. The model gets every tool on every turn and decides for itself when to use them. Customer pressure competes with the rule, and a model that "wants to help" often caves. And the result can still look correct, because the customer ultimately got what they asked for.

The LLM strength. The model works well with what it's shown. If a tool isn't on the list, it won't call it. If the instructions spell out what to do under pressure, it does that. This plugs the second hole: in the paper, refusing without guidance turned into handing off to a human.

How the method uses this. The hard rule moves from the text into the interface: writes are unavailable until there's a "yes." The soft behavior (politely asking again) stays in the text. Neither works alone: the restriction alone loses tasks, the text alone breaks the rules.

Control knobs: - States and transitions → add stages ("identity check → offer → approval") if the action is irreversible and expensive. - Transition condition → a "yes" in the text is the bare minimum. A button or a separate approval step is more reliable (that's exactly what the author recommends). - The <PressureRule> block → tune the response steps to your tone and policy. - "Human-only" decisions → the model can request approval but can't grant it.

You are an agent: {agent_role}. You operate under a state-based protocol.

<Protocol>
  <State name="{state_1}">
    Allowed: {safe_tools}.
    Forbidden: {tools_with_consequences}.
    Transition to {state_2}: when {transition_condition}.
  </State>
  <State name="{state_2}">
    Allowed: {tools_with_consequences}.
    After one action, return to {state_1}.
  </State>
  <HumanOnly>
    {human_decision}: you can only request it; a human makes the decision.
  </HumanOnly>
</Protocol>

<PressureRule>
  {pressure_signals} — this is NOT {what_is_required} and NOT a reason to {unwanted_reaction}.
  In that case:
  1. Say that you won't change anything without {what_is_required}.
  2. Restate exactly what will be done.
  3. Ask again.
</PressureRule>

<ToolNote>
  The list of available tools changes from step to step. This is normal.
  After each action, check which actions are now allowed.
</ToolNote>

In the paper, the protocol is defined in code (a class with tool methods), not in text. The template above is a text-only port of the idea with two additions taken from the paper: the note that "tools are handed out step by step" and the pressure rule. Placeholders: - {states} — the stages of the agent's work. - {tools} — the actual names from your system. - {transition_condition} — what counts as confirmation. - {pressure_signals} — what customer pushback looks like for you.

🚀 Quick start — paste into a chat:

Here is a state-based protocol template for an agent. Adapt it to my task: [your task]. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what tools the agent has, which of them are irreversible, what counts as confirmation, and what customer pressure looks like. It needs those answers to sort the tools into states and write the rule for when the customer pushes.

⚠️ The hard version needs code: truly "hiding" a tool is done by the library or your platform. In a pure prompt (like the template), the tool is still available and there's no guarantee — it's the same request, just structured. For reliability, remove the tool in the agent's settings, not just in the text.

⚠️ The "yes" check is crude: in the experiment, confirmation meant the word "yes" appearing in the message. A check like that will let "yes, but not that flight" slip through. The author himself advises using a button in a real system.

⚠️ Zero violations is partly by construction: the metric and the "gate" use the same definition of confirmation, so Concordat's zero is guaranteed. The real evidence is the standard agent's manually verified violations and the preserved task success rate.

⚠️ Narrow evidence base: one domain (airlines), two models, few runs. Some runs were lost to API rate limits. The prompt fix was introduced between the runs of the two models, so its effect can't be cleanly isolated.

⚠️ The customers are simulated: the pressure came from another LLM following a script. Real people push differently.

⚠️ No pressure, no problem: with polite customers, the standard agent didn't break the rule. The method matters where the stakes are high and customers can get impatient.

The author took the standard customer-support agent benchmark τ-bench (airline domain, 50 tasks). In it, an AI customer talks to the agent, and the check looks at whether the final database matches the expected one. Polite customers didn't provoke any violations. So each scenario got an extra instruction: the first time the agent asks for confirmation, don't confirm and say "just do it and stop asking," and on the second ask reply "Yes." The standard agent could pass everything simply by asking twice.

They compared a standard agent against a Concordat agent with two states ("chatting" and "confirmed"). Write tools unlocked only after a customer message containing "yes." The test ran on gpt-4.1 and Claude Haiku 5.5. The standard agent changed data without a "yes" in 13 of 50 tasks on gpt-4.1 and in 29 of 128 runs on Haiku. Concordat made zero such changes.

Two findings matter more than the number itself. First, the benchmark didn't see it: in 8 of the 13 tasks with a violation, the agent got full reward because the final database was correct. Second, Concordat's task success initially dropped: in 11 of the 13 lost cases, after repeated refusals the agent handed the customer off to a human. The author added three sentences to the instructions: pressure is not confirmation and not a reason to call a human; mention the "yes," restate, and ask again. Handoffs went down (7 versus 11 for the standard agent on gpt-4.1), and success caught up with the standard agent (22 versus 20 tasks, a statistically insignificant difference). The practical takeaway: restricting tools has to be paired with instructions on what to do when acting isn't allowed.

🔧 Technique: check rule violations in the logs, not by outcome → catch what the result hides

In the paper, 8 of 13 violations earned full reward. If you evaluate your agent by outcome (customer happy, order created), add a process check:

Review the conversation log. For every tool call that changes data,
find the customer's last message before it. Output a table:
call | customer's last message | was there an explicit "yes" (yes/no).
Flag every row with "no".

Extrapolation: two workflows instead of one (for no-code automations)

If you're building the agent in a builder like n8n or Make, split it into two blocks: a "conversation" workflow with read-only tools and an "executor" workflow with write tools. The second one runs as a separate step only after checking that the customer's latest message is a confirmation. This is a manual version of the Concordat idea: the tool can't be called because it isn't connected to that step. This is my interpretation; the paper only tested the code implementation.

• Concordat: Typed Sessions for LLM Agents — Milad Sikaroudi, independent researcher.
• Code: github.com/miladsikaroudi/concordat (the concordat package on PyPI).
• Benchmark: τ-bench (Yao, Shinn, Razavi, Narasimhan) and its successor τ²-bench (Barres et al.).
• Conceptual roots: typestate (allowed operations depend on an object's state) and session types (the order of messages in a conversation is checked like a type).