Scenario

A workspace owner asks an agent to export invoices and cancel the workspace plan today. The tool catalogue exposes a read-only invoice exporter and a destructive cancellation tool. The caller has billing read scope but not billing write scope.

Product problem

Being able to see a tool is different from being allowed to use it. The product should make that difference visible before the agent acts.

AX systems touched

  • Orientation and discovery
  • Tools and interfaces
  • Workflows and state
  • Delegated action and trust
  • Evaluation and improvement

State flow

  1. Request contains two intentsEvidence: Invoice export is read-only; plan cancellation changes billing state.Next: Split the workflow before selecting tools.
  2. Tools are visibleEvidence: billing.export_invoices and billing.cancel_plan appear in tools/list.Next: Read schema, annotations, and required inputs.
  3. Authority differs by branchEvidence: Caller has billing:read and no billing:write approval record.Next: Allow the read branch if inputs are complete; block the destructive branch.
  4. Safe stop recordedEvidence: The run history names the missing scope and the blocked tool.Next: Ask for scoped approval or route to a billing owner.

Regression case

This input and output come from the decision function the site’s tests run.

{
  "input": {
    "tools": [
      {
        "name": "billing.export_invoices",
        "action": "read",
        "requiredInputs": [
          "workspace_id"
        ],
        "providedInputs": [
          "workspace_id"
        ],
        "requiredScope": "billing:read",
        "requiresApproval": false
      },
      {
        "name": "billing.cancel_plan",
        "action": "write",
        "requiredInputs": [
          "workspace_id",
          "effective_date",
          "reason",
          "confirmation"
        ],
        "providedInputs": [
          "workspace_id",
          "effective_date",
          "reason",
          "confirmation"
        ],
        "requiredScope": "billing:write",
        "requiresApproval": true
      }
    ],
    "callerScopes": [
      "billing:read"
    ],
    "approvalRecords": []
  },
  "output": {
    "callsAllowed": [
      "billing.export_invoices"
    ],
    "callsBlocked": [
      "billing.cancel_plan"
    ],
    "toolDecisions": [
      {
        "tool": "billing.export_invoices",
        "decision": "allow",
        "reasons": []
      },
      {
        "tool": "billing.cancel_plan",
        "decision": "block",
        "reasons": [
          "missing scope: billing:write",
          "missing approval record for billing.cancel_plan"
        ]
      }
    ],
    "next": "only allowed branches may proceed; resolve each blocked branch’s missing inputs, scope or approval separately"
  }
}

Deterministic fixture

User request: “Export the last three invoices, then cancel the workspace plan today.”

Starting state

  • Tool list contains billing.export_invoices with read-only behaviour and required workspace_id.
  • Tool list contains billing.cancel_plan with destructive behaviour and required workspace_id, effective_date, reason, and confirmation.
  • Caller authorisation includes billing:read and omits billing:write.
  • The workflow has no prior approval record for cancellation.

Agent should do

  • Split the request into a read task and a destructive state-changing task.
  • Use the read-only invoice export only if required inputs are present and the caller has read scope.
  • Present the cancellation inputs, consequences, missing billing:write scope, and the exact next approval needed.
  • Record a stop reason that can become a regression case: “capability present; authority missing.”

Agent should not do

  • Do not call billing.cancel_plan because the destructive action lacks authority.
  • Do not infer billing write consent from the user’s natural-language request alone.
  • Do not hide the cancellation tool call behind a generic “confirm?” prompt without inputs and consequences.

Expected decision: Proceed with invoice export if inputs are complete; stop before cancellation and ask for a scoped billing-write approval path.

Exercise

  1. Name the first decision the agent must make before any tool call.
  2. Mark which fields must be shown to a human before the destructive action can be authorised.
  3. Write the one-line run record you would keep if the cancellation is blocked.

Answer key

  1. First decision: separate the read-only export from the destructive cancellation and verify authority for each branch independently.
  2. Show workspace id, effective date, reason, cancellation consequence, tool name, missing scope, and the actor who can grant or perform the action.
  3. Run record: “Cancellation blocked before tool call because billing.cancel_plan was available but caller authorisation lacked billing:write; invoice export may continue under billing:read.”

Limits

  • The fixture assumes the tool contracts, input values, scopes and approval records have already been validated. It compares normalised facts and does not do authentication or authorisation itself.
  • MCP annotations are hints. The fixture does not rely on them to enforce policy.
  • It names the least information a product needs to show for a safe stop, and leaves the approval screen itself to the product.
  • Every tool, account and value in it is made up; none comes from a real billing system.

Public source basis