m-tech-stack/laravel-ai-engine
Laravel AI Engine provides a clean, configurable layer for adding AI features to Laravel apps, with a unified API for providers, prompt and chat workflows, embeddings, and tool calling—keeping AI logic testable and maintainable.
Architecture fit
The package is a conventional Laravel package (service provider + publishable config/ai-engine.php and config/ai-agent.php) that layers an agent runtime over a multi-provider LLM abstraction. That is a good structural fit for any Laravel monolith or modular app that wants an in-process agent layer rather than a sidecar service. The opinionated decomposition is the strongest part of the design:
AgentTool / SimpleAgentTool) are the unit of action, registered declaratively in config and bound through the container.AgentSkill, AgentSkillRegistry, AgentSkillMatcher) orchestrate multi-step flows and declare required tools/final tools — the matcher is a stopword-stripped keyword match, which is simple and debuggable but not semantic.AiNativeRuntime is an explicit planner loop scoped to a ToolRegistry, and domain sub-agents get an EmptySkillRegistry deliberately so global skills cannot hijack them. That is a thoughtful guardrail, and it signals the author has been burned by planner loops.AiResource::for(Model::class) generates find/create/show tools without hand-written CRUD — high leverage, but also the highest-risk surface because it writes to your domain models.AIScopeResolver, scope_columns, 'public' => true opt-in) is the correct default for multi-tenant data, and is applied consistently across data_query, RAG, vector search, and memory.The architecture asks you to accept a framework inside your framework: its own planner, its own tool registry, its own memory/transcript store, its own credit system, its own observability events. That is a real adoption cost — you are standardizing on this package's vocabulary, not on Laravel's.
Integration feasibility
Feasible for a single team with Laravel depth; not a drop-in. Concretely:
php artisan ai:doctor to validate key health per engine. The CLI (~80 ai: commands) is unusually complete for a package at this adoption level and is the main reason I would not dismiss it outright.src/ before using the API, do not invent methods — is the single most important signal in the supplied material. A package that instructs its own consumers to verify source before use is telling you the API surface is large and drifting relative to its guides. Budget for reading src/.laravel-ai-engine-federation as a sibling package. Assume only the Laravel/DB/queue core path is safe on day one.Technical risk
ai-engine.error_handling.fallback_engines) mitigates outages but silently changes output quality and cost.AIEngineService in CI, keep live calls manual) is correct but means your CI validates plumbing, not agent quality. You own the eval harness.0 for data that exists is usually misconfigured scope, not a planner bug. That is a debugging trap for every new engineer.metadata.converged_via = 'tool_result_fallback') when the planner exhausts steps. Acceptable as a backstop; dangerous if surfaced to users without a confidence marker.Key questions
ai-agent.php tool registration and AiResource write generation safe by default (confirmation, validation, authorization), or is requiresConfirmation() opt-in per tool?analyze_file or RAG indexing?CreditManager authoritative for billing, or advisory? What happens to an in-flight multi-step skill when InsufficientCreditsException fires?Stack fit
Good fit for a Laravel app already using the container, config, queues, events, and Eloquent. It assumes queue workers (vector indexing, video polling), a cache/DB store for memory and transcripts, and optionally Redis/Mongo/Neo4j. It does not fit well if you are on a non-Laravel PHP stack, a serverless/stateless deployment without workers, or a compliance posture that forbids multi-provider egress.
Migration path
Adopt read-only first and earn write access:
ai:doctor, a single read-only tool. Publish both configs, diff them against defaults, and pin the config as internal documentation.data_query + aggregate_data on one or two models with explicit scope_columns; AiResource::for(...)->detailOnly() for relation-aware reads; search_knowledge over a small vector index.AiResource writable tools or hand-written tools with requiresConfirmation() and validate() on every mutation. Nothing writes without a confirmation step and an authorization check that is independent of the model.$triggers (the docs explicitly warn against read-ambiguous keywords). Use 'handler' => 'ai_native' for domain agents and accept that they do not inherit global skills.Compatibility
Verify Laravel/PHP constraints in composer.json before anything else, and check that optional drivers degrade rather than throw when unconfigured (the docs claim keyless engines are skipped automatically — confirm that for vector, graph, and memory drivers too). Watch for config namespace collisions: ai-engine and ai-agent are generic keys likely to clash with in-house config. Treat published config as your file and keep a diff against upstream on every bump.
Sequencing
Gate each phase on a small eval set (20–50 real prompts with expected tool calls and expected answers) run manually against live models. Do not advance phases on "it demoed well." The package gives you TraceRecorderService and ai:agent-runs:* — use those to build the eval corpus from real traces rather than writing scenarios from imagination.
Maintenance
Assume you own this code. At 1 star and 0 dependents there is no upstream support channel, no security advisory feed you can rely on, and no community to absorb upgrade pain. Practical posture: pin an exact version, mirror the repository internally, and be prepared to fork. The breadth that makes the package attractive (~80 artisan commands, large config tree, many drivers) is exactly the breadth that makes upgrades expensive — every bump is a config diff plus a driver smoke test.
Support
No SLA; MIT gives you the code and nothing else. You need an internal runbook: ai:doctor for key health, AgentManifestDoctor for agent config, ai:vector-* and ai:neo4j-* for index state, ai:agent-runs:* for planner post-mortems. Wire AIRequestStarted / AIRequestCompleted / AIFailoverTriggered into existing APM on day one — failover in particular must alert, because it is a silent quality and cost change.
Scaling
Three independent scaling axes, and they fail differently:
ai-agent.ai_native.tool_selection matters as tool count grows — start at skill_scoped (the docs' own recommendation), add keyword, and reach for semantic last because it adds an embedding dependency to the hot path. limit and always (never-trimmed core) are your cost levers; find_tools progressive disclosure is the escape valve for large registries.AIScopeResolver cheap and cached, and audit 'public' => true as a privileged annotation.Failure modes to design for
tool_result_fallback surfaces the last successful tool result, which may be stale or partial.InsufficientCreditsException interrupts a multi-turn flow with no documented resume path.src/. Enforce a review rule: any tool/skill PR cites the source class path.Ramp-up
Steep: 3–4 weeks to productivity for a solid Laravel engineer, longer for the agent-design concepts (tools vs. skills vs. sub-agents, planner scoping, RAG retrieval quality, eval design). Mitigate by assigning one owner, starting from the supplied skill map plus docs/cookbook.mdx (source-grounded, unlike the skill summary), and using ai:make-tool / ai:make-skill / ai:make-agent scaffolding so nobody hand-writes registration. The two-person-week spike in the sequencing section is the real go/no-go: if a read-only tool plus one RAG query cannot be made reliable in that window, the capability breadth is not worth the ownership burden.
How can I help you explore Laravel packages today?