Verdict Console Laravel Package

Product Decisions This Supports

• Build vs. buy for the "human approval" layer. Every agent that can take a consequential action (issue a refund, send an email, mutate a record, call a paid API) eventually needs a pause → review → resume path. This package is a ready-made runtime plus operator UI for exactly that, so the decision becomes "do we adopt this and spend our time on domain-specific policy" rather than "do we spend a sprint building an approval queue, an identity seam, and resume semantics."
• Autonomy tiering on the roadmap. It gives you a concrete mechanism to ship graduated autonomy: tools start behind a Verdict-gated pause with an operator approving each call, then move to auto-approve as confidence grows. That reframes "can we ship this agent at all?" into "which of its tools need a human, and in what order do we remove that requirement?"
• Time-to-pilot with design partners or regulated customers. Approval-with-audit-trail is usually the gating item in security review. Having an operator console with a real approval record shortens the compliance conversation, which is often the long pole rather than the model work.
• Scope of the operator experience. The UI is the product surface your reviewers (ops, support, finance, trust & safety) actually touch. Reviewing whether it fits your reviewers' workflow — context shown at approval time, queue handling, who can approve what — is a product decision, not an implementation detail. Identity policy matters here: a pause captured for a participant is resumed as that participant, never under an identity the host cannot reproduce, so approval authority maps to a real, resolvable person rather than an ambiguous system actor.
• Whether live token streaming is in scope. ChatService::stream() mirrors start/continue including the authorization seams, and pins the streamed-pause behavior: the approval request arrives as ToolApprovalRequest with the tool unexecuted, but ingestion and conversation persistence only land once the stream is fully consumed. If your console shows live tokens, you inherit a constraint — abandoned or re-iterated streams are explicitly refused by turn(). That is a UX/architecture trade-off worth deciding deliberately, not discovering in QA.
• Upgrade and compatibility policy. The version-token contract on ResumableAgents (host-supplied opaque token, exact-equality comparison only, null incomparable) tells you the maintainers are treating reconstruction fidelity as a real product concern but are making no compatibility or equivalence claims. That is a signal to plan for pinned versions and deliberate upgrades.

When to Consider This Package

Consider it when:

• You have already committed — or are prepared to commit — to Laravel + laravel/ai + Verdict as your agent stack. This is not stack-neutral; it sits inside that governance model.
• Your agents perform actions where a wrong call is expensive, irreversible, or externally visible, and you need a human approval step with an identifiable approver.
• You want the approval console to exist soon, and your team's comparative advantage is domain policy, not HITL plumbing.
• You can absorb churn: this is a 0.x line where the minor version is the breaking-change boundary, with an explicit BREAKING contract change in v0.12.0.

Look elsewhere, or plan to build, when:

• Adoption risk tolerance is low. Zero stars, zero dependents, no external production users to learn from. Treat this as a promising early library, not a proven dependency; assume you may need to read the source or fork.
• You need approval workflows beyond the participant model — multi-step escalation chains, SLA timers, delegated approvers, org-chart RBAC, approvals spanning non-AI processes. This is an agent approval runtime, not a BPM/workflow engine.
• Your stack is polyglot or non-Laravel, or your agents are not governed by Verdict.
• Your tools are low-risk and fully automatable — an approval console is pure overhead.
• You need vendor-backed SLAs or a support contract.

A reasonable de-risking posture: a time-boxed spike against one real high-risk tool, pinned version, behind your own thin adapter interface, before committing the roadmap to it.

How to Pitch It (Stakeholders)

To executives: We can put AI agents into production on actions that touch customers and money without giving the model unattended authority. This package supplies the approval step and the operator screen — the part that usually stalls in security review and costs us weeks to build ourselves. It is MIT-licensed and free, so the investment is integration time, not licence spend. The honest caveat: it is early-stage software with no external adoption yet, so we should pilot it on one workflow and keep an exit path.

To engineering: It owns the parts that are easy to get subtly wrong — pausing a governed tool call, refusing unauthorized or unresolvable resumes, ensuring the tool does not execute before approval, and keeping the same authorization seams across start/continue/stream. It is 0.x with a breaking-change-per-minor policy; budget for pinned versions and reading the changelog. Recommended: wrap it behind our own interface so we can swap or fork.

To security and compliance: Approvals are attributed to a resolvable participant identity, the paused call is not executed until a human acts, and the console persists the interaction. Reconstruction versions let us pin what "resume" rebuilds — though the package makes no equivalence guarantees, so we own that verification in our resolver.