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

@tylerilungaa 

Straight answer to your question: yeah, tmux with named sessions is genuinely good and it's where I'd start too, it's the cleanest single-machine version of this. Named, colored, one per agent, you can eyeball the grid. The two places it stops scaling are the ones you'd predict: it's still manual polling (you have to look at the grid for it to tell you anything), and it lives on one machine, so the second you walk away from the desk the dashboard you built doesn't follow you. Great while you're sitting in front of it. Useless the moment you're not, which is exactly when the agent goes quiet on an approval.

The cost dimension is the more interesting thing you said, honestly. "Same task, wildly different token burn across agents" is a real signal hiding in plain sight, it means the expensive agent is either taking a worse path or thrashing, and you'd never catch it from status alone because both finish. Status tells you it's done. Cost tells you whether it was done efficiently or it flailed its way there. Two different truths, and most people only watch one.

That's actually converging with something else in this thread, a few people landed on cost-per-useful-output rather than raw spend as the metric that matters, because raw tokens measure activity and approved output measures value. Pairing your per-agent cost with status in one view is the right instinct, and the next step is tying cost to whether the output actually shipped.

For Pushary I'm scoped on the status/approval half, status, blocked, what-changed, across tools and onto your phone, rather than the cost half, but the two clearly want to live in the same inbox eventually. Curious, when you found an agent burning way more tokens on the same task, was it taking a genuinely worse approach, or just looping and retrying? Trying to figure out if token-burn is a quality signal or just a noise signal.

@angsak6 

That's a clean little hook and I respect the minimalism, twelve lines, fires a native notification, plays Glass.aiff so you get the audio cue too. For one tool on one Mac while you're sitting at it, that's honestly hard to beat, no SaaS required.

Three ceilings it hits, all of which you've probably half-noticed: it's Codex-only (your hook doesn't know Claude Code or Cursor exist, so you'd be maintaining three of these), it's osascript so the notification dies at the edge of that machine and never reaches your phone, and the payload is just a $MESSAGE string, it tells you something happened but not whether the agent finished clean, got blocked, or what it changed. It's a doorbell. It rings the same whether it's a package or a fire.

That's basically the gap Pushary fills, same hook idea you've already wired, but the event carries a real handoff (done vs blocked vs what-changed), works across Codex/Claude Code/Cursor instead of one, and lands on your phone instead of dying on the desktop you walked away from. You've built the trigger. The missing parts are reach and payload.

Genuine question since you're clearly comfortable in the hook layer: what EVENTs are you actually firing on right now, just task-complete, or have you got it hooked into the approval/blocked moment too? The blocked one is harder to detect from a hook and it's the one that actually saves time.

@qiwap 

"I'm still the owner of the project and I know where it'll land" is the entire point, and you've protected it the most reliable way there is: reviewing every change so nothing enters the codebase you haven't seen. At one agent with review-on-every-update, that ownership feeling is real and earned, not a vibe.

The interesting question is what happens to that feeling when you scale. The whole reason ownership stays intact for you is that you can personally review everything in real time, one agent moves at a pace one human can fully watch. The thread's pain starts the moment that stops being true: six agents move faster than you can review live, and the ownership feeling erodes not because you stopped caring but because you literally can't see everything anymore. You become a bottleneck or you lose the plot, pick one.

That's exactly the feeling Pushary is trying to preserve at scale, let you keep being the owner who knows where it lands, by surfacing what each agent changed and flagging the stuff that actually needs your eyes, so "review everything" becomes "review the things that matter" without losing the thread. Same ownership, just affordable past one agent.

Genuine question: at one agent reviewing every update, would you even want more agents, or is the deliberate single-stream pace part of how you keep that ownership clear? Some people run six to go fast, some run one on purpose, curious which camp you're in.

@andreas_rubin_schwarz 

"The moment you start working in the agentic world you turn into a manager" is the cleanest one-line diagnosis in this thread, and it reframes the whole problem correctly. People keep trying to solve this as an engineering tooling issue when half of it is just management, and nobody handed us the management training. The skills that suddenly matter, scoping work, defining done, planning what runs in parallel, are exactly the things a good eng manager does, and exactly the things ICs spent years avoiding.

Your planning-heavy approach is the right one and I'll push it one step further: good planning is preventative, it reduces the number of interruptions by removing ambiguity up front, which is genuinely the highest-leverage move. But it caps out, because no plan survives contact with execution perfectly, and the residual, the ambiguous call the plan didn't anticipate, still surfaces mid-run. So planning shrinks the interruptions, it doesn't zero them. The two halves are "plan well so it asks less" and "see clearly when it does ask," and you need both.

