Can AI Discover Better Network Architectures? Designing a Controlled Experiment

TL;DR

from itertools import combinations

LEAVES = (“l1”, “l2”, “l3”, “l4”)
SPINE_ZONES = {“s1”: “A”, “s2”: “B”, “s3”: “A”, “s4”: “B”}

def structural_rejections(topology):
problems = []
if set(topology) != set(LEAVES):
problems.append(“unexpected leaf inventory”)
for leaf in LEAVES:
uplinks = topology.get(leaf, ())
if len(uplinks) != 3 or len(set(uplinks)) != 3:
problems.append(f”{leaf}: exactly three distinct uplinks required”)
if set(uplinks) – set(SPINE_ZONES):
problems.append(f”{leaf}: unknown spine”)
elif len({SPINE_ZONES[s] for s in uplinks}) < 2:
problems.append(f”{leaf}: both power zones required”)
for spine in SPINE_ZONES:
if sum(spine in topology.get(leaf, ()) for leaf in LEAVES) > 4:
problems.append(f”{spine}: port budget exceeded”)
for left, right in combinations(LEAVES, 2):
shared = set(topology.get(left, ())) & set(topology.get(right, ()))
if len(shared) < 2:
problems.append(f”{left}/{right}: insufficient shared spines”)
return problems

def zone_failure_rejections(topology):
problems = []
for failed_zone in (“A”, “B”):
for left, right in combinations(LEAVES, 2):
shared = set(topology[left]) & set(topology[right])
surviving = {s for s in shared if SPINE_ZONES[s] != failed_zone}
if not surviving:
problems.append(
f”{left}/{right}: no shared spine after zone {failed_zone} fails”
)
return problems

baseline = {leaf: (“s1”, “s2”, “s3”) for leaf in LEAVES}
balanced = {
“l1”: (“s1”, “s2”, “s3”),
“l2”: (“s1”, “s2”, “s4”),
“l3”: (“s1”, “s3”, “s4”),
“l4”: (“s2”, “s3”, “s4”),
}
zone_aware = {
“l1”: (“s1”, “s2”, “s3”),
“l2”: (“s1”, “s2”, “s3”),
“l3”: (“s1”, “s2”, “s4”),
“l4”: (“s1”, “s2”, “s4”),
}

for name, topology in (
(“baseline”, baseline),
(“balanced”, balanced),
(“zone-aware”, zone_aware),
):
structure = structural_rejections(topology)
zones = zone_failure_rejections(topology) if not structure else [“not evaluated”]
print(
f”{name}: structure={‘PASS’ if not structure else ‘FAIL’}, ”
f”power-zones={‘PASS’ if not zones else ‘FAIL’}”
)

A network topology is more than a diagram showing which devices connect.

A network architect is asked to redesign a datacenter fabric that supports virtualization, storage traffic, Kubernetes applications, and an expanding collection of AI workloads.

An AI system that proposes a new topology must respect the underlying requirements. Novelty alone cannot justify removing useful path diversity.

Introduction

There is no single network evaluator that proves every relevant property. The validation stack should become progressively more expensive and more realistic.

None of these calculations proves a real-world performance improvement. They show that even a small topology search can produce different validity outcomes depending on which failure domains the evaluator understands.

baseline: structure=PASS, power-zones=PASS
balanced: structure=PASS, power-zones=FAIL
zone-aware: structure=PASS, power-zones=PASS

Perhaps changing a small number of physical connections would improve traffic distribution. Perhaps an alternative allocation of links would reduce the impact of a particular failure. Perhaps the existing topology is already the best practical option, but an unconventional design could expose a useful relationship between traffic patterns and network capacity.

Assume four leaf switches and four already installed, powered, and licensed spine switches. Each leaf has three approved uplinks, for a total of twelve leaf-to-spine connections. Each spine has four available leaf-facing ports. No leaf-to-leaf or spine-to-spine links are permitted in this simplified two-stage fabric. All candidate links use the same approved port speed and compatible physical media.

Do not let one optimization metric hide the full cost of change. A topology requiring recabling or new operational procedures has a transition cost even when the switch inventory is unchanged. Consider optics, structured cabling, maintenance windows, redundancy during cutover, routing-policy complexity, monitoring, training, and rollback.

Most enterprise network architectures begin with established design patterns. Engineers choose proven topologies, routing protocols, redundancy models, and traffic-engineering methods because those approaches have understandable failure behavior and operational history. That discipline is necessary, but it also limits how many alternative designs an engineering team can realistically investigate.

These documents help explain why physical connectivity, next-hop selection, and effective bandwidth utilization must be evaluated separately.

Graph theory can establish whether two devices remain connected after a link or node failure.

Those are appropriate engineering activities.

