The review inbox and the human gate

BreezyCorp's defining rule is agents prepare, humans decide. This page explains the machinery behind it — the agentic harness, proposed actions, routing, and the review inbox where you do the deciding.

The workflow spine

Every module follows the same shape:

instruction → agent prepares → human decides → loop closes

An instruction arrives (from an intake channel, a schedule, or an operator). An agent run does the preparation — reading data, calling tools, filling forms, evaluating rules. The run produces a proposed action. A human decides on it. Once decided, the loop closes — the action applies, the registers or artifacts update, and the audit trail records who decided what, when.

Runs and steps

A run is one execution of an agent workflow for an entity. It is durable and resumable — it can pause waiting for a client, a document, or your decision, and pick up exactly where it left off. A run is made of steps, each of a known kind:

• LLM — a model call (records model, prompt version, tokens, cost, latency).
• Tool — a deterministic action (a calculation, a lookup, a document build).
• Form — a dynamic form bound to live data, sent to a client or operator.
• Rule — an evaluation against a jurisdiction rule pack.
• HITL (human-in-the-loop) — a deliberate stop for a human decision.

You can watch runs under Runs (/dashboard/runs); you act on them in the review inbox.

Proposed actions and routing

An agent never files, sends, or posts on its own. It produces a proposed action, and the platform routes it according to risk:

• Auto-apply — low-risk, fully-determined actions may apply directly (still audited).
• Queue — routed to the review inbox for an operator decision.
• Escalate — sent to a higher-scoped role (e.g. a Group Lead).
• Mandatory human gate — regulated or external actions (filings, client dispatches) always require a human approval; there is no auto-apply path.

The review inbox

The review inbox (/dashboard/review) is where queued and gated actions wait. For each item you can:

• Approve — the action applies and the loop closes.
• Edit — adjust the prepared content, then approve.
• Reject — send it back, with a reason recorded.

Who may approve a regulated or external action is constrained by role and scope: operators, module specialists (within their module), and group leads — never a client role. A Platform Admin configures the platform but does not thereby bypass the gate.

Why it's built this way

• Accountability — every decision has a named human and a timestamp.
• Reproducibility — every AI step records its model and prompt version, so a filing can be explained later.
• Safety — nothing regulated reaches a regulator or a client without a human saying yes.

Related

• The platform model — where work attaches and how isolation works.
• Intake channels — how instructions arrive.
• Roles & permissions — who can approve what.