Migration and architecture case study
Transition to OpenClaw
Why I moved from earlier automation toward OpenClaw, and what changed once routing, telemetry, and direct control became first-class concerns.
Migration logic
A move from brittle automation to a governed control surface
The migration was driven by the need for fresh information, real-time telemetry, agent specialization, and direct control over execution.
- Fresh information on demand instead of frozen assumptions
- Telemetry-aware planning and routing
- Model-agnostic tools and skills as first-class capabilities
Problem / Context
This post is a practical sequel to AI Agents. The earlier post is about how I think about agents in general and how the system evolved over time; this one is about why I chose OpenClaw specifically and what changed once I moved toward a more explicit fleet architecture.
Why OpenClaw?
From my post about AI agents in general:
OpenClaw has native local provider support as long as the API in question supports either OpenAI or Anthropic specs, including documentation on how to use Ollama and other providers. I already had experience with Ollama, which made me inclined to use it as my model provider for OpenClaw. OpenClaw is also open source, so I do not have to worry about a company taking my data or discontinuing the product if it becomes unprofitable. I can simply copy the repository and run it locally without any internet connection for sensitive information. I also wanted to experiment with skills and tools with frontier LLMs, and OpenClaw conforms to the AgentSkills spec, which gave me a strong starting point for custom skills.
There were other reasons beyond those for the transition from Shortcuts-based automation to OpenClaw:
New Information, On-Demand
The earlier system was good at rearranging information I had already provided. It was much weaker at revising itself when the world changed. That became more limiting over time. I wanted a system that could search, compare, and incorporate new information without waiting for me to manually rebuild the pipeline around it.
That does not make internet search the center of the system. It makes freshness available when it matters. A system that can only restate yesterday's context becomes brittle very quickly.
Real-Time Telemetry
My older automations were deterministic in the narrow sense that they always ran the same way, but they were not dynamically aware of state. They could tell me what existed on my calendar. They could not really reason about what had changed, what had accumulated, or how much capacity remained after the rest of life had already happened.
OpenClaw made it easier to think in terms of a governed system that could pull telemetry, combine sources, and make decisions on live context rather than frozen assumptions. That matters because Work Units and the larger instrumentation model only become fully useful when the planning layer can actually consult them while work is being routed.
Approach / System Design
Agent Specialization
This was one of the biggest changes. A single planning assistant can be helpful, but the moment a system tries to plan, search, synthesize, execute, communicate, and monitor at the same time, responsibilities start to smear together. The result is usually less legible and less reliable than it first appears.
OpenClaw made it practical to separate concerns. Distinct agents can now handle routing, execution, research, communication, or observation. That structure is what eventually became The Fleet.
Direct Control
Shortcuts and automation pipelines can do a lot, but they encourage indirect control. You build a trigger, hope you predicted the right conditions, and then wait for the system to behave exactly as imagined. That works for narrow workflows. It works less well once you want to intervene, inspect, redirect, or ask follow-up questions in the middle of a process.
OpenClaw gave me a more direct control surface. I can still automate what should be automated, but I can also query, revise, or redirect the system in plain language when I need to. That flexibility matters because constraint-aware systems cannot rely on rigid automation alone.
Tools and Skills
What really pushed me toward OpenClaw was the availability of tools and skills. Claude Code and Claude Cowork made the value of skills obvious, and once the AgentSkills spec became open and model-agnostic, it was possible to build that style of capability into a more local and controllable environment.
That matters because skills change what the system is able to do. Instead of waiting for me to manually execute every high-friction step, the system can run a known capability directly and return a structured result. It reduces not only time cost, but initiation cost.
Setup
The setup process was fairly simple:
Implementing Tailscale
Because the computer running OpenClaw is not my primary machine, I used Tailscale to SSH into the secondary machine for setup. I have physical access to the computer itself, so I can still inspect configs directly, but this arrangement means my own laptop does not need to remain online 24/7 for the agent system to remain available.
It also makes setup materially easier. I can access documentation, scripts, and notes from one machine while configuring the other.
Download and Set Up OpenClaw
The OpenClaw installation itself was the straightforward part. The harder part was deciding what should live there and what should remain external. Installing software is easy; deciding operational boundaries is harder. I wanted the system online quickly, but I also wanted the architecture to stay understandable.
Add the Other Agents
Once the first agent was online, adding more became much easier. The challenge shifted away from installation and toward role definition. The important question was no longer "can I add another agent?" but "what responsibility should this agent own, and what should it refuse to do?"
That distinction is what turned a single setup into an actual fleet.
Implement Local Models and Model Routing
Local models were one of the reasons I moved in this direction at all. But local support only becomes truly useful once there is some routing logic in place. Different tasks have different needs. Some benefit from a small local model, some need a stronger remote model, and some should stay local for privacy or persistence reasons even if the output is less polished.
Model routing therefore belongs to the architecture, not just the configuration. It is part of how the system decides what kind of help is appropriate under what constraints.
Introducing the Fleet
The full system that grew out of this transition is described in The Fleet. That post covers the architecture in more detail. This post is more about the transition itself: why I left the earlier regime, why OpenClaw fit, and why the move mattered operationally.
The transition sits between the conceptual history in AI Agents, the architecture in The Fleet, and the underlying telemetry logic in Field Note 0 - Instrumentation. Together they describe the same system from different angles.
Artifacts