Filament Ai Writer Laravel Package

Product Decisions This Supports

• Build vs. buy for AI-assist UI in admin panels. The single biggest decision this package informs: whether to hand-roll an "AI generate" button, provider abstraction, streaming/retry logic, and response parsing, or adopt an existing Filament Action. At roughly a few hundred lines of glue code per field type, an in-house version is a credible 1–3 sprint line item. Buying (adopting) is justified when the roadmap values speed over control.
• Feature scoping for an existing Filament admin. This is an augmentation package, not a platform. It supports decisions like "ship AI-assisted content drafting to internal editors next sprint" without committing to a bespoke AI subsystem or a separate content tool.
• Multi-provider strategy. Support for Anthropic, OpenAI, Gemini, and (per description) OpenRouter, plus a AiProvider contract with container rebinding, means the PM decision isn't "which vendor" at build time — it's "which vendor per environment," with a documented escape hatch for a custom provider (Azure OpenAI, Bedrock, self-hosted). That de-risks vendor lock-in and lets procurement negotiate later.
• Monetization and entitlement design. beforeGenerate, globalBeforeGenerate, and the AiTextGenerated event are the load-bearing pieces for product decisions: credit-based metering, per-plan gating, free-tier caps, and usage analytics all hook here without forking the package. If the roadmap includes "charge for AI credits," this package already exposes the right seams.
• Field-level UX decisions across content workflows. Two interaction models are supported and each maps to a distinct product bet:
  • Interactive mode (modal + free-text brief) — for high-value creative fields where the human should steer: body copy, excerpts, landing page sections.
  • Silent mode (context fields in, result out, no modal) — for deterministic derivation tasks: slug from title, meta description from body, category assignment from title+body, tag suggestion from content. These are the highest-ROI features because they remove keystrokes with near-zero cognitive load.
• Structured-output decisions. valueMap (enum/scalar targets), allowedValues (constrained arrays with server-side filtering of out-of-list values), expectArray, and normalizeArrayCase are exactly the knobs needed to decide "can we let AI populate this field, or does data hygiene forbid it?" The filtering of disallowed values before injection is the difference between a demo and something you'd put in front of an editor.
• Roadmap sequencing. Because provider abstraction and the event hooks exist, later roadmap items — usage dashboards, per-team quotas, cost attribution, audit trails — are listener work, not architectural work. That's a meaningful signal for sequencing.
• Internal tooling vs. customer-facing surface. Beta status and single-maintainer risk argue for internal-only deployment (editor assistance, ops efficiency) versus customer-facing generation, which would demand SLAs, output moderation, and vendor failover this package does not yet evidence.

When to Consider This Package

Adopt when:

• You are already on Filament 4.x + Laravel 10/11/12 + PHP 8.1+. This is a hard requirement — Filament 3 shops get nothing.
• The requirement is narrow and well-matched: add an AI-assisted text button to form fields in an existing admin panel, without building a provider layer.
• You need more than one provider or expect to switch. The contract + container rebinding is the package's most durable asset.
• You need entitlement or metering hooks on day one. globalBeforeGenerate for permissions/plan gating and AiTextGenerated for credit debits are documented with working examples — genuinely the strongest part of the README.
• Your target fields are the derivation class: slug, excerpt, meta description, category, tags. Silent mode with contextFields covers these cleanly.
• You accept vendor risk on a 9-star, zero-dependent, beta package and are prepared to fork or vendor it locally. The README documents the path-repository workflow for this, which is a reasonable signal the author expects local forks.

Look elsewhere, or build in-house, when:

