Three Specialised Agents, One Topology Problem: Why Domain Decomposition Beats a Generalist in OT Diagnostics

Before the Digital Coworker architecture had three agents, it had one. The early PoC ran a single Bedrock Agent with access to all network domain tools and a broad instruction set covering VLAN segmentation, MRP ring behaviour, and general topology queries. The intent was pragmatic: one agent, one deployment, fewer moving parts.

The problem that killed it was not a prompt engineering failure. It was a mismatch between how a generalist agent holds knowledge and how an expert actually diagnoses a network fault. An expert does not evaluate all protocol domains simultaneously. They work the problem layer by layer — eliminating one stratum of causes before descending to the next. Is the MRP ring intact? If not, is the break a genuine fault or an expected ring reconfiguration after a planned topology change? Only after that stratum is resolved does the expert ask whether a VLAN segmentation issue is compounding the fault. Each diagnostic stratum requires holding a full, coherent model of that domain’s semantics. Holding IEC 62439-2 ring state machine semantics and IEEE 802.1Q broadcast domain logic simultaneously in one instruction set means neither can be encoded at the depth the layer demands.

The evaluation confirmed it: MRP troubleshooting degrades in a general-purpose prompt. So does VLAN segmentation analysis. The three-agent decomposition mirrors the layered structure of expert diagnosis — one agent per stratum, one stratum at a time. But mirroring the layers is not sufficient. The fix is giving each stratum its own instruction-set depth and its own bounded tool surface, so the LLM’s tool selection and knowledge context cannot bleed across domain boundaries. A better prompt cannot do that.

The VLAN Agent: Scoped to IEEE 802.1Q#

The VLAN Agent’s Lambda Action Groups cover exactly what IEEE 802.1Q fault diagnosis requires: device VLAN membership queries, port assignment lookups, broadcast domain configuration reads, and path connectivity validation via NetworkX graph traversal across physical links and VLAN layers.

What the VLAN Agent does not have: any Lambda function referencing MRP ring topology state. No ring manager queries, no IEC 62439-2 role lookups, no broken segment detection. The absence is architectural, not an oversight. When the VLAN Agent receives a query, the LLM’s tool selection is bounded by what is in the registry. It cannot ground an MRP answer in live topology or ring-state data, because there is no MRP tool to invoke — the absence of the tool constrains what the agent can retrieve, not what it might say in free text. The routing layer described below is what keeps an MRP-scoped query from reaching this agent at all.

The instruction set follows the same boundary: VLAN fault pattern knowledge — broadcast storm propagation, port VLAN mismatch signatures, platform-specific data gaps. MRP ring behaviour does not appear in it. A network engineer with five years diagnosing 802.1Q mismatches on industrial switches contributed to the instruction content. That specificity is what the general-purpose prompt destroyed.

The MRP Agent: Scoped to IEC 62439-2#

The MRP Agent’s Action Groups operate against ring topology state: ring segment queries, manager/client role validation, broken ring segment detection, and IEC 62439-2 recovery behaviour checks — distinguishing a genuine ring break from an expected manager role transition that looks like a fault to a naive query.

This distinction matters operationally. IEC 62439-2 defines MRP ring behaviour in terms of role states and recovery timing. An MRP ring that has lost one segment enters a specific state sequence; a ring reconfiguring after a planned topology change enters a different one. A generalist agent cannot reliably distinguish these cases because its instruction set lacks the depth to encode IEC 62439-2 state machine semantics alongside 802.1Q broadcast domain logic without one degrading the other.

The MRP Agent has no VLAN membership tools. If it receives a VLAN-primary query — a broadcast storm with a VLAN misconfiguration root cause presenting as ring instability — it cannot answer it. That is correct behaviour. The routing layer handles query classification before the agent sees it.

The Network Analysis Agent: Coordinator, Not Fallback#

