Neuro SAN Studio: A HOCON-Driven Playground for Multi-Agent Networks
A playground for neuro-san
At a glance
- What is it?
- Neuro SAN Studio packages the Neuro SAN orchestration framework with runnable examples, a browser UI and a meta-agent that writes agent networks for you. The design bet is that agent topologies belong in declarative config files, not Python. That bet has a cost.
- Who is it for?
- Adopt Neuro SAN Studio if your multi-agent work is dominated by topology rather than custom code: support triage, policy explanation, research routing, and any case where a domain expert should own the agent graph. Skip it if you need a general-purpose orchestration library, since the studio is a companion to neuro-san rather than a replacement for it, and if your agents must hold sensitive values in LLM context, verify Sly-Data's boundaries before designing around it.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Agent Topology Lives in Code, and Code Owners Are Scarce
Most multi-agent projects start as a Python file: a planner function, a set of tool objects, a loop that routes messages. That works until the person who understands the business process cannot read the file that encodes it. At that point every routing tweak becomes a ticket, and the graph drifts away from the process it was meant to model.
Neuro SAN Studio targets exactly that gap. Its README positions the project as a playground for the Neuro SAN framework, aimed at three groups: researchers exploring adaptive AI systems, developers prototyping production solutions, and domain experts configuring agents without code. The last group is the interesting one. The framework underneath defines entire agent networks in HOCON, a declarative config format, so a support policy owner can read and edit the agent graph directly.
The studio itself is not the framework. It is the launchpad: ready-to-run examples, tutorials, and tools, per the README. If you want the orchestration engine alone, that is a separate repository.
How Delegation Works: AAOSA, HOCON and Decentralised Routing
The mechanism the README describes is adaptive communication built on the AAOSA protocol, with a link to a 1998 paper. Agents do not follow a fixed pipeline. Each one decides how to delegate a subtask to another agent, so routing emerges from the network rather than from a central scheduler. The README frames this as a response to single-agent limits: no single model has all the expertise or context for a multifaceted problem.
The concrete artefact is the HOCON file. An agent network is data. Each agent's instructions, tools and relationships live in configuration rather than in a class hierarchy. That choice has a visible consequence: the Agent Network Designer, a meta-agent shipped as an example, takes a high-level description of a use case and generates a new custom agent network for it. Generating a config is a tractable task for a language model. Generating a coherent Python codebase is not, which is likely why the design landed here.
Tool integration is broad by design. The README lists coded Python tools, APIs, databases, and external agent ecosystems including Agentforce, Agentspace, CrewAI, MCP, A2A agents and LangChain tools. Sly-Data is described as a mechanism for passing sensitive data between agents without exposing it directly to any language model. The README does not spell out the implementation, so treat that as a claim to verify in the framework source, not a guarantee.
Getting It Running: Install, Configure, Launch
The README does not reproduce an install command block in the material available here, so the exact invocation is something to confirm against the repository itself. What can be stated from the material: the project is published on PyPI as neuro-san-studio, which means a pip install of that package name is the expected entry point, and the studio wraps the neuro-san library, which has its own PyPI package.
Configuration is the part that matters. Agent networks are HOCON files, so your first real task after installation is locating the example configs and reading one. The studio ships examples across verticals; the README points to docs/examples.md for the full list and names an Airline Policy Assistance network that has agents interpret and explain airline policies.
The README also references a quick-start video and a browser-based UI, which the topic list identifies as nsflow. Expect to supply LLM provider credentials: the README names OpenAI, Anthropic, Azure and Ollama as supported providers, which means an API key or a local Ollama endpoint is a prerequisite before any network will run. The README does not document the environment variable names, so check the repository's setup instructions rather than guessing.
The Agent Network Designer Is the Most Interesting and Least Predictable Part
A meta-agent that emits agent networks is a genuinely different proposition from a library that executes them. The README describes the Agent Network Designer as taking a high-level description of a use case as input and generating a new custom agent network for it. The studio bundles it as an example, not as a core service.
That distinction is worth holding onto. Generated configs are a starting point. A HOCON file that parses is not the same as a network whose delegation behaviour matches your process, and the README makes no accuracy claim about the generated output. The practical workflow is to generate, read, and edit. The editing step is where the domain expert earns their place, and it is also where the declarative format pays off: the diff between a generated network and a correct one is readable text, not a refactor.
If your team cannot review HOCON, the Designer's output becomes another opaque artefact. The tool reduces the cost of the first draft, not the cost of understanding the result.
Where the Approach Breaks Down
Decentralised delegation is harder to debug than a fixed pipeline. When agents decide their own routing, a failure can originate in any hop, and reproducing it means reproducing the sequence of decisions. The README claims detailed logging, tracing and session-level metrics, which is the right mitigation, but tracing infrastructure tells you what happened, not why an agent chose a particular delegate. Budget time for reading traces rather than assuming they resolve the question.
The second constraint is scope. The studio is a companion to neuro-san, not a standalone framework. If you want the orchestration engine without the examples, tutorials and UI, you are installing the wrong repository. The README is explicit that the studio is a playground; a production deployment story is not described in the material available here, beyond the general claim that deployments can run locally, in containers, or in cloud infrastructure.
The third is Sly-Data. The README presents it as a way to move sensitive values between agents without exposing them to language models. That is a strong claim and the README does not document the mechanism. Any design that depends on it should be validated against the framework source first.
The Alternative: LangGraph and Code-First Orchestration
The obvious comparison is LangGraph, which models agents as nodes in an explicit graph defined in Python. The difference is not cosmetic. LangGraph gives you a graph you can inspect, type and unit test in the same language as the rest of your service. Neuro SAN gives you a graph a non-programmer can edit, at the cost of expressing control flow in a config format with less tooling behind it.
That trade decides the choice. If your agents are tightly coupled to application code, share in-process state, and change with every release, a code-first graph fits better. If your agent topology is a business process that changes on a different cadence than your deployments, and the people who own that process are not engineers, the HOCON approach removes a translation step that otherwise costs you every sprint. The README's framing of domain experts configuring agents without code is the whole argument, and it is a real one.
Note that the two are not mutually exclusive at the tool level. The README lists LangChain tools among the integrations, so a Neuro SAN network can call into LangChain components even if the orchestration layer differs.
Maintenance, Licensing and What to Check Before You Commit
The project is Apache-2.0, which permits commercial use and modification, and the repository is not archived. Release cadence is visible in the material: 0.4.0 in early September 2026, 0.3.20 in mid August, 0.3.18 in early August. That is a rapid minor-version rhythm, and the 0.x version number is the honest signal. Expect config schema and API surface to move between releases, and pin your dependency rather than tracking main.
Upgrade cost concentrates in the HOCON files. If the schema changes, your agent definitions change with it, and the studio's examples are the fastest way to see what a current file looks like. Treat the example configs as the canonical reference during an upgrade rather than assuming your existing files remain valid.
On licensing, Apache-2.0 covers the studio repository. The neuro-san framework is a separate repository with its own terms, and the integrations the README lists (Agentforce, Agentspace, CrewAI, MCP, A2A, LangChain) carry their own licences. None of that is legal advice; check each component you actually ship.
The first thing to verify is the HOCON schema in the framework repository, because every design decision downstream depends on what an agent definition can express. The second is Sly-Data's actual boundary. The third is whether the tracing output is detailed enough to debug a delegation chain you did not design. If those three hold up, the declarative bet is worth taking.
Editorial conclusion
Adopt Neuro SAN Studio if your multi-agent work is dominated by topology rather than custom code: support triage, policy explanation, research routing, and any case where a domain expert should own the agent graph. Skip it if you need a general-purpose orchestration library, since the studio is a companion to neuro-san rather than a replacement for it, and if your agents must hold sensitive values in LLM context, verify Sly-Data's boundaries before designing around it. Before committing, read the HOCON schema in the framework repository, open the Agent Network Designer example and inspect the config it emits, and confirm which LLM provider keys your environment can supply.
Community notes