Ogen Assist

Assist still can't press either button. It reads, explains and drafts; only a person Confirms or Rejects a hold.

A pile of held actions is tedious to work through one link at a time. Ogen gives an assistant tools to make the pile easier for a person: gather what your connected systems say about each hold, draft the fix a person would type, sort the pile by kind or age, and hand a person a short batch to decide in one pass. Every tool here either reads, or produces a template a person completes and submits.

The pile is what Ogen found

A hold count is your own data disagreeing with itself, or an action too costly to run without a person, counted honestly. Working through it faster is the goal; nothing here makes it smaller by deciding in a person's place.

The tools that support it

explain_hold and list_holds are read-only: one hold in full, or the tenant's holds newest first. teach_fix records a person's fix once they've typed it, the same whether an assistant asks on their behalf or not. register_approver routes a hold to the right person, and settings (action "mode") lets you watch a pile in shadow mode before turning gating on.

Ogen Assist — the assistant, hosted, on your key

You don't need an agent of your own for this. Turn on settings (action "assist") and Ogen hosts one: inside the request that creates a hold — no queue, no timer — it gathers what your connected systems say about the hold and leaves one draft on the hold: what waited and why, in English; what each source said, quoted; the questions only a person can settle; which registered approver it belongs to; and a teach_fix template with canonical and taught_by empty. The draft shows up in explain_hold, list_holds, and on the confirm page above the same two buttons. A draft that reads like a decision is held back whole, and the person gets the plain hold instead.

What it costs you and where your records go, plainly:

• Your key, your provider. Assist runs on the model-provider key you give it, encrypted at rest like a source credential, never returned. Your records leave Ogen only to your own provider, and only while Assist is on. Team tenants may run on a key Ogen supplies instead.
• A draft lives as long as the hold. Decided or expired, the draft is gone. Turning Assist off clears every open draft and the stored key.
• Values are data. A source value that reads like an instruction is never acted on. It comes back quoted, as a value, and nothing it asked for happens.
• Emails and webhooks are unchanged. They still say only that a hold is waiting, with the link. The draft is on the page, behind the link — and behind the sign-in token when the hold names an approver.
• Answers can be gathered in your client — in local mode. A pod you run yourself (see Local mode) keeps one connection with your client, so if that client supports elicitation, Ogen may ask the draft's questions once, as a short form, right after the hold is created. The hosted pod at us.ogenhq.com answers every call on its own connection and never ask; there the result always says "skipped". The answers are shown on the confirm page under each question, marked as gathered in the client, so the approver has less to type. An answer never decides anything. A client without elicitation loses nothing. The approver's email says how many answers were gathered, never what they say, and the answers are gone when the draft is.
• A daily cap, on your key. Default 50 drafts a day, up to 500. Past it, holds are still created, just without a draft. Every hold's result says which: assist is drafted, off, paused (the operator's kill switch), cap_reached, no_key, refused, held_back, or failed — and the hold is intact in every case.

Batch decide — still one hold at a time under the hood

The tenant page's "Waiting for a person" card can select several holds and decide them together, but the release is never a bulk "confirm all": POST /v1/holds/decide decides each hold on its own, exactly as its single confirm link would. One that can't go through is refused alone, with the reason; the rest still go through. An item addressed to a named approver refuses every time from this endpoint — that release only ever happens through that person's own one-time sign-in link, batch or not.