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

@grace_lee26 

Straight answer to your straight question: notifications are the wedge, not the destination. The ping is just the most acute version of the pain, the thing that gets someone to install it on a Tuesday. Underneath it is the real product, an agent activity and audit layer: what changed, what was reviewed, where a human approved, across whatever tools you're running. The notification is how it earns attention. The trail is why it stays useful.

One caveat I'd add, because smart people in this same thread pushed me on it: "dashboard" is a slightly dangerous word. The audit layer has to stay a boring handoff trail, not a charts-and-vanity-metrics thing you sit and stare at. The goal is something you almost never open until it taps you, and when you do, it hands you the decision instantly. Audit trail, yes. Dashboard you babysit, no.

And you put your finger on the actual moat: summary quality. "Done" is noise. "Changed 4 files, tests failed here, needs approval for X" is a decision point, and that gap is the entire product. Anyone can fire a notification. Making the payload good enough that you can rule on it without opening the terminal is the hard, valuable part, and it's exactly where most "we added notifications" features stop.

Curious which half of a good summary you'd trust an agent to get right, the factual part (files, tests, commands) is mechanical, but "needs approval for X" requires the agent to correctly know X is risky. Do you trust it to flag the right things, or would you rather define the risky paths yourself up front?

@audi_sport_cars 

"Agent inbox" is the right name, and you also wrote the warning that should be tattooed on the project: don't become another dashboard people forget to check. That's the failure mode that kills this entire category. The moment your tool requires the user to remember to look at it, you've just rebuilt the terminal grid with extra steps. A dashboard you have to check is a dashboard that has already lost.

The escape from that is making it push-first, not pull-first. You never check it. It checks you. The three events you listed, completed, needs-input, error, are exactly the only reasons it should ever interrupt, and the rest of the time it stays dark. The inbox isn't a place you visit, it's a thing that taps your shoulder and is otherwise silent. Get that polarity right and "forgot to check it" stops being possible, because checking was never the job.

The other half, seamless across ecosystems, is the genuinely hard engineering and I won't pretend otherwise. Per-tool notifications already exist, Claude Code pings, Warp pings, the problem is they each ping in their own silo with their own definition of done. The whole value is one inbox speaking one language across Claude Code, Cursor, Codex, and whatever's next, so you're not maintaining three notification systems and a script graveyard. That unification is the moat, and it's also the part that's hard enough to be worth doing.

Curious where you'd want it to draw the line on errors specifically, every error, or only the ones it can't self-recover from? An agent that retries and fixes its own typo shouldn't page you, but I keep wrestling with where "it'll handle it" ends and "you need to know" begins.

@grace_lee26 

"Manual polling dressed up as automation" is the most honest sentence in this entire thread. The grep-for-'waiting-for-input' aliases are clever and also a confession: you're pattern-matching on the agent's prose, which means the day it phrases a question slightly differently, your automation goes blind and you don't even know it went blind.

But you've put your finger on the genuinely hard one, and it's deeper than it looks. Finished-clean and quietly-stopped-on-ambiguity look identical from the terminal because "stopped" isn't a state the agent declared, it's the absence of output, and you cannot grep for an absence. A silent terminal is the same whether the agent succeeded, got confused, or crashed. That's the root bug: terminal-watching infers state from activity, and the most important state, "I hit a decision I can't make and gave up," produces no activity at all.

The only real fix is flipping it: the agent has to announce its terminal state explicitly, "done, here's the diff" versus "blocked, here's the ambiguous call I couldn't resolve," so you're reading a declaration instead of interpreting a silence. That's exactly the gap Pushary goes after, make the agent say which of those two it is, so the two stop being indistinguishable and you never again come back to a dead terminal and have to autopsy the whole context to learn why it died.

The learning-AI-coding angle is the part I find most motivating, honestly. When you're still building intuition for what an agent will and won't surface, a tool that consistently shows you "here's what it flagged, here's what it silently decided" is also teaching you the agent's blind spots. You stop guessing what it'll handle and start knowing. Curious, in your tmux setup, roughly how often is a stopped agent actually blocked versus actually done, do the silent-ambiguous stops happen enough to be the main tax, or is it the rarer-but-brutal case?

