Solo engineer
Single process, SQLite-backed. Local dev or proof-of-concept. One command to start.
Single binaryArchitecture
OmniTwin separates what the network is supposed to be from what it actually is. The intent lives in Postgres. The reality lives in a graph database. Agents act on the delta.
Postgres 17 + pgvector · Graph DB · Rust math · Go control plane · gRPC/MCP
New to this? Follow one address through the system first. It walks the same architecture in plain language.
Network infrastructure has two distinct states that are fundamentally different in shape: intent (what should be true) and reality (what is true right now). Mixing them in one schema creates ambiguity that compounds over time. A Go control plane routes every query across three specialised engines in one execution pipeline, so neither state is forced into the wrong shape and multi-table JOIN explosions never happen.
The relational state engine (Postgres) is the deterministic ledger: CIDR allocations, static reservations, VLAN metadata, ownership and policy, under ACID guarantees.
The semantic search engine (pgvector with an embedded local model) embeds incoming syslogs, BGP events, and device configs in milliseconds inside the control plane. Natural-language search across historical logs runs with no third-party API dependency and no external token fees.
The spatial graph engine holds reality: live topology, physical connections, observed state. Index-free adjacency computes multi-hop relationships (chassis ports to switches to VLANs to DHCP scopes to DNS records) in microseconds, which is what makes a live interactive canvas and sub-millisecond blast-radius analysis possible.
The agent runtime sits across all three, continuously comparing intent to reality. When they diverge, that's drift, and drift is the fundamental signal the platform acts on.
All CIDR arithmetic, subnet splitting, and address-space computation runs in ot-math, a Rust library compiled to the backend. Deterministic results, sub-50ms execution targets, no floating-point ambiguity.
The design constraint is deliberate: the canvas and command bar never perform arithmetic client-side. Every calculation routes through the math engine so that two users looking at the same subnet always see the same answer, regardless of browser or device.
This is both a correctness guarantee and a UX principle. When an agent proposes a subnet split, the numbers it shows are the numbers the engine computed - not a client-side approximation.
"Zero client-side math." The canvas does not do arithmetic. The engine does.
The platform is gRPC/MCP-streaming-first rather than REST. When an agent executes, the UI receives a stream of typed events - status updates, data chunks, tool calls, and a final result - rather than waiting for a single response payload.
This means the engineer sees the agent's reasoning as it happens: which vector matches were found, which tool the agent chose to invoke, and whether the final action was committed or deferred for approval. No spinner. No black box.
// Stream of typed events, not a single response
[
status { "type": "agent_status", "body": "searching..." }
vector match { "type": "data_chunk", "body": { "matches": 3 } }
tool call { "type": "agent_tool_call", "body": { "fn": "allocate" } }
commit { "type": "final_result", "body": { "committed": true } }
] OmniTwin scales from a single engineer's laptop to an air-gapped data center. Each deployment profile is a different infrastructure commitment - same platform, same agents, same data model.
Single process, SQLite-backed. Local dev or proof-of-concept. One command to start.
Single binaryPostgres + graph database on managed services. The standard deployment for teams up to 50 users.
Managed cloudHorizontally scaled control plane. Multi-region replication. For networks with 100k+ managed objects.
RoadmapSingle-binary deployment with no external dependencies. Defense, utility, and regulated-finance environments.
RoadmapThe AI gateway abstracts the model provider entirely. Agents define a contract - inputs, expected outputs, tool bindings - and the gateway routes to whichever model is configured: a hosted API, an Ollama instance on the local network, or a fine-tuned model behind a private endpoint.
Swap the model. The agent doesn't change. The data doesn't move. The contract doesn't break.
This is the anti-lock-in argument made concrete. The agent runtime is the stable layer; the LLM is a replaceable dependency. When your procurement team asks whether you're locked into a specific AI vendor, the answer is no - by architecture, not by promise.
Edge: Cloudflare Workers + Durable Objects. Core: Go + Rust + Postgres + graph database. Agents run at the edge, talk to the core over MCP.
The Cloudflare layer handles the agent runtime and real-time coordination - each IP record, each device object is a Durable Object with persistent state and low-latency access. The core backend handles the heavy lifting: CIDR math in Rust, control-plane logic in Go, persistent storage across both databases.
Private Beta
We're onboarding the first teams now. Join the list and we'll reach out when your slot opens.