IP Fabric's Michael Aragon explains how engineers can check an AI assistant's network advice against a timestamped model. His proposed evaluation separates computed paths from AI interpretation, limits permissions and checks for missed dependencies before a team relies on the workflow.
An AI assistant says an application can reach the service it needs. Before an engineer acts on that answer, three questions matter: which network snapshot was used, what the software actually checked and how the assistant reached its conclusion.
Michael Aragon, Solution Architect at IP Fabric, puts those checks at the center of a written interview with Lets Data Science. He describes a small evaluation built around applications an engineering team already understands, with known answers, a controlled change and a way to catch missing dependencies.
The interview accompanies IP Fabric's version 8.1 announcement, which describes application infrastructure mapping and changes to its cloud model. The company combines information about applications with a digital twin, a software model of network configuration and behavior. Its Model Context Protocol, or MCP, interface lets an AI assistant request information from that model.
The current release notes list version 8.1.3 as generally available on September 23. Application Infrastructure Mapping is a premium add-on that requires the AIM feature in the product license.
For teams considering an agent that investigates infrastructure problems, the useful question is whether its conclusion survives inspection of the underlying evidence.
The path calculation and the explanation are separate
Aragon's example starts with a mailing application experiencing connectivity problems. An engineer wants to identify the infrastructure it depends on and the routing or security controls that might prevent it from reaching a destination.
IP Fabric takes application information from Illumio, a segmentation platform, or from inputs such as CSV files and APIs. Aragon says Illumio is optional. He also identifies a dependency that matters for adoption: IP Fabric cannot independently discover the application information it needs. That context must come from another source.
The platform can then evaluate a path against its network snapshot. The AI assistant chooses what to ask and explains the result. Aragon distinguishes those responsibilities in his answer to LDS:
"The reachability verdict itself, though, still comes from IP Fabric's computation rather than the model's judgment."
That distinction gives an engineer something specific to inspect. A table or path lookup is evidence about the modeled network. The assistant's choice of query and its explanation still need review. A repeatable calculation cannot compensate for asking about the wrong application, destination or snapshot.
A snapshot needs a date and a scope
The word verified has a specific meaning in Aragon's answers: application connectivity has been evaluated against the network model. It does not establish that every fact needed for an operational decision is present or current.
IP Fabric's snapshot documentation describes records of network state at a particular time. It also warns that comparing a partial snapshot with a full one can produce false positives because part of the network is missing.
Aragon says teams can schedule collection, trigger a snapshot or refresh relevant devices. In a follow-up supplied to LDS, he adds an important limitation: path lookups and table queries do not carry a freshness indicator. The agent needs a separate health-check call to establish the snapshot's age.
He distinguishes three outcomes that an engineer must keep separate:
- •The lookup failed. A source missing from the discovered network can produce an error. That tells the agent the lookup failed, without establishing why.
- •The destination is outside the model's view. A path can appear to have been forwarded successfully and end at transit, with no warning that the destination is missing or invisible. A default route can make an unreachable destination look like an ordinary Internet path.
- •The model shows a block. Aragon says the path should stop at a device and show dropped traffic on an edge. That differs from merely reaching the limit of the model's visibility.
Application inputs need inspection too. Aragon says conflicting source IPs are not flagged, and the AIM status column indicates that a lookup was attempted rather than proving it succeeded. His recommended checks include verifying the source IP, matching lookup ports to the flows table and checking that a flow has a non-empty device list.
For an engineer, that means checking collection time and evidence coverage before interpreting a result, then confirming consequential findings in the product interface. A conclusion about yesterday's configuration may not explain a problem introduced this morning.
Read-only has a defined boundary
Aragon says IP Fabric does not push configuration changes to production network devices. He describes its MCP server as read-only by default, while explaining that administrators can explicitly enable methods that allow changes within IP Fabric itself, constrained by the API token's permissions.
Those are different kinds of access. Querying a model, changing information or settings inside that platform, and changing a production router should not be described as the same operation.
The official MCP documentation says requests use an API token and inherit its assigned permissions. It recommends granting only the access needed for the task.
For a pilot, Aragon recommends a narrowly scoped token and an explicit decision about acceptable actions. Human review still matters because the model can misinterpret the information it receives. A restriction on writes does not establish that every explanation is correct or answer every question about data sent to an AI provider. His follow-up clarifies that the MCP service runs on the IP Fabric appliance. That does not mean all connected AI processing stays there. IP Fabric's Local MCP Terms say the client or AI application may forward returned data to the selected AI provider, according to the customer's permissions and configuration. The provider's practices then determine how that shared data is handled. Teams need to review that separate data boundary before connecting an assistant.
A simulated path is useful evidence with limits
The supporting material supplied to LDS includes 14 simulated path lookups for a mailing-system workload. Aragon confirms that this is a demonstration, with an AI-generated illustration built from IP Fabric path and application-flow data. The figures show the same route through two modeled network devices, ending at transit.
The follow-up identifies several annotations as inference rather than IP Fabric data, including the device's role as the Internet edge, service labels inferred from ports and guesses about destination ownership. Those annotations should not be treated as additional measurements.
The figures illustrate forwarding through the modeled part of the network. They do not demonstrate that a remote application completed a real transaction, or establish a measured improvement in resolving a customer outage.
An engineer can use such an output to investigate where traffic is allowed or blocked in the model. Confirming that a service works for a user requires evidence about the service as well as the path leading toward it.
Start with applications whose answers you can check
Aragon's suggested evaluation begins with two or three familiar applications. He told LDS: "The point of the first run is to catch the tool being wrong, and you can only do that on ground you can verify yourself."
His advice can be organized into five checks:
- •Establish the baseline. Supply the application information, take a snapshot and record its time. Choose applications whose dependencies the team can independently inspect.
- •Keep the questions fixed. Ask which devices carry an application's traffic, which destinations its flows reach and which controls permit or block the path. Include a case with a known negative result, such as an unreachable destination.
- •Check the underlying evidence. Compare several answers with the platform's interface and at least one with the actual device. Open the table, path or policy behind an explanation.
- •Make one controlled change. Aragon suggests a reversible routing, firewall or segmentation change in a maintenance window, followed by a fresh snapshot and the same questions. Check both affected and unaffected flows, and whether the explanation identifies the control that changed.
- •Look for omissions and variation. Check whether the original dependency list missed an application. Repeat questions in fresh AI sessions to see whether the selected evidence or conclusion changes.
This is a way to evaluate a candidate workflow, not evidence that LDS has run or validated it. Teams should choose an appropriately isolated test environment or an approved maintenance procedure for any change.
The three outcomes in Aragon's follow-up belong in the acceptance criteria: a failed lookup, an out-of-view destination and a confirmed block require different explanations. He recommends trying a known-unreachable address to check whether a default route masks the problem. Treating transit as proof that the destination was reached would hide the coverage gap the test is intended to expose.
Aragon's most useful standard is traceability. He told LDS: "Every claim should be traceable to a table, path lookup or policy you can open yourself; if you can't click through to it, treat it as narrative."
What the interview does not establish
Asked for measured results, Aragon cited customer testimonials. The material supplied to LDS did not include a controlled comparison, a count of test cases, measured errors or missed dependencies, or a quantified time-saving result.
The practical value of the interview is the evaluation method and its boundaries. Teams can ask for evidence tied to their own applications, inspect what the agent queried and test whether its account of a change matches what actually happened. Broader claims about speed or reliability need results from that testing.
Reporting note
This LDS Exclusive is based on six written answers and subsequent technical clarifications from Michael Aragon supplied directly to Lets Data Science through IP Fabric's communications representative. The company also supplied its announcement and illustrative simulation outputs. Official product documentation and MCP terms provide supporting context. LDS did not run the software, reproduce the example or independently verify customer performance claims.
Key Points #
- 1The network engine computes paths from a snapshot; the AI assistant chooses queries and explains results. Engineers need to inspect both the evidence and the interpretation.
- 2Read-only access is the MCP default, but administrators can enable changes within IP Fabric. That is distinct from pushing configuration to production network devices.
- 3Aragon recommends a small, repeatable evaluation with known applications, negative cases and before-and-after checks. The supplied material includes no controlled performance comparison.
Scoring Rationale #
Original written answers give AI and infrastructure teams a practical method for checking network evidence, permissions and missed dependencies before relying on an agent.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Michael Aragon, Solution Architect at IP Fabric.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.