Before today’s piece, if you’re building toward IT infrastructure, support, or cloud ops roles, tomorrow’s session is worth your Saturday evening.

Aug 29th - Hybrid Identity with Active Directory & Microsoft Entra ID

LAST 24 HOURS - CLAIM 50% OFF WITH FINAL50

GET YOUR SEAT →

Robert McMillen walks through how AD and Entra ID work on their own and together, so you can actually explain identity concepts in interviews instead of just recognizing the terms.

Last chance to grab a seat before it goes live tomorrow, so don’t miss out!

Now, onto today’s piece.

In Minority Report, police arrest people for murders that three psychic “Precogs” predict they will commit. The system’s mistake is not making predictions. It is treating a projected future as fact.

Your LLM has a prompt containing seven days of bandwidth measurements.

Don’t make the same mistake.

The problem in Minority Report was not prediction itself. It was acting as if one predicted future had already happened.

It is easy to give a model recent utilization data and ask:

Predict bandwidth usage for the next 24 hours. Identify when this link will reach capacity 

The answer may look convincing. You may get an hourly forecast, a predicted peak and a confident recommendation to increase capacity. But you might want to check the following:

• But where did those numbers come from?

• What forecasting method was used?

• Did the model account for seasonality?

• Was the recent spike an actual trend or the end-of-month backup window?

• What is the expected error?

• How wide is the uncertainty range?

If the response cannot answer those questions, you do not have a forecast. You have plausible numbers in forecast-shaped prose.

Separate calculation from explanation

A general chat model can be useful in a performance-analysis workflow. It just should not quietly become the entire workflow.

There are four different jobs here.

• Observed data comes from your monitoring system. Interface utilization, latency, packet loss and error rates belong here, together with the collection period and sampling interval.

• Calculated metrics come from code. Baselines, peaks, rolling averages, rates of change and threshold breaches should be reproducible from the same input.

• Forecasts come from an identified method that has been tested on historical data. The result should include its horizon, assumptions and uncertainty, not only a line climbing towards 100%.

• Interpretation is where the LLM can help. It can summarize the calculated evidence, explain operational implications and suggest what an engineer should inspect next.

Collapsing those jobs into one prompt hides which parts are measured, which are calculated and which are merely predicted.

The research is more careful than the prompt

There is credible research showing that language models can perform time-series forecasting.

But those experiments involve more than pasting a column of numbers into a chat window.

The LLMTime research presented at NeurIPS preprocesses and rescales numerical sequences, controls how they are tokenized and evaluates the results against established forecasting methods.

A later study of LLM forecasting behaviour found that performance varies with the structure of the data. Models performed better when patterns and seasonality were clear, struggled more with multiple periods and were particularly sensitive to the most recent part of the input.

That is useful work. It is also very different from asking a general chat model to inspect recent telemetry and trusting the next 24 numbers it produces.

The architecture may contain an LLM. That does not remove the need for a forecasting method, evaluation data and error measurement.

Give every prediction a contract

Before a prediction reaches an engineer, or another agent, make the workflow return a structured record:

Metric: 
Device or interface: 
Observation window: 
Sampling interval: 

Observed: 
Calculated: 

Forecast method: 
Forecast horizon: 
Expected range: 
Uncertainty or error: 
Assumptions:  

LLM interpretation: 
Recommended checks: 
Unknowns: 

The boundaries matter more than the format.

• Observed must contain only values present in the source telemetry.

• Calculated must contain values your code can reproduce.

• Forecast must name the method that produced it. If the workflow cannot provide an uncertainty estimate or historical error measure, it should say so.

• LLM interpretation can explain the result, but it cannot introduce a new peak, probability or time-to-capacity that the forecasting layer did not supply.

That one restriction prevents the explanation layer from quietly rewriting the evidence.

Constrain the model to its actual job

Instead of asking the model to predict the next outage, give it the output from your approved analytics or forecasting pipeline:

You are reviewing the output of a network-performance 

forecasting pipeline. 

 
Rules: 

- Treat only the supplied values as facts. 

- Do not calculate or invent additional forecasts. 

- Keep observed, calculated and forecast values separate. 

- If uncertainty or historical error is missing, state that 

  the forecast is incomplete. 

- Recommend investigation steps, not configuration changes. 
 
Observed data: 
[INSERT OBSERVED METRICS] 

Calculated metrics: 
[INSERT REPRODUCIBLE CALCULATIONS] 

Forecast: 
[INSERT METHOD, HORIZON, RANGE AND UNCERTAINTY] 

 
Return: 

1. Operational interpretation 

2. Evidence supporting the interpretation 

3. Conditions that could invalidate the forecast 

4. Checks an engineer should perform 

5. Unknowns 

Now the model is doing something it is well suited to do: turning structured technical results into a useful operational explanation.

It is not being asked to disguise extrapolation as telemetry.

Test the pipeline backwards

You would not trust a monitoring alert without knowing which threshold fired. Apply the same discipline here.

When a forecast says an interface will reach capacity within 48 hours, work backwards:

• Which output contains that prediction?

• Which method produced it?

• Which observations influenced it?

• How has that method performed on previous windows?

• What uncertainty surrounds the result?

• What condition would prove it wrong?

If the trail ends at “the LLM said so,” the workflow is not ready to drive an operational decision.

Try this with one metric

Pick one interface and one metric your team already understands.Run the comparison twice.

First, give the raw observations to a general chat model and ask it to predict the next 24 hours.

Then run the data through an existing analytics or forecasting method. Give the resulting baseline, forecast and uncertainty to the model using the constrained prompt above.

Compare the responses.

The first may sound more certain. The second should make it easier to see where every claim came from, and where the unknowns remain.

That is the result you want.

The problem in Minority Report was not that the system made predictions. It was that people began treating a predicted future as an observed fact.

Your NOC needs that distinction too.

Calculate the trend. Validate the forecast. Let the LLM explain it. But keep the future labelled as the future.

Cheers,

Sayali

Editor-in-Chief

A prediction is only as trustworthy as the telemetry beneath it. Before adding forecasting or AI-generated interpretation, you need an observability stack that can show what the network is actually doing.

September 19 – Building a Network Observability Stack with Tools, Automation and AI

LEARN MORE

If the argument above only holds if your observability stack can actually produce clean, structured telemetry in the first place. Most NOCs can’t yet. They have dashboards, but not the pipeline that turns raw signals into something a forecasting method (or an LLM) can trust.

Christian Adell and David Flores are building that pipeline live, with Telegraf, Prometheus, Grafana, PromQL and LogQL.
You’ll walk out with working dashboards, alerts that understand intent instead of just thresholds, and a clear line for where AI-assisted anomaly detection actually earns its place versus where it doesn’t.

If the “contract” idea above made sense to you, this is the workshop that gets you the observed and calculated layers it depends on.

Thanks for reading The AI Network Engineer by Packt. Subscribe for free to receive future issues.

Before today’s piece, one upcoming hands-on session for anyone building AI-assisted NetOps workflows:

Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT

Last chance to register - Claim 50% OFF

Most AI assistants can write you a plausible-looking config. They can’t tell you if it matches your actual network, because they’ve never seen your runbooks, your device configs, or your topology.

Sif Baksh (Principal Solutions Architect at Tines) spends this workshop building the piece that’s missing: a RAG-powered NetOps assistant that answers from your own runbooks and device configs instead of general training data, with guardrails that make it flag what it doesn’t know instead of guessing.

Four hours. Four labs. You’ll leave with a working assistant and a workflow you can keep testing after the session.

For AI Network Engineer readers: code FINAL50 gets you 50% off all passes.

P.S. Sif wrote the book on this, literally. Building AI Agents for Network Operations goes deeper into the architecture than four hours allows. Bundle it at checkout, or grab it on its own if Tuesday doesn’t work.

Now, back to today’s test.

Your AI model needs an acceptance test

Ask someone which AI model you should use for network operations and you’ll usually get a model name.

That’s the wrong place to start.

A model can perform well on a general benchmark and still miss a requirement your workflow cannot afford to miss. Another may be unnecessary for routine summaries but worth the cost for complex troubleshooting.

You don’t need a favourite model.

You need an acceptance test

Start with the job, not the model

Suppose you give two models this prompt:

Configure OSPF on a router. 

Both responses may look reasonable. But the task is too vague to tell you much.

Which platform? Which area? What should become the router ID? Should the response include verification? What information is the model allowed to assume?

A better test looks like this:

Prepare an OSPF configuration plan for a Cisco IOS-XE router.  

Requirements: 

 - Use area 0 

 - Use Loopback 0 as the router ID 

 - Do not invent interface addresses 

 - List any missing information as an assumption 

 - Include verification commands  

Return: 

 1. Configuration plan 

 2. Assumptions 

 3. Verification steps 

Now the model has constraints it can either satisfy or miss.

That makes the response easier to evaluate. It also makes failures visible before you spend time debating which answer sounds more polished.

Write the answer key first

Before running the prompt, decide what a passing response must contain.

For the OSPF task, you might expect:

• IOS-XE-compatible syntax

• Area 0 applied correctly

• Loopback 0 used as the router ID

• Missing interface or address information identified

• Verification commands included

Then define the hard failures:

• Invented IP addresses

• Syntax from another network operating system

• Unstated assumptions

• Missing verification

• A claim that the configuration is ready to apply without checking the current device state

This is the part most informal model comparisons skip.

If you wait until after reading the responses to decide what matters, the most fluent answer tends to set the standard. Your evaluation becomes a writing contest.

The answer key prevents that.

Run every candidate under the same conditions

Use the same task, context, return format and response settings for every candidate model.

Save the raw responses rather than relying on what you remember from the chat window. Record the model version and the date too. Model behaviour changes, and an evaluation you cannot reproduce is only a snapshot.

A compact test record can look like this:

Task ID:  

Workflow:  

Prompt:  

Expected facts:  

Hard failures:  

Required format:  

Model and version:  

Response:  

Reviewer result:  

Observed cost:  

Test date: 

For a small comparison, a spreadsheet is enough. The important thing is that every model sees the same test and every response faces the same standard.

Don’t ask another model to be the only judge

Using an evaluator model can help sort a large response set. It can identify missing sections, compare formats and produce an initial score.

But it should not own the answer key.

The evaluator is still a model. It can overlook the same plausible-looking technical mistake you are trying to catch.

Let it assist with the comparison. Keep a network engineer responsible for defining the expected facts, reviewing hard failures and approving the result.

