Frequently asked
questions.

OmniTwin is an agent-native DDI platform — DNS, DHCP, and IP Address Management — built by Kortesa Labs. It maintains a live digital twin of your network and runs autonomous agents that continuously discover, validate, and act on that twin.

The key distinction from traditional IPAM tools is architecture: OmniTwin's agents don't sit on top of a database and query it. They operate on the twin as a runtime. The system of record and the system of action are the same thing.

DDI stands for DNS, DHCP, and IP Address Management — the three foundational control-plane services that every IP network depends on. DNS resolves hostnames to addresses. DHCP assigns addresses dynamically to hosts. IPAM tracks the allocation, assignment, and availability of every address in your space.

Most organizations manage these three services separately, with different tooling and different data models, which creates reconciliation overhead and drift. Integrated DDI platforms manage all three from a unified data model.

OmniTwin is built for network engineers, NetOps teams, and platform engineers who manage IP space at scale and need automation that goes beyond dashboards and manual workflows. Specifically:

• Teams migrating from legacy DDI vendors and want a clean, open-standards foundation.
• Organizations where undocumented network changes create compliance or operational risk.
• Platform teams building infrastructure automation and need a DDI API they can actually compose with.
• Any environment where the gap between the documented network and the real network is a known problem.

Three fundamental differences:

Architecture. Legacy tools are passive records — engineers query them and enter data manually. OmniTwin is an active runtime — agents continuously observe, reconcile, plan, and execute.

Standards. Legacy proprietary platforms use closed data models that create migration friction and API inconsistency. OmniTwin is built on open-standards DDI — RFC-compliant schemas, portable data, no vendor lock-in.

Automation depth. Most tools bolt an "AI" feature onto an existing IPAM UI. OmniTwin's agents are first-class — discovery, drift detection, pre-flight simulation, and closed-loop execution are the product, not add-ons.

OmniTwin pricing is tiered by IP capacity and agent access. There are currently two live tiers — Essential (free, up to 500 IPs) and Team ($300/month annual, up to 3,000 IPs with Scout Agent and The Polyglot included). Scale and Platform tiers are in development for Phase 2.

Annual billing saves 17% versus monthly. See the pricing page for the full breakdown.

Yes. The Essential plan is permanently free — no credit card required, no trial expiry. It supports up to 500 IP addresses and 500 devices, with full REST and GraphQL API access, standard SSO, and a single-tenant cloud instance.

Essential does not include any autonomous agents. You manage discovery and data entry manually. Upgrade to Team to activate Scout Agent and The Polyglot.

We don't cut you off mid-operation. When you approach your IP limit you'll receive a warning via the UI and email. You'll have a grace period to either reduce your tracked addresses or upgrade your plan. We'll always alert you before anything is restricted.

What counts as an IP: any IPv4 or IPv6 address tracked in your IPAM twin — whether assigned, reserved, or discovered by Scout. Subnets and ranges are not counted individually.

Yes. You can upgrade at any time and the change takes effect immediately — we'll credit any unused portion of your current period. Downgrading or switching from annual to monthly billing takes effect at the next renewal date.

Switching from monthly to annual mid-cycle? We'll credit the difference and apply the annual rate from the switch date.

OmniTwin is built on RFC-compliant DNS (RFC 1034/1035), DHCP for IPv4 (RFC 2131), DHCPv6 (RFC 3315), and IPv6 addressing architecture (RFC 4291). All data schemas conform to published standards — there are no proprietary object types that create lock-in or migration friction.

This means OmniTwin can interoperate with any RFC-compliant DNS server, DHCP server, or IPAM consumer without custom adapters. The Polyglot agent handles translation from proprietary vendor formats on import.

The Polyglot reads export files from supported DDI vendors — Infoblox, BlueCat, phpIPAM, and others — and maps every object to OmniTwin's open-standards schema. That includes prefixes, address records, DNS zones and records, DHCP scopes and leases, VLANs, and device inventory where available.