Which is why the line you almost threw away, "staying active in the hand-off," is the one I'd underline. That's the half that's still manual for most people, and it's exactly where Pushary lives, making the handoff legible so the manager-you can stay active in it without sitting in the terminal.

Your milestones and eval set define what good looks like, the handoff layer tells you whether each agent hit it. Planning and visibility, same job from two ends.

Genuine question, since you're running this like a Linear board: do you find the agents are good enough at self-reporting against your milestones, or do you still have to translate "what it did" back onto "which epoch this was" yourself? That mapping seems like where the manager tax quietly hides.

@md_khayruzzaman 

Your closing line is the whole thread in one sentence: the workflow is surprisingly manual considering how autonomous the agents are becoming. That's the paradox exactly. The agents got self-driving and the supervision is still a guy walking between terminals with a clipboard. The autonomy moved down the stack, the awareness didn't move at all.

And your setup proves the point better than any pitch could. Desktop notifications plus separate terminals plus a Pushover script plus periodic checks, that's four partial systems doing one job badly. Each piece works, but you've become the integration layer between them, which is why it feels like another thing to monitor. You didn't eliminate the babysitting, you distributed it.

Here's the part I have to just say plainly: your four-point wishlist is Pushary's feature list, almost word for word. One place for all agent status, instant ping when one needs input, a summary of what changed while you were away, and approvals you can answer from your phone. You wrote the spec, I built it, pushary.com. I'd genuinely like you to try it and tell me where it falls short of the list you just wrote, because you've clearly lived this problem long enough to be a brutal judge.

One question to calibrate: of your four wishes, which one would you pay for first? My bet is number four, phone approvals, because the 30-minute blind wait is the one you called the biggest issue. But people keep surprising me by picking the summary instead.

@kevinzrzgg 

The new idea in this one is your last sentence, and it's bigger than the spec: "if it can't produce that summary, I'd rather keep the run small." You just made the handoff a precondition for autonomy, not a nice-to-have. The size of task you're willing to delegate is capped by the quality of the report you get back. No summary, no long leash. That's the cleanest articulation of trust I've seen in this thread, and it flips the usual framing, people think autonomy is about the agent being smart, you're saying it's about the agent being legible.

Which means the handoff isn't a notification feature, it's the thing that unlocks bigger runs. Improve the report, and the same agent safely earns longer horizons. That's the actual product, the trust dial.

And agreed on the split, done and stuck are different species. Done is informational, read it whenever. Stuck is a blocked thread costing you minutes right now. They shouldn't even sound the same on your phone.

Pushary's bet is exactly this shape: the handoff (status, files, tests, waiting-on-what) as the standard payload, stuck as the loud one. One question, since you've effectively defined the trust dial: what's missing from today's agent summaries that stops you trusting longer runs, accuracy of what they report, or the stuff they leave out? Lying versus omitting feels like the difference between fixable and dangerous.

@yashvinder_singh 

"Fast but unaccountable junior developers" is the right mental model, and the word doing the work is unaccountable. A human junior has skin in the game, embarrassment, a performance review, a memory of last time. An agent has none of that, so the accountability has to live in the system around it: diffs, tests, linters, small reviewable steps. You're not describing caution, you're describing replacing the missing accountability with architecture. That's the correct trade.

The phrase I'd frame, though, is your last one: supervising execution at speed. Because that's where the model strains. Diffs-as-control works perfectly at one agent, the math is on your side. At four agents producing PR-sized diffs in parallel, the diffs don't shrink, your hours do. The control mechanism stays correct and you become its bottleneck. Reviewing everything was the answer when the agents were slower than you. They aren't anymore.

So the question becomes how to keep your discipline affordable at speed, and the answer isn't reviewing less carefully, it's triaging what reaches you. Tests and linters already filter the mechanical failures before your eyes get involved. The missing layer is the same filter for attention: which diff touched something risky, which agent is blocked on a judgment call, which run finished clean and can wait until after lunch. That's the slice Pushary handles, the handoff arrives with the diff, the test results, and a risk flag, so your review time lands on the 20% that needs a human and the routine stuff stops costing you context switches.

You clearly run this discipline for real, so the question I'd ask: at how many parallel agents does your review-everything approach start to crack? Everyone has a number where the queue outruns the reviewer. Mine was three. Curious where yours is, because that number is basically the whole market for this category.

