Development record · migration
Transition to OpenClaw
A migration from brittle automation toward a control surface with live context, explicit routing, telemetry, and direct intervention.
Development record
A migration driven by missing observability
The move was driven by the gap between scheduled automation and a system that could consult current information, inspect live state, and accept redirection during work.
- Fresh information on demand instead of frozen assumptions
- Telemetry-aware planning and routing
- Model-agnostic tools and skills as first-class capabilities
Context
This post is a practical sequel to AI Agents. The earlier post follows the system’s evolution; this one records the move to OpenClaw once explicit routing, telemetry, and control became necessary.
Why OpenClaw?
The platform fit four concrete requirements: native local provider support for OpenAI- or Anthropic-compatible APIs, open-source operation for local control of sensitive planning infrastructure, documentation for Ollama and other providers, and alignment with the AgentSkills spec for reusable capabilities.
There were other reasons for moving from Shortcuts-based automation to OpenClaw:
New Information, On-Demand
The earlier system was good at rearranging information already provided. It was much weaker at revising itself when the world changed. The replacement needed to search, compare, and incorporate new information without waiting for a manual rebuild of the pipeline.
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
The 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 report what existed on the 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 build a 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 useful when the planning layer can actually consult them while work is being routed.
Project timeline
Migration chronology reconstructed from the system changes described in this article. The page records the architectural turn rather than exposing a single public project repository.
- Stage 01 · constraint
Outgrow scheduled automation
Shortcuts could reliably repeat a known pipeline, but they mostly rearranged information already supplied and struggled when the world changed.
Pressure: the system needed current information and the ability to revise its assumptions.
- Stage 02 · telemetry
Make capacity and state visible
Work Units and instrumentation made task cost and accumulated work part of the design problem, exposing the limits of calendar-only planning.
Pressure: planning needed telemetry it could consult while work was being routed.
- Stage 03 · access
Put the always-on machine somewhere reachable
Tailscale connected the secondary Mac running the system so setup, documentation, and maintenance could happen without keeping the primary laptop online.
Result: the infrastructure became available as a service without hiding where it lived.
- Stage 04 · platform
Install the control surface
OpenClaw supplied local-provider support, tools, skills, and a direct interface for querying or redirecting work instead of waiting for a trigger to fire.
Result: operational boundaries moved closer to the work they governed.
- Current · routing
Turn one setup into a system
Role separation and model routing followed the installation, leading into the multi-agent architecture described in The Fleet.
Current state: the migration is best understood as the bridge between the earlier planning system and the present operating model.
System
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 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 provided a more direct control surface. Automation could remain in place where it was appropriate, while the system could also be queried, revised, or redirected in plain language. Constraint-aware systems cannot rely on rigid automation alone.
Tools and Skills
The availability of tools and skills made the platform more than a replacement runtime. Claude Code and Claude Cowork had already demonstrated the value of skills. Once the AgentSkills spec became open and model-agnostic, that style of capability could move into a more local and controllable environment.
Instead of requiring manual execution for every high-friction step, the system could run a known capability directly and return a structured result. That reduced both time cost and initiation cost.
Setup
The setup process was fairly simple:
Implementing Tailscale
Because the computer running OpenClaw is not the primary machine, Tailscale provided SSH access for setup. Physical access to the computer remained available for direct config inspection, while the primary laptop no longer needed to stay online 24/7 for the agent system to remain available.
Documentation, scripts, and notes could be accessed from one machine while the other was being configured.
Download and Set Up OpenClaw
The installation itself was straightforward. The harder part was deciding what should live there and what should remain external. The system needed to come online quickly without making its operational boundaries opaque.
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 another agent be added?" 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 part of the motivation for the move, but local support only becomes useful once routing logic is 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 about the transition itself: why the earlier setup was left behind, 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