You banned OpenClaw. Now make it your training program for agentic AI.

A few weeks ago, I wrote about why companies shouldn’t ban OpenClaw. What stuck with me afterwards, especially after the discussions at the first OpenClaw Munich meetup I organized, was something else.

I think personal agents are one of the best training grounds we currently have for agentic AI. Maybe the best! They are rough. And they are risky by default.

Most companies think they’re already enabling this because they provision Cursor, Copilot, Codex, Claude Code et al. I’m not even sure that counts as enablement. At best, it creates the conditions for people to start learning a new kind of collaboration.

Without actual enablement, most people stay stuck in tight loops anyway. They use the agent in the mode that feels safest and most legible: close collaboration, short feedback cycles, constant supervision. As I argued in the elastic loop, that is only one part of the spectrum.

I don’t think that is where the story ends: Agents are not just coming for software development. They’re showing up across knowledge work: research, writing, analysis, operations, project coordination, support. Engineering just got there first.

Without integration, agents are still stuck in the broom closet. We are the ones running up and down the stairs, carrying in the files, the context, and the decisions they need to do anything useful. Once that changes, the design problem changes too. They operate across tools, and sometimes disappear into asynchronous work that you only look at later. Most APIs were not built for that. Governance probably wasn’t either. And I don’t think anybody learns those lessons from a slide deck.

NVIDIA’s NemoClaw shows where this is going: companies will need people who understand guardrails, verification, data integration, and system integration long before a vendor packages those problems into a product.

Orchestration matters more than raw capability

Most teams obsess over the capability layer: which model, which tools, which APIs, which connectors. Fair enough. That stuff matters. But I keep coming back to the layer above it: how work gets broken down, when results get checked, where parallelism helps, where it just creates nonsense, and when a human needs to come back into the loop.

That’s the point where personal agents stop feeling like a toy. You decide when to trust the system, when to constrain it, and when to verify the output.

Integration work teaches you where the architecture lies to you

Connect a personal agent to CalDAV, Google Drive, a health API, or some half-documented service you rely on in real life, and the abstractions start breaking almost immediately.

Authentication flows behave strangely. Edge cases show up in places no product page mentions. Things that look “agent-ready” in a product demo turn out to be brittle the moment an agent tries to use them for real.

Three broken CalDAV connections teach you more than a polished reference architecture diagram. I don’t even mean that as a joke.

And I think this is going to matter more than many people expect. Once companies want agents to operate across internal systems, they’ll discover that “has an API” and “works well with agents” are two very different claims.

Intelligence is not expertise

Barry Zhang from Anthropic put it well in his AI Engineer talk “How we build effective agents”: a 300-IQ mathematician still can’t do your taxes.

An agent needs reasoning, yes. But it also needs domain knowledge, process context, and ways to act inside real systems. Otherwise you get the usual demo magic: something that sounds smart, moves confidently, and falls apart the moment the task depends on local reality.

That’s also why I keep coming back to the different layers here. Where should knowledge live in the first place? In memory? In a skill? In retrieval? In the systems themselves? Skills carry domain-specific behavior and procedural knowledge, sometimes even their own memory. MCP gives you reusable access and connectivity. Then there is a scripting layer in between, where agents use a shell like Bash and store little scripts or programs inside domain-specific skills. The important learning sits here: when to use what, how to weld it together without it falling apart, and how procedural learnings end up in skills, agent memory, and self-improvement.

Governance takes shape through use

Where does the agent’s memory end and my own knowledge system begin? What should it be allowed to edit? What should it only suggest? When should it escalate? Where should learning live: in memory, in a skill, or somewhere else?

You can write policies about this, and you probably should. But the real shape of governance only shows up once there’s friction.

Once the agent touches your notes.
Once it rewrites something you didn’t want rewritten.
Once it makes a judgment call you would rather have kept for yourself.

That’s when the rules start shaping what the agent actually does. I think that is exactly what enterprises are going to run into once agents become part of real workflows.

Skills are where procedural learning accumulates

A lot of the “agent memory” talk still feels slightly wrong to me. It often turns into a logging system with good intentions. You store corrections, observations, and mistakes somewhere, tell yourself you’ll fold them back into the system later, and then, of course, you don’t.

I learned this the hard way: if feedback doesn’t flow back into the capability that produced the mistake, the agent hasn’t really learned much. It just remembers more detail about the same failure. Like a cook who logs every failed sauce but never updates the recipe.

Skills encode the how. Memory stores the what. Those are different jobs!

That’s why I think OpenClaw matters beyond nerdy hobbyist setups on Raspberry Pis (pointing at myself here). Give employees a personal assistant. Enable them. Teach the principles, the guardrails, and give them a blueprint. That’s how an agentic AI training program for everyone begins.

This does not have to happen in a strict sequence where personal agents come first and business integration comes later. It is both at once: people learn by using agents individually, while the organization starts figuring out where agents can safely connect to real work.

OpenClaw forces you to wrestle with the right problems early. I would rather have people build taste, judgment, and a bit of scar tissue while companies figure out where agents belong in the business, instead of waiting until everything meets at the most sensitive points.