@theuniverseson 

"Finished, looks done, quietly wrong" is the scarier sibling of the silent wait, and you're right that it bites harder. A blocked agent costs you minutes. A confidently wrong "done" costs you whatever gets built on top of it before anyone notices. The wait wastes time, the lie compounds.

The move you made is the important one: you demoted the agent's "done" from a fact to a claim. Self-report is testimony. The diff is evidence. And your economics are exactly right, ten seconds of reading evidence beats re-running a task that testified falsely, every single time. The diff can't lie about what changed, it can only be misread, and that's a much better failure mode to own.

That's precisely why Pushary's "done" notification refuses to arrive empty-handed. The claim ships with its evidence attached: the diff, the tests that ran, what failed, flags on anything risky. "Done" alone is the agent grading its own homework. "Done, here's exactly what I touched" is the agent submitting it for your ten-second scan. The notification's job isn't to tell you it finished, it's to make your distrust cheap.

One question, because you've clearly tuned this: does the ten-second scan ever miss the quietly-wrong case where the diff itself looks reasonable, right files, plausible changes, but the logic is subtly off? That's the layer where I suspect the scan needs test results sitting next to it, because a clean-looking diff with a failing test tells you in two seconds what reading the code might miss in ten.

@nayan_joshi 

You just named the actual engineering problem underneath this whole thread, and you're right: there is no output contract. One agent announces completion, one just goes quiet, one blocks on stdin without saying a word, and silence is semantically ambiguous across all three. Done, stuck, and crashed can produce the identical absence of output. You can't build a clean signal on top of systems that don't agree on what stopping means.

So any honest notification layer has two choices. Hope a standard emerges, or absorb the brittleness on behalf of everyone. The good news is it's not pure terminal-scraping anymore: Claude Code ships hooks, Codex has lifecycle events, and where a real hook exists you get a true state transition instead of a guess. Where one doesn't, you're back to heuristics, process state, file activity, stdin-wait detection, and yes, that adapter is brittle and needs maintenance every time a tool changes its behavior. The question is just where that brittleness lives: in a thousand people's personal dotfiles, each breaking separately and silently, or in one adapter layer that's somebody's actual job to keep current.

That second option is literally what Pushary is. Per-agent adapters on the bottom, normalizing whatever each tool emits into one state machine, running, blocked-on-input, failed, done-with-diff, and one contract on top that your phone and your team consume. The agents never agreed on a standard, so the layer fakes the standard and eats the maintenance. You pay us to own the brittleness so your tmux split can go back to being a layout choice instead of a monitoring strategy.

And if a real standard ever does emerge, some agent-lifecycle event spec the vendors actually adopt, that's not a threat to the layer, it's a gift, the adapters get thinner and the value moves up into routing, policy, and the approval flow. Genuine question from the trenches: of the agents you run, which one's blocked state is hardest to detect from outside? My ranking has the silent-stdin-wait as the worst offender by far, since it's indistinguishable from thinking, but you're running the same pair and I'm curious if your experience matches.

@vlasoffchess 

You and at least five other people in this thread independently landed on the same two words, "control center," and then immediately flinched at them, because you all also said the same fear: not another dashboard to babysit. That tension is the whole design problem in one breath. People want one place that knows everything and zero places they have to watch. Those sound contradictory and they're not, but only if you get the polarity right.

The resolution is that a control center you check has failed, and a control center that checks you has worked. Same data, opposite default. It sits dark, knows the state of every agent, and stays silent until one crosses into a state that needs you: blocked on input, finished with a diff, failed. The "what each agent is doing" view exists for the moment you want it, but you're never required to look, because the looking comes to you. The babysitting fear is real and the fix isn't a prettier dashboard, it's making "forgot to check it" impossible by never requiring the check.

Your last item is the sharp one, by the way: "whether it is safe to approve." That's the highest bar in the list. Status is mechanical, the diff is mechanical, but "safe to approve" requires the layer to know that a payment change or an auth edit is a different animal than a typo fix. That's the risk flag, and it's the difference between a notification you glance at and a decision you can actually make from the lock screen.

That's exactly the shape of Pushary, so the honest test is whether it clears your bar without becoming the thing you fear. Question back, since you've run multiple agents: would you trust the layer to tell you "safe to approve," or do you want it to just surface what changed and let you make that call every time? I keep going back and forth on whether people want the judgment or just the evidence, and your answer tells me which one to build louder.