The import runs as a preview first: you see a diff of what will change before committing. If field mappings require disambiguation, The Polyglot surfaces them for human review rather than guessing.

Yes — OmniTwin exposes a full REST API and a GraphQL API on all plans, including Essential. The APIs cover every resource type: IP prefixes, addresses, DNS zones and records, DHCP scopes and leases, devices, and agent configuration.

Authentication is via API token (Bearer) or OAuth 2.0 client credentials for service-to-service workflows. Rate limits are documented per plan tier. See the API reference for full schema and example requests.

All plans include standard SSO via Google Workspace, Microsoft Entra ID (Azure AD), and GitHub. Scale and Platform plans additionally support enterprise SAML 2.0 and group-to-role mapping from your identity provider — so access control follows your existing directory without manual assignment.

SCIM provisioning for automated user lifecycle management is on the Phase 2 roadmap for enterprise plans.

Agents are autonomous software processes that run against your OmniTwin twin and take defined actions — discovery, translation, validation, planning, or execution. Each agent has a specific job, a specific trigger model (scheduled, continuous, event-driven, or on-demand), and a defined scope of authority.

Agents are not AI chat assistants bolted onto a database. They are first-class operational components — the twin's actuation layer. A network engineer gives an agent a mandate; the agent carries it out and reports back.

Yes. Agents are independently configurable. Your plan determines which agents you have access to, but you control when they run, which subnets or zones they cover, and what actions they're permitted to take. You can run Scout on a tight schedule for production and on-demand for dev, for example.

Agents can also be scoped to specific prefixes, VLANs, or zones — so you can enable Truth Seeker on your production environment without running it across your dev or lab space.

Truth Seeker, the drift detection agent, compares two data sources: what your OmniTwin twin records and what Scout Agent observes on the live network. When they diverge — a host in the twin with no live address, an active host with no twin record, a DNS record pointing to a decommissioned address — Truth Seeker flags the divergence as a drift event.

Each drift event has a severity rating (info, warning, critical) based on the type of divergence and the policy rules you configure. Drift events appear in the UI, are accessible via the API, and can trigger webhooks for integration into your alerting pipeline.

Truth Seeker does not automatically resolve drift — resolution requires human approval or an explicit closed-loop policy configured via The Hands/The Closer.

The Safety Net agent runs every planned change — new prefix, new DNS record, modified DHCP scope — against a simulation of your twin before anything touches the live network. It checks for IP conflicts, subnet overlap, scope exhaustion, zone delegation issues, and policy violations.

If a change fails simulation, it is blocked and the failure reason is surfaced to the engineer or the requesting system. Nothing reaches production without passing pre-flight.

This matters because DNS and DHCP changes can cascade quickly — a misconfigured scope can affect hundreds of hosts, and a bad SOA record can break zone delegation. Pre-flight catches those before they happen, not after.

It depends on the agent. Scout Agent supports scheduled scans (configurable interval per subnet range) or on-demand triggering via the API or UI — useful after provisioning events. Truth Seeker is designed for continuous background operation, comparing twin state to observed state on an ongoing basis.

The Safety Net runs per-change — it is triggered by any proposed modification, not on a schedule. The Architect and The Closer/The Hands are on-demand or workflow-triggered, not continuous.

Closed-loop automation means the system can discover a required change, plan it, simulate it, get approval, execute it, and confirm success — without a human manually touching each step. In OmniTwin, The Architect plans, The Hands stages, and The Closer executes with rollback capability.

To enable it safely, we recommend a staged approach: start with The Closer in "approval required" mode, where every execution plan requires a human sign-off before it runs. Once you've built confidence in the agent's output quality for your environment, you can configure auto-approval for lower-risk change types (e.g., DNS A record additions) while keeping manual approval for scope changes.

Every closed-loop execution is logged in full audit trail — who approved, what changed, what the pre- and post-state was — and rollback is available for a configurable window after execution.