NetClaw Around the World: A Three-Part Thai Series

NetClaw now has a Thai-language series.

Supachai Jaturaprom (ตั้ม), a CCIE (#65006), read the NetClaw documentation, listened to my Heavy Networking interview with Ethan Banks and Drew Conry-Murray, and turned both into three podcast-style episodes in Thai. They also asked the question every network engineer should ask of a project like this:

If you could type “please set up eBGP according to RFC best practice” into a chat and an AI did it, would you dare touch production?

I did not make this series, and Supachai says it is independent of me and of Packet Pushers. That is part of why I want to share it. People are reading the project documentation closely, in their own language, and testing what it says against what it can show. Here is what each episode does, translated for English readers.

How the series was made

Supachai is open about the method, and you should read the series with it in mind:

• The audio, slides and script were generated by AI (Google NotebookLM) from the NetClaw documentation and the Heavy Networking interview (episode 848, October 30, 2026).
• Nothing was run on real devices. Every example in the series is what the project's sample files show, not something Supachai executed.
• Some numbers and the creator's stories were not verified against other sources, and Supachai says so in each video description.
• The one hands-on step was a limited trial install, covered in Episode 2.

All three episodes were published on November 1, 2026 and are in Thai.

The episodes

Episode 1: History and ideas (24 minutes)

NetClaw ตอนที่ 1: ประวัติและแนวคิด | AI ผู้ช่วยวิศวกรเครือข่าย, Border Claw และ NCFED — Watch on YouTube

What it does: tells the story of the project and the thinking behind it, from a single agent to a group of specialized NetClaws behind a Border Claw. It ends on the federation draft, NCFED, which the series is careful to describe as experimental and not endorsed by the IETF.

Key moments, in my translation of the chapter titles:

• 0:53 An agent that works like a CCIE-level network engineer
• 2:00 Making changes that have been approved
• 3:28 A community that only began on February 19, 2026
• 5:12 Looping, clearing context, and writing notes to itself
• 7:10 Switching to one specification per skill
• 10:18 The agent's identity and rules, from the soul file
• 12:05 Scheduled checks that stand in for cron
• 14:35 Specialized NetClaw groups, coordinated by a Border Claw
• 17:05 A protocol so one claw can talk to another
• 19:12 What the changelog shows: some releases from 1.5.0 to 1.15.0, and 20 release entries in a single month

Its five takeaways:

1. According to the project documentation, NetClaw is an agent that behaves like a CCIE-level network engineer. It runs on OpenClaw or Hermes and reaches network tools through MCP and skills.
2. The creator says the starting idea was to use controlled MCP tools instead of letting an agent run CLI freely. The system was built with agent loops first, then moved to writing one specification per skill.
3. Three files shape behavior. The soul file carries twelve rules, and the heartbeat's default is that it does not remediate automatically.
4. As skills and MCP servers grew, the project handled context with a Border Claw and specialized member claws, and with the NCFED draft standard, which is experimental and not endorsed by the IETF.
5. The project changes quickly. Numbers and capabilities move with the changelog, and the creator's account has not been confirmed by a third party.

Episode 2: Architecture, installation and security layers (16 minutes)

NetClaw ตอนที่ 2: สถาปัตยกรรม ติดตั้ง และชั้นความปลอดภัย | DefenseClaw, OpenShell — Watch on YouTube

What it does: follows a command from chat to a device, walks through the installer, and covers the protection layers. Supachai also tried a real, limited installation and reports exactly how far it got.

• 1:06 How a command in chat reaches a device
• 1:27 MCP servers grouped by job
• 3:06 “Configured is not evidence”
• 3:40 OpenClaw or Hermes
• 4:35 “Installed does not mean qualified”
• 4:55 The interactive installer, profiles and .env import rules
• 6:07 Static or dynamic testbeds, from version 1.14.0
• 8:28 DISCOVERY_VERIFIED: what the trial install proved and what it did not
• 9:08 Three rings of protection, according to the creator
• 11:15 Not bypassing the ITSM process, and a five-phase workflow
• 13:54 Five things to remember

The trial install. Supachai installed the Minimal profile (four components) on one machine. After fixing an issue with Hermes executable detection and a Node problem, the seventh install run reached tool discovery. That proves the tools were found. It does not prove a device connection or a working model, and DefenseClaw and OpenShell were not turned on.

Its five takeaways:

1. Per the documentation, NetClaw installs with a batch installer, run as a normal user rather than root, where you choose a profile or components and a runtime (OpenClaw or Hermes).
2. Setup has two phases: runtime onboarding, then setup.sh for platform credentials and the pyATS testbed. Since 1.14.0 the testbed can be static or dynamic.
3. The trial install reached discovery only. It did not prove access to a device or a model.
4. The documentation describes layered security: DefenseClaw scanning, an OpenShell sandbox, and in production mode a systemd-limited member, with a posture report that does not claim full enforcement when a control is missing.
5. The documentation itself says that a configured item is not evidence of connectivity, and that installed does not mean qualified. Keep artifact discovery, tool access, device reachability and a successful tool call as separate pieces of evidence.

Supachai also flags two places where the figures differ and says they did not chase the cause: the documentation lists 238 skills and 177 MCP servers, while their own count of the project copy was 239 skills and 53 MCP folders. They also note the documentation describes OpenShell differently in two places (available in one, evaluated and rejected in another).

Episode 3: Usage and examples (12 minutes)

NetClaw ตอนที่ 3: การใช้งานและตัวอย่าง | health check, CVE, eBGP, full audit และ lab — Watch on YouTube

What it does: works through the examples in the project, from a one-sentence health check to a full autonomous audit and a lab the agent builds on its own, and reads each one critically.

• 2:03 Talking in natural language through chat channels
• 3:47 The creator compares MCP to a USB key
• 4:20 A health check from one sentence
• 5:29 Checking a software version for CVEs, and why a version match is not the same as exploitable
• 6:55 Setting up eBGP per RFC best practice, with the sample's plain-text neighbor password called out
• 7:40 A full autonomous audit in seven phases
• 8:04 Ordering a CML lab with one message
• 8:36 The defects the agent's own lab report admits
• 9:05 A report that only looks good is not enough
• 9:41 Production needs a ServiceNow change request
• 10:13 A catalog of 238 skills is not proof of connectivity

The lab report. This is Supachai's favorite part. The report the agent wrote says OSPF is FULL and the pings pass. Read closely, though, the running-config section is empty and the WAN values in the second table do not match the first. The lesson Supachai draws: a report is not good because it is pretty. Check that the numbers agree with each other and with the real equipment.

Its five takeaways:

1. The documentation shows natural-language use, and the project examples run from an eight-step health check to a seven-phase full audit that ties many skills together.
2. Examples that change configuration follow a baseline, plan, apply, verify, document sequence, cite RFCs such as RFC 7454, and are gated by a ServiceNow change request, according to the soul file.
3. The agent's lab report shows real successes (OSPF full, pings passing, change request closed) and its own internal defects, such as an empty running-config section and mismatched WAN values. Watch the tables.
4. Several example files do not say they are real runs, and there are date oddities, so treat them as illustrations.
5. As in Episode 2, a configured list is not evidence of connectivity. Separate configuration, discovery, device access, and results checked against a real device.

Supachai also notes the scan date in one sample file (February 19, 2025) is earlier than the repository's creation date, and that a CVE example recommends upgrading to the version already in use, which is why they read the examples as illustrations.

What I am taking from it

I think the best part of this series is the discipline of the reviewer. Supachai kept three questions apart that people tend to blur: what the documentation says, what was actually tried, and what was verified against a real device. A trial install that reached DISCOVERY_VERIFIED is reported as exactly that, and no more.

Three things stand out for me:

• “Configured is not evidence.” The documentation and the series arrive at the same sentence from different directions. A catalog of skills tells you what could be done, not that it connects to anything.
• A report has to reconcile with itself and with the device. An empty running-config section beside a passing ping is a good reminder to check the artifact before trusting the summary. The same rule applies to anything an agent writes.
• The example files are open to the same scrutiny as the code. The notes on the sample files, from the plain-text neighbor password to the dates, are exactly the kind of review that makes a project better, and I am grateful to have it.

An AI voice explaining an open-source network agent to Thai engineers, in a series that carries its own caveats on every video, is a good picture of where this community is heading. Thank you, Supachai, for the careful read and for building it in public.

If you have built something in your own language about NetClaw, MCP or spec-driven network automation, tell me about it or bring it to the VibeOps community.

Notes on this write-up

• The English here is my translation, with AI assistance, of the Thai video titles, chapter titles, descriptions and automatically generated captions. The captions were created from AI-generated audio and contain recognition errors, so treat the wording as a faithful summary rather than a verbatim transcript.
• Statements attributed to “the series”, “the creator”, or “the documentation” are Supachai's reporting of what the sources say. I have not repeated them as confirmed facts. For exact wording, watch the videos and use YouTube's caption translation.
• Related reading: NetClaw on Heavy Networking, the interview the series is based on, and the NetClaw project page.