neuron-core/neuron-ai: a PHP agent framework that ships its own Workflow, MCP connector and Inspector hookup

The gap neuron-ai fills in a PHP codebase

Most PHP teams that want an AI feature start by writing a thin HTTP client around a provider SDK, then discover they need conversation memory, then tool calling, then a way to inspect why a model chose one tool over another. Each of those gets added as a separate package, and the glue between them becomes the actual codebase. Neuron's pitch is that this glue is the framework. The README states the goal plainly: a PHP framework for creating and orchestrating AI Agents, covering the lifecycle from LLM interfaces and data loading to multi-agent orchestration and monitoring. The audience is PHP developers who want the agent to be the architecture of the application, not a feature bolted onto a CRUD app. The README frames this as the difference between a web application with AI features added along the way and an application born agentic. Whether that framing matches your project is the first decision, and it is a real one: if you only need one completion call behind a form, the framework's abstractions are overhead.

Agent subclasses, providers and the memory that comes for free

The core mechanism is inheritance. You extend NeuronAI\Agent\Agent and override two methods. provider() returns an AIProviderInterface implementation, and the README example uses NeuronAI\Providers\Anthropic\Anthropic constructed with a key and a model name. instructions() returns the system prompt as a plain string. The Agent base class then manages memory, tools and RAG on your behalf, according to the README. The chat example is the clearest evidence of the memory behaviour: after telling the agent a name in one call, a second call asking whether the agent remembers returns the name. That means conversation history is persisted between chat() invocations without the caller passing the transcript back in. The README points to a dedicated chat-history-and-memory documentation page for the details of where that history lives and how it is scoped, and that page is where you should look before assuming it matches your storage or multi-tenant requirements. The provider abstraction is the other half: swapping Anthropic for another provider is a change to one method, not a rewrite of the calling code.

Workflow, human-in-the-loop and streaming as one package

The README lists five foundations it says exist in one place in the PHP ecosystem: event-driven workflows with checkpointing, human-in-the-loop interruption, multi-agent orchestration, streaming through agentic UI protocols including AG-UI and the Vercel AI SDK protocol, MCP, and asynchronous execution. Each is a chapter of the documentation rather than a separate Composer package. The claim that matters for adoption is the continuity one: the same Workflow that runs the getting-started agent runs a multi-agent system with state, loops and human approvals in production. If that holds, the migration cost from prototype to production is a configuration change rather than a rewrite. I cannot verify that from the README alone, and the phrasing is marketing-shaped, but the architectural implication is testable: a workflow with checkpointing and an interruption point is a different object than a chat loop, and the README treats them as the same primitive. Treat the continuity claim as the thing to validate first with a small workflow that pauses for approval.

Getting it running: composer, make:agent, and the Inspector key

Installation is one command: composer require neuron-core/neuron-ai. The package requires PHP ^8.1. Agent scaffolding is a second command: vendor/bin/neuron make:agent DataAnalystAgent, which generates a class in App\Neuron. From there the README's example agent is roughly fifteen lines. You instantiate with DataAnalystAgent::make(), send a UserMessage through chat(), and read the reply with getMessage()->getContent(). Monitoring is configured through an environment variable rather than code. Setting INSPECTOR_INGESTION_KEY in the application environment file, with a value in the format shown in the README, is what turns on the execution timeline in the Inspector dashboard. That is the only monitoring path the README documents, and it is a third-party service, not a local trace viewer. For a team that cannot send agent traces to an external endpoint, that is a constraint to resolve before adopting, not after.

Where the framework is the wrong tool

The README's own argument is also its limitation. Neuron assumes the agent is the architecture. If your application is a conventional PHP web app where one endpoint calls a model and returns text, you are paying for a Workflow engine, an MCP connector and an orchestration layer you will not use, and the Agent base class will manage memory you may not want persisted. The harder constraint is monitoring. The documented debugging story routes through Inspector, and the README is explicit about why: agents influence probability distributions, same input does not mean same output, so reproducibility and versioning become real problems. If your organisation cannot send prompt and tool-call data to a hosted observability service, the framework's answer to the debugging problem is not available to you, and you would be building a substitute. A third limitation is language. Everything here is PHP, and the ecosystem of examples, tutorials and community answers is smaller than what exists for Python or TypeScript agent frameworks, so unusual problems are more likely to be yours alone.

What you give up compared with LangChain-style toolkits

The obvious alternative for a PHP team is a general-purpose LLM toolkit such as LangChain, and the difference is not feature count but centre of gravity. LangChain is a library of composable pieces where agents are one component among many, and you assemble chains, retrievers and memory stores yourself, often across several packages with independent release cycles. Neuron inverts that: the Agent class is the entry point, memory and tools are inherited from it, and the Workflow, MCP connector and streaming adapters are documented as chapters of one framework rather than as separate integrations. The practical consequence is that Neuron gives you fewer choices and a more opinionated path. If your architecture already has a queue system, a state machine and an observability stack you like, a general-purpose toolkit that plugs into them may fit better than a framework that expects to be the state machine. The README also makes a claim about the ecosystem being vertical and independent, with a registry of extensions and companies building on the same architecture. That is a positioning statement, not something the README substantiates with specifics, so weigh it as intent rather than evidence.

Maintenance cost, release cadence and the MIT licence

The release history shows a tight cadence: 3.16.10, 3.16.11 and 3.16.12 all landed within about a week in September 2026, and the default branch is 3.x. Frequent patch releases are good for fixes and bad for pinning, because a project that ships three patch versions in five days will occasionally ship a regression you have to notice. Pin the version in composer.json and read the changelog before bumping rather than tracking the branch. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence with few obligations, but it is not legal advice and your counsel should confirm how it interacts with any bundled provider SDKs, which carry their own terms. One maintenance cost is worth naming: the framework's value depends on keeping provider classes current with model APIs, so your upgrade path is partly tied to how quickly neuron-core tracks provider changes, not only to your own release schedule.

What to check before you commit

Start with the streaming adapters. The README promises AG-UI and the Vercel AI SDK protocol, and the section on stream adapters is where you confirm which protocol your front end speaks and whether an adapter exists for it. Next, run make:agent and build a two-step workflow that pauses for human approval, then kill the process and restart it, to see what checkpointing actually preserves. Then confirm the memory store's scoping against your tenancy model, because the README's example implies persistence across chat() calls without saying where that state lives. Finally, decide on monitoring before you write production code, since the documented path is the INSPECTOR_INGESTION_KEY environment variable and an Inspector account. If all four checks pass, the framework's bet (one architecture from first agent to multi-agent production system) is worth taking on the 3.x branch.

Editorial conclusion

Adopt neuron-ai if your application is already PHP 8.1+ and the agent is meant to be the architecture rather than a side feature, because the Workflow, human-in-the-loop, streaming adapters and MCP connector are documented as parts of the same package rather than separate libraries you assemble. Do not adopt it if you need a language-agnostic runtime, a Python or TypeScript ecosystem, or a framework whose release cadence you can predict months ahead. Before committing, verify three things on the 3.x branch: that the streaming adapter you need is documented for your UI protocol, that the Inspector integration is acceptable as the monitoring path, and that the new-provider surface keeps pace with the models you actually call.

Official sources

1. License: MIT
2. neuron-core/neuron-ai on GitHub
3. Project website
4. README
5. Releases