# neuro-san-studio exchanges agent thinking through a file in the temporary directory

> A studio for a multi-agent orchestration framework whose agent networks are written as configuration files rather than code, with four hosted demos and a bring-your-own-key instance to try them. The dependency file is the most instructive part of the repository, because every pin in it carries the reason it exists.

**cognizant-ai-lab/neuro-san-studio** — A playground for neuro-san

- Repository: https://github.com/cognizant-ai-lab/neuro-san-studio
- Website: https://decisionai.ml/neuro-san
- Stars: 1,127 · Forks: 305
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/cognizant-ai-lab-neuro-san-studio

## The agent and its server talk through a file in the temporary directory

The environment template is the most revealing document in the repository, and one entry in it is worth reading twice. A variable holds the path to what the template calls a thinking file, used to store the agent's thoughts, and the comment says the NeuroSan server uses it to communicate with the agent. So the boundary between the model-facing process and the server that runs it is a file, not a socket, a pipe or a queue. The default path is inside the system temporary directory, and the template tells you to change it to a Windows-style path if you are on Windows. Next to it, a second variable points the logging configuration at a HOCON file that lives in the repository root, so a local run writes its configuration from the source tree rather than from a user directory.

## Four directories are installed as top-level import packages

The packaging configuration decides which directories are importable, and it includes four of them that live at the root of the repository: a registry directory, a directory of coded tools, a directory of middleware, and a directory of skills. They are included as top-level packages with no namespace prefix of their own, so after an install the names sit directly in the import path. Alongside them, application directories, build scripts, configuration, deployment, documentation, servers and tests are all explicitly excluded, which is the correct hygiene for the rest of the tree. The package data globs go further and ship every Python file under the tools and middleware directories and both Python and Markdown under skills, so the entire example surface lands in the installed distribution. For a single-purpose project that is convenient; in a shared environment those four generic names are the ones to look for first in an import conflict.

## The framework is pinned exactly and its siblings are not

The dependency file has a comment for almost every line, and the first group is where the versioning policy is visible. Two of the three framework-related requirements are pinned to an exact version, one for the orchestration library itself and one for the flow library it depends on, while the shared utility library beside them takes a lower bound like everything else. Two more requirements are exact pins in the build configuration, one of the build backend and one of the version plugin, while the packaging tool itself has only a floor. The project's own version is a third mechanism again: it is declared dynamic, derived from a version control tag at build time, with a fallback of zero. The stub packaging file says so in a comment, that version bumps are handled at tag time and not in code. So a release is made by tagging, and the two framework dependencies are frozen while everything else floats.

## Two dependencies are declared because an upstream package stopped bringing them

This is the most useful comment in the file and it describes a failure mode rather than a preference. Two requirements, a text splitter and a numeric array library, are declared directly because until recently they arrived only as transitive dependencies of a community package, and that package was removed in a numbered issue. The comment then explains each: the splitter is imported directly by a retrieval-augmented generation module, and the array library is an optional dependency of the model library that its in-memory vector store needs at query time, with the specific consequence spelled out, a similarity function that raises an import error without it, which every in-memory retrieval tool in the repository relies on. A third comment documents two smaller requirements declared for the same reason, a hostname canonicalisation library and the URL type from the HTTP library, both already present transitively and both imported directly by a URL policy module.

## One demo is responsible for a PDF library everyone installs

Among the pinned requirements there is a PDF extraction library, and the comment above it says which feature needs it: the airline policy demo. So a single example network in the documentation set dictates a dependency that every install, including a production deployment that will never touch that demo, must satisfy. It is a small thing and an extremely common one, and it is worth naming because the alternative is an extra with a clear label. The same pattern shows up elsewhere in the file: an HTML parser is required for parsing, and a protocol adapter is required for talking to external tool servers. Those two are defensible as core, the PDF one is not, and the comment is honest enough that a reader can see the distinction for themselves.

## The URL policy module is the security surface, and its reasons are written down

Two requirement comments point at the same module by path, and that module is where a careful reader should spend time. It implements a policy for outbound URLs, and the text-fetching helper is built on top of it. The checks involve domain policy and hostname canonicalisation using the internationalised domain rules, and one comment notes that the URL type is used to attach a redacted request record to a translated error, which is what you want when an error message would otherwise echo a full request. The environment defaults point the same way: the server connection is plain HTTP, both hosts default to the loopback address, and the only variable documented for cloud use is the one you set to all interfaces to allow external access. Nothing here is enabled by accident, and the defaults are local-only.

## The hosted demo is bring your own key on a different domain

Near the top of the page there is an invitation to try the thing with no installation, and a note underneath that qualifies it: the instance is bring your own key, so a key from one of three model providers is required. That is the right way to run a public demo, since the operator is not paying for inference, and it also means the demo is not a zero-configuration experience despite the wording above it. Two domains are in play for one project, with the homepage field pointing at a documentation site on one and the demo hosted on another, which is normal for a company with a products domain and a lab domain but worth noting when you are following a link. The feature list names four provider families as compatible, while the environment template carries five key variables, four of them commented with where to obtain the key and one of those noting an extra provider library has to be installed separately.

## The protocol behind adaptive delegation cites a 1998 archive entry

One feature bullet is named for an adaptive communication protocol and links to an archive identifier from the late nineties, and the acronym is never expanded in the visible text. That may well be correct, since the linked work is old and foundational, but it means a reader evaluating the delegation mechanism is sent to a document older than most of the frameworks in the comparison, and the name of the protocol in the bullet is not the name in the citation. The rest of the feature list is more concrete. There is a meta-agent that takes a description of a use case in plain language and generates a new agent network, shipped as an example, which is the one place where a system both demonstrates and uses its own capability. The published example networks are that designer plus three verticals: an airline policy assistant, a banking operations and compliance workflow, and a consumer goods analysis, with more listed in a document rather than on the page.

## Conclusion

Use this studio if your team includes people who will not write Python and you need agent networks described in a configuration file they can read, since that is the premise the whole project rests on. Four things to check before you run it. The interpreter floor is 3.12 and the package installs four directories into the top level of your import path, which is worth knowing before you add it to a shared environment. The agent and its server talk through a file in the system temporary directory, so think about what that file contains and who can read it. One example network is responsible for a PDF library that every install needs. And a hosted instance exists that is bring your own key, on a different domain from the project's own homepage.

## FAQ

### What is neuro san?

An open-source, data-driven multi-agent orchestration framework where agent networks are defined in declarative configuration files, and where language-model agents delegate subtasks to each other through adaptive communication protocols instead of a single agent doing everything.

### What is the primary purpose of the Neuro San Studio editor?

It is a playground for that framework: ready-to-run example networks, tutorials and tools for designing, testing and deploying agent networks, aimed at researchers, developers and domain experts who want to configure agents without writing code.

### What is neuro san studio?

A hands-on studio built on the Neuro SAN framework, distributed as a Python package with a command line entry point registered under two names, and offered as a hosted bring-your-own-key instance as well as something you run yourself.

## Sources

- [cognizant-ai-lab/neuro-san-studio on GitHub](https://github.com/cognizant-ai-lab/neuro-san-studio)
- [License: Apache-2.0](https://github.com/cognizant-ai-lab/neuro-san-studio/blob/main/LICENSE)
- [Project website](https://decisionai.ml/neuro-san)
- [README](https://github.com/cognizant-ai-lab/neuro-san-studio/blob/main/README.md)
- [Releases](https://github.com/cognizant-ai-lab/neuro-san-studio/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cognizant-ai-lab-neuro-san-studio