Neuro AI Multi-Agent Accelerator
May 21, 2026 · View on GitHub
Welcome to the Neuro AI Multi-Agent Accelerator tutorial. In this guide, we will walk you through the process of
setting up a Data-Driven Multi-Agent Network using the neuro-san library, managing it via web-based clients,
and customizing how Large Language Model (LLM) based Agents coordinate with each other to solve tasks. We will also
explore switching LLM providers (like Ollama and Anthropic), adding custom-coded Tools, and running everything from a
single command.
Table of Contents
- Neuro AI Multi-Agent Accelerator – Getting Started
- Table of Contents
- 1. Introduction
- 2. Project Structure
- 3. Setting Up a Working Python Environment
- 4. What is an LLM-based Agent?
- 5. Creating an Agent Network from Scratch
- 6. How to Switch LLMs in the Agent Network
- 7. How to use tools in Neuro-San
- 8. How to Add Middleware to an Agent
- 9. How to Access the Logs
- 10. How to Stop the servers
- 11. Key Aspects of Neuro AI Multi-Agent Accelerator
- 12. End Notes
1. Introduction
Neuro-San is a multi-agent orchestration library that enables you to build data-driven agent networks. These networks of agents can use LLMs (Large Language Models) and coded tools to coordinate and solve complex tasks autonomously.
Users can interact with these multi-agent networks through web-based clients:
nsflow or MAUI.
This entire setup is easily configurable using HOCON (.hocon) files.
Note: This tutorial is written with the help of the agent network example advanced_calculator.hocon.
2. Project Structure
Below is a simplified view of the reference project structure. You can adapt it to your needs.
.
├── coded_tools
│ └── basic
│ └── advanced_calculator
│ └── calculator_tool.py
├── logs
│ ├── client.log
│ └── server.log
├── neuro_san_studio
│ └── run.py
├── registries
│ ├── basic
│ │ └── advanced_calculator.hocon
│ └── manifest.hocon
├── README.md
└── requirements.txt
Key directories and files
coded_tools/: Contains custom-coded tool classes (e.g.,calculator_tool.py).logs/: Where client and server logs are written.neuro_san_studio/commands/run.py: A starter script to run the server and the web client.registries/: Holds.hoconfiles that define multi-agent networks and their configurations.
Here are the detailed instructions to run an agent network along with a web client.
3. Setting Up a Working Python Environment
Follow these steps to set up and activate your Python virtual environment:
# 1) Clone your project repository (if applicable)
git clone https://github.com/cognizant-ai-lab/neuro-san-studio
cd neuro-san-studio
# 2) Create a dedicated Python virtual environment
python -m venv venv
# 3) Activate it
# For Windows
.\venv\Scripts\activate && set PYTHONPATH=%cd%
# For Mac/Linux
source venv/bin/activate && export PYTHONPATH=`pwd`
# 4) Install the required Python packages.
pip install -r requirements.txt
Please find the detailed instructions to run an agent network along with a web client.
Note: You may need to adapt the filenames if versions differ.
4. What is an LLM-based Agent?
An LLM-based Agent is a component in your agent network that uses a Large Language Model to process instructions
and make decisions. By embedding the agent’s logic in a data-driven configuration (the .hocon file), you can define:
- Agent roles and responsibilities
- Tools (or other agents) it can call
- Function schema that the agent can handle
Agents for Autonomous Decision Making
These agents can coordinate tasks among themselves. A top-level (or front-man) agent can receive a user’s query, figure out which sub-agents (or tools) are best suited to answer it, and orchestrate the communication necessary to generate a response.
Function Calling with Agents
In Neuro AI Multi-Agent Accelerator, Agents may declare a function with defined parameters. Other agents can call this function by providing the required parameters. This allows complex tasks to be broken into sub-tasks, each handled by specialized agents or tools.
Note: Refer to this OpenAI blog and OpenAI Cookbook for more information.
Data-Driven Agent Network
A Data-Driven Agent Network is composed of multiple agents defined in a .hocon file. This file describes:
- LLM configuration: which model to use, how to connect to it, etc.
- Agent definitions: including instructions, roles, domain knowledge, and which tools/agents they can call.
- Tools: references to Coded Tools that contain Python functions or classes.
5. Creating an Agent Network from Scratch
Single Agent Network Example
Let’s start simple. We’ll build a minimal .hocon file containing only one agent – the Math Geek. This will show how to
run a single-agent network that can handle basic math operations (though it won’t actually do the math by itself unless
you also link to or embed the coded tool).
Step 1: Create a file registries/single_agent_example.hocon
{
"llm_config": {
"model_name": "llama3.1",
},
"commondefs": {
"replacement_strings": {
"instructions_prefix": """
You are responsible for a segment of a problem.
Only answer inquiries that are directly within your domain.
""",
"aaosa_instructions": """
When you receive an inquiry:
0. If you are clearly not the right agent...
1. Always call your tools...
2. ...
"""
},
"replacement_values": {}
},
"tools": [
{
"name": "Math Geek",
"function": {
"description": "I can help you to do quick calculations."
},
"instructions": """
{instructions_prefix}
Your name is `Math Geek`.
You are the top-level agent for mathematics.
{aaosa_instructions}
- Only handle calculation related inquiries.
""",
"tools": []
}
]
}
Note: You can also automatically create simple agent networks using our example agent_network_designer agent network (see: agent_network_designer.md)
Step 2: Run the server with this .hocon file. You can do so by
# Make sure your venv is active
export AGENT_MANIFEST_FILE="./registries/manifest.hocon"
export AGENT_TOOL_PATH="./coded_tools"
python -m neuro_san_studio run
Since this agent has no further sub-agents or coded tools, it will simply respond to queries but won’t be able to do actual calculations. It is functionally incomplete, but demonstrates a minimal single-agent network.
Multi-Agent Network Example
Let’s take a look at a more robust multi-agent network file: advanced_calculator.hocon. Below is a simplified variant
with two agents: Math Geek and problem_formulator, plus a coded tool named CalculatorTool.
{
"llm_config": {
"model_name": "llama3.1",
},
"commondefs": {
"replacement_strings": {
"instructions_prefix": """
You are responsible for a segment of a problem...
""",
"aaosa_instructions": """
When you receive an inquiry:
0. If you are clearly not the right agent...
1. Always call your tools...
...
"""
},
"replacement_values": {}
},
"tools": [
{
"name": "Math Geek",
"function": {
"description": "I can help you to do quick calculations."
},
"instructions": """
{instructions_prefix}
Your name is `Math Geek`.
You are the top-level agent for the mathematics system.
{aaosa_instructions}
""",
"tools": ["problem_formulator"]
},
{
"name": "problem_formulator",
"function": {
"description": "Convert a math problem into a sequence of known operations.",
"parameters": {
"type": "object",
"properties": {
"inquiry": { "type": "string" }
},
"required": ["inquiry"]
}
},
"instructions": """
Your name is `Problem Formulator`.
You will be handed a math problem and parse it into a known sequence of operations...
""",
"command": """
- Identify operations and operands
- Call the CalculatorTool
""",
"tools": ["CalculatorTool"]
},
{
"name": "CalculatorTool",
"function": {
"description": "Solve the math operations",
"parameters": {
"type": "object",
"properties": {
"operation": { "type": "string" },
"operands": {
"type": "array",
"items": { "type": "float" }
}
},
"required": ["operation", "operands"]
}
},
"class": "calculator_tool.CalculatorCodedTool",
"command": "Perform the calculation."
}
]
}
A few points to note about multi-agent networks:
- The snippet above is intentionally simplified. The actual
advanced_calculator.hoconis more verbose and includes more detail (you can see the full example provided in this tutorial’s introduction). - The relationship between different agents can be defined in the hocon file itself. The down-chain agents can be
defined in the
toolssection of each agent definition in a parent-child style. For example theMath Geekagent has access to theproblem_formulatoragent and theproblem_formulatoragent has access to the calculator agent via '"tools": ["CalculatorTool"] - It is possible to have the same down-chain agent available for several other agents at the same time.
- Defining an agent network is highly flexible. We can define all sort of networks: Single Agent Network, Hierarchical Agent Network, DAG oriented Network, Single Agent with Coded Tools, Multiple Agents with Multiple Coded Tools.
LLM Config
LLM configurations is a way to tell the agents which LLM (Large Language Model) to use in order to process a query sent to it.
- LLM config is defined on top of the hocon file which implies that the same config is accessible to all the agents in the network by default.
- It is possible to keep the default config and have separate config for each agent in the network. This means an agent that does not have a defined config always uses the default llm_config defined on top of the hocon file.
- It is possible to have different LLMs for each of our agents for example, we can use
gpt-4ofor the front-man agentMath Geekandllama3.1for theproblem_formulator. Here is the hocon example to show that:
{
"llm_config": {
"model_name": "gpt-4o",
},
"commondefs": {
"replacement_strings": {
"instructions_prefix": """
You are responsible for a segment of a problem...
""",
"aaosa_instructions": """
When you receive an inquiry:
0. If you are clearly not the right agent...
1. Always call your tools...
...
"""
},
"replacement_values": {}
},
"tools": [
{
"name": "Math Geek",
"function": {
"description": "I can help you to do quick calculations."
},
"instructions": """
{instructions_prefix}
Your name is `Math Geek`.
You are the top-level agent for the mathematics system.
{aaosa_instructions}
""",
"tools": ["problem_formulator"]
},
{
"name": "problem_formulator",
"llm_config": {
"model_name": "llama3.1",
},
"function": {
"description": "Convert a math problem into a sequence of known operations.",
"parameters": {
"type": "object",
"properties": {
"inquiry": { "type": "string" }
},
"required": ["inquiry"]
}
},
"instructions": """
Your name is `Problem Formulator`.
You will be handed a math problem and parse it into a known sequence of operations...
""",
"command": """
- Identify operations and operands
- Call the CalculatorTool
"""
},
]
}
Notes on llm_config
- The llm_config uses
model_nameas a parameter. We can use these models with openai, azure, ollama, anthropic and nvidia as a provider. - Here is a list of supported LLMs that can be used as
model_nameas of 26-Feb-2025:- OpenAI: ['gpt-3.5-turbo', 'gpt-3.5-turbo-16k', 'gpt-4o', 'gpt-4o-mini', 'gpt-4-turbo', 'gpt-4-turbo-preview', 'gpt-4-1106-preview', 'gpt-4-vision-preview', 'gpt-4', 'gpt-4-32k']
- AzureChatOpenAI: ['azure-gpt-3.5-turbo', 'azure-gpt-4']
- Anthropic: ['claude-3-haiku', 'claude-3-sonnet', 'claude-3-opus', 'claude-2.1', 'claude-2.0', 'claude-instant-1.2']
- Ollama: ['llama2', 'llama3', 'llama3.1', 'llama3:70b', 'llava', 'mistral', 'mistral-nemo', 'mixtral', 'qwen2.5:14b', 'deepseek-r1:14b']
- ChatNvidia: ['nvidia-llama-3.1-405b-instruct', 'nvidia-llama-3.3-70b-instruct', 'nvidia-deepseek-r1']
- Note that not all of these LLMs support function-calling, it is advisable to read the documentation before using any of the LLMs.
- Each of these LLMs have several config params. Some of the common config parameters are:
model_name,temperature,max_tokens. - For the available configuration parameters of the above chat models, please refer to Langchain Chat Models and their respective documentation
Running the multi-agent network
export AGENT_MANIFEST_FILE="./registries/manifest.hocon"
export AGENT_TOOL_PATH="./coded_tools"
python -m neuro_san_studio run
Now, the top-level Math Geek agent will parse user queries, pass them to problem_formulator, which in turn calls the CalculatorTool. The final answer is then relayed back to the user.
6. How to Switch LLMs in the Agent Network
Because Neuro AI Multi-Agent Accelerator uses neuro-san, it is LLM-agnostic, you can switch to different models or
providers by changing the model_name of llm_config in your .hocon file.
"llm_config": {
"model_name": "<your_model>",
# Replace with the name of the model you want to use
# You can also specify other fields, like temperature, max_tokens, etc.
}
Available Models and Preset Parameters
All available models and their corresponding providers are defined in the default LLM info file.
Each entry includes preset parameters that determine how the model should be used, such as token limits or default temperature values.
If needed, you can override these preset values directly in your llm_config.
For more information on customizing or extending available models, refer to:
- Using Custom or Non-Default LLMs
- LangChain Chat Model Integration for provider-specific parameter options
API Keys & Environment Variables
For most cloud-based providers (e.g. OpenAI, Anthropic, Azure), you’ll need to set the appropriate environment variables in your shell or .env file. Common examples include:
OPENAI_API_KEYANTHROPIC_API_KEYAZURE_OPENAI_ENDPOINT
More details can be found in the following resources:
- User Guide: LLM Configuration
- API Key Documentation
- .env.example
- LLM Info HOCON Reference Guide
- Agent HOCON Reference Guide
Using Local LLMs via Ollama
To use a locally hosted LLM with Ollama, follow the instructions in the Ollama section of the user guide. These models can be configured in the same way, provided they are correctly installed and running locally.
7. How to use tools in Neuro-San
Neuro-San supports two types of tools that agents can call during execution:
- Custom Tools – Built using Neuro-San’s
CodedToolinterface. These allow you to define your own logic in Python and integrate it with the agent. - Prebuilt Tools (via toolbox) – Tools that are already implemented and configured for reuse. These include:
LangChain’s BaseTool implementations (e.g., tavily_search, requests_get)
Shared CodedTool implementations that are registered in the toolbox config file
Use Custom Tools when your application needs behavior that isn't covered by the prebuilt options — such as accessing APIs, performing custom calculations, or interacting with internal systems.
Custom Tools
In Neuro-San, custom tool integration is done through Coded Tools — Python class that implement the CodedTool interface.
These tools allow agents to perform specialized operations like API calls, database queries, or computations that go beyond the LLM’s native capabilities.
To integrate a custom tool, you must define it in both HOCON and python files:
- Agent Network (HOCON) – for configuration and orchestration
- Python (Coded Tool) – for actual implementation
Defining Functions in Agent Network (HOCON)
Each tool must define a function block, and reference a Python class.
The LLM provides values for inputs defined in
function.parameters.
However, users can manually provide additional arguments using theargsfield.
functiondescription: Describes when and how to use the tool.parameters: Defines input arguments. Optional if no parameters are required.
class- Python class reference in
module.Classformat.
- Python class reference in
args- User-specified arguments that override or supplement LLM inputs. Optional.
Schema of Parameters
Neuro-San supports the following data types:
string, int, float, boolean, array (list), object (dict)
arraymust include anitemsfield to define the element typeobjectmust include apropertiesfield- The top-level
parametersmust always be anobject
| Field | Description |
|---|---|
type | Must be object |
properties | Dict of argument names → each has a type and description |
required | List of required argument names |
Defining Tool in Python (Coded Tool)
- Inherit from
CodedTool - Implement either
invokeorasync_invokeNeuro-San prefers
async_invoke, and falls back toinvokeif unavailable - Access LLM and user-provided arguments via
args
Tool Path
-
The tool's path can be set via the environment variable:
AGENT_TOOL_PATH -
If not set, the default path is:
neuro_san/coded_tools -
A tool module placed in a folder that matches the HOCON file name (excluding
.hocon) will be scoped only to that specific agent network. -
To reuse a tool across multiple networks, place its module directly in the configured tool path (
AGENT_TOOL_PATH). -
This allows you to choose between:
- Local tools tied to one agent network, and
- Shared tools accessible by multiple networks.
Example 1: Tool with parameters
HOCON
{
"llm_config": {
"model_name": "gpt-4o"
},
"tools": [
{
"name": "weather_agent",
"instructions": "Use your tool to provide weather report to the user.",
"tools": ["get_weather"]
},
{
"name": "get_weather",
"function": {
"description": "Provide weather at a given location.",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "Location to provide weather for"
}
},
"required": ["location"]
}
},
"args": {
"current_weather": "cloudy"
},
"class": "weather_tool.WeatherTool"
}
]
}
Python
class WeatherTool(CodedTool):
def invoke(self, args: Dict[str, Any], sly_data: Dict[str, Any]):
location = args.get("location")
current_weather = args.get("current_weather")
if current_weather:
return f"It is {current_weather} in {location}."
return f"It is always sunny in {location}."
Example 2: Tool with no parameters
HOCON (with no parameters)
{
"llm_config": {
"model_name": "gpt-4o"
},
"tools": [
{
"name": "datetime_agent",
"instructions": "Use your tool to provide current date and time.",
"tools": ["current_date_time"]
},
{
"name": "current_date_time",
"function": {
"description": "Return current date and time."
},
"class": "date_time.DateTime"
}
]
}
Python (with no parameters)
class DateTime(CodedTool):
def invoke(self, args: Dict[str, Any], sly_data: Dict[str, Any]):
# Get current UTC time
now = datetime.now(timezone.utc)
return str(now)
Prebuilt Tools (via Toolbox)
Neuro-San includes a powerful Toolbox system that allows you to reuse existing tools across agent networks without redefining them every time.
These tools are already integrated and can be plugged into agents directly via configuration.
Toolbox tools come in two forms:
-
LangChain Tools – Built-in tools like tavily_search, requests_get, etc., implemented using LangChain’s BaseTool.
-
Shared Coded Tools – Predefined tools using the CodedTool interface (Python classes) that are already available and registered in your Toolbox config.
These are called prebuilt because you can use them right away without defining their logic or schema again in the agent network config.
Using Toolbox Tools in Agent Network
To use any tool from the Toolbox, simply reference it in the toolbox field of your agent config:
{
"name": "search_agent",
"instructions": "Use web search to find information for the user.",
"toolbox": "tavily_search"
}
You do not need to define function, parameters, or class for toolbox tools — that information is already
included in the langchain tools class or the Toolbox config file.
Toolbox Configuration
Toolbox tools are defined in a centralized configuration file. This file includes definitions for both LangChain tools and shared coded tools. If the tool is defined in the toolbox config, you don’t need to redefine it in the agent network — just reference it by name.
LangChain Example
"tavily_search": {
"class": "langchain_community.tools.tavily_search.TavilySearchResults",
"args": {
"api_wrapper": {
"class": "langchain_community.utilities.tavily_search.TavilySearchAPIWrapper"
}
}
}
Coded Tool Example
"rag_retriever": {
"class": "rag.Rag",
"description": "Retrieve information on the given urls",
"parameters": {
"type": "object",
"properties": {
"urls": { "type": "array", "items": { "type": "string" } },
"query": { "type": "string" }
},
"required": ["urls", "query"]
}
}
Extending the Toolbox
If you want to add your own tools to the Toolbox (so they can be reused easily):
-
For coded tools: Implement your tool in Python using the
CodedToolinterface. -
Add your tool to a config file: Define an entry in your custom toolbox info file, following the structure shown in the previous examples.
-
Register the config file by one of the following methods:
- Set the
toolbox_info_filekey - Use the
AGENT_TOOLBOX_INFO_FILEenvironment variable
- Set the
This setup allows you to introduce custom tools without modifying the built-in toolbox definitions.
See also
- Toolbox section of the user guide
- Toolbox Info HOCON File Reference documentation
8. How to Add Middleware to an Agent
What is Middleware?
Middleware lets you inject custom code at key points during an agent's execution — without modifying the agent's instructions or tools. This is useful for cross-cutting concerns such as:
- PII detection and redaction – scrub sensitive data before it reaches the LLM or after it is returned
- Logging and auditing – record inputs and outputs for compliance or debugging
- Input/output transformation – reformat or enrich data flowing through the agent
A middleware hooks into six points of the agent lifecycle:
Note: The asynchronous variants (
abefore_agent, etc.) are preferred in the Neuro SAN server environment.
| Hook | When it runs |
|---|---|
abefore_agent() | Before the agent execution starts |
aafter_agent() | After the agent execution completes |
abefore_model() | Before each LLM call |
aafter_model() | After each LLM call |
awrap_model_call() | intercept and control async model execution |
awrap_tool_call() | intercept and control async tool execution |
Adding Middleware in HOCON
Middleware is configured per agent using the middleware key, which takes a list of middleware definitions.
Each definition requires a class field (the fully-qualified middleware class name) and an optional args
dictionary for constructor arguments.
Here is a complete example based on pii_middleware.hocon.
The prankster agent uses PIIMiddleware to detect and redact phone numbers:
{
"llm_config": {
"model_name": "gpt-5.2"
},
"tools": [
{
"name": "prankster",
"function": {
"description": "Send me a phone number and I will leave a message on its voicemail for you.",
"parameters": {
"phone_number": {
"type": "string",
"description": "The phone number to send the message to."
},
"message": {
"type": "string",
"description": "The message to send to the phone number."
}
}
},
"instructions": """
You are an impotent wannabe prank caller.
Always respond by telling the user that the message was left at the phone number you received,
but you will actually do nothing with the message.
""",
"tools": [],
"middleware": [
{
"class": "langchain.agents.middleware.PIIMiddleware",
"args": {
"pii_type": "phone_number",
"detector": "[a-zA-Z0-9]{3}-[a-zA-Z0-9]{4}",
"strategy": "redact",
"apply_to_output": true
}
}
]
}
]
}
The args values depend on the constructor signature of the middleware class you are using.
The framework will also automatically populate the following special args if they appear in the
constructor signature:
origin– a list of dictionaries describing the agent's position in the network hierarchyorigin_str– a string representation oforiginsly_data– the shared data dictionary available to all middleware and coded tools for the request
Multiple Middleware
You can apply more than one middleware to an agent by listing them in order. They are applied sequentially, so order matters:
"middleware": [
{
"class": "my_package.LoggingMiddleware",
"args": { "log_level": "INFO" }
},
{
"class": "langchain.agents.middleware.PIIMiddleware",
"args": {
"pii_type": "email",
"strategy": "redact",
"apply_to_output": true
}
}
]
For more details, see the Middleware section of the user guide.
Using Agent Skills Middleware
AgentSkillsMiddleware is a built-in middleware that lets an agent draw on a library of skills
— reusable instruction sets stored as SKILL.md files — without injecting all of their content
into the prompt at once. This is useful when an agent needs to follow domain-specific workflows
(writing, analysis, coding patterns, etc.) that would be too large to embed directly in instructions.
The middleware eagerly loads and caches the full contents of each configured SKILL.md, but only
injects lightweight metadata or summaries into the agent’s context initially. When the agent calls
a skill tool, the tool returns the cached full content for the selected skill (and can load any
additional resources if requested). This pattern of revealing only what is needed in the prompt is
called progressive disclosure.
Local skill source
Point skill_sources at a local directory containing a SKILL.md file:
{
"name": "name_assistant",
"function": {
"description": "I can help with name-related inquiries."
},
"instructions": "You are a name assistant that provides career information based on user's name.",
"middleware": [
{
"class": "middleware.agent_skills_middleware.AgentSkillsMiddleware",
"args": {
"skill_sources": ["skills/tests/job_guessing"],
"keep_skill_in_context": true
}
}
]
}
See job_guessing_skill.hocon for the full example.
Remote skill source
skill_sources also accepts URLs. The middleware will fetch SKILL.md over HTTP:
"args": {
"skill_sources": ["https://raw.githubusercontent.com/anthropics/skills/main/skills/internal-comms/"],
"keep_skill_in_context": true,
"http_timeout": 30.0
}
See internal_communication_skill.hocon for the full example.
⚠️ Security note: Always review skills from the internet before use. They may contain malicious scripts or instructions that reference tools or resources not available in your environment.
Tools in Skills Middleware
Once configured, the middleware automatically registers three tools the agent can call:
get_full_skill_content— loads the completeSKILL.mdfor a named skillload_skill_resource_local— loads a supplementary file from a local skill directoryload_skill_resource_remote— loads a supplementary file from a remote skill URL
Security: All three tools restrict file and URL access to paths and URLs whose prefixes fall under the configured
skill_sourcesentries. Requests outside those configured prefixes are rejected, which helps mitigate SSRF and data exfiltration risks but does not guarantee complete protection in all scenarios.
For more details, see the Agent Skills Middleware section of the user guide.
9. How to Access the Logs
By default, when you run:
python -m neuro_san_studio run
- The server logs go to logs/server.log.
- The client (web UI) logs go to logs/client.log.
Additionally, you will see logs on your terminal. Checking these files is useful for:
- Debugging agent interactions
- Viewing any errors or exceptions
- Auditing how the queries are being orchestrated
10. How to Stop the servers
When you are running the server in the foreground (via python -m neuro_san_studio run), simply press:
CTRL + Con Windows/Mac/Linux terminals- This will terminate both the nsflow client and the
neuro_sanserver gracefully.
If you launched them separately, you would stop each process individually (again by CTRL + C or sending a kill signal).
11. Key Aspects of Neuro AI Multi-Agent Accelerator
- Flexibility of Use: Define any agent network structure using
.hoconfiles, easily adjustable for different use cases and tasks. - LLM Agnostic: Swap between OpenAI, Anthropic, Ollama, Azure, or your own custom model endpoints with minimal configuration changes.
- Cloud Agnostic: Host your solutions on any cloud or on-prem python environment.
- Tool/Function Calling: Agents can systematically call coded tools or other sub-agents, enabling powerful, modular, and autonomous decision workflows.
- Hierarchical Agent Networks: You can create nested agent networks to handle complex tasks in a structured manner.
12. End Notes
You’ve now seen how to:
- Set up a Python environment and install the requirements.
- Create single-agent and multi-agent networks in
.hoconfiles. - Switch LLM providers (e.g., Ollama, Anthropic, OpenAI).
- Add coded tools to expand agent capabilities.
- Run the server and Flask client.
- Check logs and stop the server.
Feel free to be creative, explore adding more complex agents, linking them in various ways, or building advanced coded tools. We hope you find Neuro AI Multi-Agent Accelerator intuitive, powerful, and adaptable to your needs.