For a fairer comparison, hide the model names during review. “Response A” and “Response B” are harder to favour than two brands the reviewer already has opinions about.

Score by workflow, not only by model

Do not collapse every result into one overall number too early.

Separate the tasks by the work the model will perform:

• Configuration planning

• Troubleshooting

• Documentation

• Log or ticket summarization

• Structured data extraction

A model that performs well on documentation may not be the strongest choice for troubleshooting. Another may follow a JSON schema reliably but produce weak operational recommendations.

Different workflows may justify different models.

You already work this way with network tools. The application used for packet analysis does not need to be the same one used for configuration management. Model selection should follow the same logic.

Compare cost only after quality

Cost matters, especially when a workflow will run hundreds or thousands of times.

But a cheap response that fails a mandatory technical check is not better value. It is a failed response delivered inexpensively.

Use the acceptance criteria as the first gate:

• Did the response include the required facts?

• Did it avoid every hard failure?

• Did it follow the requested format?

Only the models that pass should move into the cost comparison.

Then you can ask whether the improvement from a more expensive model is meaningful for this particular workflow.

Try this today

Choose two models and four tasks your team already understands:

• Two configuration-planning tasks

• Two troubleshooting tasks

Use resolved tickets, reviewed MOPs or lab scenarios as your source. Remove credentials, customer data and sensitive infrastructure details before using an external service.

Write the expected facts and hard failures first. Run each model under the same conditions. Save the responses and review them without the model names visible.

You do not need a hundred-question benchmark to learn something useful.

Four well-chosen network tasks will tell you more about your workflow than a general leaderboard ever will.

Stop asking which model is best.

Ask which model passed your acceptance test.

Cheers,
Sayali
Editor-in-Chief

Upcoming live workshops

The tool boundary is only half the production story. The next questions are what happens after an agent proposes a change and how access is governed. These two upcoming sessions approach those problems from different sides.

Aug 27 · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder and CEO of AI Guru, will show you how to build an infrastructure agent that reads pod events, correlates live metrics and proposes fixes—but executes them only after approval.

You’ll work through seven production-grade failure scenarios injected into your own local Kubernetes cluster, which you can keep and rerun after the session.

Claim 50% Off

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

If this issue helped sharpen the conversation, please like it or leave a comment so more platform, cloud, security and infrastructure engineers can find it.

Thanks for reading The AI Network Engineer by Packt. Subscribe for free to receive future issues.

Before today’s piece, here’s a practical way to explore the same production-safety questions hands-on.

Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT

Register now at 40% off

In this four-hour workshop, Sif Baksh will guide you through building a RAG-powered NetOps assistant that answers from your own runbooks and device configurations, with guardrails around how those answers are produced and used.

You’ll leave with four completed labs and a workflow you can continue testing after the session.

Four hours. Four labs. For AI Network Engineer readers, use code LIMITED40 for 40% off all passes.

P.S. Sif’s book, Building AI Agents for Network Operations, covers the same architecture in greater depth. You can bundle it with the event pass at checkout or purchase it separately if the workshop date doesn’t work for you.

Now, back to the tool boundary.

Why run_command () doesn’t belong in your first network agent

You’re building the tool layer for a network agent. You already have a device inventory and an SSH library that works.

There’s an obvious shortcut sitting right there:

run_command(device, command) 

One function. Every command. Every vendor. Anything you haven’t anticipated yet.

You could ship it this afternoon.

Don’t.

Flexibility is the risk surface

A general-purpose tool means you don’t have to enumerate what the agent might need.

That is also what makes it dangerous.

The model composes the action, while your policy layer receives an arbitrary string at runtime and has to decide whether it is safe. Every new command and vendor behaviour expands the set of cases that layer must interpret correctly.

You end up building a command parser and treating it as a security boundary.

Narrow tools move that decision from runtime to design time.

bgp_summary(device) 

That tool has one purpose. It accepts a known argument, returns a defined shape and cannot be persuaded to perform an unrelated operation.

The safety property is structural. It does not depend on the model remembering an instruction or your code correctly interpreting a new command string.

Sif Baksh draws this boundary clearly in Building AI Agents for Network Operations: prompts can guide behaviour, but code enforces policy.

A tool that cannot perform an unsafe action is stronger than a prompt asking the model not to perform one.

Start with the questions your team actually asks

Your first tool set does not need to cover every operational possibility. It needs to cover a small number of useful, low-risk questions.

device_status(device) · Low risk
Allow authenticated users and approved devices.

interface_status(device) · Low risk
Allow and log every call.

bgp_summary(device) · Low risk
Allow and log every call.

show_command(device, command) · Medium risk
Accept commands only from a fixed allowlist.

run_command(device, command) · High risk
Replace with narrower tools.

Configuration-change tools · High risk
Require approval, a ticket reference, a diff, and a rollback plan.

Restart or clear-session tools · High risk
Keep out of scope for the first pilot.

show_command() is the compromise.

It is general enough to support several read-only checks, but the requested command must match an approved list. If it is not on that list, the tool refuses the request and records the decision.

This is different from checking whether an arbitrary command looks safe. The allowlist defines what is permitted before the agent runs.

More tools also mean more possible actions to evaluate, test and audit. Start with tools that map to real operational questions. Add another only when you can define its purpose, inputs, outputs and failure behaviour.

Write down the contract

Once a tool exists, other components start depending on it: the agent, another client and eventually someone else’s workflow.

Treat it as an interface with a documented contract:

tool_contract: 

  name: "bgp_summary" 

  owner: "Network automation team" 

  purpose: "Return BGP neighbor state for an approved device" 

 

  arguments: 

    device: 

      type: "string" 

      required: true 

      validation: "must exist in approved device allowlist" 

 

  returns: 

    device: "string" 

    total_peers: "integer" 

    established_peers: "integer" 

    neighbors: "array" 

 

  blocked_when: 

    - "device is unknown" 

    - "backend times out" 

 

  logs: 

    - "user_or_client_id" 

    - "tool" 

    - "device" 

    - "decision.allowed" 

    - "duration_ms" 

Two fields do disproportionate work:

• blocked_when forces you to decide how the tool fails before you discover its behaviour during an incident.

• owner puts a name against future decisions. If every tool belongs to everyone, nobody owns the boundary when it needs to change.

Once other components depend on the tool’s name, arguments or return shape, changing them becomes a compatibility decision, not a casual refactor.

Log the decision, not only the call

Every invocation should leave a structured record, including blocked requests.

{ 

  "timestamp": "2026-06-28T18:36:38Z", 

  "user_or_client_id": "noc-operator-1", 

  "tool": "show_command", 

  "device": "spine1", 

  "command": "show ip bgp summary", 

  "decision": { 

    "allowed": true, 

    "reason": "read-only command approved", 

    "risk": "low", 

    "requires_approval": false 

  }, 

  "result_summary": "success" 

} 

The decision block is the important part. It records not only what happened, but why the system permitted it.

Blocked calls are useful too. They show which capabilities users keep requesting. That gives you evidence for deciding whether to build a narrow version properly or keep the boundary closed.

Keep secrets and full tool payloads out of these records. Log enough to audit the action without creating another place for sensitive data to collect.

Try this on your tool layer

Start with three checks:

1. Inventory the tool surface

List every tool the agent can call. For each one, describe the worst thing it could do if called with the least helpful arguments the model could construct.

If the answer makes you uncomfortable, narrow or disable the tool.

2. Put tool access in configuration

{ 

  "tools": { 

    "device_status": { 

      "enabled": true 

    }, 

    "bgp_summary": { 

      "enabled": true 

    }, 

    "show_command": { 

      "enabled": true, 

      "read_only_only": true 

    }, 

    "configure_interface": { 

      "enabled": false 

    } 

  }, 

  "global_kill_switch": false, 

  "allowed_environment": "read_only_pilot" 

} 

This lets you enable capabilities for a limited pilot, keep write tools disabled until the approval path exists and reduce the agent’s scope without changing its prompt.

3. Ask how quickly someone else can stop it.

If the agent starts behaving unexpectedly at 4 p.m. on a Friday, how quickly can an operator who did not build it disable its tools?

If the answer involves finding a repository, editing a prompt and waiting for a deployment, the shutdown path is not ready.

The safest agent is not the one you expect to make good decisions every time.

It is the one whose tools make the dangerous decisions unavailable.

Further reading: This issue draws on Building AI Agents for Network Operations by Sif Baksh. Chapter 9 covers authentication, secrets, approval workflows, observability, staged rollout and the production go/no-go review. Appendix A includes tool-contract, runbook and readiness worksheets.

EXPLORE THE BOOK →

What’s next: Narrow tools define what an agent can do. The next production question is who can request an action, and who has the authority to approve it.

Cheers,
Sayali
Editor-in-Chief

Upcoming live workshops

The tool boundary is only half the production story. The next questions are what happens after an agent proposes a change and how access is governed. These two upcoming sessions approach those problems from different sides.

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, will show you how to build an infrastructure agent that reads pod events, correlates live metrics and proposes fixes—but executes them only after approval.

You’ll work through seven production-grade failure scenarios injected into your own local Kubernetes cluster, which you can keep and rerun after the session.

Book Now

If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.

Check it out on Amazon

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.

Check it out on Amazon

If you’re a regular reader, hit reply and tell me which content would be most useful for your team: hands-on agent patterns, security and guardrails, or practical tool reviews.

If this issue helped sharpen the conversation, please like it or leave a comment so more platform, cloud, security and infrastructure engineers can find it.

Thanks for reading The AI Network Engineer by Packt. Subscribe for free to receive future issues.

Today’s story is about an agent that told an engineer a device was fine while its own tool output said otherwise. Before we get into it, Sif Baksh, whose book this issue draws from, is running a hands-on workshop on August 25th that walks through exactly this problem: building the evidence checks that catch an agent lying to you in fluent prose.

Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT

Claim 40% Off

If you’ve ever had an agent tell you everything looked fine while the raw output said otherwise, you already know why this session exists. In this four-hour hands-on workshop, you build a RAG-powered NetOps assistant that answers from your own runbooks and device configs, then build the evidence record and response checks that stop it from writing a confident summary its own tool output disagrees with. Same failure mode as today’s story, except you’re the one building the guardrail.

Four hours. Four labs. For AI Network Engineer readers, use code LIMITED40 for 40% off all passes.

