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
AISA AI Skills Test
the notification piece solves "when did it stop" but the harder half is "did it actually do the thing right." a ping that says done still leaves you opening the diff to check, and with 6 agents running thats where the real time goes. supervising agents is turning into an output-evaluation skill more than a monitoring one. whoever makes the "is this correct" check fast wins, not just the "is it finished" ping.
Pushary
Honestly, I still mostly keep terminals visible and check manually, which is not ideal.
The worst part is not even when the agent fails , it’s when it quietly stops and waits for approval while I assume it’s still working. I’ve also started keeping smaller tasks per agent so I can track progress better, but once multiple tools are running, it still gets messy.
A unified notification + approval layer would actually be useful, especially for solo builders who jump between coding, debugging, product, and marketing all day.
Pushary
Personally I am trying to avoid giving too complicated and potentially long tasks. It's not easy tho. To achieve this I start with the business requirement , I ask the LLM to show me the steps that are required to complete the task. I try to understand every step. For every step , I want LLM to create a control mechanism to check the validity of the step. ( a simple test case for example). And finally I try to create and automatic script that check the whole use case functionality.
The dilemma of using an agent is if you want speed you need to have less control of your ecosystem. If you want to have 100% control of your system you need to spend your day to understand 30-40 minutes of your agent's work. I try to optimize this and try to know enough to be able to maintain the project and know the general overview.
Pushary
@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.
@aadilghani I try to ask these questions
which step of the overall solution am i going to solve now
which technology stack/library/solution will is the agent using
what are the constraints of this solution
how can i fully sure that the solution meets my requirements (this is half understanding the solution and half testing the solution)
I think the most important part is the third one. Because every solution can have some constraints that you need to take care in the long run. So I try to learn my weaknesses as well. And more than that I try to keep that in the agent's context as well. Becasue if you just tell the agent to develop an API for example when you switch to another context the LLM forgets about some details and just knows there is an API without knowing its constraints (for example a dependency , a performance criteria etc).
Pushary
@ozgurds
Question three carrying the weight is the correct call, and the reason is subtle: steps one, two, and four are about getting the thing built, but constraints are about not getting silently betrayed by it six weeks later. A solution that works today and quietly violates a performance ceiling or pins a dependency you can't upgrade isn't done, it's a debt you haven't been billed for yet. Most people only discover their constraints by violating them.
But the real insight is your last point, and it's bigger than your own workflow: the agent forgetting the constraint on context switch is the actual bug. It remembers "there's an API," loses "the API must stay under 200ms and can't touch that library," and now it's confidently building on top of a forgotten rule. The constraint didn't change. The agent's memory of it evaporated. That's not a model being dumb, that's constraints living in volatile context instead of somewhere durable.
Which is exactly why I think constraints belong in the handoff trail, not just the prompt. If "this was built under constraints X, Y, Z" is recorded next to "what changed," then a later agent, or you at 2am, can check work against the rules it was supposed to honor instead of trusting that it still remembers them. The trail becomes the constraint's long-term memory so the agent doesn't have to be.
Curious how you keep them alive in practice, do you re-inject the constraints into context every task, or pin them in a project file the agent has to read first? The forgetting problem seems like it needs a forcing function, not just hope.
@aadilghani to be honest I couldn't keep these straight from the beginning of the project. Because some wisdom comes after some bad experiences :)
But after some point what i do is this:
I keep a tracker table for all the project.
The list just keep growing when i want to add new feature. I add a feature as "TODO" in the list
When I finished it I add notes to that item before labeling it as DONE.
And tell the agent to add enough documentation in the code before commiting.
In every conversation I reupload the tracker excel. Trying to keep the excel small enough to be easily maintainable but also comprehensive about crucial feature.
The minimum I’d want is not a fancy dashboard, just a boring handoff trail: current task, last file touched, last command run, whether it is waiting on approval, and what it plans to do next.
For multiple agents, the useful signal is “stuck / waiting / changed code / tests failed / ready for review”. Anything more detailed can usually stay in logs.
Pushary
@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?
This is a real pain point once you run more than one agent at a time. For me the useful alert is not just “the job finished,” but what state it finished in: completed cleanly, waiting for approval, blocked by an error, or made a change that needs review.
The part I’d care about most is the summary quality. A notification that says “done” is less useful than “changed 4 files, tests failed here, needs approval for X.” That turns the alert from noise into a decision point.
Curious if you’re thinking of notifications as the main product, or as the first layer of a bigger agent activity/audit dashboard?
Pushary
@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?
Honestly, I think this is becoming a real problem as people run multiple AI agents in parallel. Keeping terminals visible works for one agent, but it breaks down quickly when you're juggling Claude Code, Cursor, Codex, and other tools.
The most effective setups I've seen use notifications (desktop, mobile, Slack, Discord, ntfy, Pushover, etc.) for three events:
Task completed
Agent needs approval/input
Agent encountered an error
Without that, you end up wasting time either waiting on agents or having agents wait on you.
What seems to be missing is a unified "agent inbox" that shows the status of all running agents in one place. If you're building push notifications and approval flows, you're solving a real pain point. The challenge will be making it work seamlessly across different agent ecosystems rather than becoming yet another dashboard people forget to check.
Pushary
@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.
My setup ended up being pretty janky too — tmux splits with a watch command tailing logs on each agent session, plus a few custom aliases to grep for 'waiting for input' strings. It works but it's manual polling dressed up as automation.
The part I haven't solved is knowing which agent finished *successfully* vs which one quietly stopped because it hit an ambiguous decision and didn't know what to do. Those look identical from the terminal. You come back, nothing's running, and you have to read through the whole context to figure out why.
The visibility gap feels especially real when you're learning AI coding — you're still building intuition for what the agent will or won't surface on its own.
Pushary
@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?
The notification piece you're describing solves half of it — knowing when the agent finished. The half that kept biting us was knowing whether what it did was any good, and being able to see it later. The agent runs, produces output, and the context evaporates — you can't see what it knew going in or whether the result held up.
We ended up wiring memory + execution + review into one layer so the answer doesn't disappear when the terminal closes. The thing that finally made it legible was cost-per-approved-output instead of raw token spend — turned out a handful of people were producing most of what actually shipped, and you can't see that from notifications alone.
How are you thinking about the "was it good" layer in Pushary, or are you keeping it tightly scoped to the notify-on-finish problem?
Pushary
@caro_fogli
Straight answer: I'm scoping Pushary to make the "was it good" check fast, not to render the verdict itself, at least at the layer I'm building. The notify-on-finish piece is the wedge, the handoff payload, diff, tests, what's risky, is meant to collapse the time-to-evaluate, so you're judging from the first second instead of reconstructing context. But that's compressing the eval, not performing it, and I want to be honest about that line rather than pretend a notification layer secretly grades quality.
That said, you just named the thing I keep circling: context evaporates when the terminal closes, and a notification by definition lives at the exact moment of finish and then dies too. So a pure notify tool inherits the same amnesia it's supposed to fix. Wiring memory plus execution plus review into one durable layer so the answer survives the terminal closing is the correct shape, and it's the part I think notification-only tools quietly fail at.
The cost-per-approved-output metric is the sharpest idea in this whole thread, full stop. Raw token spend measures activity, which is noise. Cost-per-approved-output measures the only thing that matters, output that actually shipped, and the fact that it surfaced a power-law, a few people producing most of what holds up, is exactly the kind of truth that's invisible from notifications and invisible from token dashboards. You measured the denominator everyone else ignores.
So genuine question back, since you've clearly run further down this: how do you define "approved" cleanly enough to be the denominator? Merged-to-main is concrete but lagging, human-thumbs-up is fast but noisy. Where did you land on what counts as approved, and did it survive contact with people trying to game it?
@aadilghani You're poking exactly where it's still soft, so let me be precise about the line today.
Right now "approved" in NEST is a state-transition event with an actor attached — who resolved it, when, and at what scope (one-shot vs session-wide for agent actions; submitted → approved with an optional rejection reason for time/work logs). That gives us a clean, auditable denominator: a real person moved the artifact forward, and we know who and when. It's concrete, not a vibe.
Where you're pushing is exactly the edge we haven't closed yet, and I won't pretend otherwise: today approval is binary. We don't yet capture "approved-but-heavily-edited" as its own bucket, there's no edit-distance or rewrite-ratio on what happens after the approval, and approval quality isn't paired against cost yet. So the gaming question you asked — does it survive someone rubber-stamping weak output? — the honest answer is the current model wouldn't catch that cleanly. A stamp is a stamp.
That post-approval layer is exactly what we're building right now — capturing what happens to the artifact after the approval, so a rubber-stamp that gets rewritten downstream stops counting as a clean approval. It's close. Happy to show you where it lands once it's running against real usage — you've thought about the noise problem harder than most people in this thread, and I'm curious whether the approach survives your scrutiny.
Pushary
@caro_fogli
@caro_fogli That's a clean answer and the honesty about the soft edge is exactly why it's worth engaging with. The state-transition-with-actor denominator is the right primitive: a real person moved the artifact forward, you know who and when, it's auditable rather than vibes. That gets you provenance, which is real. What it can't get you, and you said this plainly, is whether the thing they moved forward was any good. A stamp is a stamp. Provenance tells you a decision happened, not that it was correct, same gap that bites everywhere in this space.
The post-approval layer you're building is the right answer to that, and I think it's sharper than even you're pitching it. The insight is that quality is a lagging signal, so you can't measure it at approval time no matter how good your notification is. The truth about whether an output was good is written later, in what survives. If an approved artifact gets quietly rewritten downstream, the approval was hollow regardless of how confident the stamp looked. Measuring the fate of the artifact instead of the moment of approval is the correct move, and the lag is the feature, not a bug to engineer away.
One trap I'd flag before you ship it, because it's the same false-positive shape that came up elsewhere in this thread: a downstream rewrite is ambiguous about why. It could mean the approver rubber-stamped weak output, or it could mean requirements changed and the artifact was correct-at-the-time and simply got superseded. Edit-distance alone conflates "the approval was bad" with "the world moved." If you penalize both as failed approvals, you'll start dinging people for approvals that were right when they made them, which is unfair and also teaches the wrong lesson. The disambiguator I'd reach for is time-proximity plus intent: a rewrite twenty minutes later smells like the approval was wrong, a rewrite three weeks later smells like a pivot. Weight the signal by how soon the rework lands, and you separate "bad call" from "stale call" without asking anyone to hand-label it.
Which connects to the part I'd resist: don't make the human tag "approved-but-heavily-edited" as its own bucket. You'll never get clean self-grading, nobody flags their own rubber-stamp. Infer the grade from what survives rather than asking the approver to confess. Keep approval binary at the moment, and let downstream survival turn it into a distribution after the fact. That respects your "a stamp is a stamp" honesty while still extracting the quality signal, you just stop trusting the stamp and start trusting the artifact's fate.
Where this rhymes with what I'm building: my handoff-and-risk-flag at approval time is the leading indicator, the cheapest preview of a bad call before it lands. Your post-approval survival metric is the lagging confirmation of whether the call held up. They bracket the same decision from opposite ends in time, and honestly the dream is one timeline per artifact that runs from "agent flagged this as risky" through "human approved at this scope" to "survived / got rewritten in twenty minutes." Take the offer, genuinely, show me where it lands against real usage and I'll throw my hardest gaming scenarios at it.
One question back, since you've run furthest on this: when an approved artifact does get rewritten downstream, can you currently tell who rewrote it, the same approver catching their own miss, or someone else cleaning up after them? Because "approver fixes their own stamp fast" and "someone downstream silently eats the cost of a bad approval" are very different organizational signals, and only the second one is the rubber-stamp problem you actually want to surface.
@aadilghani Verified this against the actual code before answering, because it's a sharper question than it looks and the honest answer is "it depends on the artifact."
For structured work — tasks, docs, admin actions — yes, I can answer your question today. Every post-approval mutation is logged with the actor and a before→after, so I can tell whether the person who approved it is the one who later reworked it, or whether someone downstream quietly cleaned up. That's exactly the "approver fixes their own miss" vs "someone else eats the cost" distinction you drew, and you're right that only the second one is the rubber-stamp signal worth surfacing.
On identity — this is where it's stronger than I'd have guessed before checking: each person gets their own namespace per project, so in normal use the actor on these logs is the individual, not a team blob. The only way that goes fuzzy is if someone deliberately shares a token across people, and at that point you've opted out of attribution yourself. So for the structured artifacts, the "who" is real at the person level.
Where it genuinely breaks down is unstructured output — chat messages, session state, the actual code. Messages are append-only with no editor attribution, and code provenance lives in git, not in us. So the downstream-survival signal isn't uniform across artifact types yet, and I won't pretend otherwise — that's the real gap.
On your edit-distance point — you're completely right and it changed how I'm thinking about this. Conflating "the approval was bad" with "the world moved" is exactly the trap, and time-proximity-plus-intent is the cleaner cut: fast rework smells like a wrong call, slow rework smells like a pivot. I'm taking that. Genuinely — when the post-approval layer is running against real usage I'll show you where it lands, and you can throw your gaming scenarios at it.
Completely relate to the "half your brain monitoring" thing. You think you're doing deep work but part of your attention is always reserved for checking the terminal.
Pushary
@richard_smith_sv
That reserved attention is the real tax, and almost nobody prices it correctly. People count the minutes spent checking the terminal, but the actual cost is the background process that never shuts off, you're never fully in the deep work because a thread of you is permanently on terminal-watch duty. It's not the checking that's expensive. It's that you can never stop being ready to check.
And the cruel part is that standby thread is running even when the agent's fine. You pay the attention tax on every minute, not just the minutes something happened. That's the whole pitch for getting it off your shoulders: not "save you the clicks," but let you actually close that background process because you trust something else will tap you when it matters. You can't go deep until you're allowed to forget.
Out of curiosity, do you find that standby thread ruins focus work specifically, or does it leak into everything, like you're half-watching the terminal even during a meeting or lunch? Trying to gauge whether it's a deep-work problem or an always-on one.
The learning angle is underrated here.
When you're new to AI coding agents, the wait-and-miss loop isn't just wasted time — it breaks the feedback you need to actually learn what the agent is doing. Agent gets stuck, waits 30 min, you come back to a half-finished state and have no idea what decision it was waiting on.
I started adding checkpoint comments to my CLAUDE.md: "after each major step, describe what you did and what you're about to do next." Not a notification system, just making the agent narrate. It doesn't solve the async problem, but it means when I do check back, I can actually see where it got stuck and why — which is how I'm learning what these tools can and can't handle autonomously.
What's the most common approval request you see people missing?
Pushary
@grace_lee26
Direct answer: the most-missed approval isn't the scary one, it's the boring clarifying question. People instinctively watch for the destructive stuff, rm, force-push, dropping a table, those get attention. The one that silently eats 30 minutes is "the requirement was ambiguous so I paused to ask which way you meant," or "should I use library X or Y." It doesn't look dangerous, so nothing flags it, so it doesn't alarm anyone, and the agent just sits there politely waiting on a question that would've taken you ten seconds. The dangerous approvals get caught. The trivial-looking ones are where the time actually dies.
Your CLAUDE.md narration trick is exactly right and more clever than you're giving it credit for. "After each major step, describe what you did and what you're about to do next" converts the agent's silence into a readable trail, which is half the entire problem solved with a prompt. You built the "what did it do" half by hand. The half you correctly note it doesn't solve is the async one, you still have to come back to read the narration. The narration makes the check fast. It doesn't make the check come to you.
That's basically the seam Pushary sits in: take the trail you're already making the agent write and push the state-change moments out of it, so "it's about to do something / it got stuck and here's the decision it's waiting on" finds you instead of waiting for you to wander back. You've already done the hard prompt-engineering half. The missing piece is just delivery.
And big agree on the learning angle being underrated, when you're new, the narration trail is how you build the model of what these things will and won't handle alone. The wait-and-miss loop doesn't just waste time, it severs the cause-and-effect you need to actually learn. Curious, now that you've been narrating for a while, has it changed what you trust the agent to do unsupervised, or are you still surprised by where it gets stuck?