AI Agents & Automation

The Agent That Speaks First

Brett Ridenour Brett Ridenour · Published July 2026

Almost every AI product I use is reactive. I type a thing, it does a thing. Claude Code, ChatGPT, Cursor, Copilot — none of them open their mouths first. They wait. The transcript is always one where I speak, they answer, I speak again.

That model is fine for coding. It falls over the moment you want an agent to actually manage something. A manager who only speaks when you ask them a question is not a manager. They’re a search engine with better manners.

I’ve been building a small thing this week — call it a reservation babysitter — for the operators on Freebo, my booking platform for tour and charter businesses. It reviews the next three days of upcoming reservations, cross-checks them against the operator’s calendar and their inbox, and flags anything that looks wrong. Missing paperwork. A booking that says four people but the confirmation email says five. A slot that was moved on Google Calendar but never updated on the booking page. A payment that hasn’t settled.

The interesting part isn’t the check. It’s that the check happens without anyone asking for it. Every morning at six, the agent wakes up on its own and either says “you’re clear for the next three days” or drops a short list of things to look at before the boat leaves the dock.

This is a different kind of AI product, and it’s underbuilt.

Reactive is the default because it’s the safe shape

The reason nobody ships proactive agents by default is that a proactive agent has failure modes reactive agents don’t have. A chat interface is bounded — the worst thing that happens when a model misfires is you don’t hit send. A proactive agent can bury you in false alarms. It can also fail silently, which is worse: you assume you’re being watched, you stop watching, and then the one thing that mattered slips past the sleeping guard.

So the design work is not “how do I make the model smart.” The model is fine. The design work is:

  • What does it look at?
  • When does it look?
  • What is the bar for it to speak?
  • Where does it speak, and does that surface survive being ignored?

Get those four right and the model layer almost doesn’t matter. Get any of them wrong and the smartest model on Earth becomes a nag you mute.

The shape

1
Timer fires
systemd timer at 6:00 local time. No inbound trigger. The agent wakes itself.
2
Pull state
Next 3 days of Freebo reservations. Same window from Google Calendar. Unread inbox threads that mention any of those bookings.
3
Compare
For every reservation: does the calendar match? Does the inbox contain updates that never made it into the system? Are there payments pending past due?
4
Speak (or don't)
If nothing looks off, post one line: 'You're clear through Sunday.' If something is off, post the specific list with the specific bookings.
5
Suppress
Anything flagged today gets a fingerprint. If tomorrow's run finds the same fingerprint unresolved, it goes into a quieter 'still open' section, not the top.

That’s the whole thing. There is no chat interface. There is nowhere to type. The agent has one job and it does that job on a schedule.

The systemd timer is 90 percent of it

The unglamorous truth about proactive agents is that the interesting engineering happens outside the model call. The model call is a well-solved problem — you write a prompt, you call the API, you get a response. What’s actually load-bearing is the timer, the state pull, and the surface where the output lands.

The systemd timer and service files that run the babysitter every morning

The whole scheduling layer is those two files. Persistent=true on the timer is the important line — if the machine was asleep at six, it runs the moment it wakes. Miss that and the agent is only vigilant when the laptop happens to be up at the right minute. The service unit shells out to the Claude Agent SDK with a fixed prompt and read-only credentials for the three data sources. There’s no fine-tuning, no vector store, no orchestrator, no memory. Every run is stateless except for one small JSON file that remembers which issues it flagged yesterday.

The prompt is short on purpose

The temptation with proactive agents is to hand them a novel of instructions. Don’t. The longer the prompt, the more places for the agent to invent things to flag.

The core is one paragraph:

You are reviewing the next three days of reservations. You have access to the booking system, the operator’s calendar, and their inbox. For each reservation, check: does the calendar block match? Has any email in the last 72 hours mentioned a change that isn’t reflected in the booking? Is the payment status what it should be for how close the trip is? Return one line if everything looks fine. Otherwise, list only the specific reservations with the specific issue in one sentence each. Do not speculate. If you are not sure, do not flag it.

That last sentence is the ballgame. “If you are not sure, do not flag it” is the difference between an agent you keep and an agent you kill inside a week. False positives are how proactive AI dies. A model that flags six things a day, four of which are nothing, gets muted, and once it’s muted it might as well not exist.

The output surface has to survive being ignored

The one thing I’ve learned from a year of building this kind of system is that the output surface matters more than the model. Push notifications get dismissed. Emails get filtered. Slack messages get read once and buried under whatever came in the next hour.

The surface that actually works is a persistent file the operator will look at anyway. In my case, it’s a small notes file that lives on the operator’s dashboard. Yesterday’s list is still there. Today’s list is above it. If a flagged reservation is still open, it stays visible until it isn’t. You cannot dismiss it into oblivion by swiping. The only way to make it go away is to fix the thing it’s pointing at.

Why this shape is underbuilt

Proactive agents are underbuilt because they are less demoable than chat. You can put a chat interface on a landing page and get an “aha.” You cannot put a systemd timer on a landing page. The demo is “here is what wasn’t in your inbox this morning because I already handled it,” which lands about as well as “here is the burglary that didn’t happen.”

They’re also harder to sell. A chat product charges per message. A watchful agent charges per day of vigilance, and the value on any given day is either “nothing bad happened, which was going to happen anyway” or “I saved you from a very specific disaster.” The customer only feels the value on the second kind of day, and by then they’ve been paying for the first kind of day for months.

A manager who only speaks when you ask them a question is not a manager. They’re a search engine with better manners.

— the shape of the whole idea

The takeaway

If you’re building with the Agent SDK and everything you’ve shipped so far is a chat, try building one thing this month where the model never gets a human prompt. Pick a piece of state you already have to check every morning — reservations, invoices, deploys, inbox threads over three days old, whatever — and hand that check to an agent on a timer.

The interesting product surface for AI right now is not “answer my question faster.” It’s “watch the thing I keep meaning to watch and speak up when it matters.” The model layer is a commodity. The vigilance layer is not, and almost nobody is shipping it.