Solo engineer
Single process, SQLite-backed. Local dev or proof-of-concept. One command to start.
Single binaryArchitecture
Two databases. One twin.
OmniTwin separates what the network is supposed to be from what it actually is. The intent lives in Postgres. The reality lives in Neo4j. Agents act on the delta.
Postgres 17 + pgvector · Neo4j · Rust math · Go control plane · gRPC/MCP
Why two databases.
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.
Postgres holds the intent — allocations, plans, ownership, policy. Its relational model is purpose-built for structured records, and pgvector enables semantic search across the entire intent corpus. Neo4j holds the reality — the live topology, physical connections, observed state. Its graph model naturally represents the relationships between devices, ports, cables, and interfaces.
The agent runtime sits between them, continuously comparing intent to reality. When they diverge, that's drift — and drift is the fundamental signal the platform acts on.
The math engine.
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.
Streaming, not request/response.
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.
Server streaming JSON envelope
// 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 } }
]Four ways to deploy.
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.
Small team, cloud-hosted
Postgres + Neo4j on managed services. The standard deployment for teams up to 50 users.
Managed cloudEnterprise multi-region
Horizontally scaled control plane. Multi-region replication. For networks with 100k+ managed objects.
RoadmapAir-gapped, on-premises
Single-binary deployment with no external dependencies. Defense, utility, and regulated-finance environments.
RoadmapVendor-agnostic by design.
The 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 and core.
Edge: Cloudflare Workers + Durable Objects. Core: Go + Rust + Postgres + Neo4j. 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
Get early access.
We're onboarding the first teams now. Join the list and we'll reach out when your slot opens.