Filament Agents Laravel Package

Technical Evaluation

Architecture fit

• Clean two-layer split, and the boundary is the thing to enforce in review: packstub/agents is the engine (agent loop, tool contracts, budget enforcement, MCP server, migrations, config); packstub/filament-agents is a thin Filament v5 adapter (pages, Livewire components, resources, navigation). Anything that must run outside a panel belongs upstream; our record shapes, filter vocabulary, prompt domain content, and consent vocabulary belong in our app behind AgentResource and the agent's slots.
• One tool list feeds two channels — the in-panel assistant (laravel/ai) and an MCP server (laravel/mcp). That is a strategic property, not an implementation detail: "expose our admin toolset over MCP" becomes a cheap follow-on bet rather than a second workstream.
• The assistant inherits the panel's guard, tenancy, and policies via FilamentContext, with TenantSet still firing. Reusing the existing authorization model instead of standing up a parallel permission surface is the single most defensible thing here from a compliance and audit standpoint — reviewers can reason about AI access with rules they already have.
• Answers render as the panel's own live tables and charts (AgentTable Livewire) rather than markdown. Consequence for us: answer quality is partly a function of how good our Filament resources already are. That's a useful forcing function but also means resource debt becomes assistant debt.

Integration feasibility

• Feasible but gated on hard floors: Filament v5 and PHP 8.4+, with no fallback path. Confirm both before any planning commitment.
• Lockstep dependency on the sibling engine — v1.16 requires packstub/agents ^1.9, and the classifier confidence display arrives with engine 1.10. Plugin and engine upgrade as a pair; anything running outside a panel (tools, budget rules, migrations, config) is an engine change and shapes our upgrade path.
• Database story is now credible: Postgres parity for case-insensitive chat search, null-safe sorting of unclassified chats, and a guarded tenant lookup (no slug passed into an integer key). CI runs Postgres and MySQL alongside SQLite. Teams standardized on Postgres can adopt without a "chat search is subtly broken on our fleet" caveat.

Technical risk

• Maturity/supply chain is the headline risk. 13 stars, 0 dependents, MIT, active cadence, single maintainer. Zero dependents means we are an early adopter, not a follower — say that out loud in the business case and require a code review plus a fork/vendoring escape hatch before production.
• We now own consent policy. v1.16 makes approval fail-closed: a typed reply over a waiting proposal is read by an app-owned rule, per-locale word lists (extendable and replaceable in-app), and an opt-in classifier; ambiguous replies ("Ok?", "Yes, but only Alpha.") no longer approve. This is a behavior change on a minor upgrade — operators trained on the old semantics need retraining, and approval UX must be localized and tested in every locale we serve. Product and QA time for that is real, not incidental.
• Scope risk if we only want chat. If the MCP half is unused, we are still maintaining it. Adopt when both channels are on the roadmap.
• Provider latitude is constrained by the laravel/ai ecosystem; we do not get provider-agnostic model integration from this package.

Key questions

• Is our panel actually on Filament v5 and PHP 8.4+, in every environment including staging and CI?
• Do we want MCP in the next two quarters, or is this a chat-only purchase?
• Who owns the approval rule, the per-locale word lists, and the classifier opt-in — and who signs off on the locale set?
• Which mutating tools will be approvable in the pilot, and which stay read-only?
• Who consumes the Decided by column — risk, support, or nobody? If nobody will ever ask "why did it do that?", the provenance machinery is overhead.
• Do we have a named engineering owner for the domain layer behind AgentResource and the agent slots?

Integration Approach

Stack fit

• Assumes a Laravel + Filament v5 admin panel on PHP 8.4+, which matches a typical internal back-office. The package is panel-centric by design — no email, Slack, or voice channels. If our operators already live in the panel and "ask the panel" beats "open a separate BI tool," the fit is good.
• Best-fit workloads, roughly in adoption order: internal ops/admin back-offices; B2B SaaS tenant admins querying their own tenant data in natural language; support and CS tooling.
• Budgets and an operator limits resource ship in the box. That is where the package earns its keep versus rolling our own loop, tool registry, conversation store, and audit plumbing.

Migration path

• Greenfield install rather than a migration: no incumbent AI surface to displace. The migration we actually perform is organizational — moving "AI assistant in the back-office" from next year to this sprint, and shifting the roadmap question from "can we afford to build this?" to "which tools and data do we expose first, and in what order?"
• Plan a spike against a staging panel on Postgres with a widget resource fixture, and explicitly exercise an ambiguous approval reply, before committing.
• Retain a vendoring/fork path: pin exact versions, read changelogs, and be willing to file or fix issues upstream.