The third agent handles cross-domain and topology-level queries: path analysis across the full network graph, multi-hop connectivity checks, and fault correlation across VLAN and MRP layers. Its tool surface includes NetworkX graph traversal (the deterministic approach established in Why Graph Traversal Beats RAG for Safety-Critical OT Diagnostics) and, when a query requires domain-specific validation, the ability to invoke the VLAN and MRP agents as sub-agents through Bedrock’s multi-agent collaboration — the Network Analysis Agent configured as supervisor, VLAN and MRP as collaborator agents, not as a Lambda proxy or undifferentiated tools in its own Action Group.

This is the agent that answers “is this ring break causing this VLAN isolation?” It does not hold both protocol models in its instruction set. It queries each specialised agent for the domain fact it needs, then synthesises the result. The coordination logic is explicit: Network Analysis routes a ring state question to MRP, a VLAN membership question to VLAN, and assembles structured answers into a compound response.

Invocation is not where the three agents agree on facts, though. The network state all three reason over — ring status, VLAN membership, topology position — is the same shared Apache Iceberg lakehouse; no agent maintains a private, divergent snapshot of it. Part 5 covers that consistency guarantee — the data layer as epistemic ground — in depth.

The distinction between coordinator and fallback generalist is precise. A fallback generalist holds all domain knowledge and degrades uniformly. A coordinator holds routing logic and delegates domain depth to agents that hold it correctly. The Network Analysis Agent’s instruction set is topology and correlation; it does not encode IEC 62439-2 and 802.1Q semantics simultaneously.

The Routing Layer: Accounting for the Trade-Off#

Specialisation adds complexity at the routing surface. The AWS Amplify frontend classifies queries by symptom type: VLAN-primary symptoms route to the VLAN Agent, ring redundancy symptoms to MRP, cross-domain and path queries to Network Analysis. Classification is rule-based, keyed to the symptom vocabulary support engineers already use.

The architectural trade-off is explicit: routing complexity added at the frontend versus instruction set degradation avoided inside each agent. The complexity added is a bounded classification rule set. The degradation avoided is unbounded — the failure modes of a combined-context agent in boundary cases are not enumerable in advance. The trade-off resolves clearly in favour of specialisation when domain knowledge is deep enough that mixing instruction contexts degrades both, when queries are classifiable by symptom type at the routing layer, and when the cross-domain coordinator can be scoped without becoming a second generalist.

All three conditions hold here. MRP and VLAN fault patterns are deep, distinct, and do not compose gracefully in a shared instruction set. Support engineers classify by symptom type naturally — the routing vocabulary is already present in how they describe problems. The Network Analysis Agent’s scope is genuinely bounded: topology correlation, not protocol depth.

The prior question for any team considering this pattern is whether the problem decomposes into diagnostic strata that an expert already works through one at a time. In industrial OT network fault diagnosis, it does: an expert typically resolves ring-level causes first — because a broken ring segment can mask VLAN faults — before correlating across strata. The system does not replicate that sequence per query — it routes a query to the agent whose stratum matches the symptom. The sequential logic belongs to expert intuition; the system captures that logic as a classification boundary. Each stratum has its own vocabulary, its own state machine semantics, its own failure signatures. The AI architecture that works is the one that mirrors how expert diagnosis moves through layers — one agent per stratum, with a coordinator that assembles the strata into a compound answer — not the one that tries to compress all strata into a single instruction set. VLAN specialists and MRP specialists are real organisational categories with different training and different escalation paths. That division is a consequence of the layering, not its cause. People specialised because the strata demanded it.

The four markers that produced this architectural decision — and which held up at one month of production pressure — are in the previous post: The Four Markers of AI-Native: What Held Up at One Month.

The deterministic graph traversal mechanism inside the Network Analysis and VLAN agents is covered in depth in: Why Graph Traversal Beats RAG for Safety-Critical OT Diagnostics.

The organisational reflection on this architecture — why layered diagnosis drives both the AI architecture and the team structure — is on javatask.systems: Debugging Layer by Layer: What Expert Intuition Told Us About AI Architecture.