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