DEV Community: Khaled Hammrouni

05 - Multi-Provider LLM in PHP - Switch Between Groq, OpenAI, and Mock

Khaled Hammrouni — Sun, 27 Sep 2026 18:26:47 +0000

Hard-coding one LLM provider is a trap. You want to test locally with a mock, run cheap on Groq, and fall back to OpenAI in production - without rewriting the agent. The whole provider choice is one config array.

This example loops over three providers with the identical agent code and shows the switch is genuinely that small.

The providers are just config

Read the default provider/model/key from config once, then lay out three provider configs as a plain array - a free offline mock, your configured default (Groq), and OpenAI as a paid fallback.

use NanoAgent\Agent;

$configFile = __DIR__ . '/../NanoAgent/config.php';
$default = file_exists($configFile) ? require $configFile : [];

$apiKey   = $default['api_key']  ?? '';
$provider = $default['provider'] ?? 'groq';
$model    = $default['model']    ?? 'llama-3.3-70b-versatile';

$configs = [
    'Mock'   => [
        'llm' => ['provider' => 'mock', 'model' => 'test-model', 'api_key' => 'mock-key'],
        'description' => 'Offline mock for local development.'
    ],
    'Groq'   => [
        'llm' => ['provider' => $provider, 'model' => $model, 'api_key' => $apiKey],
        'description' => 'High-performance inference.'
    ],
    'OpenAI' => [
        'llm' => ['provider' => 'openai', 'model' => 'gpt-4o', 'api_key' => getenv('OPENAI_API_KEY')],
        'description' => 'Commercial provider.'
    ]
];

The loop - same agent, different brain

Skip any provider you have no key for, then create an Agent per config and send it the same test message. Notice the Agent constructor call is identical every time except for the llm array.

foreach ($configs as $name => $cfg) {
    if ($name !== 'Mock' && empty($cfg['llm']['api_key'])) {
        echo "$name: skipped (no key)\n";
        continue;
    }

    $agent = new Agent(
        llm: $cfg['llm'],                       // <-- the ONLY thing that changes
        systemPrompt: "You are testing the $name provider. Reply briefly identifying yourself."
    );

Wrap the call in try/catch so one provider's outage or bad key doesn't stop you from testing the others.

    try {
        $response = $agent->chat("Verify connection.");
        echo "$name: OK -> $response\n";
    } catch (Throwable $e) {
        echo "$name: ERROR -> {$e->getMessage()}\n";
    }
}

The new Agent(llm: ...) line is the seam. Everything downstream - tools, history, streaming, structured output - is provider-agnostic. You never touch the rest of your code to change the model.

What this buys you

Offline development. Point at the mock provider and develop/test the whole agent flow with zero API spend and zero network. No .env required.
Cost control. Route high-volume, low-stakes calls to a cheap/fast model; reserve the expensive one for the hard paths.
Resilience. Wrap in a fallback: try the primary, catch Throwable, retry on a secondary provider. Same agent object shape.
A/B and evals. Run the same task against several providers and compare outputs programmatically - this loop is an eval harness.

The fallback pattern

$providers = ['groq', 'openai'];
foreach ($providers as $p) {
    try {
        return (new Agent(llm: ['provider' => $p, 'model' => $model, 'api_key' => $key]))
               ->chat($message);
    } catch (Throwable $e) {
        // log and try the next provider
    }
}

Bottom line: keep the provider in config, keep the agent code generic, and "switching models" stops being a refactor and becomes a one-line change.

Part of the NanoAgent examples series. Landing + demos.

04 - Structured Output in PHP - Extract JSON from Unstructured Text

Khaled Hammrouni — Sun, 27 Sep 2026 18:24:31 +0000

The most useful "AI feature" in a real app is rarely a chatbot. It's turning a blob of unstructured text into clean, typed data - a profile, an order, a support ticket, a CV. The trick to doing this reliably is to not ask the model to "return JSON." Instead, you define a tool with a JSON Schema and instruct the model to call that tool with the data. The schema becomes the contract.

This is the "tool-as-schema" pattern, and it's the most reliable structured-output approach in practice.

Define the schema as a tool

First, the shape of the data you want. Each field gets a type and a description - this is a plain JSON Schema object, no different from any other tool's parameters.

use NanoAgent\Agent;
use NanoAgent\Tools\FunctionTool;

$extractedData = null;

