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

@heather_byrd 

That specific sting, "stalled 35 minutes on a yes/no I'd have answered instantly," is the one that should be illegal, and the reason it hurts more than a slow task is the mismatch. The cost of answering was one second. The cost of not being asked was 35 minutes. When the gap between the effort and the waste is that lopsided, it doesn't feel like a delay, it feels like waste, because nothing hard happened, you just weren't in the room for a trivial question.

And the trivial part is exactly why it's so dangerous. A scary approval at least justifies the wait, you'd want to think about that one. But the instant yes/no slips through because it doesn't look like it matters, so nothing flags it, so it sits. The cheapest decisions cause the most expensive stalls, precisely because they're cheap enough to be invisible until you walk back and find the whole thing parked on one.

That's the entire reason to get the question off the terminal and onto your phone, a one-second answer should cost one second, not half an hour of you being elsewhere. Approve from the lock screen, it unparks immediately, the trivial stays trivial. Question, since you've clearly lived this: when you come back to one of these, is it usually a genuine judgment call, or is it stuff the agent could've just done if you'd pre-authorized it? Because if it's mostly the latter, the real fix is letting it not ask at all for the safe stuff, and only pinging you for the few that actually need a human.

@hassan_ismail_rebe 

That's the exact breakpoint, and it's worth being precise about why three or four is where it snaps rather than some gradual decline. With one agent, watching is basically free, it's one glance, one source of truth, your attention isn't really divided. The cost doesn't scale linearly as you add agents, it scales worse, because now you're not just watching more screens, you're context-switching between them, holding which agent is doing what, and the misses compound: while you're checking agent one, two finished and three got stuck, and you find out about both late. Manual watching has a hard ceiling, and three or four is where most people hit it.

The deeper reason is that keeping terminals visible is a pull system, you have to go look for the information, and pull systems don't survive parallelism. Push does. Instead of you checking four terminals on some interval that's always wrong, the agents tell you when one actually needs you, done, blocked, or waiting on a decision. Then four agents costs the same attention as one, because you're not allocating a watch-budget per terminal, you're just receiving the one alert that matters. Three silent agents are free. The stuck one taps you.

That's the whole jump Pushary is built for, exactly the point where visible-terminals stops scaling. Question, since you're clearly at or near that breakpoint: when it gets messy at three or four, what actually breaks first for you, missing that one finished, or losing track of which agent is doing what in the first place? I'm trying to figure out whether the core pain is the missed alert or the lost mental map, because they need slightly different fixes.

@johanna_john1 

You're exactly right that they're different urgencies, and the way I think about it is that the two events aren't even the same type of thing. "Task completed" is informational, the work is safe, nothing is waiting, you can read it whenever, it's a receipt. "Blocked and needs approval" is a live cost, the agent is frozen and burning idle time until you respond, and on a parallel setup it might be holding up everything downstream of it. One is a record. The other is a bill that's actively running. They should not look, sound, or feel the same on your phone.

So the prioritization isn't a nice-to-have ranking, it's the core design, and I'd actually go further than two tiers. There's a third that's sneakily the most urgent: "blocked and has been waiting X minutes." Freshly blocked is a heads-up. Blocked for 20 minutes is the thing you'd pay to never let happen again, because that's the silent-stall everyone in this thread keeps describing. So the model is roughly: completed is low and silent-ish, needs-approval is high and unmissable, and time-in-blocked escalates the urgency the longer it sits. The clock is part of the priority, not just the event.

The other half of prioritization is the part people forget: it's not only how loudly you alert, it's whether you alert at all. The fastest way to ruin the urgent tier is to fire the boring one too often, because then the channel gets muted and the urgent one dies with it. So "task completed" probably shouldn't even be a push for most people, it's a thing you check, while "blocked, needs you" is the one that's allowed to interrupt. Protecting the urgent signal means being stingy with the routine one.

Question back, since you've clearly thought about the tiers: for the completed case, would you even want a push, or would you rather it sit silently in a list you glance at, and reserve actual interruptions purely for the blocked-needs-you case? I keep going back and forth on whether "done" earns a notification at all, or whether pushing it just trains people to ignore the channel.

@senk0 

That's a legit pragmatic move, and the instinct underneath it is the right one: matching how much you trust the review to how much the change actually matters. For low-stakes updates, a quick LLM summary is plenty, and reading the full diff yourself would be over-verifying something that didn't need it. You're triaging your own attention, spending it where the risk is and saving it where there isn't. Most people either review everything or nothing, and you've found the sane middle.

The one place I'd flag caution, and it's the exact spot this trick is weakest: an LLM summarizing the agent's own answer is asking one model to vouch for another, and it inherits the original's blind spots. If the agent quietly skipped a check or made a wrong assumption, the summarizer often won't catch it, because it's summarizing the narrative, not auditing the actual diff. It's great at "what does this say it did" and unreliable at "did it actually do that, and what did it leave out." So it works precisely because you're applying it to non-serious updates, the moment it touches something risky, summarizing the claim instead of inspecting the change is how the quiet-wrong slips through.