A conventional leaf-spine fabric provides predictable structure. In a fully connected two-tier design, each leaf has uplinks to every spine, allowing traffic to use multiple paths through the fabric.

Before using this code against a real inventory, replace the illustrative devices and zone map with approved data. Add hard gates for allowed port pairings, physical cabling, line-card failure domains, route and policy dependencies, and service-specific reachability. A production discovery harness also needs strict input validation and safeguards against malformed or excessive candidate submissions.

Part 3 applies those ideas to a concrete networking problem.

The search should stop when further evaluation cost exceeds the plausible value of the remaining candidates, when the improvement is no longer reproducible, or when no qualified candidate offers a meaningful advantage over conventional engineering alternatives.

The proposed experiment uses an intentionally small, constrained network. The objective is to compare different assignments of the same physical uplink budget, rather than give the AI unlimited freedom to buy devices or invent forwarding capabilities.

Separate search scenarios from holdout scenarios. The generator may receive scores from an approved development evaluator, but it should not repeatedly tune against the final acceptance suite. Otherwise, strong scores may reflect benchmark overfitting rather than robust network behavior.

Why Network Architecture Is a Difficult Discovery Problem

The challenge is to use that structure to expand exploration without weakening engineering discipline.

A candidate still needs a supported device configuration model. A passing graph test cannot substitute for route-policy analysis. Likewise, static reachability analysis is not a throughput benchmark.

All three are useful when the evidence is retained. None requires pretending that AI has invented a universally superior network fabric.

Established Patterns Exist for Good Reasons

The business wants more usable capacity without a disproportionate increase in infrastructure spending.

The twelve-link example shows why that process must be layered. A balanced-looking candidate can satisfy local redundancy rules and still break connectivity when a shared failure domain disappears. A different candidate can survive that failure while creating a new concentration of critical paths. Structural validity, performance, resilience, and operational acceptability are separate decisions.

This is also where a mathematically elegant topology may become unappealing. It might require awkward recabling, consume unusual port combinations, complicate maintenance, or create a failure pattern that the operations team cannot readily diagnose.

The existing infrastructure is functional. Redundant switching is in place, Border Gateway Protocol (BGP) provides routing in the fabric, and Equal-Cost Multipath (ECMP) distributes eligible traffic across available paths. Monitoring shows that the environment is generally healthy, although some links experience congestion while others remain underutilized.

Comparison of two twelve-link leaf-spine fabrics: the balanced candidate loses a common surviving spine after a modeled power-zone failure.

A Valid Topology Is Not Necessarily a Good Topology

A network simulator such as ns-3 can provide a repeatable environment for testing modeled packet-level behavior. Its suitability depends on the specific protocol and queue models configured and whether they capture the mechanisms that matter for the workload.

A candidate may disconnect a workload during a spine failure, oversubscribe an uplink, exceed a switch’s port capacity, violate a segmentation requirement, or depend on forwarding behavior the installed hardware does not support.

This makes networking an especially useful domain for testing the discovery-engine concept.

Do not assume the simulator’s ECMP or congestion model matches the hardware. That claim requires its own validation.

A comparison should distinguish the best normal-operation result from the most defensible operating result. An extra percentage point on a simulated throughput score is not enough to justify a design with materially weaker fault tolerance or an unmanageable change path.

A topology may look excellent in simulation while failing under real congestion, route reconvergence, or optical faults.

• Can the network forward traffic between required endpoints?
• Can it preserve that connectivity through the defined failures?
• Does routing converge to the intended paths?
• Are security boundaries enforced along those paths?
• Can the topology handle representative traffic without unacceptable degradation?
• Can engineers deploy, monitor, troubleshoot, and recover the design using supported mechanisms?

The following is the proposed experiment’s evidence plan, not a report of completed test results.

Bound the Search: A Twelve-Link Fabric Experiment

A search algorithm concerned with distributing links evenly might suggest spreading all twelve links across four spines, three links per spine. On a simple port-utilization score, that arrangement looks attractive. It also passes basic tests requiring three unique uplinks per leaf, connections in both power zones, and two common spines between each pair of leaves.

This is exactly the kind of subtle failure a discovery engine must catch before performance scoring.

Continue the AI discovery series or explore the Enterprise AI hub.

AI-assisted network architecture discovery is a reasonable engineering research direction precisely because networking exposes the difference between plausible proposals and verifiable results. Graph structure can be tested, routing and policy can be analyzed, traffic can be simulated, and selected candidates can be challenged on physical hardware.

The comparison should use identical traffic inputs and equivalent resources for the baseline and qualified candidates. Test steady-state load, bursts, asymmetric traffic, and failures. If the objective involves distributed AI, include traffic patterns representative of the relevant collectives or service communications rather than relying on a generic uniform-flow generator.

The Counterexample: Better Balance Can Make Resilience Worse

