Laravel Ai Attributes Laravel Package

Product Decisions This Supports

• Build vs. buy for AI-enriched Eloquent data: v2.0.0 reframes the decision cleanly. laravel/ai is the transport layer (providers, retries, manager); this package is the modelling layer. The question is no longer "which AI SDK" but "do we want AI-generated fields to behave like ordinary model attributes?" If your roadmap involves summaries, classifications, tags, embeddings-backed flags, or SEO copy attached to domain entities, this is a concrete build-vs-buy comparator against ~200–500 lines of in-house trait code.
• Feature scoping for "AI in the admin panel" style initiatives: $article->ai_summary, $model->aiPersona('...'), and GenerateAiAttributeJob let you scope an MVP as "declarative attributes on existing models" rather than "a new AI service." That is a materially smaller estimate — no new tables, no bespoke job classes, no prompt-config UI required for a first slice.
• Cost governance as a product requirement: content-hash caching (same input → free) and aiAttributeOrNull() give you a defensible answer to "what does this cost at 50k rows?" before you commit. This is the strongest roadmap argument: caching is a product feature (deterministic, idempotent generation), not just an optimisation.
• Provider strategy / procurement: inheriting all 14 providers from laravel/ai removes per-provider procurement negotiation from the critical path. You can ship on OpenAI, swap to Azure OpenAI for enterprise data-residency, or fall back to Ollama for on-prem/air-gapped customers — as configuration, not as code. That directly supports enterprise deal requirements.
• Roadmap sequencing around a platform dependency: the package now tracks Laravel's official direction. That is a positive signal for sequencing an AI roadmap (you're not betting on a vendor's private abstraction), but it also means your feature plan inherits laravel/ai's release cadence and any future first-party additions to this exact layer.
• Backfill and editorial workflow decisions: the ai:regenerate Artisan command and queued generation turn "backfill 30k legacy articles" from an engineering spike into an ops task — useful for deciding whether an AI-enrichment feature ships as a big-bang migration or as a gradual, queue-driven rollout.
• Make-vs-keep for internal tooling: teams that already wrote this trait internally should treat v2.0.0 as a forcing function to either delete theirs or deliberately keep it — but the decision should be made once, not drift.

When to Consider This Package

Adopt when most of the following hold:

• You are on PHP 8.3+ and Laravel 12.62+ or 13.x. The dropped Laravel 11 support is the single hardest gate — if you're mid-cycle on L11, this package is not available to you until you upgrade, and that upgrade is the real cost, not the composer require.
• You already have (or will adopt) laravel/ai. This package is a strict add-on; it adds no provider value on its own.
• Your AI outputs are per-record, per-field, and materialised — summaries, labels, tags, sentiment, metadata. Not chat, not streaming, not multi-turn agents, not tool-calling workflows.
• You value framework-native ergonomics ($model->field just works in Blade, API resources, and Nova/Filament) over bespoke prompt-orchestration logic.
• You can accept config migration work: provider config moves to config/ai.php, driver → provider, and max_tokens/temperature are removed from $aiAttributes. Budget a half-day for a small app, more if attributes are spread across many models.

Look elsewhere when:

• You need agentic, conversational, or streaming behaviour — laravel/ai directly, or a dedicated orchestration layer, is the right call.
• You need fine-grained per-attribute token/temperature control. v2.0.0 explicitly removed these from the attribute definition; if prompt tuning per field is a core product requirement, this abstraction is now in your way.
• You are pre-Laravel 12.62 / pre-PHP 8.3 and cannot move.
• You want a stable, pinned API surface. A 1.x → 2.0 rewrite that deleted ~500 lines and its own driver layer in favour of a first-party SDK is a reasonable move, but it signals a package still finding its shape. Plan for another breaking release if laravel/ai absorbs attribute-level convenience itself — which is the obvious competitive risk.
• Your AI needs are one or two one-off calls. A trait dependency is over-engineering for a single summarise-a-ticket endpoint.
• You require vendor SLAs, security review, or long-term support commitments. Single-maintainer package; treat it as a code dependency you may need to fork.

How to Pitch It (Stakeholders)

For executives: This release makes our AI feature bet cheaper and lower-risk, not bigger. The package's author deleted their own provider integration layer — roughly 500 lines — and rebuilt on Laravel's official laravel/ai SDK. That means we inherit Laravel's maintenance, security posture, and 14 supported providers instead of a third party's. What remains is a thin convenience layer that lets any database record expose AI-generated fields as if they were normal columns. Net effect: faster to ship, fewer moving parts to own, and a provider-swap option that satisfies enterprise data-residency questions. The trade: it is a breaking upgrade, it requires PHP 8.3+ and Laravel 12.62+, and dropping Laravel 11 support is a real constraint on our upgrade calendar.

For engineering: It's now a decorator over laravel/ai, not a competing SDK. We get attribute magics (HasAIAttributes), content-hash caching, typed casting (text/json/number/bool), runtime persona override, a queued job, and ai:regenerate — about the amount of glue we'd otherwise write and own ourselves. Migration is mechanical but non-trivial: driver → provider, remove max_tokens/temperature from attribute definitions, move config into config/ai.php, set AI_ATTRIBUTES_PROVIDER. Tests are mocked via AnonymousAgent::fake(), so our own test suite can follow the same pattern. Two caveats worth stating plainly: the per-attribute max_tokens/temperature removal means less prompt-level control, and the package is single-maintainer — pin the major version and keep a fork-and-own escape hatch in mind.

Recommendation: Approve a spike, not an adoption. One engineer, one non-critical model, one sprint — validate the attribute ergonomics, measure the caching hit rate against real data, and confirm the Laravel 12.62/PHP 8.3 baseline against our upgrade plan. Revisit as a committed dependency once a concrete feature (e.g. article summaries or support-ticket classification) is on the roadmap.