Move Over Python: PHP Is the Sleeping Giant of AI Agents

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. I simply opened my existing codebase, wrote a service, and made an API call.

That's it. That was the whole unlock.

The Assumption Nobody Is Questioning

Python owns AI. Everybody knows this. If you're training models or building research pipelines, Python is the right tool. 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. 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.

You Already Have the Stack

PHP powers over 71% of all websites with a known server-side language. Your CRM, your CMS, your admin panel -- already PHP. And AI agents at the production layer aren't exotic research software. They're authenticated API calls, database reads, webhook handlers, queue workers.

Here's something the AI industry won't tell you: most "agents" are just good old services. 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. Real, and it matters. But the underlying pattern is not foreign to anyone who has spent time in an MVC framework.

So why 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?

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. 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 PHP application you already control.

A working Claude integration in 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',
        'content-type'      => 'application/json',
    ],
    'json' => [
        'model'      => 'claude-haiku-4-5-20251001',
        'max_tokens' => 1024,
        'messages'   => [
            ['role' => 'user', 'content' => $userPrompt]
        ],
    ],
]);

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

No platform. No monthly seat. No new infrastructure. Composer, Guzzle, an API key, and you're live.

What an Actual Agent Looks Like

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. Here's that shift in PHP using Neuron AI:

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) {
                    $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.

PHP's Territory

Python wins at model training, ML research, data science pipelines, and computer vision. Uncontested. Go use Python for that.

PHP's territory is the production web layer. CRMs, dashboards, ecommerce platforms, CMS systems, admin panels, business workflow tools. That layer is already PHP. The agents should be too.

Your agent needs access to your authenticated user session, your database schema, your business rules, your caching layer. Transferring all of that to an external Python service isn't just overhead. It's a technical debt liability.

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.

For the full breakdown including RAG in PHP, MCP, FrankenPHP, and the complete ecosystem rundown, read the full article at zadroweb.com.