Running an action
Confirming hands the action to the service that owns the thing — the follow-up service, the approval path, the memory tiers, the send boundary. That service applies its own gates before anything happens, so a confirmed action can complete, be held for a further decision, or be refused. The result says which, and the decision log keeps it.
The path a confirmed action takes#
- The writing tool is called with the arguments as you left them, including your edits.
- The tool calls the domain service that owns the thing — never a table directly.
- That service applies its own rules: the channel's autonomy mode, suppression and do-not-contact, the workspace's daily allowance, and whatever else governs that kind of change.
- The action completes, is held for a further human decision, or is refused with a reason.
- The outcome is written to the decision log, attributed to you, with the rule that applied.
Step three is the one that surprises people, and it is the point of the design. Confirming in the Assistant is not a way around the rules a workspace has set for itself; it is a request that travels the same road a person's own click travels. Why an agent's tools should call domain services makes the case.
Three endings, all normal#
| Ending | Typical cause | Where it now lives |
|---|---|---|
| Done | Nothing in the way — the follow-up exists, the memory is written, the opportunity has moved | The service's own screen, plus the decision log |
| Held | The channel is set to ask before sending, so a finished reply waits for a human yes | Needs You, as a held draft |
| Held | The daily allowance is spent; the approval is recorded and the send waits | Needs You, until the allowance resets |
| Refused | The recipient is suppressed, or the action is beyond the Assistant's authority | The decision log, with the reason |
A held outcome is not a failure and not a slow success. It is a second decision that a person has to make, and the queue it lands in is ranked rather than chronological so it does not sink under older items.
What the result shows#
- What was created or changed, by name — the follow-up with its date and channel, the memory and the tier it landed in, the opportunity and its new stage.
- Where to see it, so you can open the thing rather than take the Assistant's word for it.
- What did not happen, when part of a request was refused or held. A partial outcome stated plainly beats a summary that reads as complete.
- Evidence for a send. Connect does not call a message sent because it handed it over: the state stays uncertain until the provider acknowledges it.
Stopping, retrying and doing it twice#
- Stop during the work
- The compact Stop on the status line ends the run. Anything already completed stays completed — stopping is not a rollback, and Undoing an action is where that question goes.
- Confirm the same card twice
- Not possible: a card is spent once confirmed. Asking again produces a new proposal, which is a second decision and will read as one in the log.
- A refusal you think is wrong
- Read the reason first — it names the rule. A suppression, an allowance and an authority limit look similar in the panel and are resolved in three different places.
- Nothing appears to have happened
- Check the decision log before repeating the request. An action that completed and one that was never confirmed look identical from a conversation and are easy to tell apart from the log.
Questions#
Does confirming override the autonomy settings?
No. Autonomy resolves at four scopes and the narrowest wins, and a confirmed Assistant action is subject to it exactly as a person's own action is. If the channel is set to draft only, the reply is written and not sent, and the panel says so.
Who is the action attributed to?
You. The decision log records the person who confirmed, what was decided, under which rule and what happened — which is what makes 'who released this' answerable months later.
Can an action fail after it says done?
A send is the case worth understanding: it is complete when the provider acknowledges it, and until then the state is uncertain rather than sent. Other actions are complete when the owning service has written the change.