How to Tame the AI Agent Zoo with Nasiko

When you run a single Python agent for testing, everything works predictably. Add a second one in TypeScript, a third in Go, and the headaches begin. Agents start calling each other directly, API keys for models scatter across configs and logs, and when a dialog loops, tokens fly away by the thousands in a couple of minutes.

The Nasiko-Labs team tackled this the way network engineers approach microservices. The Nasiko project serves as a unified control-plane for agents, handling routing, authorization, infinite loop protection, and telemetry collection. The agents themselves are isolated from the outside world and communicate strictly through the A2A specification (Agent-to-Agent v1.0).

What this platform can do

The entire system is designed around the idea of a single entry point. Agents physically don't accept incoming connections from outside. Every inter-agent request passes through the server, where access rules are checked and limits are deducted.

Smart call routing

The client or calling agent doesn't need to know the specific ID of the target service. Inside Nasiko, a three-stage pipeline selects the executor. First, the system filters candidates by vector similarity of descriptions, then re-ranks them based on the current dialog context, and a separate lightweight LLM makes the final choice.

Secure key handling and LLM Router

Instead of hardcoding OPENAI_API_KEY into environment variables of each container, agents are issued an internal address OPENAI_BASE_URL and a short-lived token. The internal proxy router substitutes the correct provider key on the fly. Secrets never end up in logs or container code.

Protection against infinite loops and cascades

If two agents decide to endlessly ping-pong each other, the token balance quickly hits zero. Nasiko keeps counters in Redis for call graph depth, branching limits, timeouts, and per-session token budgets. As soon as the chain depth exceeds the set threshold, the server aborts execution.

MCP protocol tool gateway

For connecting external tools, there's a built-in MCP Gateway. It aggregates connectors (for example, Composio or custom MCP servers) and provides agents with a single URL for function calls with per-agent access control.

Architecture and stack

The backend is written in Rust and compiles into a single binary using the Axum framework. Proven components are used for state storage:

• PostgreSQL stores users, agent configurations, and encrypted secrets (AES-256-GCM).
• Redis handles call counters and cycle protection.
• The built-in OCI registry stores container images in S3-compatible storage.
• The OpenTelemetry, Tempo, and Loki stack collects distributed traces and logs for each step.

Any request between agents becomes an OTel span. The dashboard immediately shows how many tokens went to a specific step and how much the call cost in cents.

Quick start with Docker

To spin up the entire stack, no knowledge of Rust is required. You only need Docker Engine with the Compose V2 plugin.

First, clone the repository and create the environment file:

git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env

In .env, you must specify your OpenAI key and the admin password:

OPENAI_API_KEY=sk-...
ADMIN_PASSWORD=strong_password_here

After that, bring up the infrastructure:

docker compose up -d

The first startup will take a few minutes, as the Rust server compiles inside the container. The control panel will be available at http://localhost:8080.

Working via CLI

For developers, there's a console utility nasiko. It's installed via Cargo:

cargo install --path cli/

Creating and launching a new agent takes four commands:

# Подключаемся к локальному кластеру
nasiko connect http://localhost:8080
nasiko auth login

# Создаем проект из шаблона
nasiko new openai assistant-bot
cd assistant-bot

# Собираем и деплоим
nasiko deploy .

# Проверяем работу в чате
nasiko chat --agent assistant-bot "Привет, чем ты можешь помочь?"

The deploy command automatically builds the container, pushes it to Nasiko's built-in registry, and registers the agent with the router.

Where this comes in handy

The project is aimed at teams that have outgrown simple LangChain scripts and are building production systems from dozens of specialized agents.

Here are typical scenarios where Nasiko saves time:

1. Multi-agent pipelines where agents are written by different teams in different languages (Python, Node.js, Go).
2. Systems with strict security requirements where production API keys cannot be handed out to external execution environments.
3. Monitoring LLM costs per specific tasks and users without manual log parsing.

Bottom line

Nasiko looks like a mature attempt to package the networking layer and observability of multi-agent systems into one compact tool. There's no attempt to force a custom DSL for writing prompts: you're free to write logic in any framework, as long as you support the A2A v1.0 specification.

If you're tired of manually wiring together agent microservices and counting tokens across fragmented OpenAI and Anthropic dashboards, the project is definitely worth running locally and trying out. For production, keep in mind the tight coupling to the Docker runtime in the open-source version, but for local development and internal staging environments, it's already a viable option.