Decision stack

What lands here

Employees add to the stack deliberately. They are told to ask only when a human's judgement genuinely changes what happens next — not for permission to do the work they were hired for, and not for something they could look up. A typical row is work that is already finished except for the call: the email is drafted, the post is written, the shortlist is down to two.

This matters most inside a Routine. A routine's brief was written hours or weeks earlier and there is nobody to ask mid-run, so before the stack existed an employee in that position had to guess. Now it can stop.

Answering a decision

• Open Home, or the Decisions section for the full list.
• Press Show context to read what the employee actually wrote — the draft, what it already checked, and what each option costs. It is rendered as the employee wrote it, so a drafted email reads like an email.
• Press the option you want. You can add a note first; the employee reads it alongside your choice.
• Nothing to decide? The × dismisses the row and tells the employee nobody picked an option, so it stops waiting.

Any Member can answer, not just owners and admins. If the employee addressed the question to one person, only they — or an owner or admin — can answer it, so nothing strands behind somebody on holiday. Owners and admins get a notification for every unassigned decision; an assigned one notifies only its recipient.

What happens next

The employee starts working again immediately. Pressing an option kicks off a work session right away, briefed with your choice, your note, and the context it stacked with the question — so a reply you approved goes out in the next minute rather than waiting for that employee's next scheduled run. The row shows the session running, then the employee's own report of what it did.

Your answer is also written to that employee's journal, and the last week of its journal is part of every prompt it runs. That is the backstop: if no session can start — no AI Model is connected yet, or the server restarted mid-session — the row says so, and the employee still picks the work up on its next run. It can also read the answer at any time with its list_decisions tool.

The Already answered list keeps the trail: what was asked, what was chosen, who chose it, any note, and what the employee did next.

Where a question came from

Every row says which surface the employee was working when it asked, and links straight to it — the Routine and the exact run, the email thread, or the chat. It is the context that decides how you read the question: “send the pricing reply to Acme?” means one thing out of the nightly outreach routine and another out of a conversation you had five minutes ago.

An employee can retract its own question if the situation moves on. A decision can also carry a deadline, after which it stops nagging anyone and shows as expired.

Decisions are not approvals

The two look similar and are deliberately separate. An Approval is Genosyn holding back an action an employee already attempted — a gated Routine tick, a payment over your threshold, a browser form submit — and the server performs that exact action once an admin approves it. That is why approvals are admin-only and ask you to re-authenticate.

A decision performs nothing itself. It records which option a human picked and hands that back to the employee, which is why an ordinary Member can answer one. The work session your answer starts runs under the employee's own authority, so anything privileged it then does still meets its own approval gate.