Intercept Tool Approval Guard Laravel Package

Product Decisions This Supports

• Build vs. buy for agent tool governance: If the roadmap includes LLM/agent features that can execute tools (write to DB, call internal APIs, send emails, move money), this package is a candidate to supply the "human approval before execution" checkpoint instead of hand-rolling one. Treat it as a narrow, composable primitive rather than a platform.
• Feature scoping and time-to-market: A guard-style package can shorten the path to a shippable "approve/deny before the agent acts" experience, letting the team spend its own effort on the approval UX, policy rules, and audit trail that are actually differentiating.
• Risk and compliance posture: Supports decisions about whether high-risk tool classes (destructive, financial, PII-touching) require explicit sign-off, and gives a defensible answer to security review questions about agent autonomy.
• Roadmap sequencing: Fits an "agent safety / guardrails" track ahead of expanding agent autonomy. Approval gating is a prerequisite for letting agents touch production surfaces; it can ship early and cheaply.
• Buy-vs-integrate: Because it is a read-only subtree split of promptphp/intercept, the real decision is whether to adopt the upstream intercept ecosystem. This package is an entry point, not an independent commitment — evaluate the parent package's maintenance, release cadence, and API stability before standardizing.
• Dependency and support policy: Informs whether this belongs in composer.json directly or is pulled transitively, and whether the team accepts depending on a package whose issue tracker and changelog live in a different repository.

When to Consider This Package

• You are building Laravel/PHP agents (or scheduled/queued jobs that call tools on an LLM's behalf) and need an interception point where a tool invocation can be held for approval.
• You already use, or are willing to adopt, promptphp/intercept; this package is only a distribution artifact of it. Adopting it standalone without the parent ecosystem makes little sense.
• Your approval model is coarse-grained — pause, review, approve/deny, resume. If you need rich policy DSLs, role matrices, multi-step escalation, or SLA-driven approvals, expect to build that layer yourself or look elsewhere.
• Your team accepts semver pre-2.x churn: v1.1.1 signals a stabilizing but still young API.
• Look elsewhere or defer if:
  • You need a vendor-supported, SLA-backed guardrail product with an independent security disclosure process. A subtree split has no separate issue tracker, changelog, or CVE feed — everything routes upstream, and this release note carries no functional detail beyond a source commit pin.
  • You need framework-agnostic (non-Laravel) support, synchronous-only guarantees, or a managed approval UI — none of that is evidenced here.
  • Your organization requires per-release changelogs and reproducible, artifact-level release notes. This release communicates only intercept-source: 73ed9bb…, which is a traceability pointer, not a change description.
  • Approval volume is high enough that human-in-the-loop becomes a bottleneck; you would want automated policy evaluation first, approval as fallback.

Adoption criteria to confirm before committing: verify the parent promptphp/intercept repository's recent activity, open-issue responsiveness, and whether v1.1.1 contains behavioral changes or only a source re-sync (the notes do not say). Pin to ^1.1 and diff the upstream commits between your current pin and 73ed9bb rather than trusting the split tag alone.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, focused PHP/Laravel library that adds a human approval checkpoint before an AI agent is allowed to execute an action — the difference between an agent that drafts an email and one that sends it. It is low-cost to trial and lets us ship agent features with a defensible safety story rather than blocking on a from-scratch build. It is one component of a larger ecosystem (promptphp/intercept), so the real commitment is to that upstream project, not this tag.

For engineering: Version 1.1.1 is a maintenance release of a read-only subtree split; the only substantive information is the pinned upstream commit 73ed9bb. There is no separate changelog, issue tracker, or release narrative here, so change review must happen against the parent repository. Proposed handling: pin the version, diff upstream commits since our current pin, and treat the package as a thin, replaceable interception seam behind our own interface — so we can swap it if the upstream project stalls or the API shifts. Do not spread direct imports across the codebase.

Decision requested: Approve a time-boxed spike (one engineer, ~1 week) to integrate against the parent intercept package, with the explicit exit criterion that we can wrap the guard behind an internal abstraction and that upstream shows active maintenance.