Every assistant I run waits to be asked, which means it only helps when I remember that it could. This is the design work on the opposite arrangement, a cheap model watching continuously and deciding when something is worth escalating to an expensive one.
Role Sole designer. Period 2026, ongoing. Scope Problem framing, architecture, and the integration with an existing personal assistant agent.
I run a reasonable amount of AI infrastructure. A personal assistant agent that reads my notes and my task tracker, a knowledge vault with its own set of agent commands, scrapers and watchers on a server, scheduled jobs that refresh a paper corpus. All of it works, and all of it is reactive. Every one of those systems waits for me to open a terminal and ask.
That is a real limitation and it is not a limitation of the models. The bottleneck is that the trigger is my memory. If I forget that a deadline exists, no amount of capability in the assistant helps, because the assistant is never invoked. The most useful thing an assistant could do for me is notice something and say so first.
This page is the design work on that, not a finished system. Two tracks: a cheap model watching continuously and escalating to an expensive one when something warrants it, and making the personal assistant I already have initiate rather than respond.
Reactive assistance has a specific shape of failure that is easy to miss because nothing appears broken.
When I ask my assistant what is on my plate, it answers accurately. It reads the vault, queries the tracker, and tells me. The answer quality is not the problem. The problem is that I asked on a day I happened to think about it, and the days I most need that answer are the days I am too busy to think about it.
An earlier check in this vault made the point precisely. There were unchecked items sitting in a daily note four months old, still open, that had never made it into the task tracker. Nothing failed. Nobody was blocked. The information was sitting there, correctly recorded, and no system had any reason to bring it up, because bringing things up unprompted was not a thing any of them did.
The obvious answer is scheduling, and I already have some. A cron fires a warmup at nine every morning. A systemd timer refreshes the paper corpus on a fortnightly cycle. Both work.
Neither is proactive in the sense that matters. A cron runs whether or not anything happened. It has no view on whether today is different from yesterday, so it can only ever produce the same digest, which is exactly the kind of notification a person learns to ignore within a week. Periodic is not the same as attentive.
Being genuinely proactive requires a judgement: something changed, and that change is worth an interruption. The judgement is the hard part and it is the part none of my current infrastructure makes.
The reason this is an architecture problem rather than a prompt is cost. Watching continuously means running something across my notes, tasks, calendar and activity data all day. Running a frontier model in that loop is not affordable, and running nothing means staying reactive.
So the arrangement is two tiers with an escalation gate between them. A small model runs constantly and cheaply, and its only job is to decide whether anything deserves a closer look. When it thinks something does, it calls a capable model to actually reason about it, and only that second stage can produce something that interrupts me.
This is the same argument I made when replacing four API calls with a model I trained: the interesting question was never which model is better, it was which costs scale with usage and which do not. Here the continuous tier has to be cheap enough to leave running, and the expensive tier has to be rare enough that it stays affordable.
The figure shows both arrangements. The part to look at is the gate in the lower path, and the fact that the most common outcome of the whole pipeline should be silence.
The first track is the watcher tier, and the open question is what runs in it.
The requirement is unusual. It needs to be cheap enough to leave running against a stream of personal signals, capable enough at tool calling to query the vault and the tracker itself rather than being fed a digest, and it never needs to write anything a human reads. Its entire output is a decision and a reason. That is a much lower bar than the assistant work people usually benchmark small models on, and it suggests the right candidate is a strong tool calling model rather than a strong writing one.
DeepSeek and the Hermes family are the two I want to try first, with escalation to Claude for the reasoning tier. That pairing is the part I am least sure about and the part I most want to test, because the whole design rests on the watcher being trustworthy about when to stay quiet.
The second track is less exploratory, because the agent already exists and already has the context.
I run a personal assistant agent that reads an Obsidian vault of notes, daily logs and project records, and queries a self-hosted Plane workspace for tasks and deadlines. It is deliberately scoped: the task tracker exposes 139 tools, and those are attached to the subagent rather than registered in the main session, so the manager agent never carries that tool list in its context. It connects when the agent starts and disconnects when it finishes.
Everything that agent needs in order to be proactive is already wired up. It can see what is overdue, what has gone stale, and what I wrote down and never filed. What it lacks is any reason to run when I have not summoned it, and any judgement about which of those observations is worth saying out loud.
So track two is narrower than track one. It is not a new system, it is a trigger and a gate on an existing one.
The honest risk is that the gate is the entire difficulty and I have not built it yet.
Notification fatigue is the obvious failure and it is unforgiving. A proactive assistant that surfaces four things a day when one mattered does not degrade gracefully, it gets muted, and once muted it is worth less than the reactive version because at least I used to open that one deliberately. The tuning problem has no safe default, since being too quiet reproduces exactly the system I am trying to replace.
The second risk is that the watcher’s cheapness is what makes it wrong. A small model deciding what deserves my attention is making a judgement about my priorities on thin context, and the cases where it will be most confidently wrong are probably the cases that matter most, because those tend to be unusual rather than typical.
I have no measurement for either yet. Until there is one, this stays an architecture rather than a claim.
Design and exploration. No escalation layer exists.
What is running: the personal assistant agent with its vault and tracker access, a knowledge vault with its own agent commands, watcher style skills on a self hosted agent framework, a daily cron and a fortnightly systemd timer. Those are the pieces the proactive layer would sit on, and none of them currently initiates anything on its own judgement.
The model choice for the watcher tier is unsettled, and the gate has neither an implementation nor an evaluation. I would rather publish it in that state than describe an intention as a system.