How do you stay aware of what your AI coding agents are doing?
I've been running Claude Code, Cursor, and Codex pretty heavily for the last few months and I keep hitting the same loop:
1. Start a task in one agent
2. Switch to something else (Slack, Twitter, another terminal)
3. Come back 30-40 minutes later
4. Agent finished 35 minutes ago. Or worse, it's been waiting for my approval the entire time.
The more agents I run, the worse it gets. There's no unified way to know what's happening across them.
Curious what other people's setups look like:
- Do you just keep terminals visible and check manually?
- Built any custom notification scripts?
- Use something like ntfy or Pushover?
- Just... accept the wasted time?
I've been building something in this space (push notifications + approval flows for AI agents) and I'm trying to understand if everyone's workflow is as janky as mine, or if some of you have figured out something clever.
Would love to hear what's working and what's not.
Replies
Pushary
Launch is live guys - would love some support https://www.producthunt.com/posts/pushary-3
The "waiting for approval" loop is the absolute silent killer of AI productivity! 🛑 Right now, it's mostly manual terminal-watching or messy custom scripts. A unified notification layer for agent execution is a brilliant move—definitely a tool the space needs.
Pushary
@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.
@aadilghani Couldn't agree more—maintaining that custom glue code across different AI tools is a massive hidden time-sink for engineering teams.
We've built some of our own notification workarounds for our dev workflows to dodge the terminal-watching trap, so I completely validate the pain point you're solving here. Centralizing this into a single, reliable layer is a game-changer for team efficiency. Really looking forward to seeing how Pushary handles the multi-tool ecosystem!
This is a real problem, especially once you’re running more than one coding agent at the same time.
What has helped me is treating AI coding agents less like autocomplete and more like junior engineers that need task boundaries, check-ins, and review points.
My workflow is usually:
I break tasks into very small tickets before sending anything to Claude Code/Cursor/Codex.
I define the expected output upfront: files to touch, files not to touch, acceptance criteria, and what “done” means.
For any critical change, I ask the agent to update the project .md file with what changed, why it changed, files touched, assumptions made, and any follow-up risks.
I ask for a summary before implementation when the task is risky.
I review diffs before accepting changes.
For longer tasks, I use checkpoints: “stop after planning,” “stop after backend changes,” “stop before modifying auth/payment/database logic.”
That .md file has been surprisingly important because it becomes a running memory and audit trail for the project. When something breaks later, I’m not trying to reverse-engineer what the agent did from vibes.
For me, the bigger issue is not just notification visibility. It’s workflow observability.
I don’t only want to know “the agent is done.” I want to know what changed, why it changed, what assumptions it made, what files were touched, and what needs human approval before moving forward.
That’s where I think the real opportunity is: status, approvals, logs, summaries, risk flags, and handoff points across agentic coding tools.
Because once you’re building production software, the real question becomes: how do I stay in control while AI moves faster than I can manually monitor?
Pushary
@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.
@aadilghani Glad to hear that, I will be reviewing the product link. Initially I do prompt for that everytime. Which can be a token killer. I switched to automating it on skill
There's hundreds way to handle this I believe.
In my case, the most efficient way was letting my agent access to my Slack and format the AI to let know any of the team member related to the question so they can answer in slack and the agent can read the response.
You can also let the agent to wait X minutes and check back if got any answer.
That has been quite smooth with my co founder. They went to sleep, the agent was running/building stuff, when it got stuck, the agent just ping me on Slack, I gave him the solution or fix the problem it was facing, then it get back to work confirmed me and back and fourth this way.
Of course, there's still the first step of planning the work which need attention and you can't really get off the computer. But when it's building, anyone from a company should be able to help it make the works done.
Pushary
@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?
@aadilghani You're right about the two fragile places but we've easy solution to counter that.
Let me give you more context about our team workflow.
We train each of our team member to Opencode from sales, customer support, delivery, developper, finance, what ever. We've 30+ MCP connected (built-in MCP server that is used as a gateway) that our team can use in Opencode accross all the company services and connect their own company account to it.
It has been the best productivity tool we found and by far the most performing one.
Easy script setup that can run on any device and configure everything properly without any technical knowledge required. Just a one line command to run (could become an executable).
So to answer the two fragile places:
- No need to format the prompt, global instructions are setup in a way that it know what to do.
- The time it wait, we don't really care and can be incremental. At the end, we just want the work to be done what ever time it takes. If it waited too long, it will ping the concerned person again to follow up. I wish there's some way to wake up an agent on specific event (slack messages received and so on, that could be the perfect improvement/solution long term).
For the wrong person, we of course use agent memory. It is not yet shared accross the team, but we may have ASAP. Right now, everyone have his own personal memory and the Agent can remember who to talk with according to the task we're dealing with at the moment.
I think the problem most people face is big at the beginning and they all need to find a way it match with the team mindset.
We are evolving our ecosystem with our discovery and rely more and more with agents, with this setup we have already automated most of it:
- Development
- New workflows
- Create/Update documentation
- & much more.
The most underrated winning MCP has been Playwright MCP. There's no more limits with this one and way more efficient than any built-in Claude/GPT/Perplexity browsing agent system.
I feel your platform is interesting, but if I have to keep being on my phone confirming the notification, this will drive me crazy.
We need to provide the agent the capability of having a dedicated environment for it to fail, so the basic question/authorization is nbot required anymore.
Pushary
@florent_duthoit
You just argued me into a better version of my own product, so thank you for that.
You're right, and I'll go further than you expect: if Pushary is pinging your phone for "can I create a file," it has already failed. That class of approval shouldn't exist. A sandboxed environment where the agent is free to fail and self-correct kills 90% of interruptions, and I'm fully on board with that being the goal. Anyone building approval flows for reversible actions is just adding friction with extra steps.
But there's a second class that no sandbox removes, because it's not "did it fail," it's "which way did you want this." Touch the payment logic or not. Ship to prod now or wait. The spec was ambiguous and there are two reasonable interpretations. In those, the human isn't a safety net, the human is the missing input. The agent can't fail its way to your intent. That irreducible slice is the only thing Pushary should ever surface, and if it surfaces more than that, I'm doing it wrong.
And here's the fun part: you already designed the rest of it. "I wish there was some way to wake up an agent on a specific event, Slack message received" is exactly the return path Pushary is built around. The agent sleeps, the event fires, it wakes and keeps going. You're not arguing against the platform, you're spec'ing its core loop. We just disagree on whether you want to be the device that confirms, and I think the answer is "only for the handful that actually need your brain."
Separately, your Opencode plus 30+ MCP gateway setup with non-technical teammates running one-line installs is one of the more impressive org-wide agent rollouts I've heard described, and the shared-memory routing is the obvious next unlock. Big co-sign on Playwright MCP too, the built-in browsing agents aren't close. Quick one: when the agent hits a genuine judgment call, not a failure, who in that 30-person setup ends up being the input, and how does it know?
@aadilghani we believe more in agent than god itself 😂
Mostly when the agent designed everything, human mostly guide it the wrong way.
If the agent came with a blocker, then we just need to let him investigate and came with choices that match what we want. The human is just here to give insights or information he doesn't have, but never to make a decision.
I remember Jensen saying: "I'm not asking it to think for me. I'm asking it to teach me things that I don't know."
This happen during the plan mode, that's why the focus and waiting (reading actually) during this phase is important, you learn every minute.
We know what we want but we don't know how to achieve it in a proper & quickest way.
SlimSnap
Ran into the same wall running three agents at once. What actually helped wasn't a notification tool, it was going back to one agent at a time on anything that needs approval, and only fanning out on tasks I'm fine letting run unattended. The awareness problem is really a batching problem. You can't watch four things, so don't start four things that need watching.
Pushary
@bickov
"Don't start four things that need watching" is a genuinely sharp reframe, and you're right that it's a batching problem before it's a notification problem. Splitting by "needs approval" versus "safe to run unattended" is the correct first cut, most people skip that triage entirely and then wonder why six terminals feel like chaos.
Where I'd gently push: that split is manual and static. You're the one deciding upfront which tasks are watch-worthy, and you're right most of the time, but the awkward case is the task you launched as unattended that hits an unexpected approval mid-run. Your batching didn't predict it, so now it's stuck and you're back to the same silent-wait problem, just less often. The batching reduces the surface, it doesn't close it.
That leftover slice is the only thing I'm really trying to catch, the unattended task that unexpectedly needs you. For the stuff you correctly batched as needs-approval, honestly your one-at-a-time approach is fine and a tool would just be noise.
Curious, when an unattended task does surprise you with an approval, how often does that actually happen? If it's rare, you've basically solved this with discipline. If it's common, that's the gap.
SlimSnap
@aadilghani For me it's rare, maybe one in five or six unattended runs, and always the one I was most sure about. The frequency isn't the problem, it's that I can't predict which one, so I either check all of them or get burned on the one I ignored. Real gap, just a narrow one. The thing I'd actually want isn't a dashboard, it's a single ping the moment any agent goes from running to waiting. Not status, just the state change. Everything else I can live without.
Pushary
@bickov
"Always the one I was most sure about" is the whole thing, isn't it. The unpredictability is the actual problem, not the frequency. One-in-five that you can't predict forces you back to checking all five, so the narrow gap quietly taxes every run anyway. That's the sneaky cost of rare-but-unpredictable: you pay attention on all of them to catch the one.
And you just described Pushary's core primitive better than my landing page does. Not a dashboard, not status, just the single running-to-waiting state change, pushed the moment it happens. That's the one signal that collapses "check all five" into "check the one that pinged." Everything else really is optional, you nailed it.
The only thing I'd add underneath it: catching running-to-waiting cleanly is harder than it sounds, because from the outside a waiting agent and a still-thinking agent can look identical. The ping only works if the agent actually declares "I'm blocked" rather than just going quiet. That detection is the real engineering, the notification is the easy part.
That's exactly what I'm building, so genuine question: would you want to answer the approval from the ping itself, or is the ping alone enough and you'll go to the terminal to act? Some people want the full remote yes, some just want the nudge.
SlimSnap
@aadilghani The nudge, every time. The tasks that hit an approval are exactly the ones that need my judgment, and judgment needs context a ping can't carry. If I say yes from the notification I'm approving blind, which defeats the point of it stopping for me. So the ideal is a nudge that drops me straight into the right terminal with the context already there. The remote-yes is most tempting for the tasks it's least safe on.
On detection, you're right it's the hard part. Quiet-and-thinking and quiet-and-blocked look identical from outside. The only clean signal is the agent declaring "blocked," which makes it doable on tools you can hook like Claude Code and near-impossible on black-box ones. I'd rather you nail detection on the three agents everyone actually uses than support forty badly.