Laravel Loop Filament Laravel Package

Product Decisions This Supports

• Build vs. buy on the internal AI-operations surface. The package ships pre-built Filament resources and pages for browsing, creating, editing, and monitoring Loop agents, including run/conversation history. The alternative is a bespoke admin screen we own, staff, and maintain forever. The PM decision is a clean trade: one internal-tooling sprint plus indefinite upkeep versus a pinned 0.x dependency with a periodic review pass. This is a classic "convert a recurring engineering line item into a vendor dependency" call, and it belongs in the buy column for a non-differentiating back-office surface.
• Whether our agents are operator-facing or headless. This is the gating question and the PM should answer it before funding any further evaluation. If a human needs to trigger or inspect agent runs from an admin panel, the package creates real leverage. If our agent usage is queued jobs, cron, or API calls with no human in the loop, it belongs nowhere near the roadmap. Everything downstream depends on this single answer.
• Scope control on the internal-tooling roadmap. For a team already running Filament for back-office tooling, this extends the existing admin surface rather than opening a new one. It supports a deliberate "thin vendor glue over bespoke admin code" strategy — treat internal tooling as a cost center to be minimized, not a product to be invested in.
• Dependency-tier classification as an explicit decision. A pre-1.0, single-maintainer, 31-star, zero-dependent package is appropriate for internal admin tooling and disqualifying for anything SLA-bearing or compliance-scoped. A PM should force the tier to be written down now, with a named owner and a documented fallback, rather than rediscovering the classification during an incident.
• Filament v4 upgrade sequencing as roadmap input. Release 0.1.5 is a dependency-alignment patch enabling Filament v4, with no stated product-facing change. If this plugin is anywhere in our admin dependency graph, it removes one blocker on the v4 workstream. Frame it as enablement/maintenance, not a feature. Critically, our v4 date is set by the slowest Filament plugin in the tree — this package is necessary but not sufficient, so the real roadmap commitment is a full plugin audit.
• Prioritizing the v4 migration date. Composer cannot hold two Filament majors at once, so every Filament-dependent package becomes a gate. 0.1.5 clears one gate; the scheduling commitment should wait on the enumerable remainder. This is a PM-visible dependency, not just an engineering detail, because it moves a date.

When to Consider This Package

Consider it when:

• We run Filament and laravel-loop as first-class parts of the same application. This is a bridge package; it inherits both the value and the limitations of the underlying Loop package. Adopting it without Loop in the stack inverts the buy-vs-build math.
• We want operators to trigger, monitor, and inspect agent runs without funding custom admin screens — the core use case.
• We are planning or executing a Filament v4 migration. Treat >= 0.1.5 as the minimum floor; earlier tags will not resolve against v4. Validate on staging first.
• We prefer many small, composable vendor packages over a monolithic admin suite, and we are comfortable with pre-1.0 versioning plus a review pass on each tag.
• The admin surface is internal and non-SLA. Agents can invoke tools with side effects, so panel scoping and Filament policy enforcement are a security control. This belongs behind admin authorization, never on a customer-facing surface.

Look elsewhere when:

• API stability is a hard requirement. At 0.1.x there is no compatibility promise and no LTS. A patch release may legitimately carry a breaking constraint change.
• laravel-loop is not already in the stack. Adding a bridge to pull in a second package for a capability we do not otherwise need is a straightforward decline.
• Filament's native Repeater/Builder or a simple custom page covers the use case. Always compare against the built-in before adding a dependency to the admin layer.
• We are stable on Filament v3 and not migrating. Nothing here forces an upgrade. If 0.1.5 turns out to be a hard ^4.0 bump rather than a widened ^3.0|^4.0 disjunction, read it as a signal to schedule the migration, not a patch to apply today.
• The capability is headless. If no human drives or inspects agents from a panel, skip it.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk adoption that gives operators a maintained admin interface for our AI agents instead of us building and owning one. The current release (0.1.5) is a compatibility patch that keeps our admin tooling aligned with the latest Filament release — no product-facing change, no new spend, and it clears one blocker on the admin-panel upgrade already on our roadmap. The trade-off is honest: a pre-1.0, single-maintainer dependency with 31 stars and no dependents. That is acceptable for internal operator tooling and not acceptable for anything with an SLA. The ask is approval to adopt it at the internal-tooling tier, with a named owner and a documented fallback — not a strategic bet.

For engineering: Treat the package version and the Filament major as a coupled pair in dependency policy and write it down: "Filament 3 → loop-filament 0.1.4; Filament 4 → loop-filament 0.1.5+." Because it is 0.x, prefer exact pins or ~0.1.5 in production manifests and rely on the lock file for reproducibility. One thing to resolve before scheduling anything: 0.1.5 is described as a dependency-compatibility patch, but the constraint shape matters — "widened to ^3.0|^4.0" is a safe patch for v3 apps, while "bumped to ^4.0" forces a co-upgrade. Read the actual composer.json diff in PR #9 and check whether any code changed for v4's registration APIs or whether the bump is constraint-only and untested against v4. Recommended path: inventory every Filament-dependent package and its v4 status first (the migration date is set by the last one), then bump to ^0.1.5 on a non-production branch, run composer update --with-dependencies, confirm a single Filament major resolves across the tree, and smoke-test the panel surface end to end — resource listing, Loop run pages, actions, asset publishing, and authorization gates on agent-triggering actions. Roughly half a day per application, then roll one app at a time. The genuine risk is not this package; it is coordinating every other Filament plugin still pinned to v3 so we do not end up with an unresolvable dependency set.