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

@kevinzrzgg 

You've now described the spec three times from three angles and it's converged on the same thing, which is honestly the best validation a spec can get. "Not a fancy dashboard, a boring handoff trail" is exactly right, and I'll say it against my own interest: the dashboard is a trap. The second it has charts and a hero number, it's optimizing to be looked at, when the entire goal is something you almost never look at until it taps you.

Your minimum trail, current task, last file, last command, waiting-on-approval, plans-next, is the actual product, and the multi-agent signal set, stuck / waiting / changed / tests-failed / ready-for-review, is the whole vocabulary. Everything past that stays in the logs where it belongs. The discipline is in what you refuse to surface, not what you add.

So Pushary's job is to be the boring trail, not the fancy dashboard. Six agents, each showing one line of state and a "next," and a ping only when one crosses into a state that needs you. If it ever tempts you to sit and watch it, I've built the wrong thing.

The one field I'd argue is doing the most work is "plans to do next," because that's the cheapest possible preview of a bad decision before it happens, you can kill a wrong turn at the plan instead of the diff. Curious if you actually trust that field, do you read "plans next" and intervene early, or do you ignore it and just judge the result once it's done?

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

@veer_singh14 

"Silent killer" is the perfect phrase for it 🎯 — the agent finishes its actual work in 5 minutes and then just... sits there waiting, and you don't find out for half an hour. The work was fast; the waiting on you to notice is what's slow.

Appreciate the read on it being a unified layer rather than another one-off script. That's the bet exactly — everyone's already solved this badly with their own custom ntfy/Pushover hacks, but nobody wants to maintain that glue across Claude Code, Cursor, and Codex. Are you currently running any custom notification scripts yourself, or still in the manual terminal-watching phase? Trying to gauge how many people have already duct-taped a solution vs. just living with it.

@toch_aria 

You basically wrote my product spec, so I'm either flattered or out of a job.

You're right: "done" is the shallow version. What changed, why, what it touched, what needs sign-off, that's the actual signal. The notification is just the courier. The .md-as-audit-trail move is the smart part, because future-you debugging at 2am does not accept "vibes" as a commit message.

That control-while-it-moves-faster-than-you-can-watch problem is the whole reason pushary.com exists. Think of it as a control panel for your agents: status, approvals, and risk flags across Claude Code, Cursor, and Codex, so you stay in the loop without babysitting six terminals.

Quick one back at you: do you prompt for that .md update every time, or have you wired it into a skill so it's automatic? That reliability is load-bearing for the whole thing.

@florent_duthoit 

This is genuinely one of the better setups in the thread, and the insight buried in it is the real gold: "anyone from a company should be able to help it get the work done." That's the part most people miss. Once the agent can route a question to whoever can actually answer it, you've turned a solo bottleneck into a team that happens to be asleep half the time.

The Slack relay is smart, and it's basically Pushary's thesis built by hand. The two places it gets fragile: you had to wire it up per agent, give it Slack access, and format the prompts just so, and the "wait X minutes and check back" loop is polling sneaking back in through the side door. Works great with a cofounder who knows the dance. Gets messy across six agents and a bigger team where you also want to know what it changed, not just answer its question.

Pushary is that pattern as a product instead of a custom integration: structured handoffs with risk flags routed to the right person, no per-agent plumbing, and the relay handles the wait so the agent isn't burning cycles checking back.

You nailed the one honest limitation too. Planning still chains you to the desk. Agreed, and I think that's correct for now. You should be in the room for the plan. It's the babysitting after the plan that shouldn't require a human at all. Curious, does your agent ever ping the wrong person, or have you got the routing dialed in?