How do you stay aware of what your AI coding agents are doing?

by

I've been running Claude Code, Cursor, and Codex pretty heavily for the last few months and I keep hitting the same loop:

1. Start a task in one agent

2. Switch to something else (Slack, Twitter, another terminal)

3. Come back 30-40 minutes later

4. Agent finished 35 minutes ago. Or worse, it's been waiting for my approval the entire time.

The more agents I run, the worse it gets. There's no unified way to know what's happening across them.

Curious what other people's setups look like:

- Do you just keep terminals visible and check manually?

- Built any custom notification scripts?

- Use something like ntfy or Pushover?

- Just... accept the wasted time?

I've been building something in this space (push notifications + approval flows for AI agents) and I'm trying to understand if everyone's workflow is as janky as mine, or if some of you have figured out something clever.

Would love to hear what's working and what's not.

4.1K views

Add a comment

Replies

Best

Ran into the same wall running three agents at once. What actually helped wasn't a notification tool, it was going back to one agent at a time on anything that needs approval, and only fanning out on tasks I'm fine letting run unattended. The awareness problem is really a batching problem. You can't watch four things, so don't start four things that need watching.

 

"Don't start four things that need watching" is a genuinely sharp reframe, and you're right that it's a batching problem before it's a notification problem. Splitting by "needs approval" versus "safe to run unattended" is the correct first cut, most people skip that triage entirely and then wonder why six terminals feel like chaos.

Where I'd gently push: that split is manual and static. You're the one deciding upfront which tasks are watch-worthy, and you're right most of the time, but the awkward case is the task you launched as unattended that hits an unexpected approval mid-run. Your batching didn't predict it, so now it's stuck and you're back to the same silent-wait problem, just less often. The batching reduces the surface, it doesn't close it.

That leftover slice is the only thing I'm really trying to catch, the unattended task that unexpectedly needs you. For the stuff you correctly batched as needs-approval, honestly your one-at-a-time approach is fine and a tool would just be noise.

Curious, when an unattended task does surprise you with an approval, how often does that actually happen? If it's rare, you've basically solved this with discipline. If it's common, that's the gap.

 For me it's rare, maybe one in five or six unattended runs, and always the one I was most sure about. The frequency isn't the problem, it's that I can't predict which one, so I either check all of them or get burned on the one I ignored. Real gap, just a narrow one. The thing I'd actually want isn't a dashboard, it's a single ping the moment any agent goes from running to waiting. Not status, just the state change. Everything else I can live without.

 

"Always the one I was most sure about" is the whole thing, isn't it. The unpredictability is the actual problem, not the frequency. One-in-five that you can't predict forces you back to checking all five, so the narrow gap quietly taxes every run anyway. That's the sneaky cost of rare-but-unpredictable: you pay attention on all of them to catch the one.

And you just described Pushary's core primitive better than my landing page does. Not a dashboard, not status, just the single running-to-waiting state change, pushed the moment it happens. That's the one signal that collapses "check all five" into "check the one that pinged." Everything else really is optional, you nailed it.

The only thing I'd add underneath it: catching running-to-waiting cleanly is harder than it sounds, because from the outside a waiting agent and a still-thinking agent can look identical. The ping only works if the agent actually declares "I'm blocked" rather than just going quiet. That detection is the real engineering, the notification is the easy part.

That's exactly what I'm building, so genuine question: would you want to answer the approval from the ping itself, or is the ping alone enough and you'll go to the terminal to act? Some people want the full remote yes, some just want the nudge.

 The nudge, every time. The tasks that hit an approval are exactly the ones that need my judgment, and judgment needs context a ping can't carry. If I say yes from the notification I'm approving blind, which defeats the point of it stopping for me. So the ideal is a nudge that drops me straight into the right terminal with the context already there. The remote-yes is most tempting for the tasks it's least safe on.

On detection, you're right it's the hard part. Quiet-and-thinking and quiet-and-blocked look identical from outside. The only clean signal is the agent declaring "blocked," which makes it doable on tools you can hook like Claude Code and near-impossible on black-box ones. I'd rather you nail detection on the three agents everyone actually uses than support forty badly.

First
Previous
•••
131415