Which is why I'd point the summarizer at the diff, not the agent's answer. Same effort, but now it's reading what changed rather than what the agent said about what changed, and it can flag "this also touched a file you didn't mention." That's the difference between a summary of the testimony and a summary of the evidence. Your workflow is the right shape, just feed it the artifact instead of the narration.

Question, since you've clearly tuned the effort-to-stakes ratio: how do you decide an update is "not too serious" before you've reviewed it? That's the chicken-and-egg I keep hitting, you need to know the stakes to pick the review depth, but knowing the stakes kind of requires the review. Curious whether you go by what you asked for, which files it touched, or just gut.

@dannyheng 

Per-agent email is genuinely clever, and the reason it works is smarter than it looks: you didn't build a notification system, you repurposed one that already solves the hard parts. Email is already async, already on your phone, already threaded per sender, already searchable later. Giving each agent an address means each one gets its own thread, so "what happened while I was gone" becomes an inbox you scan instead of a context you reconstruct. You routed around the whole problem with infrastructure that already existed. Respect.

The ceiling it hits is the one email always hits: it's one-directional and it's noisy at scale. The agent can mail you "I'm blocked on this approval," but you can't cleanly mail back "yes, proceed" and have it act, email wasn't built to be an approval channel with a structured response. And per-agent addresses are elegant at three agents and a flood at fifteen, plus a "done" email and a "blocked, need you now" email land in the same inbox with the same weight, so the urgent one drowns. It's a great read-only awareness layer. It strains as a control layer.

But the credentials problem you raised is the actually hard one, and it's a different beast entirely, so I want to be careful not to hand-wave it. Hardcoding secrets or pasting them into a prompt is exactly the sketchy thing everyone does and nobody should, because now the credential lives in context, in logs, in the model's history. The right shape is the agent never holds the secret, it requests an action that needs the credential, and something outside the agent, a broker you control, injects it at execution time and hands back only the result. The agent gets capabilities, not keys. That's adjacent to the approval problem, actually, "agent needs to do a privileged thing" is the same gate whether the privilege is a risky action or a secret, the human or the policy authorizes, the credential never touches the agent.

That's honestly where this whole space is heading and where my head's at with Pushary, the approval gate and the credential gate are the same primitive: the agent asks, a layer it doesn't control decides and supplies. Question, since you've hit the credential wall directly: when an agent needs creds mid-task, is it usually the same few services over and over, or genuinely unpredictable each time? Because if it's a known set, you can pre-broker those and the agent never has to ask, but if it's unpredictable, you need a real-time hand-off-with-approval flow, and those are very different things to build.

@rahulbhavsar 

"Without that trail, the agent may be productive, but the human still carries all the risk" is the sentence that should anchor this whole category, because it names the asymmetry everyone feels and few articulate. The agent gets the productivity, the human keeps the liability, and visibility is the only thing that closes that gap. It's not a convenience feature, it's how the risk gets transferred back to where the authority actually is. An invisible productive agent is just a way to launder accountability away from the person who'll answer for it.

And you're right that this generalizes past code, but the sharper version of your point is that your three layers are domain-independent while their contents aren't. Intent, change, and approval-point is the universal skeleton, that's true whether it's an agent writing code or updating a CRM. What swaps out is the artifact: plans/diffs/tests for code, CRM-updates/customer-drafts/escalation-reasons for business. So the visibility layer that wins isn't coding-specific or CRM-specific, it's the one that nails the skeleton and lets the artifact type plug in. Most tools are building the skeleton hardcoded to one domain, which is why they don't travel.

Your middle layer is the one I'd argue carries the most weight, too: "what it actually changed," emphasis on actually. Intent is the agent's claim about what it'll do, approval is your decision, but the change is the ground truth, and it's the only one of the three that can't lie. An agent can intend well and act badly. So the trail has to privilege the diff over the narration, what happened, not what the agent said would happen.

That's exactly the shape I'm building Pushary around, the universal skeleton with the coding artifacts plugged in first, intent, real diff, approval point, delivered so the human reclaims the risk instead of carrying it blind. Question, since you've clearly thought across domains: of your three layers, which is hardest to capture honestly for business agents? For code it's mechanical, diffs and tests are concrete. But "what a CRM agent actually changed" or "why it escalated" feels squishier and easier to fake, and I'm curious whether the trail is genuinely harder to trust the further you get from code, or if that's just my coding bias talking.

@blah_mad 

Direct answer: persisted, as part of the run record, not just used to unblock and discarded. And I'd argue the discard-after-unblock version isn't even a lesser version of the product, it's a different product that happens to share a button. An approval you only use to release the session is a keystroke, it does its job and evaporates. An approval you persist, with who decided, when, at what scope, against which proposed action, is a record you can answer for later. The first fixes flow. The second is the only one that touches trust, which is exactly the line you drew.