$extractionTool = new FunctionTool(
    name: 'save_profile',
    description: 'Saves the extracted user profile data into the system.',
    parameters: [
        'type' => 'object',
        'properties' => [
            'full_name'         => ['type' => 'string',  'description' => "The person's full name"],
            'job_title'         => ['type' => 'string',  'description' => 'Current job title'],
            'skills'            => ['type' => 'array',   'items' => ['type' => 'string'],
                                    'description' => 'Technical skills mentioned'],
            'experience_years'  => ['type' => 'integer', 'description' => 'Years of experience'],
            'is_open_to_work'   => ['type' => 'boolean', 'description' => 'Looking for opportunities']
        ],
        'required' => ['full_name', 'skills']
    ],

The callable here doesn't do real work - it just grabs whatever arguments the model filled in and stashes them in $extractedData by reference, so you can use them after the chat finishes.

    callable: function (array $args) use (&$extractedData) {
        $extractedData = $args;
        return "Internal: Profile for {$args['full_name']} captured.";
    }
);

Force the model to use only the tool

Give the agent an unstructured blob of text - a bio, in this case - and a system prompt that leaves it no other option than to call save_profile.

$inputText = "Hi, I'm Sarah Jenkins. I've been a Senior PHP Developer for about 8 years. "
           . "I love Laravel, Symfony, and Docker. I'm leading a team of 4. "
           . "Not actively looking, but open to interesting offers.";

$agent = new Agent(
    llm: $llmConfig,
    systemPrompt: "You are a precise data extraction specialist. Your ONLY task is to identify "
                . "profile details and call the `save_profile` tool once. Answer only via tool call.",
    tools: [$extractionTool]
);

$agent->chat($inputText);

After chat() returns, $extractedData holds a real, typed PHP array - no parsing, no regex, no hoping the model's JSON is valid:

// ['full_name' => 'Sarah Jenkins', 'job_title' => 'Senior PHP Developer',
//  'skills' => ['Laravel','Symfony','Docker'], 'experience_years' => 8, ...]

Why this beats "just return JSON"

The schema is enforced by the tool-calling layer, not by the model's good intentions. The model fills a defined shape; you get a guaranteed structure.
required fields mean the model knows what it must produce.
Your callable is where validation happens. $extractedData is a real PHP array - cast, validate, persist, however you like. The model never touches your storage.
additionalProperties / types keep it tight. No stray keys, no "kind of a number."

Where this shines

Form automation - parse a free-text email into a structured ticket.
ETL - clean messy upstream text into your database schema.
Classification - define a tool with category: enum[...] and you have a classifier.
CV parsing - the exact example above, at scale.

The pattern generalizes: whatever shape you need out, declare it as a tool, and make "call the tool" the model's only job.

Part of the NanoAgent examples series. Landing + demos.

03 - Streaming LLM Tokens in PHP with Server-Sent Events

Khaled Hammrouni — Sun, 27 Sep 2026 18:07:55 +0000

The worst part of a chat UI is the blank screen while the model thinks. Fix: stream the tokens as they're generated, not the whole reply at the end. In PHP that's Server-Sent Events (SSE) - one persistent response that keeps pushing data.

NanoAgent's Agent::stream() hands you each token through a callback. Your job is just to format it as SSE and flush.

The streaming endpoint

1. The route and the SSE headers

Everything below only runs when the request is asking for a stream (?stream=1&message=...). The four headers are what turn a normal PHP response into a Server-Sent Events stream the browser will keep open and read incrementally.

require_once __DIR__ . '/../NanoAgent/autoloader.php';
use NanoAgent\Agent;

if (isset($_GET['stream']) && !empty($_GET['message'])) {
    header('Content-Type: text/event-stream');
    header('Cache-Control: no-cache');
    header('Connection: keep-alive');
    header('X-Accel-Buffering: no');   // critical under Nginx

    $userMessage = trim($_GET['message']);

    $configFile = __DIR__ . '/../NanoAgent/config.php';
    $config = file_exists($configFile) ? require $configFile : [];

    $agent = new Agent(
        llm: [
            'provider' => $config['provider'] ?? 'groq',
            'model'    => $config['model']    ?? 'llama-3.3-70b-versatile',
            'api_key'  => $config['api_key']  ?? ''
        ],
        systemPrompt: "You are a helpful and concise streaming assistant."
    );

2. Stream - one callback per token

stream() calls your closure once for every token the model generates. Each call formats the token as an SSE data: line and forces PHP to send it immediately instead of buffering it.

    $agent->stream($userMessage, function ($token) {
        echo "data: " . json_encode(['token' => $token]) . "\n\n";
        ob_flush();
        flush();
    });

3. Signal completion

Once the model is done, send a sentinel value the client can watch for, then close out the request.

    echo "data: [DONE]\n\n";
    ob_flush();
    flush();
    exit;
}

