Working with Gini
Approvals
What stops and waits for a person, who can clear it, and where the boundary holds without Gini having to recognise the moment.
Before Gini does something that reaches another person and can't be taken back, it stops and asks. The run parks, posts a card naming the action and its scope, and does nothing until someone clicks.
You@Gini the Q3 numbers are final, send the update to the investor list.
Gini
Drafted. Ready to send to 11 recipients via Gmail, from your address.
Subject: Q3 update: ARR $2.1M, net retention 118%
[ Approve and send ] [ Show me the draft ] [ Cancel ]
What triggers one
Anything irreversible that goes to another person: sending or replying to an email or message, posting into another system on your behalf, submitting a form, purchasing, spending or moving money.
Reading isn't gated. Neither is drafting, working on a file, or anything reversible with one click: an agent that stopped for those would need babysitting rather than doing the work.
Two things pause always, no matter what the run is doing:
- Entering a credential. Gini never takes a key or password in chat. It gives you a secure field and waits.
- A step a skill declares as needing approval. If your team wrote "never send this without review" into a skill, that step parks for a person every time.
What waiting actually means
When Gini asks, the task genuinely stops. It parks in a waiting state on the server and resumes only when your decision arrives: it isn't the model politely holding off while free to continue. Every action, approved by you or not, writes an audit row you can read afterwards.
Where the hard guarantee is
For most irreversible actions, Gini is the one that recognises it should ask. That's reliable in practice and it's the behaviour we build and test for, but if you need a boundary that doesn't depend on Gini recognising the moment, the mechanism is the connection itself. A tool connected read-only cannot write, whatever happens in a run. Scope it that way where the cost of being wrong is high, and treat approvals as the layer above that rather than the only one. See How connections work.
Who can approve
Anyone in the channel where the work is happening: with the same constraint that holds everywhere: Gini acts with the approver's own access to the tool. Approving a Stripe refund doesn't work if you can't issue one in Stripe yourself.
Approve in the thread where Gini asked. On mobile, the buttons work the same.
An approval is for that action, not that kind of action
Approving one email doesn't approve the next one. There's no "always allow" for a tool or a category, and approval policy isn't a customer-facing setting : there's nothing to switch off in a hurry and leave off.
If nobody approves
The run waits, then stops on its own and says so in the thread. Nothing is sent, spent, or changed. Nothing happens by default and nothing happens by timeout.
If it stopped and you still want it, ask again in the thread. Gini picks up from where it was rather than redoing the work.
Reading an approval before you click
The card names the tool, the action, and the scope: how many recipients, which record, what amount. That's the part to read. If it says 11 recipients and you expected 4, the mistake is upstream of the send.
"Show me the draft" is always available. Use it on anything that leaves your company.
Making Gini not need approvals
Ask for a job that doesn't include the irreversible step. "Draft it, don't send" produces a draft and no gate. "Prepare the refunds and list them for me" gets you the list.
This is the right pattern for work you want to review in bulk: one look at ten drafts beats ten approval cards.