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. A decision still unanswered after 24 hours re-pages the same people once — the employee that stacked it is blocked until someone picks, and a blocked employee should never be a silent one.

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.

Routing to an AI decider

By default every question waits for a human — no configuration, exactly the behavior above. A routing rule (the Routing tab on the Decisions page, admin-managed) changes that for one asking employee: it names who may answer on a human's behalf — the employee's manager, via the org chart's reports-to line, or a named employee. A decision the employee addressed to a specific person is never routed.

A routed question skips the creation-time bell. Instead, the decider is briefed in a background session under its own authority, investigates with its own tools, and answers — or declines — through its decide_decision tool. A decline, or 4 hours of silence, drops the question back into the human flow with exactly the bell it skipped, so routing can delay a human's attention but never lose it. Any Member can still answer a routed question from the stack while it waits — a human answer always wins.

An AI answer renders as Answered by {name} (AI), is written to the audit log and the asker's journal, and starts the asker's pickup session immediately, the same as a human answer. And because answering fires no side effect — the section above — the asker's privileged follow-ups still meet their own gates. Routing decides who picks the option, never what the answer can execute. See Earned autonomy for the other half of the trust-by-evidence story.