Nasiko Agent Control Plane
A self-hosted control plane for deploying, routing, gatewaying, and observing containerized AI agents.
Per-dimension scores and reasoning
Evidence: README describes role-based auth (RBAC), JWT, and GitHub OAuth, but lacks permission model details and user confirmation mechanisms. Data flow diagrams show request routing and observability, but data flow transparency is not explicit. Sensitive data handling mentions encryption keys and passwords, but storage and access controls are not detailed. Dependency security: pyproject.toml lists many dependencies, but no vulnerability scanning or lock files. External effects: deployment and routing are described, but external side effects are not explicit. Rollback: hot deployment and rollback are mentioned, but no concrete mechanism. Source attribution: no contributor guidelines or attribution policy. Deductions: unclear permission model, missing user confirmation, insufficient data flow transparency, missing sensitive data handling details, unverified dependency security, unclear external effects, unspecified rollback mechanism, and missing source attribution.
Evidence: README and test files are mostly consistent in architecture description, but test files reference data files not included in the source (e.g., agent_cards, registries.json), causing self-consistency issues. Dependency availability: dependencies are listed, but no lock files or version pinning strategy. Failure messages: error handling exists in test code, but no user-facing failure messages. Deductions: missing test data, missing dependency locking, and failure messages not user-facing.
Evidence: README clearly identifies target audience (developers) and multiple scenarios (local dev, production, CLI, Web UI). Capability boundaries: core features are described, but limitations are not explicit. Trigger precision: routing system uses query analysis, but precise trigger conditions are not provided. Environment fit: Docker Compose and Kubernetes deployment options are provided, but detailed configuration instructions are missing. Deductions: unclear capability boundaries, insufficient trigger precision, and missing environment configuration details.
Evidence: README provides clear information architecture, including quick start, documentation links, and architecture diagrams. Install notes are detailed, including Docker Compose and CLI installation. Naming stability: project name and version are clear, but no naming conventions. Examples and FAQ: example agents and routing examples are provided, but no FAQ. Known limitations: none mentioned. License: Apache 2.0 provided. Versioning and changelog: no CHANGELOG or version history. Maintenance responsibility: no maintainers or contribution guidelines. Deductions: missing naming conventions, FAQ, known limitations, versioning, and maintenance responsibility.
Evidence: Output usability: CLI, Web UI, and REST API are provided with clear output formats. Marginal value: centralized management, intelligent routing, and observability provide clear value. Cost-benefit: one-command Docker Compose deployment, but no performance benchmarks or cost analysis. Deductions: cost-benefit not quantified, performance data missing.
Evidence: Claims in README (e.g., feature lists) lack specific evidence or test results. Cross-source corroboration: test files exist, but no test results or coverage. Fact-inference separation: README descriptions are mostly assertions, not distinguishing facts from inferences. Deductions: claims lack evidence, test results not provided, and facts/inferences not separated.
- Test files reference data files not included in the repository, so tests cannot be verified as runnable.
- Dependencies are not locked, posing supply chain risks.
- Permission model and user confirmation mechanisms are unclear; careful configuration is needed in production.
- No known limitations or version history provided; maintenance responsibility is unclear.
What does this agent do, and when should you use it?
Nasiko is a developer control plane for production AI-agent ecosystems built as cloud-native microservices. Its documented components include a FastAPI Backend, Router Service, Auth Service, Chat History, Kong Registry, and Kong API Gateway, with Web UI, Python CLI, and desktop application entry points. Agents are uploaded as directories or ZIP packages containing AgentCard.json, a Dockerfile, and a Python project, then accessed through Kong at /agents/{agent-name}/. The Router Service uses LangChain to analyze a query, match AgentCard capabilities, and return an agent URL with a confidence score. It supports local Docker Compose deployment and documents Kubernetes deployment on DigitalOcean or AWS using Terraform, Helm, and BuildKit.
Users can upload an agent directory with nasiko agent upload-directory ./my-agent --name my-agent or a package with nasiko agent upload-zip agent.zip --name packaged-agent. Each agent must include AgentCard.json, which declares capabilities, examples, endpoints, and protocol version; the backend passes upload processing through the Redis Stream Listener into the build system, container registry, Kubernetes deployment, and Kong registration. Requests sent to /router/route?query=... are analyzed by the Router Service with LangChain for query intent, capability matching, confidence scoring, and fallback selection, producing agent_url and confidence. Kong Gateway routes /api/, /auth/, /router/, /app/, and dynamic agent paths to their services; Phoenix records request and LLM traces, while Chat History persists and retrieves conversations.
- A platform engineer needs to register, build, and deploy internal FastAPI agents from a local Docker Compose environment.
- An operations team wants requests automatically directed to translation, compliance-checking, or GitHub-oriented agents according to AgentCard.json capabilities.
- A team needs Kong Gateway to provide a single access layer for /agents/{agent-name}/, /api/, /auth/, and /router/ routes.
- A team needs Arize Phoenix traces for agent and LLM requests alongside searchable persisted conversation history.
- An organization is preparing to deploy containerized agents to Kubernetes on DigitalOcean or AWS and build images through BuildKit.
What are this agent's strengths and limitations?
- Connects agent registration, image building, Kubernetes deployment, and automatic Kong registration in one documented deployment flow.
- Uses AgentCard.json both as an agent capability manifest and as input to LangChain-based routing that returns an explicit agent_url and confidence.
- Combines Kong, Phoenix, MongoDB, Redis, and Chat History for gatewaying, tracing, caching or sessions, and conversation persistence.
- Offers Web UI, Python CLI, and REST APIs, with documented local Docker Compose and Kubernetes deployment paths.
- Local operation depends on Docker, Docker Compose, and Python 3.12+, with 4GB+ RAM recommended.
- Agents must conform to a specific package structure with AgentCard.json, Dockerfile, and Python project configuration, so existing agents outside that format require adaptation.
- Kubernetes agent deployment depends on BuildKit; the production bootstrap also involves Terraform, Helm, a container registry, and cloud-account setup.
- Although routing supports OpenAI, MiniMax, and OpenRouter, users must configure API keys, models, and ROUTER_LLM_PROVIDER/ROUTER_LLM_MODEL.
- Repository metadata says License: NOASSERTION while the README claims Apache 2.0, so adopters should verify the actual LICENSE file and licensing status.
How do you install or deploy this agent?
Prerequisites are Docker, Docker Compose, Python 3.12+, and a recommended 4GB+ RAM. Clone and prepare the project:
git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .nasiko-local.env.example .nasiko-local.env
pip install uv
uv syncEdit .nasiko-local.env and configure USER_CREDENTIALS_ENCRYPTION_KEY for production security. OPENAI_API_KEY, MINIMAX_API_KEY, GITHUB_CLIENT_ID, and GITHUB_CLIENT_SECRET are optional. Start the platform:
docker compose -f docker-compose.local.yml --env-file .nasiko-local.env up -dVerify it with curl http://localhost:8000/api/v1/healthcheck, then open http://localhost:9100/app/.
How do you use this agent?
Set NASIKO_API_URL=http://localhost:9100, run nasiko login with the automatically generated credentials in orchestrator/superuser_credentials.json, and check nasiko status. Upload an agent directory with:
nasiko agent upload-directory ./my-agent --name my-agentThe documented structure includes AgentCard.json, Dockerfile, pyproject.toml, and src/main.py. After deployment, call an agent with:
curl -X POST http://localhost:9100/agents/my-agent/analyze -H "Content-Type: application/json" -d '{"text": "Sample document content"}'Or let the router choose an agent:
curl "http://localhost:9100/router/route?query=analyze this document"How does this agent compare with similar options?
The README positions direct service access as development-only and recommends Kong Gateway paths such as /app/ and /router/ for production access; it does not name standalone competitors for a product comparison.