Keeping work current

In June 2026, I wrote about something I had started calling GPT fatigue. I enjoyed working with the models, but the context switching was wearing on me. It was far from the uninterrupted coding rhythm I had enjoyed earlier in my career.

A large share of our company’s operations lived in a directory: specifications, code, analytics, a financial model and a sales CRM. Real events would change our plans, and I would drop back into a session to ask an agent to bring one of those records up to date.

I had written programs for these jobs. What I wanted was for them to become ongoing responsibilities.

Putting everything on a schedule got expensive quickly. That led me toward a design inspired by React: declare the state you want, respond to upstream changes, and avoid repeating work whose inputs have not changed. The analogy had limits, but it was a useful starting point.

The experimental Reactor harness was one attempt at that design. Its units were agent sessions responsible for keeping parts of the maintained state current.

The larger ambition was still a hypothesis: could the cost of maintaining that state scale with surprise, rather than with wall-clock time?

I had not reached that point. The idea was to work toward it incrementally, with the practical goal of reducing the attention it took to keep things current.