Neuron AI - PHP Agentic Framework

"And in six months, when things change?"
Clients don't just buy what works today, they buy what keeps working.
An agentic system you can measure is one you can keep improving without breaking the promises you made: on every change, the same checks run again. It gets better over time, not more fragile.
That is the difference between a project you deliver once and a client who stays.
Built in PHP with Neuron.

"What if the agent does something it shouldn't?"
It is the fear that stalls every agentic budget. The answer is not "it won't", it is "it can't, and we prove it".
On the risky actions, a person approves first. The agent never does anything irreversible on its own, and a test fails the moment it tries.
You are not selling a black box. You are selling control your client can see.
Agentic-native software, built in PHP with Neuron.

Your client will ask one question that decides the deal: "how do I know it works?"
For agentic software, "trust me" is not an answer. A number is.
You run it on real cases and measure how often it actually gets the job done. That is your success rate, and you put it in the contract. "Good enough" stops being an argument at delivery: it is agreed up front.
That is how you sell an agentic project with confidence, and defend your price.
Built in PHP with Neuron.

There are two kinds of software.
One is an app that exists for something else, with AI added along the way. The other is born agentic: the agent is the architecture from the first commit, driving how the whole system reasons, acts, and works.
Your next application will be that second kind. And you can build it in PHP, with Neuron.
Agentic-native.
Which side will your next project be on? 👇

If you are on one framework and you plan to stay there, the official AI SDK for it is a reasonable choice. I mean it, and it is the honest starting point for everything else I am about to say.

In early 2026 Symfony and Laravel shipped their own AI SDKs. That was a relief on our side. It validated a direction we had been working in since March 2025, and it told the PHP community that this is real engineering and not a side quest.

So the question is no longer whether your framework can call a model. They all do that well now, and it is no longer where anything gets decided.

The question that is actually hard is which decisions you can still change later. Durable ex*****on, resuming after a crash, pausing for human approval, streaming a real interface to a user: these are not things you consume, they are things that change how ex*****on works. Adding them to a layer designed to abstract provider calls means reopening the foundations, which is why they tend to arrive late, when they arrive.

That matters once you are past the prototype and the agent is carrying real work. Discovering an architectural limit at that point is the most expensive version of that discovery.

I am obviously not neutral here, so do not take the criterion from me. Take the question and apply it yourself: what does my agent need to do in eighteen months, and can the layer I pick today grow into it.

Full clip: https://youtu.be/rTV-s03_4RA

🧩 You saw the agent create a full Spryker product from one plain sentence, live on the storefront. The interesting part is not what it does. It is how it is built.

Here is what is actually running, and why it all stays in PHP:

🔹 It is not a chatbot bolted onto Spryker. The agent runs inside the back office, in the same stack that already runs the store. You enable it from the admin config and it is there. No separate AI service to host and keep in sync.

🔹 Structured extraction first. One sentence becomes concrete fields: product name, SKU, description, variants, price, stock per unit, category, tax set. The model reads intent, the framework turns it into a typed plan the back office can act on.

🔹 It acts through tools, not prompts. The agent calls real back office functions: list_categories, list_tax_sets, set_product_stock, assign_product_to_category, approve_product. Each is a defined tool with a defined result, not text it hopes is right.

🔹 Missing data does not break it. When the category is missing, a rigid script stops with an error. The agent notices, asks, searches the store for the closest existing category, and binds the product to it. That is a workflow with state, not a single call.

🔹 A human stays in the loop by design. Before it writes anything, it shows the exact tools it will call and a summary of the product. Nothing is created until you approve.

🔍 This is the line between a framework and a wrapper. You can follow every step: the plan, the tool calls, the state between them. When something looks off, you can see why. An agent you can inspect is one you can actually run in a real back office.

And all of it stays in PHP, inside Spryker. No rewrite, no separate service, no leaving your stack. What scales is not typing product forms by hand, it is reviewing one plan per product while the agent does the rest.

Full demo built by Hidran Arias, running inside a Spryker back office on Neuron.

Neuron, the framework that brought AI agents to PHP.

▶️ Full demo by Hidran Arias: https://www.youtube.com/watch?v=HIMS4LGxCoQ

Build a Spryker AI Agent to Create Products + Images (End-to-End) I walk through the full flow: enabling the product creation agent i...

Your client isn't afraid of AI. They're afraid of paying for something that might not work.
If you build software for clients, that fear is what kills the deal or shrinks the price. Here is how you turn it around: you make the agent measurable, and you show it.
Swipe through the 4 things that make an agentic project easy to say yes to. 👇
Built in PHP with Neuron.

When you add AI to an application you are choosing between two shapes, often without noticing: a wrapper around a provider, or a framework that owns ex*****on.

I had to make that choice in early 2025, for Inspector. It is a PHP product, and what existed at the time gave you the first shape. I could not find the second one anywhere: no orchestration, no state surviving a step, no model for an agent that runs, pauses and resumes.

So we built the second shape, and the reasoning still holds today. A wrapper is enough while an agent is one call and one answer. It stops being enough the moment the agent has to do several things in order, keep what it learned along the way, survive a failure and wait for a human.

The part I did not expect came after we published it. A developer wrote that his 15 years invested in a PHP platform were not meant to die. Then others wrote something similar. That is when this stopped being an internal tool and started being a project with an ecosystem around it.

What it saves the person reading this: adding agents to an existing PHP application no longer means a rewrite in another language, or a second team on a second stack. Those are paid in engineering months, not in license fees.

Neuron: the framework that brought AI agents to PHP.

Full clip: https://youtu.be/AVkQpsPiRTg

🧭 Here is a rough edge in the demo, and I want to point at it on purpose.

After a few exchanges, the agent sometimes loses track that it is the product creation agent, and you have to reselect it to be explicit again. Hidran shows this in the video, he does not cut it out.

I could pretend agents are magic. They are not, and the people we build for know it. What makes an agent trustworthy in production is not that it never has a rough edge, it is that you can see the edge, understand why it is there, and work with it.

🔍 That visibility is the whole point of building on a framework instead of a wrapper: state you can inspect, ex*****on you can follow, limits you can name. An agent you cannot see into is the one you cannot trust with real work.

🧩 Running inside a Spryker back office, built on Neuron. Full demo by Hidran below.

👉 Would you rather have an agent that hides its limits, or one that shows them?