01Layers
| Layer | Responsibility | Options | Guardrail role |
|---|---|---|---|
| Experience | Where people work with ODIN: a web client for operators and approvers, an on-call phone app (approval inbox, push, hands-free status), optional speech. | Any web stack; a native or cross-platform app; any speech-to-text and text-to-speech service | Clients hold no authority; everything is enforced behind them. |
| Orchestration | Sessions, routing to specialists, the nine-check tool gate, approval cards, the change path, budgets, schedules and triggers, the audit log. | Your implementation around an agent framework | The guardrails live here. |
| Agents | ODIN and its specialists: narrow roles, each with its own tier, tool servers and access, defined as configuration. | Claude Agent SDK, OpenAI Agents SDK, LangGraph or similar | No shell or file tools; only granted tools; a clean environment with no credentials. |
| Model gateway | One endpoint in front of hosted or self-hosted models: routing by tier, budgets, logging, data residency. | Hosted APIs (Anthropic, OpenAI, Azure OpenAI, Google) or self-hosted (vLLM, Ollama, TGI behind an OpenAI-compatible API) | Swappable after an evaluation; safety doesn't depend on it. |
| Tool layer | Tool servers (MCP) per system, admitted by hash, each tool classed read, write or blocked; read paths filtered and redacted. | One server per integration class | Scoped read-only tokens; guards in code. |
| Pipelines | CI (validation, twin what-if, optional emulation rehearsal) and the automation platform: the only path to the infrastructure, after approval. | GitLab CI, GitHub Actions; Ansible Automation Platform / AWX; Terraform or OpenTofu runners | Run as the pipeline's identity, with short-lived credentials from the vault. |
| Platforms | What is operated: network, compute, storage, cloud; plus the source of truth and ITSM. | VMware vSphere, Proxmox VE, Nutanix, Azure, AWS, Kubernetes / OpenShift; NetBox / Nautobot; ServiceNow / Jira Service Management | Protected targets; agents never hold their credentials. |
| Digital twin | A graph twin of live state for path tracing, blast radius and what-if, with an emulation lab for rehearsals. | Neo4j; Cisco CML, GNS3, EVE-NG, containerlab | Read-only to agents; what-if on a copy; rehearsal labs with their own vault paths. |
| Identity and secrets | People sign in with the enterprise IdP; every credential lives in a vault. | Any OIDC IdP (Entra ID, Okta, Keycloak); HashiCorp Vault / OpenBao, cloud secret managers, CyberArk | Roles from directory groups; agents never see a secret. |
| Observability and audit | Metrics, logs, the hash-chained audit log, shipped to your SIEM. | Prometheus / Grafana / Grafana Loki, Splunk, Elastic | Every decision attributable and verifiable. |
02The two boundaries
Agents ↔ infrastructure: code and pipelines
Agents read through tool servers and write only change records in Git. CI validates them and asks the twin; the automation platform applies them after an approval card, as its own identity. There is no tool that changes a device directly.
Agents ↔ credentials: the vault
The agent process carries one model-gateway credential and nothing else. Tool servers hold scoped read tokens; pipelines fetch short-lived credentials at run time. Output is redacted before the model sees it.
03Orchestration: one process, one warm agent per chat
A simple, proven shape (the reference implementation's): one orchestrator process holds every chat's state, the pending approval cards and the listeners; each active chat runs its own agent process with its own tool-server processes, kept warm between turns and closed when idle. It keeps the gate, the cards and the audit chain in one place; the cost is that it runs as one active instance (Redundancy & resilience).
04What the agent is told
The system prompt is rebuilt at every agent start from capped layers: the agent identity (how ODIN works), the operator policy (your organisation's profile and standing rules) and the environment (an operations brief kept in Git and refreshed on a schedule). Inventory is deliberately absent: devices, addresses and networks come from the source of truth and the twin through tools, so the prompt stays small and the facts stay current. A hash of the prompt context is in the audit record of every agent start.
05State
Durable
- The audit log (append-only, hash-chained)
- Each chat's events and its metadata (model tier, origin, usage, members)
- Specialists' hand-off reports
- Change state: merge request, check, approvals, merged
- Automation state: last runs, alert fingerprints, open incidents
- Attachments, sign-in sessions (hashed), device tokens
Volatile in the reference shape
- Pending approval cards (awaited by the agent's permission callback)
- Warm agent processes and their tool-server caches
- Per-turn counters, connections, rate-limit windows, metric counters
How to run it on Kubernetes or VMs: Operating it. What a multi-instance design would need: Redundancy & resilience.