P.S. My book, Building AI Agents for Network Operations, goes deeper into the same architecture. You can bundle it with your event pass at checkout, or pick it up separately if the 25th does not work for your calendar.

That's the hands-on version. Now, the story.

Your troubleshooting agent finishes its run and gives you this:

leaf2 appears to be functioning normally. It has two established peers and no major connectivity issues. 

Clear. Confident. Well-written.

Now scroll up to the tool output it was summarizing. total_peers: 2. established_peers: 1. Neighbor 10.1.2.2 sitting in Idle with zero prefixes received. And Ethernet3, described as server_rack_2, is down.

The prose is fluent. The evidence disagrees.

Two outputs. Only one is evidence

This is one of the easiest failure modes to miss in agentic troubleshooting, especially in a polished demo.

A tool-using agent produces two distinct things.

• First, the tool results: what get_bgp_summary() actually returned and what ping_device() actually reported.

• Second, the final summary: natural language written about those results.

The second is another model-generated output. It can omit, soften, or contradict facts that appeared in the tool results, even when the underlying investigation was correct.

During an incident, a confident wrong summary is worse than no summary. It sends someone down the wrong path with the reassurance of a second opinion attached.

So the rule is simple: when the summary and the tool output disagree, the evidence wins. Always.

The final model response is never more authoritative than the tool results it describes.

That means you need something in your system that can tell when they disagree.

Better prompts help. They don’t close the gap.

You can reduce the drift with prompt rules, and you should.

Instructions such as always compare established_peers against total_peers, always name any neighbor not in Established state, treat zero prefixes received as possible routing impact, and never claim there are no issues if a tool returned an error or degraded state can meaningfully improve the output.

But prompt rules are guidance, not enforcement.

They make the good answer more likely. They don’t make the bad answer impossible. If your only defence against a wrong conclusion is a bullet point in a system prompt, you don’t have a defence.

The enforcement has to live outside the model.

Build an evidence record

Sif Baksh demonstrates a useful approach in Building AI Agents for Network Operations.

Alongside the conversation history the model reasons over, the application builds a separate, structured record of what was checked and what looked unhealthy. The model doesn’t write this record. Your code assembles it from the raw tool results.

For the leaf2 case, the record holds:

• Device status: up

• Down interface: Ethernet3, described as server_rack_2

• Total BGP peers: 2

• Established BGP peers: 1

• Non-established neighbor: 10.1.2.2, Idle, with zero prefixes received

Once those facts exist as data rather than prose, your application can derive rules from them:

• If established_peers < total_peers, the response must flag a BGP issue.

• If a neighbor isn’t Established, the response must identify that neighbor.

• If a neighbor reports zero prefixes received, the response should flag possible route impact.

• If ping_device() returns unreachable, the response must not describe the target as reachable.

• If a tool returns an error, the response must surface it or request another check.

The evidence checks themselves do not need another model. Your code can derive them directly from the tool results.

To enforce them reliably, require the final response in structured fields before rendering it as prose. That gives the application something deterministic to validate instead of searching an unrestricted paragraph for the right conclusion.

Careful wording is a feature

Say a host at 10.99.99.99 is unreachable and the agent is asked whether BGP on leaf2 might be involved.

The ping tool returns 100% loss. That proves reachability failed. It does not prove why.

If the BGP summary also shows an Idle neighbor, the honest answer is that the failed session may be related to a missing route, not that BGP caused it.

Hedging in a troubleshooting summary can look like weakness. Here, it’s the opposite.

An agent that separates what it confirmed from what it inferred is far more useful during a 2 a.m. incident.

Try this

Give your agent’s final response a fixed shape with five structured parts:

• Finding: The short operational conclusion.

• Evidence: The specific tool results supporting it, recorded as facts. For example: leaf2 status is up, BGP total_peers is 2, BGP established_peers is 1, and neighbor 10.1.2.2 is Idle.

• Likely cause: A clearly labelled hypothesis, using may be or likely rather than certainty the evidence doesn’t support.

• Next checks: What the engineer should verify or approve.

• Unknowns: What the agent did not check.

That last section is the one to fight for. It keeps the agent honest.

If the route table was never inspected directly, the response should say so. If only reachability was tested, it should say that the route itself wasn’t examined.

Then run your evidence checks against those structured fields before displaying the final answer. If a check fails, don’t show the answer. Show the mismatch.

The summary is a view of the evidence. It is not the evidence itself.

When the two disagree, trust what the tools returned; not how confidently the agent described it.

Thanks,

Sayali

Editor-in-Chief

This issue draws on Building AI Agents for Network Operations by Sif Baksh. Chapter 7 follows the leaf2 investigation step by step, including the evidence record and response checks.

Get the Book

The evidence-versus-summary problem doesn't stop at troubleshooting. It shows up the moment an agent proposes a change, or the moment you're deciding who's allowed to approve one. That's the thread running through the next two sessions.

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.

Book Now

If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.

Check it out on Amazon

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.

Check it out on Amazon

Before you go, I’d like to hear from regular CloudPro readers. Hit reply and tell me what would be most useful for your team. And if this issue helped sharpen the conversation, please like it and leave a comment so more platform, cloud, security, and infrastructure folks can find it.

You’ve got an LLM turning show interface output into JSON. It works across your test samples, the fields come back clean, and you wire it into the next step.

Now give it this:

GigabitEthernet0/1 is up, line protocol is down (err-disabled) 

If the model returns a neat JSON object describing a healthy interface, json.loads() will accept it without complaint.

Nothing crashed. That’s the problem.

Subscribe now

Model output must clear two gates, not one

When json.loads() succeeds, you’ve cleared the first gate: the response is syntactically valid JSON.

That tells you nothing about whether the content is correct. Valid JSON can still:

• Omit a required field

• Return an MTU as text instead of an integer

• Return a state your schema doesn’t allow

• Invent a value that never appeared in the source output

The second gate is validation, and it belongs in your code.

Sif Baksh draws this boundary clearly in Building AI Agents for Network Operations: the model helps transform the text, but the application owns the trust decision. Until your code validates it, an LLM response is only candidate data.

First ask whether you need the model

If the device returns native JSON, use it.

If a reliable TextFSM template already exists, use it. If the format is stable and under your control, a deterministic parser will usually be faster, cheaper, and easier to test.

LLM-assisted parsing earns its place in a narrower band.

The clearest example is multi-vendor normalization. Cisco IOS might return GigabitEthernet0/1, Arista Ethernet1, and Juniper ge-0/0/1.0. The text differs, but you may want each result mapped into the same shape:

{ 
  "interface": "...", 
  "admin_status": "...", 
  "oper_status": "..." 
} 

The other good fit is text that was never structured to begin with: incident notes, ticket bodies, or mixed log output containing prose.

Use the model where flexibility helps. Keep exact decisions in deterministic code.

Validate the smallest useful shape

Start by checking whether every required field exists:

expected = [ 

    "interface", 
    "admin_status", 
    "oper_status", 
    "ip_address", 
    "mtu", 
] 
missing = [ 

    field for field in expected 
    if field not in result 

] 
if missing: 

    print(f"Missing fields: {missing}") 

else: 

    print("All expected fields present!") 

This is only the first validation check. A production workflow should also confirm:

• Each field has the expected type

• Status values come from an allowed set

• Values agree with the source data where possible

• Missing or unsupported values are handled safely

A typed data model or validation library such as Pydantic makes these checks easier to enforce before anything downstream touches the result.

The key phrase is before anything downstream touches it. Logging a validation warning while still passing the object forward defeats the point.

Validated output is only one part of a safe workflow. If the next step is an infrastructure change, policy enforcement and approvals need to live in the execution layer, not in the prompt.

Turn infrastructure intent into governed execution

Stop managing IaC manually. Spacelift brings AI-native orchestration to Terraform, OpenTofu, Ansible, and more. With automatic drift detection, policy as code, approval workflows, and natural-language provisioning through Spacelift Intelligence, teams can accelerate infrastructure delivery while retaining the governance and visibility production environments require.

TRY SPACELIFT ON AWS MARKETPLACE →

Give uncertainty somewhere to live

Real device output doesn’t always fit neatly into up or down.

An interface may be err-disabled. A port may be flapping, leaving its current state unclear. A command may return % No interface information available.

If your schema only permits clean states, the model has two choices: break the schema or guess. Models are very good at choosing the second option.

Allow states such as unknown, and include fields such as error_reason and warning. Keep those fields empty unless the reason appears in the source data. A failed command should return a controlled error or an explicitly uncertain result – never a confident, invented status.

The same rule applies when the model produces malformed output. It may wrap JSON in Markdown fences or add a helpful sentence before the object. Strip the common wrappers and retry. If it still won’t parse, return a structured error and let the caller decide what happens next.

Never fail silently, and never pass a half-valid result forward.

Try this on one parser

Take one parser you already use (or the next one you’re planning), and check whether it does these five things:

1. Requests only the fields the workflow actually needs.

2. Uses a low temperature for predictable output.

3. Checks required keys, types, and allowed values.

4. Represents missing or uncertain data explicitly.

5. Stops the workflow when validation fails and logs the raw input, model response, and parsed result.

That last check pays for itself the first time something breaks during an incident. You need to know whether the device returned unexpected data, the model produced a bad response, or your code accepted something it should have rejected.

This issue draws on Building AI Agents for Network Operations by Sif Baksh, out now from Packt. Chapter 4 is the one to read if you’re building parsers. The labs run on local models via Ollama with mocked device data, so you can work through the whole thing without touching a production device.

Get the book

Agentic RAG for Network Operations - Tuesday, August 25th, 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines, himself is teaching you how to build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of the open internet, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll also learn the guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can trust mid-incident.

This one’s capped on seats and going quicker than usual. Use code LIMITED40 for 40% off.

Book Now

P.S. - We have a special bundle for you where along with the event you get access to the book. Avail now

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.

Book Now

If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.

Check it out on Amazon

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.

Check it out on Amazon

AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

This event is happening next Thursday, don’t miss out!
Most AI-in-GitOps failures trace back to one thing: stale context, not a bad model. Taylor Dolezal (Head of OSS at Dosu) has seen this pattern across 100,000+ repos, and this session runs a live query against fresh vs. stale knowledge side by side, so you can see where the token cost actually goes and where the accuracy breaks down before you build anything on top of it.

Use code FINAL50 for 50% off.

Book Now

One signal is not a diagnosis

Your monitoring system reports packet loss on a production link.

