PHP for AI? It Makes More Sense Than You Think

#php #webdev #ai #discuss

Say "AI" in a room full of developers and a pecking order forms on its own. Python sits at the top, JavaScript gets a seat because somebody has to render the chat window and PHP gets the sympathetic look, the one that says maybe you will catch the next wave.

Now hold that against one number. As of August 2026, W3Techs counts PHP behind 70.5% of all websites whose server-side language it can identify. JavaScript, the supposed runner-up in the AI race, sits at 7%. The language that's supposedly watching the boom from the sidelines is serving most of the web the boom is trying to reach.

For a while, both things were true at once. Not long ago calling an LLM from PHP meant a community API client or hand-rolled HTTP requests, while Python people got LangChain, LlamaIndex and a new agent framework every other Tuesday. The gap was real and pretending otherwise would've been denial.

I would say, it's not real anymore, it closed quietly and most people outside the Laravel world haven't noticed yet. Laravel's own blog now publishes posts titled "Building AI Agents with Laravel: No Python Required". When a framework's marketing is that direct the tooling underneath usually got there first.

An AI Feature Is Mostly Not AI

Strip the branding off any "AI-powered" feature and look at what the code does. Somewhere in the middle there's one HTTPS call to a model provider. Everything wrapped around it is software you already know how to build: auth, validation, rate limiting, queues, retries, billing, persistence and a UI that doesn't jump around while tokens arrive.

The model itself never runs in your app. It runs in a datacenter owned by Anthropic, OpenAI or Google and it has no idea what language dialed it up. From the provider's side a request sent by a Laravel queue worker is indistinguishable from one sent by a FastAPI service.

That's the reframe this whole argument rests on: you needed Python to make the model not to make the thing that uses it. Training a model and building a product around one are different jobs, done by different people with different tools. Conflating the two is exactly how PHP developers talked themselves out of their own territory, because the application layer is most of what an "AI app" actually is.

The Stack That Quietly Showed Up

Here's what a PHP developer has to work with in 2026. I want to be precise about each piece because they're not five flavors of the same thing.

Prism is the community's unified provider layer: one fluent API over OpenAI, Anthropic, Mistral and the rest, so swapping vendors is a config change instead of a rewrite.

The official Laravel AI SDK (laravel/ai) is the big one. First-party, from the same team that maintains Eloquent and the queue system, announced in February 2026 and currently in beta. Agents are plain PHP classes, structured output is an interface, embeddings hang off the Str class. It talks to 14 providers, fails over between them when one goes down and ships a full fake layer for tests.

Neuron AI covers the heavier agentic end. You extend an Agent class and get memory, tool calls, RAG components, and workflows with human-in-the-loop steps, plus observability through Inspector. It's framework-agnostic, runs on PHP 8.1+ and supports 15+ providers.

LLPhant is the retrieval specialist: LangChain-style abstractions, question answering with reranking and chat memory and a long list of vector store integrations. Also framework-agnostic which makes it the natural pick on Symfony.

Laravel Boost is the odd one out. It doesn't put AI in your app; it puts your app in front of AI. It's an MCP server that hands your coding agent (Claude Code, Cursor, whatever you run) inspection tools for your application plus Laravel-specific guidelines and docs, so generated code matches the framework version you actually have installed.

The word "official" in that list is doing real work. When AI support ships as a first-party package with migrations, Artisan generators, and a testing story, it stops being a hobby integration and becomes part of the framework's contract. The fact that Embeddings::fake() exists at all tells you how seriously the Laravel team took this: somebody designed the testing experience before shipping the happy path.

How Little Code This Takes Now

Talk is cheap, so here's code. Suppose product feedback lands in your database and you want a one-line summary next to each entry. With Prism, the whole feature is this:

use Prism\Prism\Enums\Provider;
use Prism\Prism\Facades\Prism;

$response = Prism::text()
    ->using(Provider::Anthropic, 'claude-haiku-4-5-20251001')
    ->withSystemPrompt('You write one-sentence summaries of customer feedback.')
    ->withPrompt($feedback->body)
    ->asText();

$feedback->update(['summary' => $response->text]);

Change the provider enum and the model string and you've switched vendors. That's the entire migration. $response->usage gives you token counts too because somebody will ask about the bill in month two.

The official SDK goes a step further with typed output. Imagine you're triaging support tickets:

app/Ai/Agents/TicketTriage.php

<?php

namespace App\Ai\Agents;

use Illuminate\Contracts\JsonSchema\JsonSchema;
use Laravel\Ai\Contracts\Agent;
use Laravel\Ai\Contracts\HasStructuredOutput;
use Laravel\Ai\Promptable;
use Stringable;

class TicketTriage implements Agent, HasStructuredOutput
{
    use Promptable;

    public function instructions(): Stringable|string
    {
        return 'You triage customer support tickets. '
            .'Summarize the issue and score its urgency.';
    }

