Netris — Agents & FFO Integration

How the Netris physical fabric becomes part of the Federal Frontier Ontology and the autonomous SRE agent tool surface — the fabric ontology, the Scout ingestion pattern, the Netris MCP tool surface, and the detect-diagnose-remediate-verify loop. A technical reference implementation.

Netris — Agents & FFO Integration

Technical Reference Implementation. Target design per ADR-007. The FFO fabric ontology is defined and TypeQL 3.x-validated; the Scout, MCP server, and autonomous-ops loop are reference designs, not deployed systems.

For Federal Frontier’s autonomous SRE agents to reason about the physical fabric, that fabric must exist in the platform’s living digital twin — the Federal Frontier Ontology (FFO) — and be actionable through the agent tool surface. This page describes how.

The FFO fabric ontology

The FFO network: ontology models the physical fabric as first-class entities and relationships. It is the structural half of the digital twin (slowly-changing topology and configuration), kept deliberately separate from live operational state and metrics.

Entities

Entity	Represents
`netris_controller`	The fabric controller / system of record
`fabric_switch`	A spine, leaf, or ToR switch (role, vendor, model, ASN, status)
`switch_port`	A physical port (speed, state, mode, VLANs, MTU)
`bgp_session`	A BGP session (local/remote ASN & IP, state, prefix counts, uptime)
`netris_vpc`	A tenant VPC (CIDR, tenant, isolation mode)
`dpu_policy`	A DPU isolation policy (HBN enabled, enforcement mode)

Relations

switch_connects_to · switch_has_port · port_connects_node · switch_runs_bgp · bgp_peers_with · vpc_contains_node · controller_manages · dpu_enforces_policy

The ontology follows the FFO snake_case convention and is validated against TypeDB 3.x. (Note: TypeDB 3.x derives relationships via functions rather than the rule blocks used in earlier TypeDB versions; any inference over the fabric is expressed accordingly.)

The Scout ingestion pattern

The Netris Scout is a lightweight integration route that periodically reads inventory, IPAM, topology, and BGP peer configuration from the Netris Controller API and writes that structural state to FFO through the platform’s ontology service. It does not write live operational state or metrics — those follow the data-flow discipline:

Structural state → FFO (via the Scout): topology, VPCs, DPU policy, BGP peer configuration, node membership.
Live state → agent context (via the MCP server, at investigation time): current BGP session state, current port state.
Metrics & events → Prometheus/Alertmanager: utilisation, packet loss, prefix trends, flap events.

The Netris MCP tool surface

The Netris MCP Server wraps the Netris Controller REST API and exposes it to agents through the Frontier MCP Registry. Read and live-query tools are low-risk; write tools carry policy risk scores and route high-risk actions through human-in-the-loop approval.

Tool	Type	Risk / gating
`netris.fabric.topology`	Read	Low (read-only)
`netris.bgp.sessions`	Live query	Low
`netris.switch.ports`	Live query	Low
`netris.vpc.list`	Read	Low
`netris.fabric.health`	Read	Low
`netris.vpc.create`	Write	Low (additive)
`netris.bgp.reset`	Write	Medium — brief disruption, fast convergence
`netris.port.bounce`	Write	High — affects all nodes on the port; human-in-the-loop gate

Risk scores are evaluated by the agent harness’s policy engine; anything classified High or Critical (for example, a switch-port bounce or a DPU policy change) is routed to the approval queue rather than executed autonomously.

The autonomous operations loop

The reference scenario that ties it together — a fabric fault handled end to end:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#0c332d','primaryTextColor':'#e6edf3','primaryBorderColor':'#2dd4bf','lineColor':'#8b949e','secondaryColor':'#11203a','tertiaryColor':'#161b22','fontSize':'14px'}}}%% graph LR A["Alert fires
(BGP session down on a leaf uplink)"] --> B["Read structural context from FFO
(which leaf, which VPC, which nodes)"] B --> C["Query LIVE fabric state via MCP
(netris.bgp.sessions)"] C --> D["Diagnose"] D --> E["Policy-gated remediation
(netris.bgp.reset — Medium risk)"] E --> F["Verify recovery"] F --> G["Write outcome back to FFO"]

Detect — an alert fires (e.g., a BGP session drops to a non-established state on a leaf uplink).
Diagnose with context — the agent reads structural context from FFO (which leaf, which VPC, which nodes are affected, what happened last time), then queries live fabric state via the Netris MCP server.
Remediate under policy — for a Medium-risk action like a BGP session reset, the agent acts autonomously; higher-risk actions are gated to human approval.
Verify & record — the agent confirms recovery and writes the outcome back to FFO as institutional memory.

This combination — FFO structural context plus live MCP queries plus policy-gated action — is what enables accurate, environment-specific autonomous operations over the physical fabric. Neither the digital twin nor live queries alone is sufficient; the design depends on using each for what it is good at.