Proposed
The agent has described or prepared work. No external action is implied.
CONTROL / EXECUTION / PROOF
Planning is not execution.
Keep consequential actions behind a clear yes. A plan can be useful without being permission to change the outside world.
Approval should identify the exact action and scope. This guide describes the boundary; enforcement still depends on the specific tool and integration.
01 / KEEP THE STATES SEPARATE
One workflow.
Four different claims.
When a status skips a step, people can mistake intent for action or action for success. Name what happened—and what is still unknown.
Approved
A person authorized one clearly described action, target, and scope.
Executed
A tool call was attempted. Preserve the returned status; it may be pending or failed.
Confirmed
A separate source or read-back observed the intended outside result.
Keep the wording exact: “approved,” “submitted,” “accepted,” and “confirmed” describe different evidence. Do not upgrade one status into another.
02 / DECIDE WHAT NEEDS A YES
Gate the actions
that can change things.
Teams often require a fresh approval before an action that affects money, access, production systems, or another person. These are policy examples, not a claim that every tool uses the same gate.
Send or publish
Messages, posts, offers, customer notices, and public changes that leave the workspace.
Spend or transfer
Purchases, payments, trades, transfers, and other actions with financial consequences.
Change or delete
Production settings, customer data, repositories, records, or other hard-to-reverse state.
Grant or widen access
Permissions, credentials, scopes, or access that lets another person or process act.
03 / MAKE CONSENT SPECIFIC
A clear yes has
something to point to.
Show the reviewer the actual proposed action—not just a goal or a vague “continue?” prompt—before they approve it.
Exact action
State what will happen, including the tool or service that will do it.
Target and scope
Name the recipient, account, record, environment, or resource affected.
Parameters and limits
Show amounts, content, timing, quantity, and any important boundary.
Approver and authority
Make clear who is approving and whether they are allowed to authorize it.
Expiry and side effects
Explain how long approval lasts and what else the action may change.
Cancel or recovery path
Say what can be stopped, reversed, or escalated if the result is wrong.
Changed request, new approval. If the recipient, target, amount, or side effects change, treat it as a new proposal. Do not reuse consent for a materially different action.
04 / AFTER APPROVAL
Run only what
was approved.
Approval is a boundary, not a shortcut around verification. Keep the handoff narrow and return an honest status.
| Step | Good practice | Do not claim |
|---|---|---|
| Re-check | Compare the approved action with the request about to run. Stop if the scope changed. | That an earlier, broader approval covers every later variation. |
| Execute | Record which tool ran, when it ran, and whether the call returned success, failure, or pending. | That a drafted plan or queued job has already changed outside state. |
| Verify | Use a provider response, read-back, settlement reference, or target-system check when available. | That a local “success” response proves delivery or final settlement by itself. |
| Report | Show the evidence, remaining uncertainty, and the next safe action. | Completion when the result is blocked, ambiguous, or unconfirmed. |
05 / RECEIPTS AND EVIDENCE
A receipt matters.
So does its limit.
Keep the record tied to what the system observed. When the result matters outside that system, add an independent confirmation.
What a call record can show
- The tool or provider call that was recorded.
- The time, status, and returned result captured by that system.
- The declared evidence and integrity checks attached to the record.
What it cannot prove alone
- That an unobserved message was delivered or read.
- That a payment settled or a trade reached its final state.
- That a publication or data change remains present later.
Verify the outside state separately. A verifiable record can support an audit of what the system recorded. It does not turn missing upstream evidence into proof of delivery, settlement, or publication.
06 / COMMON QUESTIONS
Approval, without the guesswork.
Is a plan the same as execution?
No. A plan describes proposed work. Execution requires a tool or provider call; confirm the resulting state separately.
Does approval prove the action completed?
No. Approval authorizes a specific next step. It does not show that a request ran or that an external system applied it.
What if the target or parameters change?
Treat a changed recipient, target, amount, scope, or side effect as a new request and obtain approval for the revised action.
What does an execution receipt prove?
A receipt can document the call and the result observed by the system that issued it. It does not independently prove an unobserved delivery, payment, publication, or state change.
Can read-only research happen before approval?
Often, yes, if the data access is authorized and no consequential side effect occurs. Access and privacy rules still apply; confirm the tool's actual scope.
Does Zambo enforce this approval step for every tool?
No blanket guarantee is implied. Approval behavior depends on the specific integration and action. Check the current tool contract and its confirmation mechanism before relying on a gate.
One connection. A clearer boundary.
Keep your chosen AI in control of the conversation, and make the plan, approval, execution, and evidence visible as separate steps.