    public function schema(JsonSchema $schema): array
    {
        return [
            'summary' => $schema->string()->required(),
            'urgency' => $schema->integer()->min(1)->max(5)->required(),
        ];
    }
}

Using it reads like any other Laravel class:

$response = (new TicketTriage)->prompt($ticket->body);

$ticket->update([
    'summary' => $response['summary'],
    'urgency' => $response['urgency'],
]);

No "please respond with valid JSON" begging in the prompt. No try/catch around json_decode. The schema constrains the output and the response is array-accessible in the shape you declared. If you've ever babysat a script that parsed LLM output with a regex, this is the part where you get quietly jealous.

Embeddings are a one-liner on a class you already use every day:

use Illuminate\Support\Str;

$embeddings = Str::of($ticket->body)->toEmbeddings();

And RAG doesn't require a new service in your docker-compose. The SDK's SimilaritySearch tool plugs into Eloquent models backed by pgvector, with the vector math handled by the query builder. Streaming to the browser is (new TicketTriage)->stream($question) returned straight from a route as server-sent events, and long-running work goes on the queue like any other Laravel job.

Add up what those snippets cover: provider abstraction, typed output, semantic search, streaming, background processing. That used to be the pitch for a standalone Python microservice. Now it's an afternoon of work in a codebase your team already knows how to deploy, monitor, and roll back. And if you think of agents the way I've argued before, as software workflows with tools, a framework built around workflows is a natural place to run them.

Where PHP Belongs, And Where It Never Will

Here's the part that keeps this from being cheerleading.

PHP belongs at the application layer: the part that calls the model, owns the business workflow, holds the auth, the data, the domain rules, the billing, and the user-facing product. That layer decides whether your AI feature is a demo or a business, and it's exactly the layer Laravel has spent a decade making boring in the best sense, with queues, policies, validation, and deploys you don't lose sleep over.

PHP does not belong in model training, fine-tuning, or data science, and it shouldn't try to get there. There's no PyTorch for PHP, and there shouldn't be. The numerical stack underneath modern ML (NumPy, CUDA kernels, the whole tower of scientific computing) took Python decades to accumulate, and it's welded to the research community that publishes with it. If your product needs a custom fine-tune or serious data work, that piece is Python, full stop.

But notice what the split actually means. The model is a component; the product is the application around it, and the application is where your users, your data, and your revenue live. You didn't write Postgres either, and nobody says PHP developers are locked out of databases.

Where's the boundary in practice? A hypothetical: your team ships a document assistant for a legal SaaS. The retrieval pipeline, the permissions deciding who can query which documents, the audit log, the rate limits, the prompt assembly, the UI: Laravel, all of it. The embedding model that turned clauses into vectors: trained in Python, by people you'll never meet, consumed over an API the way you consume Stripe. That division of labor is already how you build everything else.

The Rough Edges, Honestly

The flip side of a fast catch-up is that much of this tooling is young. Four things I'd want to know before betting a roadmap on it:

The official SDK is in beta. Laravel says so themselves. APIs can still move under you, and upgrading a beta dependency in production is a decision, not a formality.
Streaming works, but it isn't frictionless. The primitives are there: server-sent events straight from a route, and the Vercel AI data protocol for Livewire and Inertia setups. But PHP's request-per-process model makes long-lived connections feel less native than they do in Node, and there are young-ecosystem surprises, like Prism's documented warning that Telescope can consume stream events before Prism emits them. That's the kind of gotcha that costs you an evening and doesn't have a Stack Overflow answer yet.
You'll be reading docs and source, not tutorials. Search any agent pattern and the top twenty results assume Python. The Laravel material is good but thin: a docs page, a handful of blog posts, conference talks still catching up. Being early means being your own example.
Overlap means choosing. Prism and the official SDK solve overlapping problems, and Neuron and LLPhant overlap again from the framework-agnostic side. My take: on a Laravel app starting today, use the official SDK and accept the beta risk; stay on Prism if you're already running it or its provider coverage fits you better; look at Neuron or LLPhant when you're outside Laravel entirely. Whichever you pick, wrap it behind your own service class so a swap stays cheap.

None of that is disqualifying. It's the normal texture of an ecosystem that's a year or two old instead of five. The Python stack went through the same era; everyone's just forgotten how often LangChain broke its own APIs in the 0.x days.

So flip the old question. "An LLM in PHP, why?" was always the wrong frame. The right one is: which part of an AI product does your language need to be good at? For everything except the model itself, the answer is the part PHP was already good at, the auth, the data, the workflow, the product you put in front of users.

The how is one composer require laravel/ai away. The model never cared what language called it, and as of this year, the tooling doesn't either.

P.S. Thanks for taking the time to read this article! The ideas and opinions expressed here are my own. English is not my first language, so I use AI to help correct grammar and make my writing clearer and easier to read. If anything still sounds a little awkward, I appreciate your understanding!

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