Laravel Ai Engine Laravel Package

Product Decisions This Supports

• Build vs. buy for the "AI layer" of a Laravel product. This package is a pre-built substrate for the parts of an AI feature that are expensive and undifferentiated: multi-provider failover, tool/skill registration, planner runtime, embeddings + vector indexing, conversation memory, streaming, tracing, and credit metering. The decision it informs is not "should we ship AI" but "do we spend a quarter building agent plumbing or spend it on our domain workflows."
• Whether to commit to an agentic/interactive product surface at all. Because tools extend AgentTool/SimpleAgentTool and model CRUD can be generated declaratively via AiResource::for(Model::class)->search()->writable()->register(), the cost of a first "ask your data" or "create a record by chatting" surface drops from a platform project to a feature ticket. That changes what belongs on the roadmap this half.
• Roadmap sequencing for AI features. The capability map gives a credible phasing ladder: (1) single-prompt generation with failover, (2) read-only data_query/aggregate_data analytics assistant, (3) write actions behind confirmation + ResolvesAgentRelations, (4) RAG over knowledge/content, (5) domain sub-agents with scoped toolsets, (6) file intake with prefill for structured forms, (7) media (image/video/voice). Each rung is independently shippable and independently valuable, which is exactly what a roadmap wants.
• Monetization and packaging. CreditManager (hasCredits/deductCredits/calculateCredits), InsufficientCreditsException, and per-model credit_index turn "AI usage" into a metered, priceable SKU with per-model cost differentiation — feeding pricing-page and plan-tier decisions rather than a flat "AI included" promise.
• B2B / multi-tenant go-to-market. Fail-closed scoping via AIScopeResolver and scope_columns (user_id/workspace_id/tenant_id) flowing into data query, RAG, vector search, and memory is the difference between a single-tenant demo and a sellable enterprise SKU. It also removes the most common security objection from a security review.
• Vendor strategy. engines config with per-engine keys, fallback_engines, keyless-engine skipping, and ai:doctor diagnostics mean the product is not wired to one model vendor. That derisks margin exposure to a single provider's price change and enables "best model per task" (cheap model for classification, frontier model for the planner).
• Feature-scope calls the package lets you defer or decline. Federation (laravel-ai-engine-federation), Neo4j hybrid graph RAG, realtime voice, and the model council are all opt-in. Their presence lets you confidently say "not now" on each without the answer being "we'd have to rebuild the architecture."

When to Consider This Package

Consider it when:

• The product is Laravel/PHP and will stay Laravel/PHP. The value is the framework-native integration (Eloquent-aware tools, artisan commands, config-driven registration). Off-framework, the value evaporates.
• Your AI features are action-and-data oriented — CRUD over models, filtered analytics, document extraction and pre-fill, knowledge retrieval — not a thin chat wrapper. If a single generate() call would do, this is over-engineering.
• You need multi-provider redundancy and cost arbitrage on day one, not as a later refactor.
• You are multi-tenant or security-sensitive and would otherwise spec a bespoke scope model. The fail-closed default is a genuine adoption argument.
• You want commercial metering (credits) without building a billing-adjacent subsystem.
• Your team can own a fork. MIT license plus the maturity signals here (1 star, 0 dependents) means you must assume you are adopting code, not a vendor relationship.

Look elsewhere or build in-house when:

• You require a supported vendor, an SLA, security review paperwork, or an indemnity clause. None of that exists here, and no amount of MIT licensing substitutes for it.
• You need battle-tested-at-scale evidence. Zero dependents means zero production reference points; you would be the first. Treat any load, concurrency, or cost-per-request claim as unverified until your own spike confirms it.
• The bus factor matters more than the feature list. The surface here (~80 artisan commands, dozens of services, RAG/graph/voice/video/federation) is very large relative to visible maintainer depth. Breadth of this kind often correlates with uneven depth — expect thin spots.
• You need only prompt-in / text-out. Use a provider SDK or a minimal Laravel wrapper.
• Your architecture is polyglot or microservice-first and AI is a Python/TypeScript service. You can borrow the design decisions (tool registry, scope-fail-closed, credit metering, progressive tool disclosure) without the code.
• You are under a hard compliance regime requiring audited data flows through vendor-held infrastructure.

Evaluation gate before committing: a two-week, time-boxed spike with explicit exit criteria — one real domain agent, one data_query path against a scoped non-public model, one file-intake pre-fill flow, mocked-AIEngineService tests in CI, ai:doctor green on two providers with failover triggered deliberately, and a measured cost-per-action. Decide on evidence, not on the capability list.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have an opportunity to ship an AI assistant and AI-assisted data entry on top of our existing Laravel product in feature-ticket time rather than as a multi-quarter platform build. An MIT-licensed package already covers the unglamorous 80% — multi-provider failover, secure tenant-scoped data access, retrieval over our own content, conversation memory, per-user credit metering, and tracing. It is free to use and free to modify, so there is no licensing cost and no lock-in to a model vendor or to the package author: if the project stalls, we keep the code. The real cost is not the license — it is engineering ownership, because the package is early (essentially no public adoption) and we would be its first serious production user. Recommendation: fund a two-week spike with hard success criteria, then commit, fork-and-harden, or walk away with a reusable design we can implement ourselves.

To engineering: Treat this as a source-available accelerator to be forked and pinned, not a dependency to trust blindly. Adopt its architecture — tools as the unit of action, skills orchestrating tools, a planner scoped to a declared toolset, fail-closed scoping, config-gated surfaces — because those choices are correct and expensive to rediscover. Mitigate maturity risk concretely: pin a version and vendor the code, read src/ before relying on any API (the skill doc itself instructs this), keep CI free of live LLM calls by mocking AIEngineService, and run ai:doctor in your deploy checks. Prioritize the boring, high-value paths first — data_query/aggregate_data, AiResource CRUD tools, ResolvesAgentRelations, embeddings via VectorSearchService — and defer the exotic surfaces (video, realtime voice, Neo4j graph RAG, federation, model council) until a product decision demands them. Note two documented sharp edges worth designing around early: domain sub-agents run skill-free by design, and a domain agent returning zero rows is usually missing 'public' => true or an incorrect scope, not a planner failure. Budget roughly half an engineer for a quarter to own the fork, harden tests, and establish an upgrade path.