Why I Built an AI Agent in Native PHP in 2026 (And Not Python/Node)

php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');

while (ob_get_level() > 0) ob_end_clean();
@ob_implicit_flush(true);

echo "event: delta\n";
echo "data: " . json_encode(['text' => $chunk]) . "\n\n";
@ob_flush();
flush();
That's the entire streaming contract. No framework, no library, no adapter. The main gotcha is output buffering — you have to disable it aggressively or the browser will buffer your entire stream before rendering. Once you know that, SSE in PHP is 20 lines of boilerplate.

5. The Framework Tax Is Real
I built this in native PHP, not Laravel. Here's why: frameworks are great when you need to solve 50 problems at once. When you need to solve 5 specific problems well, frameworks add more abstraction than value.

Every agent turn passes through the same 4-5 functions. My tool execution layer is ~200 lines. My memory system is ~150 lines. My SSE handler is ~80 lines. If I had used Laravel, half my debugging time would be understanding the framework, not my own code.

This is not a critique of Laravel. It's an observation that for a small, well-understood domain, a framework is sometimes the wrong abstraction.

The Trade-Offs (Because Nothing Is Free)
Let me not pretend this was all rosy. PHP has real limitations for this use case:

Concurrency. PHP-FPM spawns processes. If you need 100 concurrent long-running requests, you need 100 processes. For a chat product this is fine because most requests are short-lived streams, but if you were building a real-time collaboration tool, this would hurt.

Long-running background jobs. PHP doesn't have a natural "worker daemon" story without extra infrastructure (Supervisor, PM2, etc.). For ZixcAI, background work is minimal — title generation and memory extraction run inline after each turn. If I needed serious async processing, I'd probably add a small worker process in Node or Python.

Python ecosystem. There are Python libraries for AI that have no PHP equivalent. The OpenAI SDK for Python is richer than any PHP option. But the OpenAI API is just HTTP + JSON — you don't need an SDK. A curl_init() and a json_decode() cover 99% of what the SDK does.

Hiring. If I ever need to hire, "PHP developer with AI experience" is a smaller pool than "Python developer with AI experience." But for a solo project, this is a hypothetical.

What I Learned Building This
1. Streaming Is a Debugging Nightmare Until You Understand Buffering
The first version of my SSE stream didn't work. The browser received nothing until the entire response completed, then dumped everything at once. Three days later I found out that output_buffering in php.ini was silently holding every chunk.

Lesson: In PHP, for streaming, ob_end_clean() + ob_implicit_flush(true) + flush() after every chunk is non-negotiable.

2. Upstream Timeouts Kill Chat Products
LLM APIs are slow. A single turn can take 30+ seconds if the model is reasoning heavily. If your HTTP timeout to upstream is 15 seconds, you'll get random "chat failed" errors that only happen sometimes.

Lesson: Set CURLOPT_TIMEOUT to 0 (infinite) for streaming, and set a hard wall-clock limit at the product level (e.g., "if no token received for 45 seconds, abort the turn"). Distinguish between transport timeout and product timeout.

3. Tools Are Just Functions With a Contract
I spent a week designing an elaborate tool-call protocol before realizing: the LLM only sees a JSON schema and returns a JSON call. Your job is to route the call, sanitize arguments, execute safely, and return a text result.

php
if ($tool === 'shell.exec') {
    $cmd = (string)($args['command'] ?? '');
    if (!self::isSafeShellCommand($cmd)) {
        return ['exit_code' => 400, 'stdout' => '', 'stderr' => 'blocked'];
    }
    // ... execute via bridge
}
That's the whole tool layer. Everything else is bookkeeping.

4. Memory Is Harder Than Tools
Reading files and running code is easy — the LLM tells you what to do, you do it. But knowing what to remember across sessions is a genuinely hard problem. My current system extracts 0-3 memory items per turn via a secondary LLM call, deduplicates with similarity matching, and injects the top-30 into the system prompt.

It works. It's not perfect. But it taught me that "memory" in agentic systems is 20% storage and 80% extraction policy.

5. Circuit Breakers Save You From Cascading Failures
If your sandbox bridge goes down, every tool call will hang for 30 seconds and then fail. That's a bad user experience and it exhausts your process pool.

Adding a simple circuit breaker (5 consecutive failures → short-circuit for 30 seconds) made the product dramatically more resilient:

php
if (self::$bridgeFailures >= self::BRIDGE_FAILURE_THRESHOLD) {
    if (time() - self::$lastBridgeFailure < self::BRIDGE_CIRCUIT_RESET_SECONDS) {
        return ['ok' => false, 'status' => 503, 'body' => [
            'violation_code' => 'bridge_circuit_open',
        ]];
    }
}
This is 6 lines of code and it's the difference between "the product degrades gracefully" and "the product crashes when one dependency hiccups".

So, Should You Use PHP for Your AI Agent?
If you're building a research project, a training pipeline, or heavy ML work — no. Use Python. The ecosystem is unmatched.

If you're building an agentic product where the LLM does the reasoning and your job is orchestration, streaming, and persistence — PHP is a perfectly defensible choice. It's fast to ship, cheap to deploy, and boring in the best way.

The "AI must be Python" rule is a community convention, not a technical constraint. The technical constraint is: can your language make HTTP requests, handle JSON, and stream output? If yes, you can build an AI agent in it.

The real question isn't "is PHP good for AI" — it's "is this stack right for this product". For ZixcAI, it was.

What's Next
I'm continuing to ship ZixcAI features: better memory, multi-modal inputs, and more tool primitives. If you want to see what an agentic AI built on PHP actually looks like in practice, check it out.

If you're building something similar — in PHP, Python, or anything else — I'd love to hear about it. Drop a comment with your stack and what surprised you the most.

And if you made it this far: yes, PHP is fine. Really.

Thanks for reading. If you found this useful, I write occasionally about AI engineering, unorthodox stack choices, and building products solo.