G Talks Tech

Garrett Masters
  • 5,0 (1)
  • Tecnologia
  • Quinzenal

Practical AI workflows for senior network, security, and infrastructure engineers who are tired of doing everything the hard way. Audio from the G Talks Tech YouTube channel plus audio-first episodes.

Episódios

  1. há 1 dia

    How to Use Claude Code as a Network Engineer

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/njerxFIa974 Letting AI push changes to your switches sounds like a bad idea until you can see every command before it goes out. In this episode I use Claude Code in my lab to snapshot the network, build a health check skill, review the design, and add a new VLAN across six switches with a pre-check, post-check and a tested rollback. Everything runs over SSH from the terminal, read-only until I approve the change. Free download: the three skills from this episode (network-snapshot, network-health-check, network-push) are one Claude Code plugin on GitHub. Install commands are in the pinned comment. https://github.com/GTalksTech/netops-skills/tree/main/plugins/network-ops What you’ll learn How to start every session from a fresh snapshot of the network, not old docs How to keep your AGENTS.md or CLAUDE.md short with one instructions file per folder How to build a health check skill with plan mode, then run it against a whole lab How to give Claude Code runbooks so it follows your change process How to approve every push and see the exact commands first How to run a pre-check, post-check and rollback on a real VLAN change Why you should keep your own show-command skills sharp Chapters 0:00 Intro 1:02 01 How to start every session 8:20 02 Working with AGENTS.md and CLAUDE.md files 11:01 03 Building a health check skill together 16:46 04 How to let your AI make changes, safely Resources Skills (free): https://github.com/GTalksTech/netops-skills/tree/main/plugins/network-ops Lab instructions files from this episode: https://github.com/GTalksTech/netops-skills/tree/main/lab-workspace Blog post: https://gtalkstech.com/blog/claude-code-network-engineers/ New skills and lab guides by email: https://gtalkstech.com/join Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  2. 3 de nov.

    AI News for Network Engineers: MCP Servers + 4 Security Alerts

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/PZOrS7CInsU Join the free G Talks Tech mailing list (new videos, lab files and guides): https://join.gtalkstech.com A lot happened in AI for network engineers in October. Cisco, Juniper and a pile of open source projects shipped ways for AI to touch your network. Some are read-only, and some can make changes. This roundup walks through the new MCP servers, the repos worth your time, the AI tool updates that matter if your AI can reach network gear, and the security advisories you actually need to act on. What you’ll learn Which vendor MCP servers are read-only (Meraki) and which can make changes (Catalyst Center, ThousandEyes, Junos) Why the API key you hand an MCP server decides more than the server does What Cisco’s Privileged Infrastructure Access is, and why just-in-time access for people and AI agents matters The open source repos worth a look: NetBox MCP, Netdryrun, fw-skills-share, NetClaw and Awesome Network Automation AI The Claude Code change for anyone whose AI can reach network equipment: hooks that fail closed What to check after the LiteLLM compromise, the backdoored Claude Code extension in Cursor’s marketplace, and the Cisco ASA/FTD zero-day Chapters 00:00 Intro 00:42 01 What the vendors shipped 00:59 Cisco Privileged Infrastructure Access 02:35 Vendor MCP servers: Meraki, Catalyst Center, ThousandEyes, Junos 04:55 02 Repos worth your time 06:12 NetClaw 07:07 03 Updates to your AI tools 07:42 GitHub Copilot Fusion and Ollama Flint 08:25 04 Security quick hits 09:08 Cursor marketplace backdoor 09:56 Cisco ASA/FTD patch reminder 10:20 Recap Heads up on this one: it’s a news roundup read off the vendor pages, so a few moments point at things on screen. Every story and link stands on its own in audio; the links are below, and the video has the pages if you want to see them. Links from the episode Vendor news and MCP servers Cisco, October 26 announcement: https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2026/m10/cisco-expands-partner-opportunity-with-new-cisco-360-program-updates-high-yield-customer-experience-offerings-and-ai-ready-innovations.html Cisco Privileged Infrastructure Access: https://blogs.cisco.com/security/cisco-rethinks-privileged-infrastructure-access Meraki MCP server (read-only): https://github.com/CiscoDevNet/cisco-meraki-mcp-official Catalyst Center MCP server: https://developer.cisco.com/codeexchange/github/repo/cisco-en-programmability/catc-mcp-oss/ ThousandEyes MCP server: https://docs.thousandeyes.com/product-documentation/integration-guides/thousandeyes-mcp-server Junos MCP server: https://github.com/Juniper/junos-mcp-server Open source NetBox MCP server: https://github.com/netboxlabs/netbox-mcp-server Netdryrun: https://github.com/netdryrun/Netdryrun fw-skills-share: https://github.com/JNPRAutomate/fw-skills-share NetClaw: https://github.com/automateyournetwork/netclaw NetClaw project site: https://automateyournetwork.com/netclaw/ Packet Pushers Heavy Networking 848, NetClaw: https://packetpushers.net/podcasts/heavy-networking/hn848-netclaw-your-open-source-network-assistant/ Awesome Network Automation AI: https://github.com/packetcoders/awesome-network-automation-ai AI tool updates Claude Code changelog: https://code.claude.com/docs/en/changelog GitHub Copilot Fusion: https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/ Ollama Flint: https://ollama.com/library/flint Security MCP Inspector security advisories: https://github.com/modelcontextprotocol/inspector/security/advisories LiteLLM security incident: https://docs.litellm.ai/blog/security-incident-oct-21-2026 Cursor, Claude Code extension security notice: https://cursor.com/blog/claude-code-extension-security-notice Cisco ASA/FTD advisory: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-tunnel-dos-s6mgkb75 Support the show: https://ko-fi.com/gtalkstech

  3. 15 de out.

    Will AI Replace Network Engineers?

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/nwnLdVSPtN4 Is AI going to replace network engineers? Honestly, I don’t think so. But I do think it’s going to split us into two groups: the engineers using it to finally build the automation they’ve never had time for, and the ones still doing everything by hand. Here’s my take after eleven years in IT: three jobs I’d hand to AI first, and the parts you keep. What you’ll learn Why AI is more likely to widen the gap between network engineers than replace them How AI can test every app before and after a firewall cutover, then check hit counts and logs Why security advisory triage is really a matching problem, and why AI is good at it How to answer “are we affected by this?” without logging into every device yourself What it looks like to chain it all together, from advisory to patched, with you still approving the change What AI won’t do for you, and why the change still has your name on it What you get back: time for the backlog, and the kind of work that tends to get engineers promoted Chapters 00:00 Intro 00:42 01 Three jobs I’d hand to AI first 01:19 Advisory triage 02:09 Are we affected? 02:40 02 Chain them together 03:48 Why it hits us so hard 04:35 03 What it still won’t do 06:37 04 What you actually get back 07:45 Recap Resources Free download, My Top 5 Ways to Start Using AI as a Network Engineer: https://gtalkstech.com/start/ai-use-cases/ Cisco PSIRT openVuln API (free, needs a Cisco account): https://developer.cisco.com/psirt/ BLS outlook, network and computer systems administrators: https://www.bls.gov/ooh/computer-and-information-technology/network-and-computer-systems-administrators.htm BLS outlook, computer network architects: https://www.bls.gov/ooh/computer-and-information-technology/computer-network-architects.htm Network Automation Forum 2025 survey results (NANOG 95 slides): https://storage.googleapis.com/site-media-prod/meetings/NANOG95/5509/20251025_Grundemann_The_2025_State_v1.pdf Network Automation Forum 2026 results: I’ll add the link here once they’re published. This one is a straight conversation, so it works fine as audio. The video version adds a few 8-bit explainers and the BLS and survey numbers on screen if you want to see them. Support the show: https://ko-fi.com/gtalkstech

  4. 9 de out.

    How to Stop Your AI Agent From Making Changes You Don't Want

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/dsY4_s3NL04 Before an AI agent touches your network, you want to know what decides whether a change actually runs. This episode wires Goose, a free agent harness running a local model, to a real lab Cisco router through an MCP server with three read tools and one write tool. Then it sets permissions in both places that matter: the labels on your MCP tools and the rules in your harness. What you’ll learn What an agent harness is, and where the approval gate sits in its loop Why Goose ships in auto mode, and how to switch it to smart approve How to stop approval fatigue by always allowing your read tools Why incomplete tool output makes the model fill in the gaps How readOnlyHint and destructiveHint mark a tool as read, write, or destructive How Goose decides: your rules first, then the tool’s label, then the model’s best guess Why Bionic 1.1.6 needs the guardrail built into the MCP server itself Chapters 00:00 Who decides whether a tool call runs 00:53 What an agent harness actually is 01:32 Goose out of the box: auto mode and setup 02:25 Wiring router tools to Goose over MCP 02:56 Approval fatigue, and the fix 04:24 Guardrail 1: complete tool output 05:15 Guardrail 2: label your tools, set your own rules 07:16 What Goose’s approval gate is made of 09:04 destructiveHint: not every write is dangerous 10:03 Guardrail 3: Bionic and the same write tool 12:07 Recap 12:53 Free kit on GitHub Resources Free kit (MCP server, permissions file, runbooks, checklist): https://github.com/GTalksTech/netops-toolkit/tree/main/local-ai/local-agent-harness Blog post companion: https://gtalkstech.com/blog/local-agent-harness/ Goose (Agentic AI Foundation): https://github.com/aaif-goose/goose LM Studio Bionic docs: https://lmstudio.ai/docs/bionic MCP spec, tools and tool annotations: https://modelcontextprotocol.io/specification/2026-07-28/server/tools Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  5. 22 de ago.

    Local AI For Network Engineers - Stop Redacting Configs for ChatGPT

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/dDE8gajTKkQ Local AI for network engineers: your configs never leave your desk. This episode sets up Ollama properly on a MacBook, benchmarks 6 local models against real Cisco configs, generates handoff documentation from a full 14,000-token show run all capture, and finishes with a 9B model driving real network tools through LM Studio’s permission gate. Free, private, and measured on camera, including the parts where local AI needs a fix. What you’ll learn How to install Ollama and the 5 environment settings that make it config-ready instead of chat-ready Why a bigger mixture-of-experts model runs 4x faster than a smaller dense one, and the ollama show check that tells you before you download How to turn a real show run all capture into handoff documentation with a free local model Why the default 4,096-token context window silently breaks config work, and the one-line fix How to get valid JSON out of a thinking model for automation pipelines How to verify nothing leaves your machine with a live socket check, plus the cloud-tag exception to watch for How to wire a read-only MCP server into LM Studio and drive live network tools from a 9 billion parameter model Chapters 00:00 Local AI Can Do Real Work 01:03 Why Local AI for Network Engineers 01:44 Install Ollama and the 5 Settings 03:41 What This Mac Runs: MoE vs Dense 05:58 The Real Test: Docs From a Config 09:31 Four Edge Cases That Fail Silently 12:59 Local AI vs Claude 15:16 Is It Actually Private? Watch the Sockets 16:38 What It Costs 17:27 A 9B Model Driving Real Tools 18:55 Recap and Resources 20:12 A Prayer for Engineers Resources Everything from this episode (runbook, prompt pack, configs, topology, scripts): https://github.com/GTalksTech/netops-toolkit/tree/main/local-ai/local-ai-network-engineers Companion blog post: https://gtalkstech.com/blog/local-ai-network-engineers/ Ollama: https://ollama.com LM Studio: https://lmstudio.ai Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  6. 19 de jul.

    My Network AI Agent Found a CVE. It Can't Touch Prod Without Me.

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/dbkwtuXuPPQ If you’re the senior engineer on a small team, you’re probably being told to put AI agents on your network while being the one who answers for the outage if it goes wrong. In this episode I build a bounded AI agent with real network tools (FastMCP, Netmiko, Claude Code as the harness, NetBox as the source of truth) and turn it loose on three Cisco IOS XE devices in my CML home lab. It finds a real CVE by checking my running configs against Cisco’s live PSIRT openVuln API, writes the fix, and then my own server-side boundary blocks it from applying anything until I approve the change by name. What you’ll learn How to build an MCP server that gives an AI agent real network tools (FastMCP and Netmiko) How to wire it into Claude Code with .mcp.json and keep credentials in shell environment variables, never in config files How to pull live Cisco security advisories through the PSIRT openVuln API and correlate them against your running configs How the agent caught a cross-device ACL gap that neither config shows on its own, then proved it with real packets Why exactly one gated write tool, with everything else read-only, is the shape that makes an agent safe to run How the approval workflow runs: propose, approve by name with a reason, apply, then a full audit log on disk Why a server-side boundary still holds even with every Claude Code permission gate turned off Chapters 00:00 An AI agent found a CVE 01:17 What an AI agent actually is 03:14 Why the boundary matters 06:13 Inside the MCP server 08:59 NetBox, secrets, and wiring it in 13:39 Turn it loose: the audit sweep 15:36 The cross-device ACL gap 18:57 The CVE, honestly scoped 20:21 The boundary says no 21:17 Approve, apply, audit log 24:30 Inside the boundary code 28:03 Skip-permissions test and wrap-up Resources Hardrails (spec and code front door): https://gtalkstech.com/hardrails Hardrails repo on GitHub: https://github.com/GTalksTech/hardrails Anthropic on trustworthy agents (the “model plus a harness” idea): https://www.anthropic.com/research/trustworthy-agents P.E.N.E. framework by Sif Baksh (a peer working this same problem from the prompt side): https://sifbaksh.com/blog/pene-framework-ai-network-operations/ NetBox: https://github.com/netbox-community NetBox Docker (the source of truth in this episode): https://github.com/netbox-community/netbox-docker Cisco Support APIs: https://developer.cisco.com/site/support-apis/ Cisco PSIRT openVuln API: https://developer.cisco.com/psirt/ CVE-2025-20334 details: https://nvd.nist.gov/vuln/detail/CVE-2025-20334 Netmiko by Kirk Byers: https://github.com/ktbyers/netmiko FastMCP: https://github.com/jlowin/fastmcp Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning, the findings, and the boundary argument all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  7. 11 de jun.

    Build a Custom MCP Network Assistant With Python and FastMCP

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/LZrmRdSMiJ0 Every network engineer has asked an AI chatbot for help, then had to manually copy and paste show command output back and forth the whole time. This episode walks through building a custom MCP server with FastMCP and Netmiko that gives Claude Desktop live, read-only access to real Cisco IOS lab devices, so you can ask questions in plain English and get answers pulled straight from your running network. What you’ll learn How to build an MCP server from scratch with FastMCP and Netmiko How MCP (Model Context Protocol) actually works and why it matters now that it’s an open standard How to test a custom MCP server with MCP Inspector before wiring it into anything How to connect a custom MCP server to Claude Desktop without falling into the Connectors trap How to whitelist safe commands and redact sensitive output (passwords, SNMP strings, MD5 keys) before anything reaches the AI How to diagnose a real OSPF Hello/Dead timer mismatch using a single plain-English query How the same MCP server works inside Claude Code from the terminal, and what changes when more tools are in play Chapters 00:00 Intro 01:44 Building the MCP Server 03:31 What MCP Actually Is 06:11 Server Code Walkthrough 09:05 Testing With MCP Inspector 11:05 Wiring Into Claude Desktop 14:55 Live Demo: Tools and Blocked Commands 17:10 Security Demo: Redaction in Action 20:14 The Headline Query: Diagnosing OSPF 23:50 Bonus: Same Server in Claude Code 26:04 Recap and What’s Next Resources GitHub (full MCP server, lab YAML, setup instructions): https://github.com/GTalksTech/netops-toolkit/tree/main/scripts/netmiko/mcp-network-assistant Blog post (written walkthrough): https://gtalkstech.com/blog/mcp-network-assistant/ FastMCP: https://github.com/jlowin/fastmcp Netmiko (Kirk Byers): https://github.com/ktbyers/netmiko Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  8. 16 de mai.

    Prompt Engineering for Network Engineers - 4 Rules and 15 Free Prompts

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/OEfeS8pyn_s It’s 11 PM, your maintenance window is going sideways, and ChatGPT just spit out 10 config changes. Two of them will break your network, three are noise, and you don’t have time to figure out which is which. This episode walks through the four-part prompt structure that fixes that, runs four prompts live against a real Cisco lab in Claude, and shows where AI still gets things wrong so you know when to override it. What you’ll learn How to structure a network prompt so the model stops guessing Why context beats persona prompting in 2026 (and what to do instead) How to use the “if you don’t know, tell me” rule to kill 90% of hallucinations How to audit an ACL, generate an OSPF config, and walk an outage with AI Where AI still misses (Layer 2 vs Layer 3 MTU is in here) A data hygiene rule for free vs enterprise AI so you don’t leak configs Why “fix this config” is the worst prompt you can write Chapters 00:00 Intro and the 11 PM AI disaster 01:34 Example of a bad prompt 03:30 Prompt engineering vs context engineering 05:24 The 4 elements of a good network prompt 08:32 Data hygiene and Shadow AI 09:34 Demo 1: OSPF standardization 13:07 Demo 2: ACL auditor 14:47 Demo 3: One-off runbook generator 16:29 Demo 4: OSPF troubleshooting walkthrough 25:23 Key takeaways 26:01 Free 15-prompt pack 26:59 Beard reveal Resources Free 15-prompt pack (GitHub): https://github.com/GTalksTech/netops-toolkit/tree/main/ai-prompts/prompt-engineering-network-engineers Companion blog post: https://gtalkstech.com/blog/prompt-engineering-for-network-engineers/ Previous episode (automated network runbook and diagram generator): https://github.com/GTalksTech/netops-toolkit/tree/main/scripts/netmiko/ai-network-documentation Claude: https://claude.ai ChatGPT: https://chat.openai.com Heads up on this one: the four demos run live on screen, real prompts against a real Cisco lab. The rules and the reasoning all stand on their own in audio. If you want to see the prompts and the configs, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  9. 22 de abr.

    Fully Automated Network Documentation using Python and AI - Part 2

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/LA3_eIaBM1E Manually copy-pasting show command output into a browser chat works fine for a lab, but it falls apart the moment you need to run it against a whole site, on a schedule, or hand it off to a teammate. This episode walks through a fully automated network documentation pipeline built on Python, Netmiko, and the Claude API. One YAML inventory, one command, and you get back a finished runbook plus an optional draw.io diagram in minutes. What you’ll learn How to set up a YAML inventory file that drives the entire pipeline How to get an Anthropic API key, store it safely in ~/.bashrc, and understand the real cost How the one-command pipeline collects, redacts, assembles, calls the API, and restores real values How to generate a draw.io network diagram with a single flag (no extra API call) How to switch between Claude, OpenAI, and Gemini and override the default model How to handle scaling honestly once you have more than 20 devices Chapters 00:00 Intro 01:08 From 5 Scripts to 1 Command 02:28 Inventory YAML File 04:01 API Keys, Cost, and Setup 06:23 Credentials and Secrets Warning 06:42 Running the Pipeline Live 07:37 Inside the Generated Runbook 09:24 Optional Network Diagram Flag 10:17 Switching AI Providers and Models 11:10 Token Limits and How to Scale 12:14 GitHub, Blog, and What’s Next 12:47 Recap Resources GitHub (script, inventory example, README): https://github.com/GTalksTech/netops-toolkit/tree/main/scripts/netmiko/api-automation-pipeline Blog post companion: https://gtalkstech.com/blog/api-automation-pipeline/ Anthropic API console (to create your key): https://console.anthropic.com Netmiko (Kirk Byers): https://github.com/ktbyers/netmiko Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  10. 5 de abr.

    I Automated My Network Documentation with AI and Python

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/z89tfs7HV0I Network documentation is always outdated. Configs change constantly, but the docs never keep up. This episode walks through a complete AI-powered workflow that takes raw show command output from live Cisco devices and turns it into a finished operational runbook and network diagram in about 10 minutes. What you’ll learn How to collect show commands from network devices using Python and Netmiko How to redact sensitive data (IPs, hostnames, credentials, serial numbers) before sending anything to a public LLM How to assemble a structured prompt and generate a full runbook with ChatGPT How to restore real values back into the AI-generated runbook How to generate a draw.io network diagram with zero AI involved Why redaction matters and how to think about LLM data safety Chapters 00:00 Intro 00:43 What We’re Building 01:21 Script 1: Collecting Show Commands 03:55 Why Redaction Matters 05:32 Script 2: Running the Redactor 07:00 Reviewing Redacted Output 08:00 Script 3: Prompt Assembler 09:14 Pasting Into ChatGPT 10:01 AI Limitations (Full Disclosure) 11:36 Script 4: Restoring Real Values 12:45 Reviewing the Finished Runbook 13:54 Script 5: Diagram Generator 15:48 Download the Scripts 16:26 Recap Resources GitHub (all 5 scripts + CML lab YAML): https://github.com/GTalksTech/netops-toolkit/tree/main/scripts/netmiko/ai-network-documentation Netmiko (Kirk Byers): https://github.com/ktbyers/netmiko Heads up on this one: it’s a screen-share build, so there is real terminal work you can’t see here. The reasoning and the findings all stand on their own in audio. If you want to replicate the lab, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  11. 10 de fev.

    It's Not the Network: The 10-Minute Framework to Stop Getting Blamed

    This episode is the audio from a YouTube video. Some segments reference on-screen demos. Watch the full video at https://youtu.be/kdyXSark_ck Every network engineer knows the vague ticket: the app is slow, so it must be the network. This episode walks through a practical framework to rule the network in or out fast, using evidence instead of guesswork, and finishes with a PowerShell script that runs the checks and produces paste-ready proof for your ticket response. What you’ll learn Why the network is everyone’s default suspect and what that costs you A rule-in vs rule-out framework for fast network triage The evidence checklist: DNS, TCP path, and application-layer checks How to hand proof back to the app team without the finger-pointing Chapters 00:00 Intro: Why the network always gets blamed 01:30 The reality of network troubleshooting 03:15 The framework: Rule in vs rule out 05:45 Evidence collection checklist Resources Get-NetworkEvidence.ps1 (the evidence script from the demo): https://github.com/GTalksTech/netops-toolkit/blob/main/scripts/powershell/Get-NetworkEvidence.ps1 Incident communication templates and bonus AI prompts: https://github.com/GTalksTech/netops-toolkit/blob/main/incident-response/templates/incident_communication_templates.md Heads up on this one: the evidence script demo runs on screen, so you can’t see its output here. The framework stands on its own in audio. If you want to watch the checks run, the video version is worth the watch. Support the show: https://ko-fi.com/gtalkstech

  • 11 episódios

Sobre

Practical AI workflows for senior network, security, and infrastructure engineers who are tired of doing everything the hard way. Audio from the G Talks Tech YouTube channel plus audio-first episodes.

Informações

  • Criado por
    Garrett Masters
  • Anos de atividade
    2026
  • Episódios
    11
  • Classificação
    Livre
  • Copyright
    © 2026 Garrett Masters
  • Site do podcast
    G Talks Tech