A technically valid candidate is not automatically novel, and a novel candidate is not automatically useful.

There are three legitimate outcomes. The machine-search approach may discover a reproducible improvement worth advancing to a controlled hardware pilot. It may uncover a tradeoff or failure mode that improves the team’s understanding without changing the architecture. Or it may demonstrate that the existing design or a conventional optimizer remains the stronger option.

Only the strongest candidates should consume laboratory hardware time. On the intended devices and software baseline, verify supported cabling and optics, route convergence, link and switch failures, congestion behavior, security enforcement, and recovery after the test.

The experiment should reserve the word discovery for a candidate with a defensible difference from known approaches and a meaningful, independently reproduced benefit under the approved requirements. An alternative that works only in an unrealistic simulation should remain a research result. A design that improves one workload while violating security or recovery requirements should be rejected.

The purpose of the experiment is to find an improvement, not to guarantee that an AI-generated candidate wins.

Continue reading

Use a Deterministic Gate Before Any Simulation

For candidate selection, store the topology input, generator and evaluator versions, traffic-trace identifiers, simulator configuration, random seeds where relevant, rejected cases, results, reviewer decisions, and the cost of verification. Use consistent identifiers so the reported winner can be independently replayed.

The recommended first step is to select a narrow, non-production search problem and establish the full baseline and failure-domain model. Build the rejection gates before increasing search volume. Compare every machine proposal with credible human-designed and conventional optimization alternatives, then require independent replay before discussing production changes.

RFC 7938, Use of BGP for Routing in Large-Scale Data Centers, documents an approach built around BGP and Clos network topologies. It addresses considerations including operational simplicity, network stability, scalable capacity, and ECMP behavior.

That structure is valuable because engineers can reason about bandwidth, failure behavior, routing adjacencies, and expansion using known relationships.

Evaluate Candidates Through Different Technical Layers

This is a partially connected brownfield test model, not a complete nonblocking Clos reference design. A conventional fully connected four-leaf, four-spine fabric would have sixteen leaf-to-spine links. The twelve-link cap is a deliberate constraint for the experiment, not a recommendation to reduce production fabric connectivity.

Evaluation layer	What it can establish	What it cannot establish
Graph and inventory validation	Allowed edges, port limits, modeled path diversity, shared-risk failures	Actual control-plane operation or delivered bandwidth
Configuration and reachability analysis	Routing and policy implications of modeled device configurations	Hardware timing, all dynamic behaviors, throughput
Discrete-event simulation	Modeled packet behavior under specified traffic and failures	Faithful reproduction of every vendor ASIC, NIC, firmware, or workload characteristic
Routing emulation	Behavior of chosen routing implementations and configurations	Fidelity to production hardware data planes
Physical laboratory test	Device-specific forwarding, congestion, optics, fault and recovery observations	Every future workload or correlated production failure

Validate the Control Plane Separately

Similarly, a routing model may show that a destination is reachable while the actual workload experiences unacceptable latency or congestion.

It represents constraints involving port availability, physical reachability, capacity, routing, failure domains, forwarding behavior, security enforcement, and operating cost.

The starting layout connects all four leaves to S1, S2, and S3. S4 is installed and powered but has no leaf uplinks assigned. It is an unusual but plausible transitional brownfield state during fabric expansion.

Simulate Representative Traffic

But what if the best answer is an arrangement the architecture team has not considered?

The experiment must therefore ask several different questions:

Get Paul Bryant’s practical guides to enterprise AI, hybrid platforms, and day-2 operations by email. New articles as they publish. Unsubscribe anytime.

Part 4 will address the final boundary: how an organization decides whether a machine-discovered solution deserves production trust, including ownership, change authority, evidence retention, rollback, and ongoing monitoring.

Verify With Physical Equipment When the Claim Warrants It

Two diagrams that appear almost identical can behave very differently under load or failure.

Takeaway: AI should be allowed to challenge familiar network designs, but every proposed improvement must survive independent verification of connectivity, performance, resilience, security, and operational behavior.

Two design choices need explicit agreement before the experiment begins. First, the failure criterion is that required leaf-to-leaf traffic must retain an eligible common spine after any single spine failure and after either modeled spine power zone fails. Second, passing a connectivity check does not imply sufficient capacity during that failure.

Use a Fair Experiment Instead of a Benchmark Contest

The trap appears when a whole power zone fails.

The objective is not to prove that AI can replace network architects. It is to design an experiment that could establish whether machine-assisted search can discover useful network configurations that a conventional design process did not identify.

RFC 2992 examines an ECMP selection algorithm and the disruption caused when the next-hop set changes. RFC 7424 examines mechanisms for optimizing component-link utilization with ECMP and Link Aggregation Groups (LAGs).