@caro_fogli 

Straight answer: I'm scoping Pushary to make the "was it good" check fast, not to render the verdict itself, at least at the layer I'm building. The notify-on-finish piece is the wedge, the handoff payload, diff, tests, what's risky, is meant to collapse the time-to-evaluate, so you're judging from the first second instead of reconstructing context. But that's compressing the eval, not performing it, and I want to be honest about that line rather than pretend a notification layer secretly grades quality.

That said, you just named the thing I keep circling: context evaporates when the terminal closes, and a notification by definition lives at the exact moment of finish and then dies too. So a pure notify tool inherits the same amnesia it's supposed to fix. Wiring memory plus execution plus review into one durable layer so the answer survives the terminal closing is the correct shape, and it's the part I think notification-only tools quietly fail at.

The cost-per-approved-output metric is the sharpest idea in this whole thread, full stop. Raw token spend measures activity, which is noise. Cost-per-approved-output measures the only thing that matters, output that actually shipped, and the fact that it surfaced a power-law, a few people producing most of what holds up, is exactly the kind of truth that's invisible from notifications and invisible from token dashboards. You measured the denominator everyone else ignores.

So genuine question back, since you've clearly run further down this: how do you define "approved" cleanly enough to be the denominator? Merged-to-main is concrete but lagging, human-thumbs-up is fast but noisy. Where did you land on what counts as approved, and did it survive contact with people trying to game it?

@richard_smith_sv 

That reserved attention is the real tax, and almost nobody prices it correctly. People count the minutes spent checking the terminal, but the actual cost is the background process that never shuts off, you're never fully in the deep work because a thread of you is permanently on terminal-watch duty. It's not the checking that's expensive. It's that you can never stop being ready to check.

And the cruel part is that standby thread is running even when the agent's fine. You pay the attention tax on every minute, not just the minutes something happened. That's the whole pitch for getting it off your shoulders: not "save you the clicks," but let you actually close that background process because you trust something else will tap you when it matters. You can't go deep until you're allowed to forget.

Out of curiosity, do you find that standby thread ruins focus work specifically, or does it leak into everything, like you're half-watching the terminal even during a meeting or lunch? Trying to gauge whether it's a deep-work problem or an always-on one.

@grace_lee26 

Direct answer: the most-missed approval isn't the scary one, it's the boring clarifying question. People instinctively watch for the destructive stuff, rm, force-push, dropping a table, those get attention. The one that silently eats 30 minutes is "the requirement was ambiguous so I paused to ask which way you meant," or "should I use library X or Y." It doesn't look dangerous, so nothing flags it, so it doesn't alarm anyone, and the agent just sits there politely waiting on a question that would've taken you ten seconds. The dangerous approvals get caught. The trivial-looking ones are where the time actually dies.

Your CLAUDE.md narration trick is exactly right and more clever than you're giving it credit for. "After each major step, describe what you did and what you're about to do next" converts the agent's silence into a readable trail, which is half the entire problem solved with a prompt. You built the "what did it do" half by hand. The half you correctly note it doesn't solve is the async one, you still have to come back to read the narration. The narration makes the check fast. It doesn't make the check come to you.

That's basically the seam Pushary sits in: take the trail you're already making the agent write and push the state-change moments out of it, so "it's about to do something / it got stuck and here's the decision it's waiting on" finds you instead of waiting for you to wander back. You've already done the hard prompt-engineering half. The missing piece is just delivery.

And big agree on the learning angle being underrated, when you're new, the narration trail is how you build the model of what these things will and won't handle alone. The wait-and-miss loop doesn't just waste time, it severs the cause-and-effect you need to actually learn. Curious, now that you've been narrating for a while, has it changed what you trust the agent to do unsupervised, or are you still surprised by where it gets stuck?

@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.