An AI agent checks the alert, identifies a recent configuration change, and recommends rolling it back.

The explanation sounds convincing. But is it enough to act on?

Not yet.

A single signal can reveal a symptom. It rarely proves the cause.

Make the agent show its evidence

Before an AI agent recommends a network change, require it to find three things:

• The symptom: What does the telemetry show?

• A plausible cause: What configuration, event, or change could explain it?

• Independent confirmation: What other source supports, or contradicts, the diagnosis?

Consider the packet-loss alert:

• Interface telemetry shows a rise in errors.

• The change log shows that the interface configuration was updated shortly before the errors began.

• A path test confirms that the loss is isolated to that link.

Now the recommendation is supported by evidence, not just correlation.

If the signals do not agree, the agent should not force a conclusion. It should show what is missing and escalate the investigation.

That is the difference between an agent that produces a plausible answer and one that supports a defensible decision.

Thanks,
Sayali
Editor-in-Chief

P.S. When an AI-generated diagnosis looks convincing, what evidence does your team check before acting on it? Reply and tell us.

Here’s our star event for the month of August, Sif Baksh returns again!

Agentic RAG for Network Operations - Thursday, August 25th · 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.

Use code SPECIAL40 for a 40% off on the event

Book your tickets

Agentic AI for Infrastructure Engineering: From Chatbots to Operators -
Thursday, August 27th - 9:30 AM EDT

Ritesh Vajariya, the AI Guru himself takes you past the documentation chatbot stage: an infrastructure agent that reads live pod events and Prometheus metrics through MCP tools, correlates them against your runbooks, and tells you why your model-serving pods are crashlooping right now, not what a stale doc says about crashloops in general. You’ll build the three-layer architecture (knowledge, live-state, gated action) from the raw LLM API and MCP SDK, work through GPU scheduling failures and rollback scenarios on a disposable local Kubernetes cluster, and walk away with the guardrail patterns (approval gates, dry-run, scoped credentials) that make the difference between an agent that answers and one you’d actually let touch production.

Use code EARLY40 for 40% off.

Book now

Before you go, maybe a few books worth having on your shelf

1. LLMs for Modern Software Delivery and DevOps - Gu Huangliang, Zheng Qingzheng, Niu Xiaoling, Che Xin
   

   Check it out on Amazon →

Taylor’s upcoming GitOps workshop on 30th July is built around one idea: knowledge freshness beats model choice. This book takes that same premise and runs it across the entire delivery lifecycle, log triage, testing, code review, incident response, so if the workshop’s context-engineering angle clicked, this is the fuller playbook behind it.

2. From Cloud Native to AI Native - Pini Reznik, Michael Müller
   

   Check it out on Amazon →

This book is about how the same cloud-native patterns you already trust (GitOps, Kubernetes, observability) extend into AI-native architecture, instead of getting ripped out and replaced.

2. The Self-Taught Cloud Computing Engineer - Dr. Logan Song

   Check it out on Amazon →

If you’re building toward a platform or SRE role and keep bouncing between AWS, Azure, and GCP docs without a throughline, this book takes the “learn one deeply, then compare“ approach instead of three separate crash courses, compute, storage, security, and ML services mapped across all three.

AI agents are moving into prod. Is your secrets strategy ready for that?

Find out at the webinar on July 22.

Register Now

Your AI agent needs a stop condition

Last week, we talked about giving AI agents a context contract: a clear definition of what information they can access, trust, and use.

But even with the right context, an agent can still make the wrong move.

Why?

Because knowing what to consider is not the same as knowing when to stop.

Imagine an agent investigating a network incident. It checks interface status, reviews recent configuration changes, and summarizes the logs.

So far, so good.

But what happens when the evidence is incomplete? Does it keep investigating? Restart a service? Roll back a configuration? Escalate to an engineer?

Without a defined stop condition, the agent has to guess.

Define the boundary before the workflow

For every agentic workflow, answer three questions:

• What can the agent do independently?

• What conditions require human approval?

• What evidence must it provide before escalating?

A stop condition might look like this:

The agent may collect telemetry, compare configurations, and recommend a remediation. It must stop before making a production change unless the diagnosis is supported by two independent signals and an engineer approves the action.

That single rule turns an open-ended agent into a controlled workflow.

A useful stop condition should cover:

• Confidence: How certain must the agent be?

• Impact: Which actions are too risky to perform autonomously?

• Evidence: What must the agent show before recommending or taking action?

• Escalation: Who takes over when the boundary is reached?

The goal is not to prevent autonomy. It is to make autonomy predictable.

Because the safest agent is not the one that can do everything. It is the one that knows when it should hand control back to you.

Before deploying your next AI workflow, run it through this five-minute test.

Download the AI Agent Stop-Condition Checklist

Thanks,

Sayali

Editor-in-Chief

P.S. What is one action your team would never allow an AI agent to take without human approval? Reply and tell us.

Take a look at our upcoming workshops that point to the same issue from different angles.

1. Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT

Where do agents and MCP servers actually belong in a Kubernetes stack?

Most platform teams are still guessing. Michael Rishi Forrester (Accenture) spends four hours building a 33-component AI-native IDP live, on a provisioned cluster, with Claude Code doing the actual work: scaffolding Helm values, wiring up ArgoCD’s App-of-Apps, resolving sync issues as they come up. You clone the repo when it’s done and it runs.

Use code EMAIL40 for 40% off.

Book Now →

2. AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

Most AI-in-GitOps failures trace back to one thing: stale context, not a bad model. Taylor Dolezal (Head of OSS at Dosu) has seen this pattern across 100,000+ repos, and this session runs a live query against fresh vs. stale knowledge side by side, so you can see where the token cost actually goes and where the accuracy breaks down before you build anything on top of it.

Use code EMAIL40 for 40% off.

Book now →

Both sessions are teaching the same shift from two different angles, Michael’s building the platform itself, Taylor’s making sure the agents on it aren’t running on stale context. Worth sitting through both if you’re the one who’ll own this stack. Bundle Pass gets you both for 25% off - use code BUNDLE25.

Grab the bundle!

Agentic RAG for Network Operations - Thursday, August 25th · 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.

Use code SPECIAL40 for a 40% off on the event

Register now

Before you go, maybe a few books worth having on your shelf

1. Operational AI with Docker - Ajeet Singh Raina & Harsh Manvar
   

   Check it out on Amazon →

If Michael’s event - Agentic DevOps with Claude IDP build got you thinking about what it actually takes to run agentic workloads in production, not just prototype them, this is the deeper dive. It covers containerizing, serving, and scaling LLMs and multi-agent pipelines with Docker and Kubernetes, the infrastructure layer most “AI for DevOps“ content skips past.

2. AI Networking Cookbook - Eric Chou
   

   Check it out on Amazon →

2. Pairs naturally with Sif’s session on Agentic RAG for Network Operations. Where the workshop builds you a RAG assistant for troubleshooting, this book is recipes for the other side, using AI to automate config, monitoring, and threat detection across multi-vendor network environments, with working code for each one.

3. Microsoft Intune Cookbook, 2nd Edition - Andrew Taylor

   Check it out on Amazon →

For anyone managing endpoints rather than the network layer, practical recipes for securing and automating devices across Windows, macOS, iOS, Android, and Linux, including where Security Copilot and Graph API now fit into day-to-day admin work.

Check it out on Amazon →

Is your secrets strategy ready for AI agents?

Save your seat for Infisical’s webinar on July 22.

Register now

Now, back to infrastructure and AI.

Last issue, we shared a three-part test for AI workflows:

Fresh context. Clear validation. Reusable workflows.

This week, let’s stay with the first one.

Giving an agent access to current information does not automatically mean it has the right information.

Imagine an agent reviewing an infrastructure change. It can access the live configuration, an old architecture diagram, several runbooks, a recent incident ticket, and a Slack thread describing a temporary workaround.

Technically, the agent has plenty of context. Operationally, it has a trust problem.

• Which source should it prioritize?

• How recent is recent enough?

• What should happen when two sources disagree?

What the agent needs is a context contract.

A context contract defines three things before the workflow starts.

1. Which source is authoritative?

Not every document deserves equal weight. Define a clear order, for example:

1. Live system state

2. Version-controlled configuration

3. Approved runbooks

4. Incident and change records

5. Informal discussions

The agent shouldn’t have to guess what wins.

2. How fresh must the information be?

“Current” depends on the task, for example:

• A troubleshooting agent may need device state from the last few minutes.

• A capacity-planning workflow may be fine with yesterday’s data.

• A policy document may remain valid for months.

Set a freshness threshold. If the available context is older, the agent should flag it rather than quietly reasoning from stale information.

3. What happens when sources conflict?

Conflict is normal. The running configuration may not match Git. A runbook may describe a process that the latest incident proved incomplete.

The safest rule is simple:

If live state and the approved source of truth disagree, stop, show the conflict, and request human review.

Fresh context is not about connecting an agent to everything. It is about giving it the right sources, in the right order, with clear rules for handling uncertainty.

Thanks,

Sayali

Editor-in-Chief

P.S. What source does your team trust when the documentation, Git repository, and live environment disagree? Reply and tell us how you resolve it. Your approach may help shape a future issue.

Both sessions point to the same issue from different angles.

Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT

Michael Rishi Forrester (Accenture) helps you build a live, 33-component AI-native Kubernetes platform in four hours, so you walk away with a working IDP you can clone and run Monday, not another slide deck. You’ll also get a reference architecture showing exactly where agents and MCP servers belong in your stack, something most teams are still guessing at.

Book Now →

AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

Taylor Dolezal (Head of OSS at Dosu) helps you pinpoint exactly where AI agents earn their keep in GitOps workflows, drawn from patterns across 100,000+ repos Dosu supports. You’ll also walk through a live demo comparing fresh vs. stale knowledge, so you can see the token-cost and accuracy tradeoffs before you build anything.

Book now →

Given this is fast becoming a must-know skillset for every platform and DevOps engineer, grab the Bundle Pass for both sessions at 40% off instead of buying separately

Grab the Bundle!

Before you go, a book worth having on your shelf

If this issue made you realize your AWS/Azure/GCP fundamentals could use a refresh, The Self-Taught Cloud Computing Engineer by Dr. Logan Song is a solid pick. It’s a structured, hands-on guide covering compute, storage, networking, data, security, and AI across all three major clouds, rated 4.8★ from over 350+ readers.

Check it out on Amazon →

