---
title: "Move Over Python: PHP Is the Sleeping Giant of AI Agents"
date: 2026-04-29T14:24:00-05:00
author: Dario Zadro
canonical_url: "https://zadroweb.com/blog/php-ai-agents/"
section: Articles
---
I've been coding in PHP for over 20 years. I've watched it get declared dead at least a dozen times. And every time, it just keeps running more of the internet.

So when AI started entering project needs, I didn't reach for Python. I didn't buy a seat in some workflow builder or a course. I simply opened my existing codebase, wrote a service, and made an API call.

That's it. That was the whole unlock. You don't need fancy GUIs or complex systems.

## The Assumption Nobody Is Questioning

Python owns AI. Everybody knows this. If you're training models, building research pipelines, or doing anything in data science, Python is the right tool. That's not up for debate.

But here's the thing most teams aren't asking: are you actually training a model? Or are you calling an API?

Because those are wildly different problems. And most businesses building "AI features" today are doing the latter. They're sending a prompt to Claude, GPT, or Gemini and doing something useful with the response. That's a REST call.

REST calls are language-agnostic. And PHP has been making REST calls since before most AI startups existed.

> The best tool for the job is usually the one already running in production.

Dario Zadro Zadro Web## You Already Have the Stack

According to [W3Techs](https://w3techs.com/technologies/details/pl-php), PHP powers over 71% of all websites with a known server-side programming language. WordPress alone accounts for [42% of the entire web](https://w3techs.com/technologies/details/cm-wordpress). Add Laravel, Symfony, Magento, Craft CMS, and a few thousand custom codebases, and you get a picture of where production web software actually lives. Side note, I actually remember when PHP came out, as I was drowning in Perl at the time, and I have stuck with PHP since then!

For CMS websites, I started with WordPress years ago, but have since moved on. Still, plugins like [AI Engine](https://wordpress.org/plugins/ai-engine/) (80,000+ active installs, full MCP server support, Claude and GPT integration baked in) and the official [WordPress MCP Adapter](https://automattic.com/2026/04/21/wordpress-operating-system-agentic-web/) from Automattic's AI Building Blocks initiative are turning WordPress into a legitimate agentic platform. Hard to ignore.

And production web software is exactly where AI agents need to operate.

Here's something the AI industry won't tell you: most "agents" are just good old services. Seriously. Strip away the marketing, and a typical AI agent is a class that accepts input, calls an external API, applies some logic, and returns output. We've been writing those since the early 2000s.

The agentic wrapper adds planning, memory, and tool-calling on top. That's real, and it matters. But the underlying pattern is not foreign to anyone who has spent time in an MVC framework.

Think about what an agent actually does at the application layer. It reads from a database. It calls an external API. It processes a form submission. It fires a webhook. It queues a job. It writes back to storage and returns a response.

PHP has done all of that for 30 years. Your auth system is already there. Your database connections are already there. Your business logic is already there.

So why would you spin up a Python microservice to sit next to your PHP application, duplicate your data context across a process boundary, and introduce an entirely new runtime to maintain, just to make an HTTP request to an LLM?

Actually, scratch that. I know why. Because the tutorials all show Python. Because LangChain is Python. Because the AI discourse lives on platforms dominated by ML engineers who don't spend much time with day-to-day content management systems.

## The Overkill Problem

I've seen teams reach for AWS Bedrock to summarize a support ticket. I've seen n8n workflows with 14 nodes to do what is functionally a single API call with some conditional logic. Make.com is a fantastic tool for connecting SaaS apps without code, but it is not the right answer for embedding an AI feature in a production PHP application you already control.

These platforms exist for good reasons. But they're solutions to a different problem. They make sense when you're gluing together third-party services without a backend team, or when you're on a Node/React stack and JS is your primary language (not really my world, but it works fine there). They don't make sense when you're a PHP developer who can write this:

```php
$client = new \GuzzleHttp\Client();

$response = $client->post('https://api.anthropic.com/v1/messages', [
    'headers' => [
        'x-api-key'         => $_ENV['ANTHROPIC_API_KEY'],
        'anthropic-version' => '2023-06-01', // required header -- tells the API which response schema to use
        'content-type'      => 'application/json',
    ],
    'json' => [
        'model'      => 'claude-haiku-4-5-20251001',
        'max_tokens' => 1024,
        'messages'   => [
            ['role' => 'user', 'content' => 'Your prompt here!']
        ],
    ],
]);

$data = json_decode($response->getBody(), true);
$reply = $data['content'][0]['text'];
```

Of course, that's an API call, not an agent. But it's also a working Claude integration. No platform. No monthly seat. No new infrastructure. Composer, Guzzle, an API key, and you're live.

Production use would add error handling, rate limit awareness, and retry logic on top, but that's true in any language, and none of it requires a new stack.

Complexity should be earned. Most web-based agent use cases don't earn it.

So what's the difference between that and an actual agent? An API call waits for a response and returns it. An agent decides what to do next, calls tools, checks its own output, and loops until the task is done. The Guzzle snippet above is a solid foundation.

## What's Actually Changed

Here's the thing: PHP's readiness for this isn't just about REST calls. The language itself has evolved significantly.

PHP 8.x introduced fibers, typed properties, named arguments, match expressions, and enums. Fibers enable cooperative scheduling within a single process, which is useful but not a substitute for true concurrency. For parallel agent tasks, queue workers via Supervisor or a Redis-backed library are the practical answer, and that pattern is well-established in PHP.

Most of all, none of this requires changing your stack. A [standard LEMP setup](https://zadroweb.com/blog/debian-lemp-nginx-wordpress-digital-ocean/) handles LLM API calls, queued agent jobs, and webhook-driven workflows without breaking a sweat. That's the same stack running most of the production PHP web today, and it's more than sufficient for the majority of agentic use cases.

If you want to push further, [FrankenPHP](https://frankenphp.dev/) and RoadRunner both offer long-lived worker modes that eliminate per-request bootstrap overhead, which matters for persistent agent loops. But that's an optimization, not a prerequisite. Build the agent first. Optimize the runtime later if the workload demands (it rarely does).

And then there's MCP. Anthropic's Model Context Protocol, now [donated to the Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) under the Agentic AI Foundation, has an official PHP SDK maintained by the PHP Foundation. It works over SSE or HTTP, exposing your PHP application's tools to any MCP-aware AI client. That means PHP applications can expose tools to AI systems natively, not through a Python wrapper or a middleware layer.

## The PHP Agent Ecosystem

So what does the actual PHP AI tooling look like right now?

[**Neuron AI**](https://neuron-ai.dev/) is the most mature dedicated agent framework in the PHP space. Built by the team behind Inspector.dev, it provides an Agent base class, tool calling, RAG support, multi-agent orchestration, and built-in monitoring. It works across Laravel, Symfony, WordPress, and lean PHP frameworks without forcing framework lock-in.

Here's the pattern: an agent class with a tool attached. The tool is what separates this from a plain API call: the agent decides when to call it, not your code:

```php
namespace App\Neuron;

use NeuronAI\Agent\Agent;
use NeuronAI\Agent\SystemPrompt;
use NeuronAI\Chat\Messages\UserMessage;
use NeuronAI\Providers\AIProviderInterface;
use NeuronAI\Providers\Anthropic\Anthropic;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;

class FitnessAgent extends Agent
{
    protected function provider(): AIProviderInterface
    {
        return new Anthropic(
            key:   $_ENV['ANTHROPIC_API_KEY'],
            model: 'claude-haiku-4-5-20251001',
        );
    }

    protected function instructions(): string
    {
        return (string) new SystemPrompt(
            background: ['You are a knowledgeable fitness assistant.'],
            steps:      ['Use available tools to look up workout plans before answering questions about them.'],
            output:     ['Give clear, practical guidance based on the workout data returned.']
        );
    }

    protected function tools(): array
    {
        return [
            Tool::make('get_workout', 'Look up a workout plan by name or muscle group.')
                ->addProperty(
                    new ToolProperty(
                        name:        'workout_name',
                        type:        PropertyType::STRING,
                        description: 'The name or muscle group of the workout to retrieve.',
                        required:    true
                    )
                )
                ->setCallable(function (string $workout_name) {
                    // Your existing workout DB or API call here
                    $pdo  = new \PDO($_ENV['DB_DSN'], $_ENV['DB_USER'], $_ENV['DB_PASS']);
                    $stmt = $pdo->prepare("SELECT exercises, sets, reps FROM workouts WHERE name = ?");
                    $stmt->execute([$workout_name]);
                    $row  = $stmt->fetch(\PDO::FETCH_ASSOC);
                    return $row ? json_encode($row) : 'Workout not found.';
                }),
        ];
    }
}

$reply = FitnessAgent::make()
    ->chat(new UserMessage('How many sets should I do for a beginner chest workout?'))
    ->getMessage()
    ->getContent();

echo $reply;
```

The agent receives the question, decides it needs the `get_workout` tool, calls it with the extracted muscle group or plan name, and folds the result into its response. All without you wiring that logic manually. *That's the shift from API wrapper to agent*.

Beyond Neuron, the ecosystem is moving fast. [**LLPhant**](https://github.com/LLPhant/LLPhant) offers a LangChain-inspired approach. [**Prism**](https://prismphp.com/) is gaining traction as a clean provider-agnostic interface for Laravel projects. [**Symfony AI**](https://ai.symfony.com/) brings first-party integration into the Symfony ecosystem.

Worth noting: none of this requires a heavy framework. Lean PHP frameworks like Slim, Flight, F3, Phalcon, and CodeIgniter wire up agent services cleanly with minimal overhead. If your stack is already lean, adding an agent layer doesn't change that.

## RAG in PHP: Shorter Than You'd Think

Retrieval-augmented generation sounds intimidating. It's not. At its core, it is four steps: chunk your content, generate embeddings, retrieve the most relevant chunks, and inject them into your prompt.

Vector databases like Qdrant, Pinecone, and Weaviate all expose HTTP APIs. PHP calls HTTP APIs. So this works fine:

```php
$openAiClient = OpenAI::client($_ENV['OPENAI_API_KEY']);
$guzzle = new \GuzzleHttp\Client();

$userQuery = $_POST['question'] ?? '';

// 1. Generate embedding via OpenAI
$embedding = $openAiClient->embeddings()->create([
    'model' => 'text-embedding-3-small',
    'input' => $userQuery,
])->embeddings[0]->embedding;

// 2. Query Qdrant for nearest neighbors
$results = $guzzle->post('http://qdrant:6333/collections/docs/points/search', [
    'json' => [
        'vector'       => $embedding,
        'limit'        => 5,
        'with_payload' => true,
    ],
]);

// 3. Inject retrieved context into your prompt
$hits    = json_decode($results->getBody(), true)['result'];
$chunks  = array_map(fn($hit) => $hit['payload']['text'], $hits);
$context = implode("\n\n", $chunks);

$prompt = "Answer using this context:\n\n{$context}\n\nQuestion: {$userQuery}";
```

No Python. No orchestration layer. Just HTTP and a bit of plumbing.

## Python's Kingdom, PHP's Territory

I want to be clear about something. This article isn't arguing PHP should replace Python in AI. That's not the point.

Python wins outright in model training, ML research, data science pipelines, computer vision, and anything involving notebooks and numerical computation. Uncontested. Go use Python for that.

But PHP's territory is the production web layer. And the production web layer is where most AI agents will actually spend their time: inside CRMs, dashboards, ecommerce platforms, CMS systems, admin panels, and business workflow tools.

That layer is already PHP. The agents should be too.

## So, the No-Brainer Case

I've built production systems in PHP for clients across healthcare, legal, manufacturing, and ecommerce. The recurring challenge with adding AI features isn't capability. It's context. Your agent needs access to your authenticated user session, your database schema, your business rules, and your caching layer.

Transferring all of that to an external Python service isn't just overhead. It's a technical debt liability.

PHP keeps the agent inside the application where it belongs. The context is already there. The auth is already there. The deployment pipeline you've maintained for years is already there.

And frankly? So is most of the internet.

You don't need Bedrock. You don't need n8n. You don't need a new language on your team's resume. You need an API key, a service class, and the PHP codebase you've probably already been running in production.

The giant was never asleep. Everyone else just has their eyes closed.

 *Share* [  ](https://www.facebook.com/sharer.php?u=https://zadroweb.com/blog/php-ai-agents/ "Share Article: Move Over Python: PHP Is the Sleeping Giant of AI Agents") [  ](https://www.linkedin.com/sharing/share-offsite/?url=https://zadroweb.com/blog/php-ai-agents/ "Post Article: Move Over Python: PHP Is the Sleeping Giant of AI Agents") [  ](https://twitter.com/intent/tweet?url=https://zadroweb.com/blog/php-ai-agents/&text=Move%20Over%20Python%3A%20PHP%20Is%20the%20Sleeping%20Giant%20of%20AI%20Agents "Tweet Article: Move Over Python: PHP Is the Sleeping Giant of AI Agents") [  ](mailto:%20?subject=Check%20Out%20This%20Article&body=%0D%0AMove%20Over%20Python%3A%20PHP%20Is%20the%20Sleeping%20Giant%20of%20AI%20Agents%0D%0Ahttps://zadroweb.com/blog/php-ai-agents/ "Email Article: Move Over Python: PHP Is the Sleeping Giant of AI Agents") 

 

 ![Dario Zadro, Author at Zadro Web](https://www.gravatar.com/avatar/7fd3c6f03536f4ad85610768a8da304d?s=130&d=mm) 

### Dario Zadro

Dario Zadro is a full-stack developer and technical SEO with 20+ years of experience. Founder of Zadro Web, a web development and SEO agency operating since 2007, specializing in custom web development, SEO/GEO, and cloud infrastructure. He builds lean, maintainable systems, helping clients reduce technical debt.

 [  ](https://zadroweb.com "Vist My Website") [  ](https://twitter.com/dariozadro "Follow Me On Twitter") 

 

 

 

 

   ## Browse More in Web Development

Explore the latest insights in full-stack web development. From front-end to back-end programming, and often with SEO mixed in, find articles to help with trending and innovative best practices.

 

 

 ![Database indexes slow website](https://static.zadroweb.com/site/_card/database-indexes-slow-website.jpg) 

 [Web Development](https://zadroweb.com/blog/web-development/ "Web Development") 

##  [Your Website Is Slow and Nobody Is Checking the Right Thing](https://zadroweb.com/blog/database-indexes-slow-website/ "Your Website Is Slow and Nobody Is Checking the Right Thing") 

I review (and build) a lot of apps. Custom builds, WordPress sites, Laravel projects, CakePHP, CodeIgniter, and the list goes…

 

 

 ![Craft cms datatables integration](https://static.zadroweb.com/site/_card/craft-cms-datatables-integration.png) 

 [Web Development](https://zadroweb.com/blog/web-development/ "Web Development") 

##  [Building a DataTables Solution Using Craft CMS](https://zadroweb.com/blog/building-a-datatables-solution-using-craft-cms/ "Building a DataTables Solution Using Craft CMS") 

Whether you're new to Craft CMS or have been using this incredible framework for some time, extending it can sometimes be…

 

 

 ![Building craft cms plugin](https://static.zadroweb.com/site/_card/building-craft-cms-plugin.png) 

 [Web Development](https://zadroweb.com/blog/web-development/ "Web Development") 

##  [Building a Craft CMS Plugin - A Simple Tutorial](https://zadroweb.com/blog/building-a-craft-cms-plugin/ "Building a Craft CMS Plugin - A Simple Tutorial") 

Building a Craft CMS plugin for the very first time can be a daunting task. This is especially true if you're new to modern…

 

 

 ![Cms alternatives](https://static.zadroweb.com/site/_card/cms-alternatives.png) 

 [Web Development](https://zadroweb.com/blog/web-development/ "Web Development") 

##  [Is WordPress Still the #1 CMS? Other Alternatives to Highly Consider](https://zadroweb.com/blog/wordpress-alternatives/ "Is WordPress Still the #1 CMS? Other Alternatives to Highly Consider") 

As a web developer, I'm constantly exploring content management systems (CMS) to find the best options for our clients and…