Product Decisions This Supports
- Build vs. buy for in-product assistance. An embedded AI chat assistant in your admin panel is a classic "nice-to-have that costs a quarter to build well." This package lets you evaluate the buy side cheaply: it's a thin integration layer over a hosted service, so you can ship a pilot in an afternoon instead of scoping retrieval, prompt management, guardrails, and an eval loop.
- Support deflection and onboarding for internal/admin users. The most concrete ROI case is reducing "how do I do X in the admin?" tickets. Per-panel widget IDs mean you can scope a different assistant (and different knowledge base) to an ops panel versus a customer-support panel — useful for measuring deflection per team rather than in aggregate.
- Passing user context into the assistant. The user-context feature is the deciding capability. An assistant that knows who is asking (role, tenant, panel) can answer permission-aware questions; one that doesn't will hallucinate actions the user can't take. Treat this as the primary evaluation criterion, and verify exactly what fields are transmitted and whether they're minimized.
- Visibility rules as a staged rollout lever. Being able to show the widget to a subset of users/panels lets you run a controlled pilot: one internal panel, one team, a few weeks, measure ticket volume and thumbs-up/down before widening. This is a roadmap-friendly on-ramp rather than a flag-day launch.
- Public-page exposure is a separate product decision. The Blade component makes it trivial to put an AI assistant on marketing or docs pages. Do not let "it was easy to add" drive that decision — public assistants carry brand, accuracy, and abuse-handling risk and should go through their own review.
- Multi-version Filament support de-risks the platform upgrade. Supporting Filament 3, 4, and 5 means the widget doesn't pin your upgrade roadmap. That materially lowers the cost of adopting now, before your panel upgrade lands.
When to Consider This Package
Consider it when:
- You run Filament panels and want an AI assistant without owning model hosting, prompt iteration, or conversation storage.
- Your admin surface is large enough that navigation and "where is that setting" is a real support cost — typically multi-team, multi-panel setups.
- You need per-panel configuration and per-user context, not a single global chat bubble.
- You want a time-boxed pilot with a visible kill switch (visibility rules) and a clear success metric.
- You're comfortable sending user-identifying context to a third-party service and have checked that against your data-processing agreements.
Look elsewhere when:
- Data residency or confidentiality rules out a hosted third party. Nothing in this release suggests a self-hosted or bring-your-own-model option; if admin context can't leave your boundary, that's a hard stop and you're in build territory.
- You need guaranteed reliability or a support contract. This is a first release with no track record, no version history, and no evidence yet of backward-compatibility discipline. Treat it as a pilot dependency, not a load-bearing one.
- You need streaming, citations, tool-calling into your own domain logic, or eval tooling. None of that is described here; if those are requirements, this package is a starting point at best.
- Your panel is single-team and small. The overhead of a vendor relationship likely exceeds the support savings.
- You can't answer "what happens to conversations on churn?" before signing. Export, retention, and deletion terms matter more than the widget's feature list.
How to Pitch It (Stakeholders)
To executives: This is a low-cost experiment, not a platform commitment. A small integration lets us put an AI assistant inside our Filament admin panel and measure whether it reduces support load, scoped to one team for a fixed pilot. The main gating item is legal, not technical: we'd be sending user context to a third-party AI service, so we need a data-processing review before we start. Ask for a time-boxed pilot with a defined success metric (ticket volume, task completion time, user satisfaction) and an explicit decision point to continue, expand, or walk away.
To engineering: The package wires Asyntai's assistant into Filament 3, 4, and 5 panels via a per-panel widget, forwards user context, and honors visibility rules; a Blade component covers public pages. It's a thin adapter, which is good — low coupling, easy to remove. Two asks before we adopt: (1) audit exactly what user context is transmitted and confirm we're minimizing it; (2) confirm the public Blade component is off by default and gated behind our own review, since it's the highest-blast-radius feature in the release. Because this is v1.0.0 with no compatibility history, pin the version and isolate the integration behind our own config so a breaking change upstream is a one-file fix.
Recommendation: Adopt for a scoped internal pilot behind visibility rules; hold the public-page component until the privacy review and the pilot results are in. Revisit this assessment when the package publishes a changelog with a breaking-change policy, or when a self-hosted/self-managed option appears.