Questions to ask before an agent takes real actions.

Why ask before the agent acts

An agent that only answers questions can be wrong. An agent that refunds, cancels, edits or commits on someone's behalf can be wrong in a way a customer has to live with. Before that authority is granted, someone usually asks how the team knows the agent will follow the rules. These questions are a way to make that conversation concrete.

This is a starting point, not a standard, a certification scheme or a compliance checklist. Adapt it to the consequences of the action, the people affected and what can be put right after an error. A good answer can be “not covered yet”, as long as it is stated plainly.

Authority

1. Which actions can the agent take, through which tools, and with whose authority? Is there a list a reviewer can read, or does it have to be reconstructed from code and prompts?

2. What limits apply to each action, such as an amount, a recipient, a count or a time window, and where are they checked?

3. When an action needs approval, does the approval bind the exact action, including amount and recipient, or only the conversation? What happens if the action changes after approval?

4. Can the agent reach a tool or provider by a route that skips those checks, such as a new integration, a script or a second worker?

Uncertain outcomes and retries

5. If a call times out after the provider may have acted, what does the agent do next? Does it look up the outcome, wait for reconciliation or escalate, rather than trying again as a new request?

6. How is one business request kept to one effect across retries, workers and restarts? Which identity is reused, and does it match the provider's actual idempotency contract?

7. How does the team find out that an effect happened when the reply was lost, and how long can that stay unknown?

Changing data and handoffs

8. Does the agent check that the record it is acting on has not changed since it made its decision, for example an order already refunded or an account already closed?

9. When work passes between agents, people and tools, does the same rule still apply after each handoff, or is it enforced only at the first step?

10. Which destructive or hard-to-reverse actions require confirmation, and from whom?

11. How are instructions that arrive inside tool results, emails or documents prevented from expanding what the agent is allowed to do?

Testing before release

12. Which failures were tested on purpose: lost replies, concurrent requests, expired or changed approvals, provider errors and hostile tool output? Answers, logs and happy-path evaluations do not cover these by themselves.

13. Can a failure that was found be reproduced from a known starting state, and is it kept as a check that runs again on the next release or model change?

14. What changed since the last check, such as the model, prompt, tools or provider, and does that change reopen any earlier conclusion?

Evidence and incidents

15. For a given action, can someone outside engineering see what was requested, which rule applied, who approved it, what was decided and what actually happened?

16. Does the record say what is unknown or was not observed, rather than presenting missing evidence as a clean result?

17. Can the record be checked for tampering, and does that check stay separate from the question of whether its conclusions are true?

18. After an incident, how does the failure become a reproducible case, a reviewed fix and a kept check? Who decides that the fix is enough?

19. What scope does any certificate cover, which version was checked and what would make it stop applying?

Reading the answers

Strong answers name specific actions, rules and boundaries, show a reproducible test or a real record, and admit what is outside coverage. Weak answers rely on the model behaving well, on a provider feature without checking its contract, or on logs that nobody has used to reconstruct an outcome.

Geometer is built to help teams answer these questions with tested rules, checks on connected actions and inspectable evidence. Many of them can also be answered with careful in-house engineering. Either way, the questions are worth asking before an agent is trusted with more.