Write something
Pinned
1d •
Module 1 · Lesson 3 — How Your Agent Will Reason
📌 Read time: ~6 min | Module 1 of 8 --- Agents Are Not One-Size-Fits-All Thinkers A routing protocol does not use the same algorithm in every situation. OSPF uses Dijkstra within an area. BGP uses path attributes and policy for inter-AS routing. Same network, different problems, different mechanisms. Agents work the same way. There are three reasoning patterns. You will use one of them 80% of the time. --- Pattern 1: ReAct — For Troubleshooting ReAct stands for Reason + Act. The agent alternates between thinking and doing. Thought: Neighbor is INIT. Something is preventing it moving to 2-WAY. Check Hello and Dead timers on both ends. Action: run_command("show ip ospf neighbor detail", device="R1-NYC") Observation: Hello 10s, Dead 40s Action: run_command("show ip ospf neighbor detail", device="R2-NYC") Observation: Hello 30s, Dead 120s Thought: Timer mismatch confirmed. Root cause found. Draft fix and escalate for human approval. ReAct is the troubleshooting pattern. Evidence in, decision out, next action, repeat. This is how your senior engineers think. It is also the pattern that maps most naturally to the investigative work consuming your tier-1 team's time. --- Pattern 2: Planning — For Configuration and Deployment Sometimes the task is not "find the problem" but "build the solution." New client onboarding. Multi-site VLAN rollout or firewall policy generation. Goal: Deploy VLAN 200 across 12 branch switches for Client A. Plan: 1. Retrieve current VLAN config from all 12 devices. 2. Identify conflicts with existing VLAN IDs. 3. Generate config templates per device. 4. Run dry-run, collect diffs. 5. Present diffs for human approval. 6. Push configs in sequence with rollback ready. Use Planning when the task has multiple stages and order matters. --- Pattern 3: Reflection — For Validation The agent generates a config change. Before showing it to you, it critiques its own output: - Does this comply with the client's change policy? - Does this conflict with existing routing policy?
0
0
Pinned
1d •
Module 1 Lesson 2 - What an AI Agent Actually Is
📌 Read time: ~7 min | Module 1 of 8 --- Let's Be Precise There is a lot of noise around "AI agents." Vendors call everything an agent. Chatbots get called agents. Automation platforms get called agents. Most of it is marketing. Here is the working definition we will use in this course: An AI agent is a software system that perceives its environment, reasons about what to do, takes actions using tools and loops — until it reaches a goal or determines it cannot. Four words matter: perceives, reasons, acts, loops. Take away any one of them and you have something else. --- The Four Pillars Think about how you troubleshoot a network problem you have never seen before. You are not running a script. You are doing something more sophisticated. Let's name it. Pillar 1: Reasoning Engine This is the brain. For you, it is 10 years of network experience. For the agent, it is a large language model — Claude, GPT-4, Llama. It understands concepts and decides what step to take next. Not magic — a very good pattern-matcher that has read every RFC, every Cisco TAC document, and every BGP Stack Overflow answer ever written. Pillar 2: Memory When you walk into a client's NOC for the first time, you are less effective than after six months running that network. The difference is your mental model. An agent has the same concept. An agent without memory starts from zero every time. Pillar 3: Tools Knowing what to do is not the same as being able to do it. Tools are the agent's hands — SSH execution, API calls to your SNMP queries, log fetching, ticket creation. The agent does not run tools blindly. The reasoning engine decides which tool to call, with which parameters, based on what it has found so far. Pillar 4: Context Everything the agent knows at the moment it is working — the client's network documentation, previous ticket history, the output of the last five commands it ran. When you give your agent good context, it performs like your best engineer. When you give it no context, it guesses.
0
0
Pinned
1d •
Module 1 · Lesson 1 The MSP Problem — Why Scripts Will Not Scale You
You have 50 clients. Each one has a runbook or script written by a different engineer at a different time. None of them share knowledge. When engineer A figures out that a specific vendor drops BGP sessions under high CPU, that knowledge lives in A's head. Next week engineer B hits the same thing on a different client. Starts from zero. Same two hours of investigation. Scripts do not accumulate knowledge. Agents can. An agent that troubleshot 500 BGP issues across your client base brings all of that context to the 501st. Not because you programmed it in — because it has memory. The path to scaling your MSP without scaling headcount is not more scripts. It is agents that investigate, remember and act. --- 👇 What's next: Lesson 2 — What an AI Agent Actually Is
0
0
1d •
Module 03 · Lesson 3 — The Safety Gate
All Tool Calls Go Through One Function. No Exceptions. You do not call tool.execute() directly from the agent loop. You call execute_with_approval(). Always. This function is the single chokepoint where the three access levels are enforced and every action is logged. The agent loop does not need to know whether a tool is READ, WRITE, or ADMIN — the gate handles that. --- The Audit Log First, the logging function. Every action — approved or rejected — gets a record. import json import datetime AUDIT_LOG_PATH = "audit.jsonl" def _log_action(tool_name: str, params: dict, approved: bool, operator: str): entry = { "timestamp": datetime.datetime.utcnow().isoformat() + "Z", "tool": tool_name, "params": params, "approved": approved, "operator": operator, } with open(AUDIT_LOG_PATH, "a") as f: f.write(json.dumps(entry) + "\n") JSONL format — one JSON object per line. Easy to ship to a SIEM. Easy to search with grep or jq. Each line is self-contained. Think of this as your debug ip ospf events equivalent — a timestamped trail of everything the agent did or tried to do. --- The Full Safety Gate def execute_with_approval(tool: BaseTool, params: dict, operator: str = "unknown") -> ToolResult: """The safety gate. Every tool call goes through here.""" if tool.category == READ: result = tool.execute(**params) _log_action(tool.name, params, approved=True, operator=operator) return result if tool.category == WRITE: print(f"\n{'='*55}") print(" WRITE OPERATION REQUESTED") print(f"{'='*55}") print(f" Tool : {tool.name}") print(f" Params: {json.dumps(params, indent=4)}") if "diff" in params: print(f"\n Config diff:\n{params['diff']}") print(f"{'='*55}") answer = input(" Approve? (y/n): ").strip().lower() approved = (answer == "y") _log_action(tool.name, params, approved=approved, operator=operator) if not approved: return ToolResult(success=False, data={}, error="Operator rejected.")
0
0
1d •
Module 3 · Lesson 1 — Tool Design Philosophy
The LLM Does Not Touch Your Network Before anything else, get this right in your head: the language model cannot execute code. It cannot SSH into a router. It cannot run a Python function. What it can do is produce text — and that text, if you structure it correctly, looks like a tool call request. Your Python code reads that request. Your Python code decides whether to honor it. Your Python code runs the actual SSH session. That separation is not a design choice you can skip. It is where every safety control lives. --- Three Access Levels. No Exceptions. Think of these like privilege levels on a Cisco router. Every tool you build belongs to exactly one of three levels: - READ — show commands, lookups, pings. Runs automatically. Cannot change anything. - WRITE — config changes, interface bounces. Agent proposes, you type y to approve. - ADMIN — high-impact operations. You must type YES I CONFIRM exactly. You are running this agent against client infrastructure. The access level is not a suggestion. Here is how you define them in Python — plain string constants, nothing fancy: READ = "read" # privilege 1 — show commands only, auto-execute WRITE = "write" # privilege 7 — config changes, needs y/n approval ADMIN = "admin" # privilege 15 — destructive ops, needs YES I CONFIRM --- ToolResult: What Every Tool Returns Every tool returns exactly the same shape. This is important — the agent loop always knows what it is getting back. class ToolResult: """ Every tool returns this. Always the same three fields: success — True or False data — what came back, e.g. {"raw_output": "..."} error — error message if success is False, empty string otherwise """ def __init__(self, success: bool, data: dict, error: str = ""): self.success = success self.data = data self.error = error Usage: result = ToolResult(success=True, data={"output": "neighbor FULL"}) print(result.success) # True print(result.data) # {"output": "neighbor FULL"}
0
0
1-14 of 14
powered by
skool.com/autonomous-msp-2162
AI-powered NOC, SOC and compliance for MSPs and IT consultancies. Built by a 25-year enterprise network practitioner.
Suggested communities
Powered by