This is Part 1 of a three-part series on what happens when an IT director goes all-in on AI agents — not the hype version, the real one. Messy, broken, and occasionally awesome.

The idea that wouldn’t leave me alone

I run IT infrastructure for a mid-size company: servers, network, service desk, all of it.

I’d been using AI tools like everyone else — drafts, code suggestions, quick summaries. Helpful, but transactional. Ask a question, get an answer, close the tab. No continuity.

Then I found OpenClaw.

OpenClaw is the framework that gives an AI model agency: shell access, files, APIs, browser control, messaging. Claude is the brain. OpenClaw is the body.

I tested it on Windows first. It was immediately useful. Then i had the dangerous thought:

what if it built its own permanent home in WSL?

The bootstrapping paradox

I wanted OpenClaw running in WSL2 with a proper Linux environment, persistent services, and clean tooling.

Normal approach: spend half a day setting up WSL, Node, CLI, systemd, networking, and fixing whatever breaks.

What i actually did: told OpenClaw to do it.

So yes — the agent running on Windows was about to build the Linux environment it would eventually live in. Very normal Tuesday behavior.

Building the house (while living in it)

To be clear: i didn’t type commands. I didn’t follow a setup guide. I talked to the agent, confirmed actions, and watched it execute.

It updated Ubuntu packages, installed Node via nvm, set up OpenClaw CLI, then hit real-world issues:

• npm permissions: tried prefix approach, saw it wasn’t stable, pivoted to nvm.
• PATH conflicts: found leftover config overriding .bashrc and fixed it.
• systemd in WSL: updated /etc/wsl.conf, requested restart, verified activation.

Then networking showed up to remind me who’s boss.

WSL has its own namespace and changing IP. OpenClaw wrote a startup PowerShell script for port forwarding, then worked through:

• elevation requirements for netsh
• Windows Firewall rules silently blocking traffic
• localhost resolution weirdness between Windows and WSL

Each cycle was the same: diagnose, reason, fix, verify. Fast and methodical.

The browser relay (aka networking strikes again)

One of the best OpenClaw features is browser relay — actual browser interaction, not just HTML scraping.

Getting Chrome on Windows talking to an agent in WSL took a few tries:

1. WebSocket timeout (firewall/rules)
2. auth token formatting issue
3. version mismatch blocking commands
4. extension config mismatch in Chrome

It traced and fixed each one. No drama, just iteration.

When relay finally connected and it could control tabs, i absolutely did a fist pump at my desk.

The brain transfer

At this point i had two worlds: original Windows workspace and new WSL workspace.

The Windows side had the context: memory files, config, and identity files (SOUL.md, MEMORY.md). So the workspace had to move.

OpenClaw moved itself.

I didn’t craft rsync commands. I told it the goal. It generated and ran the transfer, handled Windows/Linux filesystem differences, validated paths, and verified integrity.

Then i launched from the WSL workspace. It came up with memory intact, tools available, and full context from prior work.

That moment felt different: not “new chat,” but continuity.

The systemd moment

Final step was persistence: run as a service, survive restarts, keep logs clean.

OpenClaw wrote its service config, enabled it, and tested startup behavior.

Seeing active (running) in systemctl status openclaw was the line-crossing moment.

It stopped being “a thing i open” and became infrastructure.

What i learned on day one

1. Agents that build their own stack are scary-effective. It understood both setup steps and architecture intent.
2. The bootstrap paradox is a feature. It now understands the environment because it built it.
3. Agency is the multiplier. Huge gap between “here’s a command” and “i ran it and validated output.”
4. Persistence changes workflow. This feels like a coworker, not a utility.
5. This changes IT operations. Same kind of shift as moving from click-ops to IaC.

That was Tuesday. By Friday, OpenClaw was handling inbox triage, calendar context, and ServiceDesk support workflows.

Next: “Teaching It to Be Useful — From Chatbot to Coworker” — where the experiment starts producing real operational leverage.