Because you're right that notifications alone fix timing, not trust, and the reason is structural: a notification is ephemeral by nature. It fires at the moment of need and then it's gone, so a pure notify tool inherits amnesia, it tells you faster and remembers nothing. The instant the terminal closes, "what was approved and why" is gone, and three weeks later when something breaks you're back to reverse-engineering from vibes. Persisting the approval is what converts a momentary "yes" into a durable "this person authorized this specific thing for this reason," and that's the artifact trust is actually built from.

The piece I'd add, because it's where persisted approvals earn their keep: persist the approval bound to what it authorized, not floating on its own. An approval is a decision about a proposed action, so the record has to hold both, "human approved X" next to "agent then did Y," so you can later check that Y actually matched X. Approve "deploy to staging," agent deploys to prod, the persisted-and-bound approval is the thing that catches the divergence. An approval stored without the action it was attached to is auditable in theory and useless in practice, because you can't tell if the agent honored it.

So the run record I want is a timeline per action: agent proposed this and flagged it risky, human approved at this scope at this time, agent then did exactly this, tests said that. Notification is just the delivery mechanism for the approval step, the persistence is what makes the whole thing trustworthy after the fact.

Question back, since you're clearly thinking about this at the record level: would you want the persisted approval to be queryable as its own thing, "show me everything I approved this week and what happened to it," or is it enough that it lives in the run's history for forensics when something breaks? Because the first is a real trust-calibration tool, you'd actually see your own rubber-stamp rate, and the second is just an audit log, and I keep wondering whether people want the mirror or just the receipts.

@atherkildsen 

Ha, the fact that your boss looked at this and went "I'll just build you a physical device" tells you everything, that's not a niche annoyance, that's a problem painful enough that someone's first instinct is hardware. People don't fabricate gadgets for minor inconveniences. The little-device impulse is the same one that gave this thread a desktop aquarium and a menu-bar edge-glow, the pain keeps independently reinventing the same fix, which is usually the sign of a real market and not just a personal quirk.

The thing I'd gently flag, and it's the ceiling every physical version hits: a device lives on your desk, and the whole pain is the thirty minutes you weren't at your desk. A blinking box is great while you're in the room and useless the moment you walk away, which is exactly when the agent goes quiet on you. Ambient hardware solves "at my desk in another window." It can't solve "away from keyboard," because you have to be looking at it. So the device scratches the itch right up until lunch.

Which is the long way of saying yes, more people are absolutely interested, and the version that travels is the one in your pocket you already carry. Same idea as your boss's gadget, minus the constraint that you have to be standing next to it. Genuine question, since your boss clearly spec'd this in his head: what was the device going to actually do, just light up when an agent needs you, or did he have it answering back somehow? I'm curious what shape the hardware instinct takes, because what people imagine building by hand is usually the cleanest statement of what they actually want.

@jordan_bulk 

We provide this at pushary.com, once you have connected your device you get a notification, you click on it and you see your activity feed across your connected agents - we call it the fleet board, give it a shot.

@adam_outbbo 

Two different moves there, worth pulling apart because one's a real fix and one's a loaded gun.

Bypassing all permissions in the config does solve the waiting problem, by deleting the thing that makes it wait. No approval gate, no stall. But you didn't remove the risk, you removed the brakes. Now the agent never pauses, which is great until the one time it confidently does something you'd absolutely have wanted to catch, deletes the wrong thing, force-pushes, touches prod, and there was no gate to stop it. "Allow everything" trades a time problem for a blast-radius problem, and the blast-radius one is the expensive kind because you find out after. It's the right setting for a sandbox where failure is free, and the wrong one the moment the agent can touch anything you can't cheaply undo.

The better shape isn't all-or-nothing, it's tiered: auto-allow the safe, reversible stuff so you're not babysitting trivia, and gate only the genuinely risky calls, auth, payments, migrations, destructive commands. That way you get the no-waiting speed on 90 percent of actions and keep a human on the 10 percent that can actually hurt you. Bypass-all is that idea with the dial cranked to a place I wouldn't leave it on anything that matters.

On the Cowork custom notifications, you're right that you can wire something up, and that's the DIY version of exactly this. The gap is it's per-tool and lives on that machine, so it doesn't follow you to your phone and doesn't span Claude Code plus Cursor plus Codex in one place. Fine for one tool at your desk, strains the moment you're away or running several.

Question, since you've gone full-bypass: has it ever actually bitten you, an agent doing something unattended you wish it had stopped to ask about? Curious whether bypass-all is working because your tasks are genuinely low-stakes, or whether it's been fine so far and the bad day just hasn't happened yet. The answer tells you whether you want the tiered version or you're honestly fine as-is.