Two things are non-negotiable here:

ob_flush() + flush() after every token. PHP buffers output; without these the browser gets nothing until the request ends, which defeats the whole point.
X-Accel-Buffering: no. Nginx buffers upstream responses by default. This header stops it from holding your tokens.

The client

A plain EventSource - no library, no WebSocket:

const es = new EventSource(`/streaming.php?stream=1&message=${encodeURIComponent(msg)}`);

es.onmessage = (e) => {
  if (e.data === '[DONE]') { es.close(); return; }
  const { token } = JSON.parse(e.data);
  answerEl.textContent += token;
};

Why SSE over WebSockets

For one-way token flow (model → browser), SSE is simpler: it's plain HTTP, auto-reconnects, and works through proxies that choke on WebSockets. You only need a real bidirectional socket if the client has to interrupt mid-stream - which is a separate feature.

The takeaway

stream() turns "wait 8 seconds for a wall of text" into "watch it type." The entire change from a blocking chat() is one callback + two flush() calls + the SSE headers. Everything else in your app stays the same.

Part of the NanoAgent examples series. Landing + demos.

02 - Persistent Memory Chat in PHP - History That Survives Restarts

Khaled Hammrouni — Sun, 27 Sep 2026 18:03:14 +0000

Sessions are the easy answer for chat history, but they vanish when the browser closes or the server restarts. For anything that should remember - a support bot, a notes assistant, a shared conversation - you want history to outlive the process.

In NanoAgent this is a first-class feature. You stop hand-rolling "load the array, save the array" yourself and attach a memory driver to the agent. It loads the conversation for a session and saves it after every completed chat() / stream() call - automatically.

The one line that changes everything

$agent->setMemory(new FileMemory(__DIR__ . '/memory'), 'demo');

That's the whole new API. setMemory() takes any object that implements NanoAgent\Contracts\Memory and a session id. From then on the agent loads the stored history up front and persists it after each reply. No manual getHistory() / setHistory() / file_put_contents() choreography.

How the example wires it up

The Memory Chat example lets you switch drivers with a dropdown so you can feel the difference:

use NanoAgent\Agent;
use NanoAgent\Memory\ArrayMemory;
use NanoAgent\Memory\FileMemory;

// One shared conversation for the demo; in a real app use a user or chat id.
$sessionId = 'demo';

$drivers = [
    'file'  => 'FileMemory (persistent)',
    'array' => 'ArrayMemory (current request only)',
];
$driver = isset($_GET['driver'], $drivers[$_GET['driver']]) ? $_GET['driver'] : 'file';

$memory = match ($driver) {
    'array' => new ArrayMemory(),
    default => new FileMemory(__DIR__ . '/memory'),
};

$agent = new Agent(
    llm: [
        'provider' => $config['provider'] ?? 'groq',
        'model'    => $config['model']    ?? 'llama-3.3-70b-versatile',
        'api_key'  => $config['api_key']  ?? ''
    ],
    systemPrompt: "You are a helpful assistant with a perfect long-term memory."
);

// Loads any stored history and saves after every chat() call.
$agent->setMemory($memory, $sessionId);

Everything after that is just normal agent use - the memory is handled for you:

if ($_SERVER['REQUEST_METHOD'] === 'POST' && !empty($_POST['message'])) {
    // History is persisted automatically once the reply is complete.
    $agent->chat(trim($_POST['message']));
}

And resetting is one call too. clearHistory() empties the in-process history and deletes the stored row/file:

if (isset($_POST['reset'])) {
    $agent->clearHistory();
    header("Location: " . $selfUrl);
    exit;
}

The three built-in drivers

Driver	Storage	Requires	Use it when
`ArrayMemory`	Current process only	-	Tests, long-running workers (queues, ReactPHP, Swoole, CLI loops)
`FileMemory`	One JSON file per session	-	Zero-infrastructure, single-user or small tools
`PdoMemory`	SQL table (SQLite, MySQL, PostgreSQL)	`ext-pdo` + driver	Multi-user apps, production, when you want queries/cleanup