Social engineering is about manipulating people’s emotions. Identify the susceptibilities that hackers use to exploit people.

This NINJIO Insights Report dives into the key emotional susceptibilities that make social engineering work and offers concrete steps that your security team can take to equip your workforce to resist cyberattacks.

Download the Guide

Now, back to infrastructure and AI.

This week, we have two hands-on sessions for teams trying to move AI from side experiments into real platform and DevOps workflows.

The common thread: AI is only useful when the system around it is strong enough to keep it grounded, reviewable, and reusable.

Agentic DevOps with Claude | July 23rd

Early Bird Live Now - 40% Off | Last 48 hours before it’s sold out

Claude Code is not just generating snippets here. It is helping build the platform.

In this 4-hour live workshop, you’ll see a 33-component AI-native internal developer platform built on a real Kubernetes cluster, with ArgoCD, Backstage, kgateway, and an observability stack included.

The cluster is provisioned for you. You leave with the repo and a working reference architecture your team can study, adapt, and build on.

Michael Rishi Forrester from Accenture, previously at KodeKloud, is running this one.

Limited seats available.

📅 Thursday, July 23 | 11:00 AM EDT

Lock in Early Bird

AI-Powered GitOps and Platform Engineering Workshop | July 30th

Early Bird Live Now - 40% Off | Last 4 days before it’s gone

Your AI agent does not know your manifests are stale.

That is the problem.

In this 3-hour hands-on workshop, you’ll work through real ArgoCD and Flux workflows, see live demos comparing fresh versus stale context, and learn how to turn repeated agent tasks into tooling your team actually keeps.

The session covers drift detection, change review, validation, and the parts of platform engineering AI tools usually get wrong because nobody gave them current operational context.

Taylor Dolezal from Dosu, an AI-native knowledge infrastructure company for agents and humans, is running this one, drawing on patterns from 100,000+ repos.

Limited seats available.

📅 Thursday, July 30 | 11:00 AM EDT

Book Your Tickets

Both sessions point to the same issue from different angles.

AI is not hard to demo. It is hard to operationalize.

The moment agents get involved in real DevOps, GitOps, or platform workflows, three questions start to matter more than the prompt itself: does the agent have fresh context, is validation built in, and can the repeated task become reusable team-owned tooling?

So here’s a quick test before you give an agent more responsibility.

Start with these three questions.

1. Is the context fresh?

Most AI failures in operations do not start with a bad model, they start with stale context.

The agent answers based on yesterday’s architecture, last month’s runbook, or a ticket pattern that no longer applies.

For platform teams, context freshness matters because the environment changes constantly: manifests, service owners, policies, dependencies, deployment history, incidents, and rollback procedures.

If the agent cannot retrieve current context, it should not be trusted with current decisions.

2. Is validation built into the workflow?

AI output should not move straight from suggestion to execution, there should be a validation step.

In GitOps environments, that might mean checking manifests, reviewing diffs, validating against policy, detecting drift, or confirming that a proposed change matches the expected deployment state.

The workflow should make review easier, not optional.

The useful question is not “did the agent produce something?”

It is “can the team verify it quickly and confidently?”

3. Can the repeated task become team-owned tooling?

If an engineer keeps asking an agent the same thing every week, that is a signal.

Maybe the task should become a reusable workflow, template, validation check, or internal tool.

The goal is not to collect clever prompts.

The goal is to turn useful AI-assisted work into something the team can maintain, improve, and trust.

That is where AI starts becoming part of platform engineering instead of sitting beside it as an experiment.

The pattern is simple:

• Fresh context

• Clear validation

• Reusable workflows

That is the difference between AI that demos well and AI that survives contact with real infrastructure work.

If your team is working through these questions right now, the two sessions above are worth a look. One shows what it looks like to build an AI-native platform live. The other goes deeper into GitOps, context engineering, validation, and reusable agent workflows.

Book your seat while Early Bird pricing is still live.

Thanks,

Sayali

Editor-in-Chief

P.S. If someone on your team is experimenting with Claude Code, GitOps, platform engineering, or AI-assisted infrastructure workflows, share this issue with them. And if you’re already testing agents in production-adjacent work, reply and tell us where they are helping, or where they are still getting stuck.

Start small. Keep the task scoped. Make the output reviewable. Don’t let an agent near production just because the demo worked once.

This week, let’s make that more specific.

Before you turn a script, playbook, or check into an MCP skill, ask one question:

Should an agent be allowed to call this?

That sounds obvious, but it is where a lot of messy workflows begin.

• A script can be useful and still be a bad MCP skill.

• A playbook can be reliable and still need a human to decide when it runs.

• A troubleshooting step can be routine and still carry too much risk if the agent gets the context wrong.

So here’s a quick test.

1. Is the task repeatable?

Good MCP skills usually start with work your team already does often: interface checks, config comparisons, log summaries, pre-change validation, post-maintenance checks.

If the task happens once a quarter and needs senior judgment every time, it probably should not be your first skill.

2. Are the inputs and outputs clear?

“Check interface health for these devices and summarize errors from the last 24 hours” is clear.

“Find out why the network is slow” is not.

The agent needs a defined job, not a vague investigation.

3. Can it fail safely?

What happens if the device does not respond?

What happens if the data is incomplete?

What happens if the tool call fails?

A good MCP skill does not only define the happy path. It defines when the agent should stop.

That is the difference between exposing a tool and engineering a workflow.

And that is exactly what Engineering Agentic Network Operations is about.

Engineering Agentic Network Operations

June 30th | 9 AM EDT | FLASH SALE - Use SAVE40 for 40% Off

The prior networking event we had, Build Intelligent Networks with AI brought together 150+ attendees from 30+ countries and became AutoCon4’s highest-rated workshop.

Now we’re taking this to the next step, building agentic networking operations at scale.

The focus is not just building an MCP server. It is building MCP skills that are reusable, composable, and practical enough to make sense in real network environments.

In this workshop, William Collins and John Capobianco of Itential will walk through how to build MCP skills that can be reused across your environment instead of becoming one-off scripts only one person can debug.

They’ll also cover spec-driven development, so agents have defined behavior before they start acting, and agentic loops that recover when they get stuck instead of failing silently.

The live lab includes OpenClaw, NetClaw, Selector AI, Containerlab, FastMCP, Python, Claude, and Arista cEOS.

If you’ve been following this newsletter and thinking, “Okay, I understand the theory, but what does this look like in a lab?” this is the session to attend.

BOOK YOUR SEAT NOW

Use code SAVE40 for 40% off while the flash sale is live upto 48 hours.

The useful question is no longer whether an agent can call a tool.

It can.

The better question is whether the workflow has enough structure to be trusted.

That is what this workshop is built around: smaller skills, clearer behavior, reusable workflows, and network automation that engineers can actually reason about.

Hope to see you there.

Thanks,

Sayali

Editor-in-Chief

P.S. If this framework was useful, share this issue with someone on your network or automation team. And if you’re working on MCP, agents, or AI-led network workflows, reply and tell us what you’re trying to build next.

Additionally, a word from a sponsor if relevant to you

Make Claude Your 2nd Brain That works 24/7 By Mastering In It 16 hours- Here’s How

A bit of history before we get into today’s issue.

When we conducted the Build Intelligent Networks with AI in January, we had 150+ attendees from 30+ countries and came out as AutoCon4’s highest-rated workshop. That response is the reason The AI Network Engineer exists. There was clearly an appetite for this conversation, not just for four hours in a workshop, but every week. So we started writing.

We understood that engineers wanted to see how these ideas actually work against real network environments. How MCP skills are built. How agents should behave when they have access to tools. How to keep automation reusable instead of creating another pile of scripts only one person understands.

Six months later, the question has changed. It’s no longer “can this work”, it’s “how do I make this work reliably, without it falling over the first time something unexpected happens.”

In the upcoming session, we’re moving from raw MCP tools to composable, reusable skills, using spec-driven development to actually constrain agent behavior, and designing agentic loops that detect when they’re stuck and recover safely, all hands-on with OpenClaw and NetClaw as production frameworks,

ENGINEERING AGENTIC NETWORK OPERATIONS
June 30th | 9 AM EDT 50% off with code SPECIAL50 (ENDS SOON)

John Capobianco and William Collins are running this one live. If their names sound familiar, it’s because they’re the same two voices behind most of what we’ve covered: John’s trust ramp from Issue #1, the RAG-is-your-vars-file and MCP-is-your-Galaxy-role explainers from Issue #4, William’s “spider-web it out” approach to agent rules from Issue #3.

Cohort 2 picks up where those conversations leave off. The honest version of where most teams get stuck isn’t building an MCP server, it’s running one in production without it becoming another thing to babysit. That’s what this session is built around:

MCP skills that are reusable across your environment, instead of one-off integrations you write once and then maintain forever. Spec-driven development, which is really the production version of the “markdown files that define what the agent can and can’t do” idea from Issue #3, and the five-line job description from Issue #6, role, trigger, tools, job, escalation, except now you’re writing the spec that an agentic loop actually follows. And agentic loops designed to recover when they get stuck, rather than failing in a way nobody can diagnose.

All of it hands-on, in a live lab, with OpenClaw, NetClaw, Selector AI, Containerlab, FastMCP, and Arista cEOS. Same digital-twin philosophy John described back in Issue #1: let the agents break things here, where it doesn’t cost you anything, before they’re anywhere near production.

If Issue #4 made MCP click for you on paper, this is where you build the thing.

Use code SPECIAL50 to get 50% off

BOOK YOUR SEAT NOW

ALSO WORTH A LOOK THIS MONTH

Linux, SysAdmin, and AI Workflows with Imran Afzal
June 27 | 11:30 AM EDT | 40% off with code EARLY40

A quick second one, because it lines up with the “collection job” idea from Issue #5. Imran Afzal, one of Udemy’s best-selling Linux instructors, is running a hands-on session on ChatGPT CLI, Shell Genie, Aider, and Goose CLI, generating commands and scripts from plain English, explaining logs, and reviewing what these tools produce before you run it. If Cohort 2 is the network and agent layer, this is the Linux layer everything underneath actually runs on.

Use code EARLY40 to get 40% off

RESERVE YOUR SEAT NOW

The Network Automation Accelerator is a new 12-week DevNet Academy program that helps traditional network engineers build practical automation skills through hands-on labs, mentoring, code reviews, and a final real-world automation project. Register your interest to learn more.

Register here

The reason we keep coming back to these sessions is simple.

