Development record · system history
AI Agents
A record of the move from loose daily automation toward a system where state, routing, and failure boundaries leave a trail.
Development record
The schedule stopped being enough
The system changed as calendar rearrangement gave way to work-unit accounting, telemetry, local model experiments, and eventually explicit routing and control.
- Single-agent planning and daily briefings
- Work Units, automation limits, and observability gaps
- OpenClaw as the turn toward governed operations
Context
This history follows the move from loose daily automation toward a more inspectable control system for planning, research, and execution.
Operating requirement
AI could reduce initiation and cognitive load, but generated output still had to be reconstructable, checkable, and owned by the person using it. The question was not only what a model could do; it was what structure made that help responsible and useful.
Where It Started
The initial agentic system was a single-agent, nondeterministic workflow. It brought some structure to daily life, but not enough. It could integrate calendar data, academic deadlines, and personal commitments into daily plans, which helped with decision fatigue. But it only structured what was on the schedule, not how to begin a task. It also could not estimate how much energy a task would take, which pushed the design toward the Work Unit system.
Version two incorporated Work Units and grew into an overbuilt web of Apple Shortcuts, many of them involving LLM calls. It was creative, but it was not deterministic enough. Version three became more engineered and less chaotic by moving more preprocessing into code and narrowing the system back down to a single planning output in the form of a daily briefing email. It was better, but it still had serious blind spots.
The main problem was observability. The system could not track Work Unit expenditure over time in a sufficiently rich way. It could reason about planned events, but not about the everyday accumulation of assignments, email, side projects, and other non-calendar work. That gap is what links this history so closely to Field Note 0 - Instrumentation. The system needed better telemetry, not just more automation.
Keeping personal data local also became more important as the telemetry system grew. Ollama looked like a promising fit, but Apple Shortcuts and local model serving were not a great combination, especially when reliability mattered at 04:00 every day. Eventually it became obvious that a different architecture was needed.
What Changed Next
After this transition, the work moved into The Fleet, which made telemetry, routing, and agent ownership more explicit. The current projects extend the same pattern into domain-specific systems such as The Shape Note Atlas: bounded work packets, source-of-truth artifacts, and validation receipts matter more than adding another generic automation layer.
This post is therefore a history of the problem and the architectural turn, not the final word on the system. The Fleet and The Shape Note Atlas are the living notes for what came next.
Project timeline
Archive chronology from the versioned narrative on this page. This article documents a system history rather than exposing one public source repository.
- Version 01 · planning
Start with the calendar
The first system combined calendar events, academic deadlines, and personal commitments into daily plans.
Result: it reduced decision friction around scheduled work, but it only represented what was already on the schedule.
- Version 02 · Work Units
Account for the work behind the schedule
Work Units were added to represent task cost and initiation effort. The system grew into a large network of Apple Shortcuts and LLM calls.
Result: the model captured more of daily life, but the automation became too nondeterministic to trust without stronger boundaries.
- Version 03 · telemetry
Move preprocessing into code
More preprocessing moved out of shortcuts and the output narrowed to a daily briefing. The remaining blind spot was observability: work-unit expenditure and non-calendar accumulation were still difficult to track.
Result: the system became tidier, but the telemetry gap became impossible to ignore.
- Version 04 · migration
Turn toward a governed system
Local model experiments exposed the limits of combining Apple Shortcuts with a reliable always-on model service. The next architecture needed live context, routing, tools, and clearer operational boundaries.
Result: the work moved into the OpenClaw transition and, later, The Fleet.
System
Version Four: Transition to OpenClaw
The companion case study covers the setup process and workflow. The short version is that OpenClaw supplied the structure the earlier versions lacked.
OpenClaw has native local provider support as long as the API in question supports either OpenAI or Anthropic specifications, including documentation on how to use Ollama. Prior Ollama experiments made that support relevant. OpenClaw is also open source, which matters when sensitive planning infrastructure should not depend entirely on a closed company remaining available or interested. Its alignment with the AgentSkills spec provided a practical framework for reusable capabilities instead of one-off prompts.
That transition later became The Fleet: a multi-agent architecture with clearer roles, better routing, and an operational model that can be inspected.
Artifacts