Honest summary. The reference implementation runs as one active instance: pending approvals are promises in that process's memory and state is flat files with one writer. Production resilience comes from restarting it fast on durable, backed-up storage, not from running two at once.
01The single-instance model
| Backend | One process: HTTP, the WebSocket, every chat's state, the gate, cards, audit and timers in one event loop . |
| Per chat | One turn at a time; a second message while a turn runs is refused ("session is busy") . Backend messages queue until the turn ends; automation messages retry every minute, up to 15 times . |
| Across chats | Independent: each active chat is its own agent process with its own MCP servers. Nothing caps how many are warm at once; the 15-minute idle close bounds the resident set . |
| Durable | Chats, hand-offs, change state, the audit chain and the agents' session files on the data volume; a restart resumes a chat on its next message . |
| Volatile | Waiting cards, warm agents, in-flight turns, counters and rate-limit windows . A passed check survives, so the next merge request raises an ordinary merge card from it . |
02The production pattern
deployment guidance · not built in
- Active/passive. One active instance; a standby that starts only when the active one is gone, on the same replicated volume (a ReadWriteOnce volume that moves with the pod, or storage replicated to a second site). Never two at once: the audit chain and the files assume one writer.
- Health checks and automatic restart. Liveness and readiness on
/health; restart on failure; aRecreaterollout so an upgrade never overlaps two backends. - Backup. Snapshot the data volume on a schedule (volume snapshots; the audit log is fsynced per record, and the audit-chain check after a restore tells you whether the snapshot caught a partial write) and copy snapshots off-site.
- Restore and DR runbook. Restore the volume, verify the audit chain with the verifier against the restored data ), start ODIN, re-admit MCP servers if the images differ, and tell approvers to re-raise any card that was waiting.
- RPO. The snapshot interval (for example 15 minutes to an hour); what is lost is recent chat history and audit records since the snapshot, so ship the audit log to the SIEM continuously to keep its RPO near zero.
- RTO. The time to start a standby on the replicated volume (minutes); ODIN itself starts in seconds, and chats resume on their next message.
- Dependencies. Each integration has its own availability; ODIN degrades per dependency (below), so its SLO can be set above the weakest integration's.
03If a dependency is down
Model gateway or provider: rate limit, outage or no credit
Stops: Turns: the model call errors and the chat gets an
error event; nothing in ODIN retries on its own .Still works: Reading chats, approving cards already raised, the admin console. Rate-limit information from the provider is kept and shown .
Recovery: Send the message again once the limit resets, the provider recovers, or the gateway fails over to another deployment of the same model.
04Timeouts and windows
| What | Value (reference defaults) |
|---|---|
| Approval card (an agent's call) | 30 min by default; denied when its turn ends |
| Merge card (the backend's own) | 24 h; survives the turn |
| Run window after a merge approval | 60 min |
| Warm agent idle close | 15 min by default |
| Automation platform: request / check / run / project sync | 30 s / 10 min / 30 min / 5 min |
| Git host: request / merge waits for CI | 30 s / 6 min |
| Git-host approval poll while a merge card waits | 60 s; 15 s per request |
| Scheduler tick | 20 s; a schedule runs once per matching minute |
| Browser session / device token | 12 h absolute, 2 h idle / 30 days sliding, 90 days absolute |
| Admin unlock | 15 idle minutes; 5 failures lock for 10 min |
05What drives latency and cost
| Cold start vs warm turn | A chat's first message (or the first after 15 idle minutes) starts the agent and its MCP servers and writes the tool definitions to the prompt cache; later turns reuse the warm process and the cache . |
| Automation platform | Device evidence is a job on the automation platform, usually the slowest step of a turn; specialists batch every device into one job, and identical reads are cached for 10 minutes . |
| Context size | Every tool round re-sends the context; one tool result is capped at 15k tokens, and past 150k tokens of context ODIN offers a fresh chat from a summary . |
| Repeated reads | Hand-offs give related specialists each other's evidence; source-of-truth and Git reads are cached in their servers . |
| Model choice | Each specialist runs on its own model; jobs and alerts default to the smallest. Cost per turn: Operating it. |
06What active/active would require
| Holds it to one instance | In the reference implementation | For several active instances |
|---|---|---|
| Approval cards | A pending card is a promise inside the process that runs the agent . | A shared card store and a distributed lock (or one owner process per chat) so a decision resolves exactly once, routed to the owning process. |
| Sessions and WebSockets | Agent processes, listeners and presence are in one process . | A shared session store, sticky WebSocket routing by chat, and pub/sub for chat events and pending lists. |
| Audit chain | seq and prev are kept by one writer . | One audit-writer service, or a chain per instance plus a periodic sealed merge. |
| Chat and change state | Index files rewritten whole; JSONL appended . | A database with transactions. |
| Schedules and pollers | In-process timers . | Leader election, or every schedule runs once per instance. |
| Rate limits, admin unlock, logins in progress | In-memory maps. | A shared store. |