AI in infrastructure is no longer just a curiosity. But it also cannot be treated like a magic layer you place on top of production and hope for the best.

The teams that get value from it will be the ones that know how to scope the work, define the boundaries, test in a lab, review the output, and keep humans in control where it matters.

That was the lesson from our first Networking event, with the second one we’re just getting started

Hope to see you there.

– Packt Conferences

P.S. Engineering Agentic Network Operations is happening on June 30 at 9 AM EDT. Use code SPECIAL50 while the flash sale is live. Goes out in <48 Hours

In this issue, I want to point you toward three sessions worth your time if you work near platforms, networks, Linux, automation, or incident response. They are connected by one theme: AI in operations is only useful when the boundaries are engineered first.

That has been the thread running through recent CloudPro issues, even when the topics looked unrelated. In the last few issues, we’ve kept coming back to the same engineering instinct: slow down, separate the moving parts, and understand what should happen before you let anything change. Whether we were talking about broken containers, MCP design, or admin rights, the point was never just the tool. It was the discipline around the tool.

AI does not remove that habit. It raises the cost of skipping it. The teams that get value from agents will not be the ones that connect the most tools. They will be the ones that know what the agent can see, what it can change, when it must stop, and how a human verifies the next step.

Taken together, these sessions give you a practical way to think about AI where it actually shows up in your work: inside the platform, inside network operations, and at the Linux command line.

FINAL CALL - Building AI-Native Platform Engineering Systems

Last 24 hours!

Start at the platform layer.

If you run an internal platform, you’ve probably felt the pressure: AI in the developer portal, agents that explain failures, golden paths that do more than point to templates.

The challenge is that platform agents need context, telemetry, policy, safe actions, approvals, and clear trust boundaries. AI can’t just be bolted on.

That’s why Building AI-Native Platform Engineering Systems stands out. It covers Backstage, OpenChoreo, CI/CD, golden paths, control planes, policy-as-code, observability, guardrails, and platform intelligence - with AI treated as part of the architecture, not an afterthought.

A solid read for platform engineers, DevOps engineers, SREs, architects, and engineering leaders asking:

“Can we make our platform AI-native?”

The answer may be yes, but only with the right control surfaces.

Use code FINAL50 to get 50% off

BOOK YOUR SEAT NOW

The session is on June 11, i.e., 24 hours from now, and you can use the discount code FINAL50 when booking.

Engineering Agentic Network Operations

Once platform boundaries are in place, the next challenge is network operations, where many AI demos fall apart.

It’s easy to build an agent that summarizes data or suggests a config. It’s much harder to build one that works within real constraints, recovers from failures, and knows when to hand control back to a human.

That’s the focus of Engineering Agentic Network Operations.

The workshop covers MCP, OpenClaw, NetClaw, FastMCP, Containerlab, Arista cEOS, and more. But the real value is learning how to design agentic workflows with clear scope, guardrails, recovery paths, and human oversight.

For network automation, SRE, platform, and infrastructure teams, those questions matter long before an agent is trusted with production operations.

Use code SPECIAL50 to get 50% off

BOOK YOUR SEAT NOW

Agentic Linux – From Commands to AI Agents

Then there’s the base layer.

No matter how advanced the platform, a lot of real work still ends up in Linux - reading logs, checking services, fixing permissions, troubleshooting errors, and deciding whether a generated command is actually safe to run.

That’s why Agentic Linux – From Commands to AI Agents is a useful third piece.

The workshop covers ChatGPT CLI, Shell Genie, Aider, Goose CLI, Bash scripting, troubleshooting, automation, and system administration tasks. What I like is that it treats AI as an assistant, not a replacement for judgment.

Generating a command is easy. Knowing whether it’s safe, spotting destructive actions before they run, and keeping humans in the approval loop is the hard part.

For Linux administrators, DevOps engineers, SREs, and IT professionals, it’s a practical look at using AI at the command line without turning the shell into a roulette wheel.

Use code EARLY40 to get 40% off

BOOK YOUR SEAT NOW

A few books to keep beside these sessions

One more thing worth mentioning: these sessions pair well with a few books from our list if you want to go deeper after the labs.

For the first workshop, I’d start with Platform Engineering for Architects, which is especially relevant because attendees of Building AI-Native Platform Engineering Systems get the book for free. Mastering Enterprise Platform Engineering is the natural follow-up if you’re thinking about platform engineering, delivery workflows, and generative AI at enterprise scale. For the network operations side, AI Networking Cookbook fits neatly with the agentic network operations session. And if the Linux workshop is closer to your day-to-day work,The Ultimate AI Guide for Linux Engineers is a good companions for thinking about what AI-generated commands are actually touching underneath.

The Ultimate AI Guide for Linux Engineers

BUY NOW ON AMAZON

Mastering Enterprise Platform Engineering

BUY NOW ON AMAZON

AI Networking Cookbook

BUY NOW ON AMAZON

Platform Engineering for Architects

BUY NOW ON AMAZON

The useful question is not whether AI can be added to these workflows. It can, and most teams are already experimenting with it somewhere. The harder question is whether the workflow still makes sense once AI is inside it. Can the team understand what happened? Can they review the output? Can they stop a bad change before it lands? Can they trust the system more after adding AI, not less?

That is the thread running through all three sessions. They are not about chasing the newest tool. They are about taking the work many of us already do across platforms, networks, and Linux environments, and asking what has to change when AI becomes part of that work.

That is what makes these sessions useful. They are not abstract AI talks. They sit close to the places many of us actually work: the platform layer, network operations, and the Linux command line.

I’ll be in attendance as well, because these are exactly the conversations CloudPro needs to keep having: what is useful, what is unsafe, what is ready, and what still needs a human in the loop.

This is time-sensitive. The first session is on June 11, and the other two follow later this month. If one of these areas is on your roadmap, I would not skip it.

Cheers,

Apramit

Subscribe now

When most teams plan their first AI agent, they build a roadmap: architecture diagrams, integration milestones, a six-month bake, maybe even a platform plan before anyone has agreed on the first useful job. By the time it reaches production, nobody can quite remember which problem it was meant to solve.

That is the wrong shape.

Last issue, we framed agents as employees. You are not just coding a platform; you are managing a team. So the natural follow-up is: who do I hire first?

The answer is the smallest hire you can possibly defend.

Why small wins

Pick a recurring task your team dislikes. Something that takes under twenty minutes, happens often enough to learn from, and produces output a human reviews anyway. Pre-change config review. Daily interface error summaries. Bulk ticket triage against known incident classes. The task does not need to be impressive. It needs clear inputs, clear outputs, low blast radius, and a failure mode you can debug.

Big agents fail in ways that are hard to diagnose. Give one too many tools and it picks the wrong one. Give it too much context and it connects dots that do not belong together. Make it responsible for too much, and when it breaks, you cannot tell which part failed.

A small agent has one job, two or three tools, and one obvious boundary. When it goes wrong, you can debug it in an afternoon.

That is why the Lumen example from Issue #5 matters. From the outside, it looks like a big agent. Under the hood, it is a stack of small ones: a selector for RCA, Itential for the change workflow, each doing a specific job. The orchestration looks big, but the agents are small.

What the first job description looks like

Here is a first job description you can steal.

• Role: Pre-change config reviewer.

• Trigger: An engineer pastes a proposed config into #change-review.

• Tools: Read-only access to the affected device’s running config and your team’s agents.md house rules.

• Job: Diff proposed against running. Flag house-rule violations like permit any any, no shutdown on management interfaces, or plaintext community strings. Name the top three risks by severity.

• Escalation: If the change touches BGP, a default route, or any tier-0 device, refuse to comment and tag the on-call lead.

That’s the entire job – one trigger, three tools, two outputs, one hard escalation rule, no write permission. A junior network engineer with two weeks on the team could do this job. So can an agent.

If you’ve written Ansible roles, the parallel is exact. You don’t write a role that “manages the network.” You write a role that configures one thing. Agents are roles that reason. The scoping discipline is the same.

Subscribe now

Try this

Sit down with whoever runs your change board and ask one question: what’s the most common thing we catch in change review that we shouldn’t be catching this late?

Whatever they answer is your first agent’s job. Pre-change config review is the common one, but there are others like duplicate IP allocations, ACL drift from a known baseline, MOP steps missing from the template. The answer your team gives matters more than the example I picked.

Then write the job description in five lines: role, trigger, tools, job, escalation. If it takes longer than that, the agent is too big. Cut it down.

Share

Subscribe now

Eric Chou puts the problem well in his new cookbook. The network engineer’s job used to be collecting data from devices. Today, it’s making sense of the data and deciding what to do with it.

Subscribe now

Most senior engineers are still running both jobs:

1. The first is the collection job: pulling show commands, grepping logs, chewing through five hundred lines of syslog to find the one that matters, copying tables into spreadsheets.

2. The second is the one on your business card: design decisions, cross-domain judgment, the call about whether to failover or roll back.

The first eats the week. The second gets whatever’s left.

That ratio is the whole problem. Most of the hand-wringing about AI in networking is about whether you can trust it on the thinking job. The more useful question is whether you can hand it the collection job. The answer is yes, and the recipes are written.

Hire it, don’t just install it

Eric’s approach to building a network co-pilot doesn’t read like a tutorial. It reads like an onboarding plan for a coworker.

You don’t start by asking the co-pilot to configure BGP. You start by interviewing it. Eric runs three candidate models against three real networking questions:

1. configure OSPF area 0 on a Cisco router, what to check when a BGP neighbor is stuck in Idle

2. create VLAN 100 named Sales. You score the responses, weigh quality against cost, pick one.

3. You also learn where each model is strong and where it’s weak, which tells you what to trust it with later.

That is hiring.

The rest is the rest of onboarding. You build the engine around the chosen model. You give it scoped access to your network knowledge: configs, diagrams, runbooks. You define what it can touch and what it can’t. What you end up with is not a tool. It’s a direct report.

John Capobianco has a line about this that sticks. He points to a Jensen Huang quote from early last year: the future of the IT department is an HR department for agents. People laughed. A year on, it reads differently. When you write a system prompt, you’re writing a job description. When you grant the agent access to tools, you’re setting permissions. When you define escalation rules, you’re deciding when it pages a human. That is management work. You do it once, and the agent does the job forever for less than minimum wage plus token costs.

What it looks like when more than one is in the mix