The conventional response is familiar. Review utilization, evaluate oversubscription, examine uplink capacity, adjust supported traffic-engineering mechanisms, and determine whether the network needs additional switching resources.

Question	Evidence required	Stop or rejection condition
Is the design valid?	Port inventory, graph gates, approved hardware combinations	Any hard constraint fails
Does it preserve security?	Allowed and denied flow analysis for normal and degraded modes	Required inspection or isolation fails
Is routing correct?	Configuration analysis, route tables, neighbor state, failure replay	Persistent blackhole, loop, or unacceptable convergence
Is performance better?	Paired workload replay, distribution of latency and useful throughput	Improvement absent or protected service regresses beyond agreed tolerance
Is it robust?	Holdout traces, multiple load levels, link, switch, and power failures	Claimed benefit disappears or critical failure behavior worsens
Is it operable?	Change plan, diagnostics, support matrix, maintenance and recovery exercise	No acceptable support or recovery path

Keep the performance measures tied to services: completed useful work, flow completion time, high-percentile latency, retransmissions or loss, queue occupancy, and the degree of degradation after failure. Vendor telemetry, including NVIDIA’s published Spectrum-X examples, illustrates why transient congestion and link errors may require finer-grained measurements than ordinary interface polling.

Network analysis tools such as Batfish can reason about supported configuration snapshots, topology, routing, forwarding, access controls, and differential behavior. That makes them useful for checking whether a generated network configuration preserves approved connectivity and isolation properties.

Treat the Search Budget and Operational Cost as Design Constraints

Establish three competitors before search begins: the approved current configuration, a credible conventional engineering alternative, and the machine-generated candidates. Where the search space is small, also include enumeration, constraint solving, or conventional heuristic optimization. If an exact method finds the best qualified layout cheaply, using a language model adds little engineering value.

This proposed trial also illustrates why performance must be expressed as more than one number. The balanced graph has attractive link-count symmetry but fails a correlated-outage condition. The zone-aware graph passes that condition, yet concentrates shared paths onto particular spines and may perform worse for certain traffic matrices. Without simulation and laboratory results, no candidate has earned a performance recommendation.

It might also generate thousands of invalid designs.

That does not establish whether the surviving path has enough capacity.

What Would Count as a Genuine Network Discovery?

This article designs a controlled experiment around a small leaf-spine Ethernet fabric. It explains how to represent candidate topologies, preserve routing and security requirements, test failure conditions, measure workload behavior, and reject designs that optimize one metric at the expense of service reliability or operational supportability. The experiment is an engineering proposal, not a claim of tested or measured AI-generated network improvements.

Search has its own economics. A generator may produce thousands of layouts quickly, while detailed network simulation and hardware tests are much more expensive. Use inexpensive graph and static-policy gates first, then reserve costly evaluation for a small set of qualified, diverse candidates.

A more conservative zone-aware alternative retains S1 and S2 as shared neighbors for every leaf. L1 and L2 also use S3; L3 and L4 use S4. Its spine link counts become 4, 4, 2, 2. That layout preserves a common spine under either modeled power-zone loss, although it concentrates critical shared connectivity onto S1 and S2 and can still fail on bandwidth, policy, routing, or supportability.

The question for network architects is not whether AI can draw a topology we have never seen. It is whether we can prove that the unfamiliar topology is better without sacrificing the properties that make the network dependable.

Conclusion

If the experiment uses BGP, test expected neighbor relationships, route advertisement and filtering, next-hop resolution, withdrawal, path selection, and effects on permitted and prohibited flows. Explicitly include management access and recovery paths, not only application data paths.

Part 1 of this series established the distinction between AI imitating human reasoning and AI searching for independently verifiable solutions. Part 2 defined the discovery engine, including candidate generation, evaluation, search memory, and approval boundaries.

Stay informed

A candidate that passes the first question has only begun the evaluation.

The document is informational, rather than an Internet Standards Track specification, but provides a useful foundation for understanding established large-scale fabric design.

The following Python 3 example performs two different checks. First, it validates the link budget and basic graph structure. Second, it removes each modeled power zone and tests whether every leaf pair retains a shared spine. It uses only the standard library and does not connect to network equipment.

External References

A physical test is a necessary escalation for consequential claims, not permission to bypass the enterprise change process.

The AI Discovery Engine: Generators, Evaluators, and Verification A practical AI discovery engine separates candidate generation from hard constraints, independent evaluation, verification, and review. Read the article →

An AI-assisted search system might investigate those possibilities systematically.

Make your next architecture decision with confidence.

The physical rack, power feed, port, optics, and cable-reach details must be replaced with the real site’s inventory before this model could become a deployment candidate. The power zones are illustrative correlated-failure groups, not assertions about any actual datacenter.

Share this:

Like this:

Like Loading…