AI Agents

This post traces how my AI-agent work moved from loose daily automation toward a more inspectable operating system for planning, research, and execution.

Thoughts on AI and AI Agents in General

How I feel about AI in general is fairly simple: it is a tool. Like every tool, it needs to be used properly. Also like every tool, a person should get to the point where they are not fully dependent on it. If it is used poorly, it can absolutely dull reasoning and weaken good habits of thought. A person should not be afraid to have AI challenge them, but they also should not let a language model drag them toward views they do not believe are morally or ethically right.

I believe AI is the next great equalizer in assistive technology. AI can simplify or structure language in more accessible ways and make text-to-speech and speech-to-text feel much more natural, among many other possibilities that I find genuinely exciting. Personally, AI functions as a sounding board and as part of my capacity management system. It helps me do things I love while keeping the associated costs legible enough that recovery stays possible. I use an LLM every day to help devise what I am doing, but I can still reconstruct that information later. I know what I am putting into the model and what is coming back out. I use AI to reduce the emotional and cognitive load of work that I can do myself but often should not have to do the hard way.

The interesting question is not just whether AI can do something, but what kind of structure makes that help responsible and useful.

Where I Started

The previous structure of my agentic system was a single-agent, nondeterministic workflow. It brought some structure to my life, but not enough. As a starting point, it helped reduce decision fatigue by integrating calendar data, academic deadlines, and personal commitments into structured daily plans. However, the system only structured what was on my schedule, not necessarily how to begin a task. It also could not accurately estimate how much energy a task would take, which is part of what pushed me to devise the Work Unit system.

I kept iterating. 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 on my calendar, 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.