A handful of operators are already running this at scale. Lumen is the clearest public example. Selector’s AI handles the root cause analysis: pinpointing, say, that a sub-interface got shut by a change and that’s what caused a BGP disruption. Itential’s workflow picks up the finding, no-shuts the interface, hands back to Selector to confirm service has returned. An engineer gets a ServiceNow ticket with the full audit trail once the fix has landed. At the scale of millions of interfaces, mean time to repair drops from days to seconds.

Two things about Lumen matter for anyone in earlier stages. It’s not one mega-agent doing everything. It’s a small team of specialists, each doing one thing well, coordinating through defined handoffs. And they didn’t start with the hardest problem. They started with the narrow sub-interface no-shut case. Low-risk, high-volume, easy to prove. Same onboarding pattern, repeated.

Try this

Pick one recurring read-only task this week. Something you do three times a week or more that doesn’t need your judgment to do right: interface health checks, config documentation, log summaries before a change review.

Interview a model the way Eric describes. Give it a scoped persona, a limited set of tools, and an escalation rule. Something like: “You are a senior network operator. Your job is to summarize OSPF adjacency logs from these three edge routers and flag anything unusual. You have read access to the logs and no write access to anything. If you see a flap pattern, escalate to a human, don’t attempt remediation.” Run it in plan mode for a sprint and review everything it proposes before anything executes.

That’s one fewer thing eating your week. And one small step toward a calendar that actually matches your job description.

Subscribe now

Eric Chou’s AI Networking Cookbook is out now from Packt. Chapter 8 is the one to start with if you’re onboarding your first agent; Chapter 9 is where it gets interesting if you’re ready to coordinate a team.

Get The Book

Cheers,

Shreyans Singh

Editor-in-Chief

Share

Here’s what nobody’s telling you: if you’ve built Ansible automation, you already understand most of this stack. The concepts map almost one-to-one. The vocabulary is different. The thinking isn’t.

HOW WE GOT HERE

John Capobianco, Head of AI and Developer Relations at Itential, laid out a timeline during a recent Packt workshop that’s worth keeping in your head.

2022: prompt engineering. You type things into ChatGPT, you get answers back.

2023: ChatGPT introduces plugins, letting you connect to external systems.

2024: the year of RAG.

2025: the year of MCP.

2026: the year of AI agents.

That’s the trajectory. But it’s also just the industry slowly figuring out how to give an LLM the two things it was missing: your data and your tools. RAG solved the data part. MCP solved the tools part. Agents put them together.

If you’re catching up, you don’t need to relive all three years. You just need to understand what RAG and MCP actually do. And the fastest way to understand them is through something you already use.

RAG IS YOUR VARS FILE

When you write an Ansible playbook, you don’t hardcode hostnames and IPs into the tasks. You pull them from inventory, from group_vars, from host_vars. The playbook stays generic. The data stays separate. At runtime, the two come together.

RAG does the same thing for an LLM.

Without RAG, a model answering questions about your network is guessing. It knows what OSPF is, broadly. It doesn’t know your topology, your naming conventions, or which interfaces are in area 0.

With RAG, you inject your configs, your runbooks, your documentation into the model’s context at runtime. The model reads your data, then answers. William Collins, Director of Technical Evangelism at Itential, described it during the workshop: “RAG is just saying, when someone asks about your network, retrieve the relevant topology and inject it into the prompt. Done.”

Your data stays current because you’re pulling it live. You’re not retraining anything. You’re not paying to fine-tune a model on your network configs. It’s open-book, not memorization.

If you’ve ever written a playbook that pulls variables from an external inventory source and uses them at execution time, you already get RAG. Same pattern. Different layer of the stack.

MCP IS YOUR ROLE INTERFACE

Before Ansible Galaxy, if you wanted to automate something on a new vendor’s gear, you wrote your own modules. Every combination of task and platform was custom glue code. Ten tasks across four vendors meant forty things to build and maintain.

Galaxy changed that. You pull in a role, call it with the right variables, and it handles the implementation details. The interface is standard. The logic is reusable.

MCP does the same thing for AI.

Before MCP, connecting a model to your tools meant writing custom integrations for every combination of model and tool. William Collins walked through the math in his workshop: four models times ten tools equals forty separate integrations. Every model has its own function-calling format. Every tool has its own API. You’re writing glue code forever.

MCP reduces that from a multiplication problem to an addition problem. Each tool implements an MCP server once. Any model that speaks MCP can use it. William used the USB analogy: before USB, every device had its own proprietary connector. MCP is the universal port.

There’s already a pyATS MCP, a NetBox MCP, a Nautobot MCP, a ServiceNow MCP. John Capobianco listed them during the panel. These are the Galaxy roles of the AI stack. You snap them in, and your agent has access to the tools.

And here’s the part that should feel very familiar. In his workshop, William actually built MCP tools that mapped directly to Ansible playbooks. Not new automation. Existing playbooks, exposed through MCP so an AI agent could call them. His point was clear: companies already have automation. They don’t need to rewrite it. They need a way for agents to invoke what they’ve already built.

If you’ve ever published a role to Galaxy so other teams could reuse it with standard inputs, you understand MCP. Same concept. The inputs just come from an LLM now instead of a YAML file.

AN AGENT IS A PLAYBOOK THAT CAN REASON

An Ansible playbook follows a fixed sequence. Task 1, then task 2, then task 3. You can add conditionals and handlers, but the logic is yours. You wrote the steps.

An AI agent takes a natural language instruction, reasons about what needs to happen, picks the right tools, and executes. If something fails, it can adapt.

John’s example: “Could you please configure OSPF on routers one and two and configure router-on-a-stick for the attached switches?” That’s the full instruction. The agent figures out which MCP tools to call. It executes the configuration. Then, and this is the part worth paying attention to, it writes its own tests to verify the config worked.

That last part is new. Your playbooks don’t write their own validation. An agent can. But everything underneath (the tools it calls, the configs it pushes, the approval gate before anything hits production) that’s automation. That’s your world.

THE DISCIPLINE DOESN’T CHANGE

Here’s where some people get tripped up. They hear “agents” and think this replaces what they’ve built. It doesn’t. It sits on top of it.

John made this point explicitly: without orchestration, AI agents will repeat every bad pattern from network automation. Script sprawl. One-off code that nobody can reuse. No central place to schedule and run things. The same mess you cleaned up when you moved from shell scripts to Ansible.

William said the same thing from the engineering side. Version control. Pinning your dependency versions. Running tests. Documenting your playbooks as baselines so the LLM can generate new ones that follow the same standards.

TRY IT THIS WEEK

Pick a read-only MCP server. John recommended pyATS MCP as the easiest starting point. Connect it to Claude Code, Cursor, or whichever tool you use. Ask it to run a show command on a lab device and summarize the output.

That’s your first agent interaction. No config changes. No risk. You’re just connecting an AI to a tool it can call, and asking it to read data you already look at. Five minutes.

You’ll notice it feels familiar. Because it is.

Cheers,

Shreyans Singh

Editor-in-Chief

Good instinct. Here’s how to act on it.

PLAN BEFORE YOU EXECUTE

If you use Ansible, you already do this. You run --check before you run the real thing. It shows you what would change without changing anything. You review. Then you commit.

AI coding tools have the same concept. Claude Code calls it plan mode. Cursor and Copilot have equivalents. The AI lays out what it wants to do, you look it over, and you say yes or no.

William Collins demonstrated this live during our workshop. He pasted a prompt into Claude Code. The tool checked his guardrails, showed the plan, and waited. He reviewed it, said go ahead, and only then did it execute. “I’m a human in the loop right now,” he said.

Eric put it simply: “Show me the configuration before you do anything else in plan mode. Once satisfied, then we turn around and enable agent mode.”

You wouldn’t run an untested playbook on prod. Same rule applies here.

SET RULES BEFORE THE CONVERSATION STARTS

This one’s less obvious, but worth knowing about. If you use Claude Code, Cursor, or Gemini CLI, you can drop a markdown file into your project that gives the AI standing instructions. CLAUDE.md for Claude Code. .cursor for Cursor. agents.md if you want something that works across tools.

Think of it as onboarding your AI the way you’d onboard a contractor. Here’s how we do things. Here’s what you’re not allowed to touch. Here are the standards.

Eric explained during the panel: your org-wide rules go in a global file (package management preferences, coding standards, security policies). Project-specific constraints go in a project-level file. William added that you can even go folder by folder. His advice: “Don’t build one gigantic monolithic file. Spider-web it out.”

What goes in them? Eric said the number one request from practitioners is rules that “decrease hallucination, decrease uncertainty, build reliability, and build trust.” Things like: reference this documentation, don’t improvise on syntax, follow our naming conventions.

TREAT YOUR API KEYS THE WAY YOU TREAT YOUR PASSWORDS

An attendee at our workshop asked: what’s the best practice for storing API keys so they’re not sitting in plain text .env files?

If you’ve used Ansible Vault, you know the principle already. You encrypt sensitive data (OSPF passwords, SNMP strings, credentials) so they never exist as plain text on disk. They get decrypted at runtime, used, and that’s it.

Same logic applies to your AI tooling. William’s setup: he keeps API keys in a 1Password vault. A script pulls them into environment variables at login. When he logs out, they’re wiped.

No keys on disk. No keys in code. No keys in commit history.

“The secrets managers are there,” he said. “The technology isn’t stopping any of us. It’s just getting organized and doing it.”

START BY READING, NOT WRITING

John Capobianco’s advice is probably the most practical thing anyone said across the entire event: don’t start by pushing config. Start by pulling data.

Have an AI agent run “show ip interface brief” and send you a Slack summary of what it sees. You’re not changing anything on the network. You’re just getting a faster view of data you already look at.

“That’s completely 100% safe,” John said. “And it saves us hours of human copy-paste.”

Start there. Build trust with read-only operations. Move to documentation and testing. Only go to configuration management once you’re confident in the tooling.

BUILD A SANDBOX

Before AI runs against production, give it a lab.

John recommended ContainerLab and Cisco CML for building virtual copies of your network. “You can make a pretty good digital twin,” he told us. “Where you run your AI agents, where you run your automation.”

Let the AI break things in there. That’s the whole point: find out how it fails where it doesn’t cost you anything.

PUT AN APPROVAL GATE ON ANYTHING THAT WRITES

John’s framework: let the AI do the reasoning, the research, the drafting. But before it pushes anything to a device, make it stop and wait. A ServiceNow ticket. A Slack message. Whatever your team uses.

