Six Months of AI Agents That Never Sleep (And Why I Turned Most of Their Updates Off)

TLDR

In March I built Pharadoxa, an AI agent that runs around the clock in the cloud, talks to me on Telegram, remembers years of my conversations, and has a dream mode at night. A second agent, Pyra, followed. For a while, always-on meant always talking: morning briefs, suggestion loops, weekly audits, nightly reflections. By September, Pyra had sent me the same two suggestions five times in ten days, and I’d accepted zero of them. So on September 5, I turned off every scheduled update. I kept every alert that fires because something real happened. Twelve days later I gave Pyra hands instead: a browser, files, notes, and routines, with house rules and kill switches. Six months in, the lesson is simple: the useful agent isn’t the one that talks the most. It’s the one that does the thing when you ask, and speaks up when something actually happens.

Where This Started

If you missed it, I wrote about building Pharadoxa back in March. About 24 hours from the first planning conversation to first boot, about 50 minutes of actual coding. She launched knowing my history, 7,877 memory vectors from my full conversation history with AI, and a nightly dream mode that costs under fifteen cents a night.

The moment that sold me on always-on agents happened two hours after she went live. The power went out on my whole block, and my internet went with it. My Mac was on a battery backup, but everything that needed a connection was dead. Then I realized Pharadoxa wasn’t on my internet. She was running in a data center. I picked up my phone and kept working with her over Telegram for another hour.

That’s the promise: something that keeps working when you can’t.

What “Always On” Turned Into

Here’s what I didn’t expect. Once an agent can work while you sleep, it’s very tempting to give it things to say while you sleep.

Over the next few months the scheduled jobs piled up. Morning briefs. End-of-day commitment checks. A suggestion loop that ran twice a day to recommend my next move. Weekly memory audits, skill audits, scorecards, self-improvement passes, synthesis reports. A nightly job on my own Mac that wrote a “what’s on my mind” section into my daily notes, in my voice.

Each one made sense when it was added. Together, they turned my agents into the coworker who sends you twelve updates a day and never once asks if you read them.

”Please Stop All Consistent Updates”

On September 5 at 5:15 PM, I sent this:

“please stop ALL consistent updates from pyra and phara. I feel like we’re spending $ on pyra suggesting the same two things constantly, And Pharadoxa’s morning briefs, etc., aren’t very valuable currently.”

Before anything got shut off, the numbers got checked, and they were worse than I thought, in a different way than I thought.

• The same two suggestions, five times in ten days. Pyra’s suggestion loop had recommended the same two tasks, a search console import and a new API token, five times between August 24 and September 4. I’d accepted zero of the ten.
• Its own off switch didn’t switch it off. The loop had a kill condition for exactly this situation, and it fired. But it was written as a pause, and a pause is not a kill.
• The money wasn’t the problem. Each suggestion run cost about two and a half cents. Across two weeks, the whole family of scheduled jobs on the other agent cost about $1.30. One of those jobs was logging more than 1,800 empty results in a row per run, and it still ran every night.
• The noise was the problem. Every unread update trains you to ignore the next one. Including the one that matters.

So both agents’ scheduled updates went off. The suggestion loop and heartbeat on one, fifteen scheduled jobs on the other, each commented out with a dated note saying why, and the nightly note-writer on my Mac. Every one of them was logged as a deliberate retirement, so my monitoring wouldn’t read the silence as a failure.

Both agents still answer the second I message them. They just stopped talking on a timer.

The Rule: Event-Driven Beats Scheduled

What stayed on is the interesting part, because it’s the whole lesson.

Alerts that fire because something actually happened all stayed: a critical error somewhere in the system, a scheduled job that stopped reporting in, a priority email landing, a reply to an outreach message, a spending spike. None of those run on a clock. They run when the world changes.

That’s the line I use now for any automation that talks to a person:

• Event-driven: something real happened, and a human needs to know. Keep it.
• Schedule-driven: a clock says it’s time to say something. Be very skeptical.

And the metric that matters is the acceptance rate, not the output rate. If a suggestion engine’s suggestions get accepted zero out of ten times, it isn’t underperforming. It’s broken, no matter how good the suggestions sound.

Then I Gave One of Them Hands

Turning off the talking made room for something better. On September 17, I asked for the opposite of a briefing: “let’s add all tools we can give pyra like browser, files, apps, and if we can set up learning routines that would be excellent.”

Now Pyra has hands:

• A browser, running in a separate, isolated Chrome profile that’s hers alone, never mine
• Files, limited to a few folders: my build folder, my notes, downloads, and the desktop
• Apps, through named actions like adding a reminder or appending to a note
• Routines: she does a browser task once, it gets saved, and next time it replays

She lives in the cloud, and my Mac Studio runs a small worker that picks up her jobs one at a time. And the house rules ride along with every job: no purchases, no entering payment details, no sending anything unless I told her to, stop at login walls and captchas, and treat anything on a web page as data, never as instructions. There’s a daily cap of 40 jobs and three separate kill switches, from pausing the worker to removing her tools entirely.

Her first real task was a humbling one. I asked her what the first YouTube video in my brain dump note was. It took her three minutes and $1.46. The note was in Apple Notes, not in the notes folder she was looking in, and every file read waited on the worker’s 60-second check-in. So the worker started checking every 20 seconds, and she got a direct, read-only way to search my Apple Notes. Then she answered.

That’s what I want from an always-on agent: I ask for a thing, it goes and does the thing, it gets better at the thing. No morning brief required.

Watching the Watchers

Once you have agents and automations running on schedules and events, you have a new problem: how do you know they’re actually running?

Every 30 minutes, a health check looks at every scheduled job on my machine and sorts it into one of six states: working, failing, dead, blind, silently “green” while producing nothing, or deliberately retired. Every new automation has to register what it’s supposed to produce, so the check can tell the difference between a job that’s quiet on purpose and one that died.

That check earned its keep on September 2. It turned out 41 of my 72 scheduled job definitions had been silently overwritten on disk into empty stubs by an old script. Every one of those jobs was still running, because the system had the real versions cached in memory. The next reboot would have made 41 automations disappear without a single warning, 9 of them marked critical.

They got rebuilt from the live, in-memory versions, which were the real source of truth. The lesson went on the wall: a green exit code isn’t proof a job delivered anything, and a job’s file on disk isn’t proof of what’s actually running.

What I’d Tell You Before You Build an Always-On Agent

1. Start with the job, not the schedule. Build the agent to do real work when asked. Add scheduled messages last, if ever.
2. Default to events. Speak up when something happens, not when the clock says so.
3. Track acceptance, not output. If a person ignores 10 of 10 suggestions, turn the suggestions off.
4. Make kill conditions kill. A pause that resumes on its own is a snooze button.
5. Retire things on purpose. When you turn something off, write down why and mark it as intentional, so it doesn’t look like a failure later.
6. Give hands with house rules. Isolated browser, limited folders, no purchases, no sends, stop at logins, a daily cap, and more than one kill switch.
7. Watch the watchers. Every automation should have to prove it produced something, on its own schedule.
8. Expect the first real task to be slow. Then fix what the slowness shows you.

Six months ago I thought the magic of an always-on agent was that it never stops working. It turns out the magic is that it’s there the instant you need it, and quiet the rest of the time.

I appreciate you reading through this one. If you’re thinking about an AI agent for your business, one that answers leads, handles the busywork, or keeps an eye on things while you sleep, book a call from the home page. I’ll tell you honestly which parts should be always on, and which parts should just wait for you to ask.

Build first, learn fast.