Compatibility

• Hard floors: Filament v5, PHP 8.4+. Hard coupling: packstub/agents ^1.9 for v1.16.
• Approval contract is not stable across minor versions — v1.16 changed what counts as consent. Treat any engine bump as a behavior change requiring operator comms, not a routine dependency refresh.
• Namespace collision note: both repos map Packstub\Agents\, so a class name may exist in one repo only. Relevant if we ever vendor or patch.

Sequencing

1. Environment gate — verify Filament v5 / PHP 8.4+ everywhere; confirm Postgres parity in our own CI.
2. Dependency review — code review of plugin and engine, pin versions, decide fork/vendor strategy, socialize the single-maintainer risk with the risk owner.
3. Spike — staging panel, one widget resource fixture, one read tool, one approvable write tool, one ambiguous approval reply on Postgres.
4. Policy build — approval rule, per-locale word lists, classifier opt-in, and the locale test matrix. This is app work, and it is on the critical path.
5. Governance — per-workspace budgets, operator limits page, model configuration; get finance sign-off on the caps before the pilot.
6. Pilot — named owner, limited cohort, read-mostly toolset, provenance reviewed weekly.
7. MCP exposure — planned as its own workstream with its own access and support story, not a freebie off the back of the chat pilot.

Operational Impact

Maintenance

• Two packages to track in lockstep, with an active release cadence and a single maintainer. Budget ongoing time for changelog review and paired upgrades — not a one-time install cost.
• We carry the domain layer permanently: record shapes, filters, prompt content, approval vocabulary and locale word lists. That is deliberate (it keeps the AI surface refactorable and prevents a shadow schema) but it is headcount, not a footnote.
• Upstream contributions may be necessary. Assume we file or fix, and that we may need to vendor.

Support

• No SLA, no completed security review, no long support window. If the business needs a vendor to call, this is not that vendor.
• Support burden is ours: operator questions about what the assistant can reach, why it wrote something, and what "approve" means in their locale. The Decided by column plus its filter is the primary support tool — it turns "why did the agent write that record?" into a filterable answer instead of a log dive. Telemetry and audit should read from that column rather than parsing transcripts.
• Localization of consent language is a support and QA obligation per locale we serve.

Scaling

• Panel-scoped by construction; tenancy is inherited, so scaling follows the panel's scaling story.
• Cost scales with usage, which is why budgets and the operator limits page matter: per-workspace caps and model configuration let us turn the assistant on for a pilot cohort without uncapped exposure. This is the surface a finance owner signs off on.
• Answer rendering reuses our resources, so heavy tables inherit our existing pagination and query characteristics — no new scaling regime, but no insulation from existing resource performance either.
• MCP widens the consumer set beyond panel users (desktop AI clients, IDEs, other agents). That is a reach multiplier and an access-review multiplier at the same time; scope and rate-limit it deliberately.

Failure modes

• Ambiguous approval read as consent — mitigated by v1.16's fail-closed defaults, but only if we actually build and test the rule and word lists per locale. Untested locales are the residual hole.
• Silent behavior change on upgrade — an engine bump alters what counts as "yes." Mitigation: pinned versions, paired upgrades, operator comms, regression tests on approval phrases.
• Maintainer abandonment — 0 dependents, 13 stars, one maintainer. Mitigation: code review now, fork/vendor readiness, and an exit plan documented before production.
• Unauthorized reach — mitigated structurally by inheriting panel authorization and tenancy; the risk shifts to how sloppily we define tools, which is fully in our control.
• Runaway spend — mitigated by per-workspace budgets and the operator limits page, provided caps are set before the pilot rather than after.
• Database-specific surprises — materially reduced by the Postgres fixes and multi-DB CI, but our own migrations and query patterns still need coverage.

Ramp-up

• Engineering: low-to-moderate to install, moderate to own. The install is a plugin plus tool wiring; the ownership is the approval rule, locale vocabulary, and domain slots.
• Product/QA: non-trivial. Consent semantics, locale coverage, and answer quality against real resources are product work with a QA matrix attached.
• Operators: modest but real. They need to learn that writes require explicit approval, that hedged replies are treated as no, and where to look when they want to know why the agent acted.
• Stakeholder framing: time-to-value on the AI roadmap plus avoided build cost on loop, tools, approvals, budgets, and audit trail. The risk is maturity — MIT, actively released, early adoption. Mitigate with pinned versions, a dependency code review, and a controlled pilot with a named owner. Do not present the risk as zero.