Ai Laravel Package

Technical Evaluation

Architecture fit. symfony/ai is a component suite, not a monolith: platform/provider adapters, an agent abstraction, message/tool primitives, and store integrations. That decomposition is the main reason it is viable outside Symfony. The parts Laravel would consume are largely plain PHP built on PSR-18/PSR-17 HTTP, PSR-7 messages, and Symfony contracts — all of which Laravel already ships transitively. The Symfony Bundle (symfony/ai-bundle) is the piece to deliberately skip: it assumes the Symfony DI container, configuration tree, and autoconfiguration tags, none of which map to Laravel's container semantics. Treat the package as an SDK, not a framework extension.

The conceptual model (Platform → Agent → Tools → Store → Result) maps reasonably onto Laravel idioms: a Platform factory and Agent factory as container singletons, tools as invokable classes, stores backed by Eloquent or pgvector. The gap is that no one has published that mapping, so it becomes internal, owned code.

Integration feasibility. Composer installation is low-friction in principle because Laravel already depends on a broad slice of symfony/*. The realistic friction points:

• Version collisions on symfony/http-client, symfony/event-dispatcher, and symfony/serializer — Laravel pins ranges that may not intersect with a fast-moving 0.x AI package.
• Config duality: Symfony bundle YAML vs. config/ai.php. You must construct providers/agents manually in a service provider and keep configuration out of the bundle entirely.
• Testing ergonomics: Symfony's test doubles and profiler integration are bundle-oriented; Laravel needs its own fakes (AIFake-style driver swap) to keep the test suite deterministic and offline.
• Streaming: the abstraction likely assumes long-lived request handling. Under PHP-FPM this needs SSE with output buffering disabled; under Octane it needs care around stateful agents and static provider clients.

None of these are blockers, but together they represent roughly a one-to-two-week adapter build before the first production use case, plus ongoing drift management.

Technical risk. Moderate, and concentrated in volatility rather than quality:

Key questions for the team. What is the BC policy between minors, and is there a 1.0 timeline? Does the HTTP layer accept a PSR-18 client we can swap for Laravel's Http facade (for logging, retries, and fakes)? Which store backends are first-class vs. community — and is pgvector supported? Are there lifecycle hooks for token accounting, tracing, and per-call timeouts? What is the documented path for non-Symfony frameworks, or is that explicitly out of scope? How does tool-calling loop termination work — is there a max-iteration guard?

Integration Approach

Stack fit. Compatible in principle with Laravel 11/12 on PHP 8.2+, precisely because Laravel's dependency graph already overlaps with Symfony components. The correct posture is "consume components, reject the bundle." Do not attempt to boot the Symfony bundle inside Laravel; the resulting container gymnastics will be brittle and hard to explain to the next maintainer.

Migration path. There is no migration — this is greenfield glue, so frame it as an incremental capability rollout rather than a replacement. Build a thin internal package (app/Ai or a first-party laravel-ai-bridge if reuse is expected) that provides:

1. config/ai.php with provider credentials, default models, timeouts, retry policy, and per-tenant token ceilings.
2. AiServiceProvider binding a Platform singleton and an AgentFactory, with a driver/environment switch pointing at a fake in testing.
3. A RunAgentJob base class so agent loops execute on the queue with explicit timeouts and retry semantics, not in the request cycle.
4. A middleware/decorator for logging prompts, completions, latency, and token counts into an existing observability channel — this is the single highest-value piece of glue and should be built before the second use case, not after.

Compatibility management. Pin exact versions ("symfony/ai-*": "0.x.y"), commit the lockfile, and gate upgrades behind a scheduled PR rather than a floating constraint. Run composer why-not before each bump to expose transitive conflicts with illuminate/*. Consider composer require --dev a compatibility smoke test that boots the container and instantiates a fake agent.

Sequencing. Deliver in this order, each stage independently shippable:

1. Spike (1 week): one provider, one non-customer-facing use case (classification or summarization) to validate install, container wiring, and error behavior.
2. Adapter + guardrails: provider registration, config, fakes, token/latency logging, budget caps.
3. Async execution: queue job, timeout, idempotency key, dead-letter handling for provider failures.
4. Structured output / embeddings: the first genuinely useful production features; store choice (pgvector on existing Postgres) decided here.
5. Tools and multi-step agents: feature-flagged, allow-listed tools only, human-in-the-loop for anything with side effects.
6. Multi-provider failover: only after a single-provider baseline has measured quality and cost; premature abstraction here hides quality regressions.

Operational Impact

Maintenance. Expect ongoing glue maintenance rather than passive dependency consumption. Budget roughly 0.2–0.5 FTE during the first two quarters, tapering to upgrade-and-monitor cadence. The primary cost driver is not Symfony releases but provider API drift — model deprecations and parameter changes will force adapter updates regardless of package stability.

Support. Documentation is Symfony-flavored and framework-neutral at best; there will be no Laravel-specific tutorials and few Stack Overflow answers at 1,226 stars. Institutional knowledge concentrates in whoever builds the adapter, which is a real bus-factor risk. Mitigate with an internal README covering the container wiring, the fake driver, and the upgrade runbook.

Scaling. Agents are stateless per invocation, so horizontal scaling is straightforward if execution is queued. The scaling constraints are external: provider rate limits, per-minute token quotas, and latency variance. Streaming responses are the exception — they require Octane/Swoole or careful SSE handling under FPM, and they pin a worker for the duration. Vector stores should reuse existing infrastructure (pgvector) rather than introducing a new datastore; otherwise a search feature quietly becomes a second platform to operate.

Failure modes to instrument explicitly:

• Provider timeout/outage → must degrade to a cached or non-AI path, not a 500.
• Infinite or runaway tool loops → hard max-iteration cap and cost ceiling per request.
• Malformed structured output → schema validation with a bounded retry, then a fallback.
• Prompt injection via retrieved content or tool results → treat all model-directed actions as untrusted input; authorize at the tool boundary.
• Cost overrun → per-tenant and per-key budget enforcement with alerting, not just dashboards.
• Silent quality regression on provider/model changes → a small golden-set eval run in CI before upgrades.
• Data residency/PII → prompt logging is a compliance surface; redact or disable by default in regulated contexts.

Ramp-up. A mid-level Laravel developer should reach productivity on a single-provider, single-call use case in one to two weeks, most of which is container wiring and testing strategy rather than AI concepts. Tool-calling and multi-step agents add three to four weeks and require review from someone who understands injection and authorization boundaries. The package itself is not hard to learn; the absent Laravel-native documentation is the real ramp-up tax, and the internal adapter is what converts that tax into a one-time cost.