← Blog
· OLAV Team

OLAV v0.12 → v0.13: From Platform Foundation to Autonomous Infrastructure

Two releases that transform OLAV from a network query tool into a full infrastructure automation platform — schema-aware API integration, environment-aware script generation, and a 7-layer security model.

release devops infra netops architecture security

Two releases. One architectural leap.

OLAV v0.12.0 laid the platform foundation — service registry, tool isolation, Docker lifecycle, multi-user audit. v0.13.0 built the intelligence layer on top — schema-aware API integration, environment-aware script generation, and a graduated security model that lets AI agents read freely but write only under strict human supervision.

v0.12.0: The Platform Layer

Service Registry Without MCP

Every external service (NetBox, InfluxDB, ContainerLab) now registers through a single command:

olav registry register http://netbox:8000

This parses the OpenAPI schema, generates a condensed API reference, and makes the service immediately queryable. No Python code generation, no MCP server processes, no runtime complexity.

Tool Isolation

Before v0.12, subagents inherited every tool from the parent — including tools they shouldn’t have. We implemented olav_delegate() with CompiledSubAgent, ensuring each agent only sees the tools declared in its SKILL.md. The lab agent can’t accidentally SSH to production. The analysis agent can’t access the network.

Docker Full Lifecycle + Multi-User Audit

deploy_service, stop_service, list_services — native Docker Compose management. Combined with short-lived DuckDB connections and exponential backoff, five concurrent olav processes can now write audit data without conflicts.

v0.13.0: The Intelligence Layer

Infra Agent: One Tool Replaces Twelve

The old architecture generated 12+ Python tool files per API service. The new infra agent uses a single api_request tool to query any registered service:

olav --agent infra "How many devices are in NetBox? List them with site and role."
# → api_request(service="netbox", path="/api/dcim/devices/", page_size=-1)
# → 6 devices: R1 (DC1, Router), R2 (DC1, Router)...

olav --agent infra "Compare devices in OLAV database vs NetBox — are they in sync?"
# → execute_sql (local DB) + api_request (NetBox API)
# → Cross-source comparison with per-device diff

DevOps Agent: Scripts For Your Actual Infrastructure

The headline feature. When you ask the DevOps agent for a script, it doesn’t give you a template with YOUR_API_KEY_HERE. It queries your database first:

olav --agent devops "Write a script to backup running-config from all routers"

The agent discovers you have R1 (192.168.100.101, Juniper Junos), R2-R4 (Cisco IOS), SW1-SW2 (Cisco IOS). The generated 158-line bash script includes:

Exported to exports/scripts/backup-running-configs.sh. Not chat text — a real, executable file.

7-Layer Write Security

Write operations follow a graduated model — because HITL alone is a rubber stamp if the user can’t see what’s about to change:

LayerDefenseBypassable?
--enable-api-writeDefault lockedNo
services.yaml readonly_onlyPer-service controlConfig only
Dry-run simulationMust pass before approvalNo
HITL approvalUser sees diff, confirmsNot skippable
sandbox_guard hard_blockHTTP writes in isolated sandboxNot skippable
unshare --netKernel network isolationNot skippable
Audit trailEvery api_request logged

The key: --dangerously-skip-permissions bypasses tool approval for testing, but cannot bypass API write approval. Network devices are always read-only — no equivalent of --enable-api-write for SSH.

What We Removed

The 8-tool Creator Agent, 12+ _generated/ Python files, 4 redundant NetBox/InfluxDB workspaces — all gone. Service onboarding is one CLI command. Script generation is natural language. The codebase is smaller and the architecture is cleaner.

Architecture

olav v0.13 (pip)                    olav-netops v0.13 (GitHub)
├── quick  (fast queries)           ├── ops orchestrator
├── infra  (API read + write)       │   ├── analysis (Dijkstra + ECMP)
├── devops (script generation)      │   ├── probe (parallel SSH)
├── audit  (compliance reports)     │   ├── diff (snapshot drift)
├── config (platform management)    │   └── lab (ContainerLab digital twin)
└── core   (tools layer)            └── netops.* (tables + collection)

By the Numbers

MetricValue
Tests passing1,358 (1,269 + 89)
DDD claims verified44
Issues closed62+
Doc pages28 (EN + ZH)
Audit messages (training data)7,650