“A human expert can review the code, review the config, review the agent’s proposal. And then we approve that.”

He calls it “the best of both worlds.” The AI handles the grunt work. You handle the judgment calls.

DON’T FORGET WHAT YOU ALREADY KNOW

This was William’s point during the panel, and honestly, it’s the most important one.

Version control. Pinning your dependency versions. Running proper tests. Doing code review. None of that goes away because you’re using AI now. If anything, it matters more.

“All those DevOps principles, all those automation principles, that stuff becomes more important than ever,” he said. “Because that helps you catch when maybe the AI missed something.”

Look, none of this is fancy. It’s the engineering discipline you already have, pointed at a new tool. Check mode before execution. Encrypted secrets. Code review. Testing. Approval gates. You know all of this.

The gap between “I use AI for side tasks” and “AI runs in my production workflow” isn’t a technology gap. It’s a process gap. And the process is stuff you’ve been doing for years.

Start with read-only. Set your rules. Build from there.

THE BAD PROMPT

Let’s say you need help setting up BGP. Here’s what most engineers type:

“Help me with BGP configuration.”

You know what comes back. A textbook answer. Generic template. Placeholder values. A reminder to “replace with your actual values” and “consult with a network specialist.” It explains what BGP is, as if you don’t already know.

You close the tab. AI isn’t ready for real work, you think.

But the AI didn’t fail you. You gave it nothing to work with.

THE GOOD PROMPT

“You are a senior network engineer specializing in BGP routing protocols. I need you to generate a BGP configuration for a Cisco ASR9000 router that will: (1) Establish EBGP peering with two upstream ISPs, AS 65001 and AS 65002, (2) Implement route filtering to accept only default routes from upstreams, (3) Set up load balancing between the two upstreams, (4) Include basic security hardening for BGP sessions. My router’s AS number is 65100. Peer IPs: ISP1 (AS 65001) at 192.168.1.1, ISP2 (AS 65002) at 192.168.2.1. Provide the configuration in IOS-XR format with explanatory comments.”

Completely different output. Full IOS-XR config. Route-policy definitions filtering everything except the default route. TTL security on both peers. MD5 authentication. Load balancing with maximum-paths. Inline comments on every block.

Specific to your ASN, and peer IPs, and platform, and OS.

Same AI. Only the prompt changed.

THE FOUR THINGS THAT MADE IT WORK

Think of AI as a new hire on day one. Capable, but needs a proper briefing. The second prompt gave that briefing. Here’s what it did:

1. Role: “You are a senior network engineer specializing in BGP.” Without this, you get generalist answers. With it, you get answers from someone who lives in routing tables.

2. Task breakdown: Not “configure BGP.” That’s too vague. Instead: establish peering, filter routes, balance traffic, harden security. Four deliverables you can check one by one.

3. Environment details: The ASN. The peer IPs. The hardware. The OS. Every detail you provide is a detail the AI doesn’t have to guess. And guessing is where hallucinations come from.

4. Output format: “IOS-XR format with explanatory comments.” Without this, you might get Cisco IOS when you need IOS-XR. Or a config dump with no context.

That’s the whole framework. Role. Task. Context. Format.

USE IT FOR ANYTHING

The BGP example is just one case. The same four-part structure works everywhere:

• Troubleshooting: “You are a network engineer investigating a routing issue. Here’s a 200-line syslog extract from a Nexus 9000 running NX-OS 10.3. Identify the root cause and suggest remediation steps in order of priority.”

• ACL review: “You are a security-focused network engineer. Review this access list for a perimeter firewall. Internal network is 10.0.0.0/8. Flag overly permissive rules and suggest a tightened version with comments.”

• Documentation: “You are a network architect preparing a method of procedure. Task: migrating OSPF area 0 to a new backbone link on two Juniper MX480s. Include pre-checks, step-by-step commands, rollback procedures, and post-validation. Format as a numbered checklist.”

• Cross-vendor translation: “Translate this Cisco firewall policy to Junos. Preserve the logic exactly. Flag anything that doesn’t have a direct equivalent.” Eric Chou demonstrated this at a recent Packt workshop. It works.

TRY IT THIS WEEK

Pick one task you already do. Write the prompt with those four elements. Compare the output to what you’d get from a one-liner.

That gap is your first AI win. Risk-free. Takes a minute.

P.S. Add a short checklist at the end of any complex prompt.

Something like: “Before you finish, verify: (1) All IPs match what I provided, (2) Security hardening is on every peer, (3) Syntax is IOS-XR not IOS.”

William Collins from Itential shared this during a panel: “It’ll say it did everything, then hit my checklist and go ‘oh yeah, I missed that’ and go back and fix it.”

The prompting techniques in this issue are drawn from Eric Chou’s AI Networking Cookbook, published by Packt. Eric has 20+ years of experience at Amazon, Microsoft, and other large-scale networks. The book is structured as practical, recipe-by-recipe walkthroughs: from your first AI environment to building network co-pilots.

See you next week.

Cheers,

Shreyans Singh

Editor-in-Chief

Subscribe now

Hi,

Before we launched this newsletter, we asked 700 network engineers and DevOps folks a simple question: what’s your biggest challenge with AI?

64% said the same thing. They don’t trust AI output for production networks.

Not “I don’t know how to use it.”

Not “the tools are confusing.”

Just: I don’t trust it.

That number didn’t surprise us. But it did confirm something we’d been hearing from practitioners for a while. The problem with AI in networking isn’t technical. It’s cultural.

Issue #1

WHY NETWORK ENGINEERS DON’T TRUST AI

(AND WHAT TO DO ABOUT IT)

Share

John Capobianco is the Head of AI and Developer Relations at Itential. He’s been pushing AI and automation in networking longer than most. And he told us something that puts the whole trust debate in perspective.

According to the Network Automation Forum’s survey last year, only 30% of enterprises have adopted automation. That means 70% are still doing things by hand. This is ten years after automation became a real option.

“What has slowed that adoption is not the technology,” John told us. “It’s the people and it’s the culture.”

AI is hitting the same wall. Except now, there’s an extra layer of fear on top. The AI might hallucinate. It might push the wrong config. It might take down a link.

These are real concerns. Nobody’s dismissing them. But John makes a point that’s hard to argue with: “How many networks have gone down because the engineer was on the wrong device? The engineer issued the wrong command? The engineer was on the wrong interface? The engineer made a typo?”

We’ve all seen it happen. A fat-finger at 2am on a live router. A copy-paste into the wrong terminal window. A change that looked right but wasn’t tested first.

The difference? When AI makes a mistake, it’s visible. It’s in code. You can catch it in review before it touches anything. When a human makes a mistake at 2am under pressure, there’s no review step. There’s no undo button.

THE SKEPTICS ARE LOUDER THAN THE BUILDERS

John said something in our conversation that stuck with us. He was talking about the engineers who try AI for 15 minutes, call it “slop,” and move on.

“Those people are three years behind,” he said. “But they’re very vocal and they say it with authority. And they might be a CCIE. So a lot of people tend to take that as their influence.”

Here’s what changed in those three years. RAG lets you ground AI responses in your own documentation, your own runbooks, your own configs. MCP gives AI agents a structured, governed way to interact with your network tools. These aren’t lab experiments. Lumen, one of the largest network operators in the world, is running closed-loop AI remediation in production right now. Problems that used to take hours are getting resolved in seconds.

But if your only experience with AI was asking ChatGPT to explain OSPF two years ago, you wouldn’t know any of this. And you’d be right to be skeptical. You’d just be skeptical about something that no longer exists.

OK, SO HOW DO YOU ACTUALLY START TRUSTING IT?

We’ve been talking to people who are actually deploying AI on production networks. Not in theory. In practice. And a pattern keeps showing up. It’s not dramatic. It’s not a big leap. It’s a ramp.

Subscribe now

Here’s how it works.

Start with read-only tasks. Don’t push config. Don’t change anything. Just have AI pull data you already look at, interface health, routing tables, log summaries, and present it to you in plain language. John’s example: have an agent run “show ip interface brief” and send you a Slack message with the results. You’re not automating anything. You’re just getting a faster view of your own network. “That’s completely 100% safe,” he said. “And it saves us hours of human copy-paste.”

Keep a human in the loop. Before any action hits the network, build in an approval step. A ServiceNow ticket. A Slack message that needs a thumbs-up. The AI proposes. You decide. John calls this “the best of both worlds.” The agent does the work, but a human expert reviews the output before anything gets executed.

Test in a digital twin. Tools like ContainerLab and Cisco CML let you build a virtual copy of your network. Let AI agents run wild in there. Let them break things. That’s the whole point. You want to see where they fail before you let them near production. This is exactly what practitioners are teaching in workshops right now: spin up a lab, give the AI room to operate, and watch what happens.

Find low-risk, high-value cases. The Lumen story is useful here. They didn’t start by letting AI redesign their routing architecture. They started with a simple, high-frequency problem: a sub-interface gets accidentally shut down, service goes down, someone has to get paged. Their AI system detects the root cause, runs a “no shut” to restore service, confirms it worked, and logs everything. Low risk. Happens all the time. Saves hours at scale.

Graduate slowly. Once read-only operations work and simple fixes are validated in a lab, you expand. But with guardrails. Markdown files that define what the agent can and can’t do. Approval gates for anything that writes config. Full audit logs. Then you widen the scope, one use case at a time.

This isn’t “move fast and break things.” That doesn’t work for networks. This is: move carefully, prove it works, expand.

THE COST OF DOING NOTHING

The trust debate tends to focus on the risks of using AI. Fair enough. But there’s a cost on the other side too, and it doesn’t show up in dashboards.

John put it in personal terms: “As someone who used to be a senior network architect and was on call, getting a call at 3:00 in the morning and spending two hours troubleshooting, and it turns out to be just a sub-interface that got shut down, that’s not a good use of my time. And the morale and the impact on my personal life and my family life.”

Every manual syslog review is time a senior engineer isn’t spending on design and strategy. Every 3am page for a routine issue is a hit to retention. Every change window that takes ten people three days is budget that could go somewhere else.

The question isn’t whether AI is perfect. It’s whether AI with human oversight is better than humans alone, under pressure, in the middle of the night, on the wrong terminal.

We think the evidence says yes. And we’ll keep bringing you that evidence, from real practitioners, real deployments, and real results, in every issue of this newsletter.

Cheers,

Shreyans Singh

Editor-in-Chief

Subscribe now