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

@raza_mughal1 

one hundred percent

@asadmalik901 

Direct answer: the gate keys on recoverable cost of error, roughly blast radius × (1 − recoverability), not on reversibility alone. Reversibility is the cheap first approximation and it fails both ways. It over-fires on irreversible-but-trivial (the agent logs a timestamp, can't undo it, nobody cares) and under-fires on reversible-but-catastrophic (mass email to 50k users, you can send a correction, the damage already landed). So what earns a human is unrecoverable damage, not whether an undo technically exists.

The wrinkle is that the agent can't compute its own blast radius. It doesn't know 50k people are on that list. Reach is the one variable it's structurally worst at estimating about itself, so in Pushary reach gets annotated at the tool and resource layer rather than inferred by the agent, and human judgment stays reserved for genuinely novel reach. Cheap, reversible, low-reach auto-clears, and that's most of the volume.

The part I care most about getting right: auto-grant should only ever loosen with evidence, never because you clicked yes quickly a few times. Fast approval on a trivial action means trust. Fast approval on a risky one might just mean you weren't looking. Conflate those and the system quietly learns to rubber-stamp on your behalf, which is worse than no automation at all.

And yes on your interrupt distinction, that's exactly how it's built: blocked is loud and answerable from your phone, done drops into the glanceable list. You put it better than my landing page does, done is a receipt, blocked is a bill that's still running.

@shivangit26 

"Structural, not more discipline" is the right diagnosis, because discipline is a strategy that fails quietly at exactly the moment you're busy, which is always. You didn't try harder to watch, you changed the shape of the problem so watching wasn't required. That's the difference between a fix and a resolution.

And the specific structural move is the good one: branch plus an end-of-run summary of what changed and which files it touched means you review a diff instead of tailing a log. Those are wildly different costs. A log is the agent's stream of thought, so reading it means re-deriving what happened. A diff plus summary is effects-first, so you're reading conclusions. Same information, a fraction of the attention, which is why the anxiety drops, you're not holding six live sessions in your head, you're reviewing artifacts on your schedule.

The one gap async-reporting leaves, and it's the thing I'm building around: it handles done beautifully and can't help with blocked. If an agent stalls mid-run waiting on an approval, the end-of-run summary never fires, because there's no end of run. So the failure mode isn't the finish you'll review calmly later, it's the agent that's been frozen for 20 minutes while you assume it's still working. Async reporting fixes the review cost; it doesn't surface the silent wait.

Curious, with agents on their own branches, do you hit approval stalls often, or have you pre-authorized enough that they mostly run clean to the summary? Because if they rarely stop to ask, you've genuinely solved this and a notification layer would just be noise on top.

@shivangit26 

"We are reading diffs after the fact and hoping" is the honest version of what most people call a workflow, and the giveaway is your second line: three terminals doesn't scale past a week, not past three agents. It fails on a timescale, not a count, because it's not the watching that breaks, it's you sustaining the watching. Discipline decays; structure doesn't.

The move you made is the right one, and it's the same conclusion a few sharp people in this thread landed on independently: one log across all runs, what it touched, what it ran, what it changed, plus an approval gate on anything that hits infra. That's not monitoring, that's a paper trail, and the difference matters, monitoring assumes someone's watching, a trail assumes nobody is and makes the work legible after the fact anyway. Junior engineers with a paper trail is the correct frame, with the one wrinkle that a junior accrues context and an agent shows up new every session, so the trail isn't training wheels you eventually remove, it's the permanent substitute for tenure it'll never build.

The line I'd underline for everyone else: dashboard-per-tool is a dead end because the agents don't share state. That's the structural reason per-tool notifications can't finish the job no matter how good they get, each tool can only ever tell you about itself, so N tools gives you N islands and no answer to "who needs me right now." A feed inside one IDE is a nicer sidebar. One feed across all of them is a different category of thing.

Which is precisely why Pushary sits above the tools rather than inside one, thin adapter per runtime, one shared state model, one inbox. You described the architecture before I got to pitch it.

The one gap I'd flag in your setup, and it's the seam I'm building in: the log is written at the end of a run, so it covers done beautifully and can't surface blocked. An agent frozen 20 minutes on an approval never reaches the write, so the silent stall is the one thing the trail can't catch, it looks identical to still-working. Curious whether that bites your team, or whether the infra approval gates are structured enough that stalls get caught fast?

@elhan_games 

"I have to remember to check" is the whole diagnosis, and it explains why every fix you tried failed the same way: terminal tabs, notifications, dashboards, they're all still pull, they just made the checking prettier. A dashboard you have to remember to open is a terminal grid with better fonts. The failure isn't the interface, it's the polarity, anything that requires you to initiate loses the moment your attention is legitimately somewhere else, which is the entire reason you handed the work to an agent.

And you landed on the fix in your last line: the agent should surface important events itself. That's the flip from pull to push, and once you make it, the number of agents stops mattering, because you're not allocating attention per terminal, you're receiving from whichever one actually needs you. Six silent agents cost nothing. The stuck one taps you.

The one thing that makes it work rather than become noise: only three events should ever earn an interrupt, blocked, done, failed. Push every step and you train yourself to ignore the channel, and then the one alert that mattered dies muted. The discipline is in what it refuses to surface.

That's exactly what Pushary is, so if you want to point it at your setup it's free to try, pushary.com. Curious though, when you tried notifications before, was the problem that they didn't fire on the right things, or that they only covered one tool and you still had to check the others?

@stacywycof83995 

"The fix isn't more visibility, it's a filter" is the same conclusion from a completely different direction, and I think you've landed on the more general principle. Everyone in this thread has been arriving at it in one domain (agents, terminals), but you're describing it across three businesses, which suggests the real problem isn't tooling at all, it's that visibility scales linearly and attention doesn't. Show a person everything and you've just moved the sorting job onto them. More visibility is often just a nicer-looking version of the original problem.

And the two-tier split you built, interrupt for the stuff that matters, queue for everything else on your own schedule, is exactly the shape. The queue is the part people underrate: it's not a downgrade from a notification, it's a different job. Interrupts are for things where the cost of not-knowing is still growing. The queue is for things where the cost is already settled and finding out later doesn't make it worse. Collapse those two into one channel and you get a firehose you learn to ignore, which is worse than silence.

The thing I'd poke at, because it's where I keep hitting the wall on my side: "confident enough to matter" is doing a lot of work. Confidence is the hardest number to make honest, because whatever's generating it will tend to overrate itself, and if the filter is confidently wrong about what matters, you don't notice, you just silently stop getting the thing you needed. A filter that's 95% right feels amazing until the 5% is the one that mattered, and by construction you'll never see it. So the question I'd ask of any confidence filter, mine included: where does the number come from, and can the thing being filtered influence it? If it can, it'll learn to sound important.

Curious how you handle that in FounderFlow, when the filter decides something doesn't clear the bar and it turns out it should have, do you find out? That's the failure I can't see a clean answer to, because a bad interrupt is obvious and a bad suppression is invisible.

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