Proposed actions
A proposed action is a card, not a change. It names the tool that would run, says why the Assistant thinks it is the right one, shows every argument it filled in, and waits. You can edit the arguments, confirm, or discard it. Until you confirm, nothing has been written and nothing is queued anywhere.
What is on the card#
| Part | What it tells you | What to check |
|---|---|---|
| The action | Which writing tool would run — creating a follow-up, approving a draft, writing a memory, moving an opportunity | That it is the verb you meant |
| The reason | Why this action, drawn from what it read | That the reason cites something you can open |
| The arguments | Every value it filled in: who, which channel, what date, what text | The date and the recipient, which are the two most often subtly wrong |
| The confirmation | One deliberate act by you | Nothing until you press it |
The arguments matter more than the verb. 'Create a follow-up' is nearly always right; 'create a follow-up for Thursday on WhatsApp for this person' has three places to be wrong, and all three are shown rather than assumed.
Editing before you agree#
Every argument on the card is yours to change, and your edit is what runs — the Assistant does not re-derive its own value over the top of yours. That is the same principle a held email draft follows: you edit the words, and the words you edited are what goes out.
- Change the date on a follow-up if the Assistant read 'next week' more literally than you meant it.
- Change the channel when the person is more reachable somewhere else — the
taskchannel exists for work that is for a person to do and is never sent by anything. - Rewrite the reason. It is stored with the commitment and read by whoever picks it up, including you in three weeks.
- Change the person if the card resolved to the wrong one — the usual cause is a tab pinned to an account you have finished with.
Why a card rather than a confirmation dialogue#
A yes/no dialogue asks whether you trust the assistant. A card asks something more useful: whether *this specific thing*, with these values, is what you want. The first question has no good answer in general; the second is easy to answer in a second and a half, because everything needed to answer it is on screen.
It also changes what happens when the Assistant is wrong. A dialogue turns a misunderstanding into a rejection and starts the exchange again. A card turns it into a two-second edit — the model got the person and the intent right and the date wrong, which is the ordinary case, and the ordinary case should cost an edit rather than a re-explanation.
Discarding, and what a discard means#
- Discard the card
- Nothing ran and nothing is pending. There is no queue of abandoned proposals to clean up later.
- Close the tab instead
- The same effect. A proposal lives in the tab that produced it.
- Say why you are discarding
- Optional and often worth it. A reason given as guidance can become memory; a bare discard is a decision about one card, not a lesson.
- Ask for something different
- Better than editing a card into an unrelated shape. The reason line will match the action if the action was proposed for that reason.
Confirming is where this page ends and Running an action begins — including the case where you confirm and Connect still holds the work, because the channel's autonomy rule says a person decides at the point of sending.
Questions#
Can the Assistant act without showing me a card?
Not from the panel: writing tools propose. Connect does act unattended elsewhere — the engine drafts and sends under the autonomy modes you set — but that is a different path with its own controls at What Connect may do.
If I confirm, is it definitely done?
It is definitely attempted, through the service that owns the thing. That service applies its own gates, so a confirmed send can still become a held draft waiting in Needs You if the channel is set to ask before sending. The result tells you which happened.
Do several actions in one request come as one card or several?
Each action is its own decision and its own confirmation. That is slower for a batch and much easier to audit, because the decision log holds one entry per thing decided rather than one entry covering several.