ArrayMemory is the "it forgets" baseline - useful to prove the driver is what's doing the remembering. FileMemory names its files with a hash of the session id, so arbitrary ids (emails, UUIDs, raw user input) can't escape the directory, and it writes to a temp file then renames into place, so a crashed request never leaves a half-written file. PdoMemory stores each session as one row with native upserts on SQLite, MySQL/MariaDB and PostgreSQL:

use NanoAgent\Memory\PdoMemory;

// SQLite file, created on first use (keep it outside your public web root):
$agent->setMemory(PdoMemory::sqlite(__DIR__ . '/memory/chat.sqlite'), "user-$userId");

// Or reuse an existing PDO connection (MySQL, Postgres, Laravel's, ...):
$agent->setMemory(new PdoMemory($existingPdo), $sessionId);

There's a full guide for the database path - connection strings, per-DB table schemas, session-id safety, and cleanup - in the PdoMemory docs.

Choosing a session id

The session id decides which conversation is loaded, so it has to come from something your server trusts, never straight from user input - otherwise one user could type another user's id and read their chat.

$agent->setMemory($memory, 'user-' . $user->id);            // one per logged-in user
$agent->setMemory($memory, "user-{$user->id}-chat-{$chatId}"); // several per user
$agent->setMemory($memory, 'visitor-' . session_id());       // anonymous visitors

Why this is better than the manual file approach

You could still do it by hand - setHistory() on load, file_put_contents(getHistory()) after each reply - and the older version of this article showed exactly that. The memory driver is the same idea, but with the round-trip built in:

No boilerplate - one setMemory() instead of load/save/clear logic in every request.
Swap the store, not the agent - go from FileMemory to PdoMemory (or your own driver) and not a single line of agent code changes.
It just works - the driver saves after every completed turn, and a call that throws mid-turn isn't saved, so storage always holds the last completed exchange.

Need a backend that isn't in the box - Redis, a framework cache, Eloquent? Implement the three-method NanoAgent\Contracts\Memory interface (load(), save(), clear()) and drop it straight into setMemory().

Part of the NanoAgent examples series. Landing + demos.

01 - Stateful Chat in PHP - Conversation History That Survives Requests

Khaled Hammrouni — Sun, 27 Sep 2026 17:59:19 +0000

A single-shot agent is easy. The real product is a conversation - and in PHP the hard part is that each HTTP request is a fresh process. There's no object living in memory between calls. You have to store history outside the request.

This example keeps it dead simple: PHP sessions.

Start the session and set up a reset path

session_start() gives you $_SESSION, which PHP keeps alive across requests for the same browser via a cookie. Initialize an empty history array the first time, and give the user a way to clear it (a POST with a reset field just wipes the array and redirects back).

session_start();
require_once __DIR__ . '/../NanoAgent/autoloader.php';

use NanoAgent\Agent;

if (!isset($_SESSION['history'])) {
    $_SESSION['history'] = [];
}

if (isset($_POST['reset'])) {
    $_SESSION['history'] = [];
    header("Location: " . $_SERVER['PHP_SELF']);
    exit;
}

Build the agent

Same config-loading pattern as the basic agent example - read config.php if it exists, fall back to Groq defaults otherwise.

$configFile = __DIR__ . '/../NanoAgent/config.php';
$config = file_exists($configFile) ? require $configFile : [];

$agent = new Agent(
    llm: [
        'provider' => $config['provider'] ?? 'groq',
        'model'    => $config['model']    ?? 'llama-3.3-70b-versatile',
        'api_key'  => $config['api_key']  ?? ''
    ],
    systemPrompt: "You are a helpful and witty web assistant. Return answers in Markdown."
);

Handle the incoming message

Three moves, in order: save the user's message to the session, let the agent reply, save the reply too. The agent itself has no memory between requests - the session array is its memory.

if ($_SERVER['REQUEST_METHOD'] === 'POST' && !empty($_POST['message'])) {
    $userMessage = trim($_POST['message']);

    // 1. Persist the user message
    $_SESSION['history'][] = ['role' => 'user', 'content' => $userMessage];

    // 2. Ask the agent - it carries the session history
    $response = $agent->chat($userMessage);

    // 3. Persist the reply
    $_SESSION['history'][] = ['role' => 'assistant', 'content' => $response];
}

The form is the boring-but-important half:

<div class="chat-input">
    <form method="POST" class="input-group">
        <input type="text" name="message" placeholder="Type your message..." required autofocus>
        <button type="submit">Send</button>
    </form>
</div>

The pattern, in one sentence

