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

@theuniverseson 

This is a really sharp distinction and I think you're pointing at something most people (including me at first) conflate. There are actually two separate problems: when to come back (the notification) and how fast you can reorient once you're there (the summary of what changed + what it's blocked on). A notification with no context just teleports you back into a wall of scrollback - you've saved the polling but not the re-reading.

The "ten-second scan instead of re-reading the session" framing is exactly right, and it's making me think the notification and the diff/blocker summary shouldn't be two features - the push should be the summary. Instead of "Agent 3 needs approval," it's "Agent 3 changed X, Y, Z, blocked on: should it touch the auth layer?" so the decision happens at the notification layer, not after you've climbed back into the terminal.

How are you surfacing the "what it changed / what it's blocked on" right now is that baked into your `/handover`-style prompt, a git diff summary, or something the agent writes out on its own at stop time? Curious whether it's reliable enough that you trust the scan, or you still spot-check.

@simonkyanite 

"The transcript is where it sounds reasonable" should be printed on a t-shirt. That's the whole problem in one line. Agents are great at confidently narrating work they didn't fully do.

The two you listed that nobody surfaces: checks it skipped and assumptions it made. Those are the silent landmines. A green checkmark on the three tests it bothered to run tells you nothing about the two it quietly decided weren't worth it.

That ugly handoff is exactly what pushary.com is built to show: files touched, commands run, what failed, what got skipped, what still needs you. Less "agent is working," more flight recorder for your agents so you find out before production does.

Which line item burns you most in practice, the skipped checks or the unstated assumptions? Curious which one I should make loudest.

@smith2026 

That is a genuinely clever hack, and also a slightly cursed one. You basically built your own telemetry pipeline out of curl and willpower. Respect.

The catch is you now own that API, that log file, and the prayer that the agent actually remembers to ping it after every step instead of "forgetting" the one that mattered. It works right up until you're maintaining infrastructure for the thing that was supposed to save you time.

That's the exact duct-tape setup pushary.com replaces: same idea, the agent reports what it did and where it's blocked, but as a hosted control panel across Claude Code, Cursor, and Codex instead of a file you babysit. You keep the comprehensive overview, you drop the plumbing.

Question for you, since you clearly think in systems: does your agent reliably fire that GET on every step, or do you catch it skipping the report when it gets deep into a task?

@riya_pariyar 

"A finished agent I can recover from, one sitting on a y/n for 40 minutes hurts differently" is painfully accurate. The finished one wasted your time. The blocked one wasted its time and yours, simultaneously, while smugly doing nothing.

To your question: there's a layer in between, on purpose. The agent doesn't push to you directly, it hits Pushary, and we relay it as the approval request with context attached, then route your y/n back to the right terminal. Going direct would mean every agent needs your device, your auth, and your phone number baked in, which is a security nightmare and breaks the second you add a seventh terminal. The middle layer is what lets one inbox sit across Claude Code, Cursor, and Codex at once.

The fun part is the layer can also be smart: batch the noise, flag the risky approvals louder than the trivial ones, so you're not getting paged for "can I create a file."

Out of curiosity, would you actually want to approve from your phone, or just be told it's blocked so you can walk back to the machine? Trying to figure out how many people want full remote control vs. just the heads-up.

@kevinzrzgg 

"Separate progress logs from needs-attention" should be the first line of the spec, and it's the line most people get wrong. They pipe every step to a notification and train themselves to ignore the channel, which is worse than silence. The signal is the four state changes you listed, nothing else. Progress is for the log you read when you choose to. Attention is for the ping you can't ignore.

You're also right that a tiny script gets you most of the way on one tool, one machine. The catch is that's where everyone starts and then quietly drowns. The script that watches Claude Code's log doesn't know about Cursor's, the one for your laptop doesn't follow you to your phone, and "finished with a summary of changed files" needs the agent to actually emit that summary reliably, which is its own small project. It scales to one of you and one tool beautifully, and falls apart at six agents across three tools.

That's the entire reason Pushary exists: the exact state machine you described (running, blocked, failed, done-with-diff) but as one layer across tools and devices, so you're not maintaining a script graveyard. You nailed the spec. We just productized the part where it has to keep working at scale.

The real unlock is your last sentence: making the agent declare when it needs a human instead of silently waiting. Curious, in your setup do you prompt the agent to announce that, or do you infer "blocked" from the terminal going quiet? The detection method is the part I keep going back and forth on.

@kevinzrzgg 

"Closer to a tiny handoff report than a push alert" is the cleanest way I've heard anyone draw that line. A bare "agent finished" just relocates the work, you still have to climb back into the terminal to find out what finished means. The notification should carry the decision, not just announce that a decision is waiting.

Your three boring bits are the exact payload: what changed, what it needs from me, and did it touch anything risky. That last one is the underrated star. Most setups surface changed files and failures but never flag "by the way, I edited the auth flow," which is precisely the change you'd want screaming at you and the one that arrives silently. Changed files and tests are the body of the report. "Touched something risky" is the headline.

This is more or less Pushary's whole spec, so either you've been reading my notes or we independently arrived at the same correct answer. The push is the handoff: changed files, tests run, failures, waiting-on-approval-for-X, with risk flags promoted to the top so the loud stuff stays loud.

The hard part is the risk flag, because the agent has to reliably know it touched something sensitive. Curious how you'd draw that line, declare risky paths per project up front (auth, payments, migrations), or have the agent infer risk on its own? I trust the first more than the second right now.

@goddey_uwamari 

The AWS-bill parallel is painfully good. "You find out what it cost when the invoice lands" is the exact same failure mode as "you find out the agent was blocked when you happen to glance at the terminal." In both cases the system was telling you the whole time, you just had no surface listening. Observability gaps are all the same shape: work happening faster than the human can passively perceive it.

To your actual question, the patterns that keep showing up in this thread and hold up: isolate first (git worktrees, one per agent, so contexts never collide), then collapse the signal to three states (done, blocked, failed) instead of streaming every step, then make the notification a tiny handoff report (changed files, tests, and crucially a flag if it touched anything risky) rather than a bare "done." And the cultural one: make the agent declare when it needs a human instead of silently waiting. Silence should never be the blocked state.

That stack is basically what Pushary productizes, which is the honest answer to "any solid tools yet." Most people are hand-rolling it with curl pings and log-watchers, and it works until you hit six agents across three tools and your script graveyard becomes its own maintenance job. The pattern is well understood now. The unsolved part is making it work at scale without you babysitting the babysitter.

Funny enough your world might be the next layer down: an agent that's burning tokens or spinning a runaway loop is a cost-observability problem wearing a coding-agent hat. Have you seen anyone tie agent activity to spend in real time, or is that still bill-arrives-and-you-cry?

@ozgurds 

The dilemma you ended on is the realest thing in this whole thread: speed costs you control, control costs you your whole day understanding 40 minutes of work. Most people pretend that tradeoff doesn't exist and then act surprised when they've either lost the plot or lost the afternoon.

But here's the thing your own workflow quietly disproves: that curve is steeper than it has to be, and it's steep mostly because surfacing control is manual. Your "every step gets a control mechanism, a test case, a script that validates the use case" approach is exactly right, and notice what it actually does, it makes verification cheap so control stops costing a full day. You're not choosing less speed. You're lowering the price of control until you can afford more of it at the same speed. That's the real move. The dilemma isn't a law of physics, it's a tooling gap.

That's the whole thesis behind Pushary, honestly. If the agent emits its per-step validity checks and what it touched as a structured handoff, you get the "general overview to maintain the project" you're optimizing for without sitting there reading the session. Make control cheap and the speed-vs-control curve bends instead of forcing a pick.

Curious where you draw the line on understanding "enough", do you read every step's validation, or only the ones that touch something you'd be scared to break? I suspect the skill is knowing which 20% to actually look at.