I Turned Off My Own AI Monitor

The promise of proactive AI is simple. It watches your business and tells you what needs you today. Mine did exactly that. Every sixty seconds it woke up, read the state of a user's work, reasoned over it, and produced something like: three threads are unanswered, two meetings need prep, one task is overdue. Correct every time. Useless every time. I switched it off in May and it is still off, and the model was never the problem.

WHAT WORKS

Send the model entities, not counts.

My monitor was reading a snapshot that had already been summarised for it. Totals by category. By the time anything reached the model, every fact worth acting on had been thrown away upstream.

Here is the difference, using an invented account so I am not publishing anyone's inbox.

Before: three unanswered threads, two meetings today, one overdue task. After: the Vendco thread has been quiet for six days. You drafted a reply on Tuesday and never sent it. Their last message asked when the pilot starts.

Same model. Same prompt. Same cost per call. The only thing that changed is what was in the payload.

The first version can only ever produce advice the user could have written themselves. The second names a person, a delay, a half-finished action and an open question, so a recommendation has somewhere to land.

The rule I use now: before you touch the model, print the exact payload you are sending it, and read it as if you were a capable new hire being asked to act on that and nothing else. If you couldn't, neither can the model, and no amount of prompt rewriting will rescue it.

An entity payload needs five things.

• →Identity. Which thread, which deal, which customer, by name.
• →Age. How long it has been sitting in this state, in days.
• →State. Where it sits in whatever process it belongs to.
• →History. What already happened, especially anything the user started and did not finish.
• →The owed thing. Whose turn it is, and what the other side is waiting for.

Drop the last two and you get a monitor that describes your day back to you. Keep them and it produces something to do.

ONE PRACTICAL IMPLEMENTATION

Here is what each payload holds, in full, so the gap is visible rather than asserted.

The old one, complete:

• →unanswered threads: 3
• →meetings today: 2
• →overdue tasks: 1

The best output any model can produce from that is a rephrasing of the input. Three numbers in, three numbers out, wearing a sentence.

The new one, one entity per call:

• →entity: email thread, Vendco pilot timeline
• →counterparty: their operations lead
• →last inbound: six days ago, asking when the pilot starts
• →last outbound: none
• →user activity: draft written Tuesday, never sent
• →stage: proposal sent, scheduling not booked

The output changes shape completely, because now there is a specific thing to say: their question about the start date is six days old and your answer is sitting in drafts.

The quickest way to check your own: count the proper nouns and the timestamps in the payload. Zero of either means you are paying a language model to redo arithmetic you already did, worse than you did it.

One warning, because entity payloads cost more per call and the obvious saving is a trap. The temptation is to batch, send twenty entities in one call and ask the model for the top three. That moves the ranking inside the model, where you cannot see it, log it or test it, and where it will change under you the next time you swap models. Rank first, in code you can read, then send the top few one at a time.

WHAT DOESN'T WORK

• →Upgrading the model to fix a data problem. The best model available would have read the same three numbers and said the same useless thing, for more money.
• →Prompt engineering around missing facts. You cannot instruct a model into knowing something you never sent it.
• →Summarising before the reasoning step. Aggregation deletes evidence by design. Do it after, never before.
• →Shipping the noisy version as a beta. People mute a noisy alert in week one and they do not come back later to unmute it.
• →Measuring the monitor by whether it ran. Mine ran perfectly, on schedule, for weeks. The number that mattered was how often anybody did something because of it, and the answer was never.

ONE THING TO DO THIS WEEK

Pick the one AI feature in your product or your workflow that reads your data and tells you what to do. Log what it actually receives. Fifteen minutes.

• →Print the exact payload from one real run, before it reaches the model.
• →Read it cold, as someone with no other context would.
• →Underline every proper noun and every date in it.
• →If you underlined nothing, fix the payload before you touch the prompt.

---

Detection is the cheap half of proactive software. Being worth interrupting somebody for is the whole product, and that gets decided in your data layer, before any model sees anything at all. Alacrio exists because of that gap, and this was the part of it I got wrong first.

If you are building something that watches and nudges, and it keeps producing sentences nobody acts on, book a free consultation.