• Filament 3 or earlier. No support.
• Customer-facing generation at scale. Beta status, "APIs may change and issues can occur," and a single maintainer are disqualifying for a surface with uptime commitments. There is no evidence of rate-limit handling beyond retry_times/retry_sleep_ms, no moderation layer, no streaming, and no failover across providers on error.
• You need streaming responses. Not present. Long generations will be a blocking request bounded by AI_WRITER_TIMEOUT (default 60s). If UX requires token-by-token rendering, this is the wrong tool.
• You need batch or background generation. Everything here is a synchronous click handler. Bulk generation, queued jobs, and scheduled content ops are out of scope.
• You need prompt/version management, eval harnesses, or output observability. Prompts live as inline strings in PHP. That's fine for ten fields, untenable at a hundred — there is no central prompt registry, no A/B capability, no stored prompt versions correlated to outputs.
• You need RAG/embeddings, document grounding, or conversation state. Nothing in the API suggests retrieval or multi-turn. Context is limited to sibling form field values.
• You need guaranteed cost control. AI_WRITER_MAX_TOKENS and per-provider token settings exist, but there is no spend ceiling, no per-user budget enforcement in-package (only via your own beforeGenerate logic), and no cost estimation in the event payload — you get provider, model, result, not token counts or cost.
• Non-Filament front ends. This is a Filament Action; the value is inseparable from the field lifecycle. Livewire/Inertia/API consumers get nothing reusable beyond the provider classes.
• You require a support contract or security review. Single maintainer, no stated security policy, MIT with no commercial backing. API keys are env-driven (good — not stored in DB), but there is no documented key-per-tenant story.

Risk register to weigh explicitly: 9 stars and 0 dependents means near-zero production validation in the wild; the first release was late 2026 and it is still pre-1.0, so breaking changes are expected, not hypothetical; the changelog shows active bug-fixing (e.g., OpenAI's max_tokens → max_completion_tokens migration), which is reassuring for maintenance but confirms the provider APIs themselves are moving targets you inherit.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: "This is a small, MIT-licensed component that adds an 'AI write this for me' button to fields in our existing admin panel. The strategic value is not the button — it's that it lets us test an AI-assisted editing workflow in production for roughly the cost of a sprint, on a system we already run, with metering and permission hooks built in. We can measure actual editor time saved before committing to a larger AI investment. The trade-off is real: it's a pre-1.0 package from a single maintainer, so we should pilot it internally, budget a small amount of engineering to vendor a fork, and not put it in front of customers until it stabilizes."

To executives — the decision framing:

• Cost/benefit: adopting is days; building equivalent (provider abstraction, response parsing for enums and arrays, entitlement hooks, eventing) is weeks. We are buying a head start on a feature, not a platform.
• Reversibility: high. It is a Composer package behind a defined interface; removing it means removing hintAction calls. The custom-provider binding means we are not coupled to any AI vendor.
• Risk being accepted: a beta dependency with one maintainer. Mitigation is internal-only scope, a vendored fork, and keeping our own provider implementation behind the same contract so we can swap out wholesale.
• What it unlocks: metered AI credits, per-plan gating, and usage analytics are already exposed as hooks. If the AI feature succeeds commercially, the path to charging for it does not require re-architecture.

To engineering — the summary: "Filament 4 Action, hintAction/suffixAction on any field. Two modes: interactive modal for creative fields, silent derivation from contextFields for slug/excerpt/category/tags. Provider layer is an AiProvider contract bound in the container — override it for Azure, Bedrock, or anything custom. Output shaping is handled: valueMap for selects, allowedValues + expectArray + normalizeArrayCase for tags, with out-of-list values filtered server-side before injection. Metering and authz go in beforeGenerate and globalBeforeGenerate; AiTextGenerated fires post-generation with user/field/provider/model/result for ledgering. Config is env-first with an optional publishable config; keys never land in the database.

Three things to plan around: (1) generation is synchronous with a 60s default timeout — no streaming, so keep prompts short and set expectations in the UI. (2) Prompts are inline strings on each action; if we exceed ~15 AI fields, we should introduce our own prompt registry rather than scatter them further. (3) Pre-1.0 with one maintainer — install via a path or VCS repository so we can patch quickly, pin the version, and add a smoke test around each wired field so an upstream change fails loudly rather than silently producing bad content in a form."