Store the history array in $_SESSION, feed it to the agent, append both the user message and the reply back to it, repeat. The agent's chat() keeps the conversation coherent because the history travels with every request.

When sessions aren't enough

Sessions die with the browser and don't survive a server restart. The upgrade is a one-line swap of the storage layer - attach a memory driver to the agent:

$agent->setMemory(new FileMemory(__DIR__ . '/memory'), "user-$userId");

Now the agent loads that session's history on construction and saves it after every completed reply. FileMemory is the zero-infrastructure option (one JSON file per session); swap in PdoMemory for SQLite/MySQL/PostgreSQL when you need multi-user and queries. The agent code doesn't change - you're swapping the store, not the agent. See the Persistent Memory Chat article for the full driver API.

Part of the NanoAgent examples series. Landing + demos.

00 - NanoAgent: Your First AI Agent in PHP

Khaled Hammrouni — Sun, 27 Sep 2026 17:54:47 +0000

PHP developers get a lot of AI examples - but almost all of them start in Python. If your app is already in PHP (and it usually is), the "add an agent" path looks like bolting on a sidecar or learning a framework. It doesn't have to.

This is the smallest working agent in NanoAgent: one agent, one custom tool, one task.

The four pieces

An agent in NanoAgent is just four objects:

Agent - talks to the LLM.
FunctionTool - a PHP callable the model can choose to invoke.
Task - bundles a goal with background context.
A config - provider, model, API key.

Let's build it piece by piece. First, the boilerplate: pull in the autoloader and the three classes you need.

require_once __DIR__ . '/../NanoAgent/autoloader.php';

use NanoAgent\Agent;
use NanoAgent\Task;
use NanoAgent\Tools\FunctionTool;

1. Config - where the LLM connection details live

