Asking the Assistant to do something, end to end

The path an instruction takes#

1. Trigger — you type an instruction: create the follow-up, approve the draft, remember this.
2. User event — the tab posts the text with the route and any pinned record.
3. Authentication and workspace resolution — the workspace is fixed before anything is read or written.
4. Ingest — the instruction joins the tab's conversation.
5. Canonical record — the target is resolved to a real row, and the screen context claim is checked against the database first.
6. Reasoning — the model selects a writing tool such as create_followup, remember, approve_draft, create_case or data_update.
7. Knowledge, memory and rules — the Assistant's own authority is applied here: pricing is outside it, and it cannot clear a do-not-contact entry.
8. Autonomy and approval — the proposal is shown to you; nothing has been written. Confirming is the human decision the mode may still require again downstream.
9. Action through the owning service — the tool calls the follow-up, memory, approval or data service, never a table.
10. Result — the change exists and the card becomes a result naming the record it produced.
11. Relationship, timeline and memory — the affected record's timeline gains the change, so it is visible outside the Assistant.
12. Audit, usage and Needs You — the decision log records who confirmed what; anything the service could not finish alone is queued for a person.

What the proposal must tell you#

A proposal that only says 'create a follow-up' is not enough to confirm safely, and that is not what you get. The card names the tool, the record it will act on, and the values it will write — the date on a follow-up, the text and tier of a memory, the stage an opportunity moves to. Reading those three lines is the whole review, and it is the only point in the flow where an error is free to fix.

Discarding a proposal costs nothing and records nothing beyond the conversation. This is deliberate: a discarded proposal is not a decision about the business, so it does not belong in the decision log.

Why the write goes through a service#

A writing tool does not touch a table. create_followup calls the follow-up service; approve_draft takes the same approval path a person's click takes; data_update goes through the service that owns the sheet's records. Every rule that service enforces is therefore enforced for the Assistant too, without anyone wiring it a second time — the suppression list, the daily allowance, the workspace stamp, the audit entry.

The alternative would be an assistant that can do things the screens forbid, which is how agent features drift away from the product they sit in. Why an agent's tools should call domain services sets out the reasoning; the visible consequence is that an Assistant action and a screen action produce the same record and the same audit trail.

What can fail after you confirm#

The service refuses

A rule you were not thinking about applies — a suppressed recipient, a spent allowance, a stage transition the pipeline does not allow. The card shows the refusal and its reason; nothing partial is left behind.

The action is held, not done

The channel's autonomy mode requires a person for the outbound step. The record exists; the send waits in Needs You.

The record moved underneath it

Somebody edited the same row between the proposal and the confirmation. The service applies its own concurrency rules and the result names what it actually wrote.

It succeeded and you regret it

That is undo, which reverses what can be reversed, compensates what cannot, and records the rest.

Verified success for this flow is not the card turning green. It is the record existing where you would look for it anyway — the follow-up on the person's timeline, the memory in Memory, the row in the grid — and the decision log naming you as the person who confirmed it.

Questions#

Related#

• Proposed actions
• Running an action
• What the Assistant may not do
• What Connect may do
• Why an agent's tools should call domain services