From “Hello World” to “Agent Ready”: Why We Built Instead of Bought

Last month i shared a screenshot of a single switch validation. 12 tests. 1.46 seconds. It was cool but it was a toy example.

Scaling that to a nearly 300 device fabric requires more than just a loop. It requires architecture.

CVP is an incredible product. But we are builders. We don’t want a black box we want a toolbox. We need the ability to customize our validation logic down to the packet level and tailoring it to our specific storage behaviors, our OOB quirks and our exact compliance standards.

This is why ANTA is a gift from Arista. Most vendors lock their validation logic inside a proprietary dashboard. Arista open-sourced theirs. They didn’t just try to sell us the platform; they gave us the engine.

This allowed us to wrap their world-class validation framework in our own custom tooling.

Here is how we moved from a simple script to a production-grade validation engine.

1. The “One Size Fits None” Problem

When you download ANTA it comes with great default tests. But a network isn’t a monolith.

If I run a full EVPN/VXLAN compliance check on my Out-of-Band (OOB) management switch it will fail. It isn’t supposed to have VXLAN. If I run a generic “interface up” check on a Storage switch I miss the critical check for Jumbo Frames or Outdiscards.

We realized we needed Contextual Validation. We built 10 specific catalogs to match our topology:

2. Building the API Layer (The “Wrapper”)

This is the most critical part. ANTA is the engine. But we needed a driver.

We didn’t want engineers manually running scripts. We wanted a service. So we built a custom API wrapper.

Instead of typing commands, our orchestration system sends a clean JSON payload:

POST /api/v1/anta/validate/site { "sites": ["par1"], "catalog": "auto" }

That “catalog”: “auto” is the magic. The API looks at the device hostname (sp01, lf04, sws12), selects the correct test catalog (Spine vs. Leaf vs. Storage), and executes the validation.

And for the humans? Of course, we built a web dashboard that consumes this API. Why? Because we aren’t (yet) Netrunners connected to the grid. Until we have neural links humans still need to visualize data to make decisions. But crucially, the dashboard is just a “dumb” client. It hits the exact same API endpoints as our automation scripts.

3. The Metrics: 97.8% Success Rate (And Why 100% is a Myth)

When we ran this against 288 devices, we finished in 121 seconds. The result: 97.8% success.

In a lab, you get 100%. In a real data center, you get:

• Signal vs. Noise: Interface counters showing 50 errors in a sea of 10 billion packets. Too small for an alert, but enough to fail a strict validation test.
• The “Server-Side” Gap: MLAG interfaces that were configured on our leafs but down on the server side.
• Provisioning Remnants: Switches staged for production that weren’t live yet, or “zombie” configs left over from maintenance.

Standard monitoring ignores this because it doesn’t hurt uptime. Validation catches it because it hurts hygiene. We accept the 93.4%, but now we know exactly what that 6.6% is.

4. The Philosophy: Machine-to-Machine (M2M) First

Why did we go through the trouble of building an API wrapper?

It isn’t just for ANTA. It is about breaking a bad habit in our industry. Network Engineering is stuck in a “Machine-to-Human” world. We love our CLIs. We love parsing text. But you cannot build robust automation on top of text streams designed for eyeballs.

We operate on a Machine-to-Machine first principle. If it doesn’t have an API, it doesn’t exist in our ecosystem.

$ curl -s -H "Authorization: Bearer $TOKEN" \ "https://fabricview.example.com/api/v1/anta/dashboard/overview" | jq { "last_run": { "run_id": "f84fa9d1-85b1-4774-b5ff-a256552fa777", "completed_at": "2025-12-29T19:46:27Z", "duration_seconds": 111.9, "total_devices": 294, "devices_connected": 294, "total_tests": 4788, "passed": 4558, "issues": 194, "health_rate": 95.2 }, "overall_health": 97.9, "total_devices": 294, "healthy_devices": 240, "warning_devices": 53, "critical_devices": 1, "sites": { "par1": {"devices": 98, "healthy": 81, "passed": 1453, "issues": 27, "health": 98.2}, "par2": {"devices": 98, "healthy": 80, "passed": 1446, "issues": 34, "health": 97.7}, "ams1": {"devices": 98, "healthy": 79, "passed": 1449, "issues": 31, "health": 97.9} }, "alerts": {"critical": 9, "warning": 125, "info": 176} }

Sure, this prepares us for the future of Agentic AI . We are pretty sure Agents will be using this sooner or later. But let’s be real: nobody is confident letting an AI agent use the CLI on its own.

A raw CLI is an open minefield, you are never really sure what an autonomous agent might type or how it interprets a prompt.

The API is a guardrail. It forces the Agent into a safe lane. It defines exactly what is allowed (Validation) and what isn't (Destruction). It turns an unpredictable "user" into a predictable "consumer."

By wrapping ANTA in our own API, we have created a "tool" that any machine can use safely. Today, it's our dashboard. Tomorrow, it's an AI agent. The requirement is the same: Structured JSON, not raw text.

Old Way: Engineer reads CLI output → Engineer types fix.

New Way: Monitor reads State → Agent calls API → Agent proposes fix.

We are actively removing the human from the "Read-Eval-Print" loop. Not because we want to replace engineers, but because we want engineers building systems , not typing show ip int brief 300 times a day.

The API isn't just a wrapper. It is a declaration that our network is software, not hardware.

Originally published at https://www.linkedin.com.