Rather than hard-code a provider and API key, read them from a config.php file if one exists, and fall back to sane defaults (Groq's free tier) if it doesn't. This means the same script runs out of the box for a first-time reader, and switches provider for anyone with their own config.

$configFile = __DIR__ . '/../NanoAgent/config.php';
$config = file_exists($configFile) ? require $configFile : [];

$llmConfig = [
    'provider' => $config['provider'] ?? 'groq',
    'model'    => $config['model']    ?? 'llama-3.3-70b-versatile',
    'api_key'  => $config['api_key']  ?? ''
];

2. The tool - a PHP function the model can call

A FunctionTool wraps three things: a name the model refers to, a description it reads to decide when to use the tool, and a JSON Schema describing the arguments. The callable is just a normal PHP closure - here it fabricates a "secret token" from the input string.

$secretTool = new FunctionTool(
    name: 'generate_secret_token',
    description: 'Generates a secure token based on input string.',
    parameters: [
        'type' => 'object',
        'properties' => [
            'input' => ['type' => 'string', 'description' => 'The string to obfuscate']
        ],
        'required' => ['input']
    ],
    callable: fn(array $args) => "TOKEN_" . strtoupper(strrev($args['input'])) . "_SECURE"
);

3. The agent - the brain that decides when to use the tool

The Agent ties the LLM config to a system prompt and the list of tools it's allowed to use. Nothing runs yet - this just assembles the pieces.

$agent = new Agent(
    llm: $llmConfig,
    systemPrompt: "You are a helpful PHP technical assistant.",
    tools: [$secretTool]
);

4. The task - the actual goal, plus context

A Task bundles a goal with any background context you want the model to have (here, just the project name). Calling execute() is what actually sends the prompt, lets the model call the tool if it wants to, and returns the final answer.

$task = new Task($agent);
$task->addContext("Project", "NanoAgent Library");

$response = $task->execute(
    "Generate a secret token for 'NanoAgent' and explain how it was created."
);

echo $response;

Why the tool matters

The FunctionTool is the whole idea. You describe a PHP function with a JSON Schema, and the model decides when to call it and what to pass. Task::execute() formats the goal + context into a prompt, and handles the tool round-trip for you - when the model asks to call generate_secret_token, the agent runs your callable, feeds the result back, and continues. You never wire that loop by hand.

What this unlocks

That's the floor. Once you have an agent that can call tools, everything else is adding more tools or more agents:

Part of the NanoAgent examples series. Landing + demos.

Why I keep coming back to PHP, even for AI agents

Khaled Hammrouni — Sun, 06 Sep 2026 17:48:11 +0000

I've tried the shiny new things.

Node.js. Python. Go. Rust.

And you know what ? They're great. They have their strengths. But every time I need to build something for production, something that actually needs to work and stay working, I find myself coming back to PHP. Not because I'm stuck in the past. Because PHP just works.

Here's the thing about PHP: I can write code at 9 AM, deploy it at 9:15 AM, and it runs. No containers. No orchestration. No 47-step build pipelines. Just FTP (okay, fine, Git push + deploy) and it's live.

Shared hosting ? Works. VPS ? Works. Serverless ? Also works.

PHP doesn't get in your way. It does what you ask it to do. No unnecessary complexity. No "you're holding it wrong" moments. It's the programming equivalent of a reliable pickup truck, not flashy, but it gets the job done.

Then AI happened, suddenly everyone was building agents, RAG systems, and LLM-powered applications. But the ecosystem ? Almost entirely Python. So I tried Python. And I felt like I was spending more time managing environments, fighting with package version conflicts, and learning new paradigms than actually building things. Don't get me wrong, Python is powerful. But for someone who builds PHP applications for a living, it felt like learning a new trade just to add one feature to an existing product.

The existing PHP solutions weren't much better, every AI library I found was either:

Embedded inside a massive framework (Laravel, Symfony, etc.)

Over-engineered with layers of abstractions

Unmaintained or half-baked

Or required you to restructure your entire application to use it

I just wanted something simple. Something I could drop into an existing PHP codebase and get working in 10 minutes. Something that felt like PHP.

So I built it. Introducing NanoAgentPHP. A lightweight AI agent library for PHP.

https://github.com/hammrouni/nanoagentphp

NanoAgent is live:👉 https://hammrouni.github.io/nanoagentphp/

The philosophy:

✅ Tiny footprint – No unnecessary dependencies

✅ Does the job – AI agents that actually work in production

✅ Feels like PHP – No magic, no crazy abstraction layers. Just clean, readable code you can understand in 5 minutes

What it does:

Tool/function calling :Turn any PHP function into an AI tool

Multi-provider support : OpenAI, Groq, Anthropic, DeepSeek, OpenRouter

MCP (Model Context Protocol) support : Connect to external MCP servers

Structured output, RAG, streaming, multi-agent chains

Built-in safety : Max iteration limits to prevent runaway costs

Here's how simple it is: I needed to add an AI assistant to a product that processes customer support tickets. The assistant needed to read the ticket, identify the issue, and suggest a response.

With NanoAgentPHP:

// Create a tool that fetches a ticket from the database
$getTicket = new FunctionTool(
name: 'get_ticket',
description: 'Fetches a customer support ticket by ID',
callable: function($ticketId) {
return $db->query("SELECT * FROM tickets WHERE id = ?", [$ticketId]);
}
);

// Create the agent with a system prompt
$agent = new Agent(
provider: new GroqProvider(getenv('GROQ_API_KEY')),
tools: [$getTicket],
systemPrompt: 'You are a support assistant. Analyze the ticket and suggest a helpful response.'
);

// Run it
$response = $agent->run("Ticket #1234 needs a response");
echo $response;
That's it. No migrations. No service providers. No config files. Just PHP. Or if I need to query a knowledge base (RAG):

$agent = new Agent(
provider: new OpenAIProvider(getenv('OPENAI_API_KEY'))
);
// Let the agent search your documentation vector database
$result = $agent->run(
'How do I reset my password?',
context: ['knowledge_base' => $searchResults]
);
The best part ? I can use this in production right now. Deploy it the same way I deploy everything else in PHP. No new infrastructure. No new deployment processes. Just code that works.

Why am I telling you all this ?

Because I think we've collectively lost sight of something important. Not every project needs microservices. Not every feature needs a new language. Not every problem needs to be solved with the latest trendy stack. Sometimes, you just need to get the job done. And PHP has always been great at that.

So if you're a PHP developer looking to add AI capabilities to your applications without the complexity of rewriting everything in Python give NanoAgentPHP a try.

It's open source. It's MIT licensed. And it's built for people who just want to build things.

⭐ Star it on GitHub if you find it useful: https://github.com/hammrouni/nanoagentphp

Would love to hear your feedback, feature requests, or just stories of what you're building with it.

P.S. The library is tiny, but it's battle-tested. I'm using it in production products right now. If something breaks, you'll find the code simple enough to fix it yourself that's the point.

P.P.S. If you're wondering "why not just use LangChain ?" LangChain is great. But sometimes I don't need a Swiss Army knife. Sometimes I just need a screwdriver. That's NanoAgentPHP.