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

@jiaqi_lu 

A desktop aquarium as an agent status light is the most charming thing in this entire thread, and underneath the whimsy you solved the exact problem everyone else is overcomplicating. You turned monitoring into ambient peripheral vision. Nobody "checks" an aquarium, you just notice when it changes color, which means zero context-switch cost. That's the part most notification systems miss: the best status signal isn't one you read, it's one your eyes catch without focusing. You made the awareness free.

Your three states are also quietly correct. Blue for done-or-idle, the generating shimmer as pure ambient "it's alive, relax," and amber as the only one that actually pulls you back. That's the done/working/needs-you split everyone in this thread keeps reinventing, except yours doesn't make you read anything. The genius is that amber is the only color that costs you attention, and it only fires when attention is actually owed.

Here's the one ceiling, and you already know it because you said "for myself": the aquarium is on your desk. It's a beautiful local solution to a problem that follows you to lunch, to meetings, to the moment you've walked away, which is precisely when the amber matters most. Glanceable is perfect while you're in the room. The thread's whole pain is the thirty minutes you weren't.

That's the only real difference between your aquarium and what I'm building, honestly, Pushary is the amber light that travels, plus the part the aquarium can't carry, which question it's asking and what changed, so you can answer without walking back. Same philosophy, ambient until it isn't, but it reaches your pocket. Genuine question, because you clearly think about this well: does the amber alone get you back fast enough, or do you still lose time walking over to read which question it's stuck on? The "what is it even asking" gap is the thing I can't see how to solve with color, and I'm curious if it bites you too.

@sleekzheng 

Ha, the TikTok-to-panic-switch is the most honest workflow anyone's posted in this whole thread. "I seemed to realize something" is doing a lot of work there, that's your brain's background process quietly pinging you that the agent probably finished twenty minutes ago. You built a notification system out of guilt. It works, it's just powered by vibes and has a 30-minute latency.

The actual problem isn't the TikTok, by the way. Zoning out while the agent works is fine, that's the dream, the agent works so you don't have to hover. The problem is the only thing that pulls you back is a random pang instead of the agent actually telling you it's done or stuck. You're using your own restlessness as the alert, which is both unreliable and a little stressful, you can never fully relax because part of you is on guard duty.

That's the whole pitch, honestly: let the agent ping your phone when it's actually done or needs a yes, so you can scroll with a clear conscience and get pulled back exactly when it matters, not 30 minutes after. Same TikTok, zero guilt, no wasted half-hour. Question for you, since you live this: would a buzz on your phone actually pull you out of TikTok, or would you swipe it away like every other notification? I keep wondering if the agent alert needs to feel different from the noise, or people will just train themselves to ignore it too.

@shakutovbekzat 

You've hit a real wall, but I think it's two different problems wearing the same costume, and separating them is the whole fix.

Problem one is execution context: what the agent needs loaded to do the work right now. That's the one that gets slow and token-hungry as it grows, because every message re-sends the whole pile and you pay for it each turn. Problem two is awareness context: what you need to know about what the agent did, status, what changed, what it's waiting on. People try to solve both with one giant growing context, and that's what's killing you, you're making the agent carry your audit trail in its working memory, so the thing it needs to think and the thing you need to review are competing for the same expensive space.

The move is to stop storing awareness inside the agent's context at all. When the agent finishes a step, it emits a small structured summary, files touched, what changed, what it's blocked on, and that gets written somewhere durable outside the conversation. Then you can prune the execution context aggressively, because the record of what happened doesn't live in the chat anymore, it lives in the log. The agent stays fast and cheap because its context only holds what it needs to act, not the full history of everything it's done. You get the persistent context you want, the agent doesn't pay tokens to carry it.

That externalized summary trail is basically what Pushary is, the per-step handoff lives outside the agent, so awareness persists without bloating the thing that has to stay lean. You're right that you need context maintained locally somewhere, the key word is somewhere, just not inside the agent's working memory where it taxes every reply.

Question back, since you've felt the token pain directly: when context gets large and replies slow down, is it mostly the agent re-reading its own past work, or genuinely needing all of it to make the next decision? Because if it's the former, externalizing the history fixes the cost outright. If the agent truly needs the whole history live to decide well, that's a harder problem and a more interesting one.

@pranay19 

"You act as the architect" is the right frame, and notice what you're really doing: not watching the agent, gating it. You stay in the loop by being the approval step, not the babysitter. That's the healthy version of this.

The catch your own example reveals is that it works because you were there. Write, build, deploy, verify screenshots, that's one continuous session where you're sitting in the chat approving inline. It holds perfectly until you step away mid-task, and on a deploy that's the worst moment to be gone: the agent hits the gate, freezes, and your approve-as-you-go flow becomes a stalled terminal waiting on a yes you're not there to give.

So the inline-approval pattern is right for synchronous work and has exactly one failure mode: it assumes you're present. The whole thread's pain is the async case, the architect walked away and the junior is politely stuck. That's the only gap I'm filling, take the same approve-before-it-acts gate you already trust and let it reach your phone when you're not in the chair.

Question, since your flow clearly works: do you ever start something and step away, or only run the agent when you can sit and approve live? If it's the latter, you've solved this by never leaving, which is valid, it just caps how much you can run at once. Curious if that's a choice or a constraint.

@nipuntaneja 

You just gave me the sharpest piece of positioning advice in the whole thread, and you're right: lead with the stuck alert, not the done ping. "It's done" is a nice-to-have everyone's already half-solving. "It's been blocked waiting on you for 12 minutes" is the one that has a dollar attached, because that's the alert that's actively stopping the bleeding instead of just reporting a finish. Done is information. Stuck-and-counting is a refund. I've been leading with the wrong one, and a marketer who builds is exactly the person who'd catch that. Taking it.

But the more valuable thing you said is the diagnosis you almost threw away: "most of my wasted time wasn't the agent finishing early, it was me under-briefing it, so it stopped to ask." That reframes the entire problem. Half the approval interruptions aren't the agent needing a decision, they're the agent needing information you could have given up front. Which means the fix isn't only better alerts, it's fewer interruptions to alert about. Your front-loaded spec is doing the real work, you're not catching the stops faster, you're preventing them. That's a tier above what most people in this thread are doing.

So the honest version of the product is two moves, not one. Prevent the avoidable stops (good briefing, declared boundaries, so it only asks when it genuinely must), and make the unavoidable ones impossible to miss and fast to answer. You've nailed the first half by hand. The second half is the stuck-timer alert you said you'd pay for. They're complementary, the better your spec, the rarer the alerts, the more each one actually means "your brain is required."

And for the record, the "marketer who builds, not a deep engineer" framing matters to me more than you might think, because if this only works for people running six terminals it's a toy for power users. The fact that the loop kills you at two agents is the signal it's a real problem, not a hobbyist one.

Question back, since your batching approach is clearly tuned: when you batch approval-heavy tasks and check at set times, how do you decide the interval, gut feel, or have you noticed a point where waiting too long to check costs more than the babysitting would have? I'm trying to figure out whether the stuck-timer should just be a number you set, "ping me if anything's been blocked longer than X," and what X actually is for real people.

@grace_vargas 

"Knowing when human attention is actually needed" is the cleanest way anyone's stated the goal, and it quietly redefines the product. The job isn't notifying, it's gatekeeping attention, deciding which of the thousand things an agent does actually deserves a human and silently absorbing the rest. A notification layer broadcasts. An attention layer protects. Different job, and yours is the right one.

Your distinction between blocked, waiting for approval, and asking for a decision is sharper than it looks, too, because those aren't the same urgency. Blocked might be a transient error that self-resolves. Waiting for approval is the silent time-killer. Asking for a decision is the one that genuinely needs your judgment. Collapsing them into one "needs attention" ping loses exactly the information that tells you whether to drop everything or finish your coffee.

And your winking caveat is the entire design constraint, not an aside. "As long as it avoids becoming another noisy notification stream" is the line every tool in this space dies on. The fix is counterintuitive: the value isn't in what it shows you, it's in what it refuses to. A layer that pings on everything is worse than no layer, because you mute it, and then you miss the one that mattered. The discipline is aggressive silence, dark by default, and an interruption is a promise that your brain is genuinely required.

That's the bet behind Pushary, the lightweight cross-agent layer you described, built so a ping always means something. Question back, since you clearly think about the noise problem: where would you set the default, would you rather it err quiet and risk missing a borderline case, or err loud and trust you to tune it down? People split hard on this, and the default basically decides whether they trust it on day one or mute it by day two.

@doganakbulut 

You're describing the manual baseline almost everyone in this thread started from, keep terminals visible and check by eye, and you've already named why it fails: it doesn't scale. Worth being precise about why, though, because it's not that watching terminals is hard, it's that it's a polling loop with you as the CPU. One agent, glance occasionally, fine. Three agents, you're now a human cron job checking screens on an interval, and the interval is always either too frequent (you're babysitting) or too slow (you missed the 30-minute wait). There's no setting that works, because manual polling can't win against parallelism. The math is against you.

The flip is push instead of pull. Stop being the thing that checks, and let the agents be the thing that reports. Done, blocked, needs-a-decision, the three states worth interrupting you over, delivered when they happen instead of discovered when you remember to look. Then the number of agents stops mattering, because you're not allocating attention to each one, you're receiving an alert from whichever one actually needs you. Six silent agents cost you nothing. The one that's stuck taps your shoulder.

That's exactly the unified layer you said is missing, and you described it correctly, the value is the unification, one inbox across tools instead of one habit per terminal. Question back, since you're at the manual stage: when you check manually, what's your actual interval, every few minutes, or only when you happen to surface from something else? I'm trying to map how people poll today, because the honest pitch is "replace your polling interval with zero," and I want to know what interval I'm actually saving them from.

@nipuntaneja 

You just handed me the best positioning note in the thread: lead with the stuck alert, not the done ping. "Done" is a nice-to-have everyone's half-solving. "Blocked, waiting on you for 12 minutes" is the one with a dollar attached, because it's actively stopping the bleeding instead of reporting a finish. Done is information, stuck-and-counting is a refund. Taking it.

But the line you almost threw away is the more valuable one: most of your wasted time wasn't early finishes, it was under-briefing, so it stopped to ask. That reframes the whole problem. Half the interruptions aren't the agent needing a decision, they're the agent needing info you could've front-loaded. So the real fix is two moves, not one: prevent the avoidable stops with a better spec, and make the unavoidable ones impossible to miss. You've nailed the first half by hand. The stuck-timer is the second.

And the "marketer who builds, not a deep engineer" part matters more than you'd think, if this only works at six terminals it's a power-user toy. The fact that it kills you at two is the signal it's a real problem.

Question, since your batching is clearly tuned: when you check at set times, how'd you pick the interval, gut, or did you hit a point where waiting too long cost more than babysitting would have? I'm trying to figure out if the stuck alert is just a number you set, "ping me if anything's been blocked over X," and what X actually is for real people.

@atherkildsen 

You've put your finger on the cost everyone undercounts. The 35 minutes is the visible loss, but the 10-minute reload is the expensive one, because it's not just time, it's the mental scramble of rebuilding what you had loaded before you left. And it's worse than linear: you have to reconstruct what the agent did and what you were thinking when you set it off, two contexts gone cold at once. The ping tells you to come back. It dumps you at a terminal with no memory of why you're standing there.

Which means a bare notification actually fails at the exact moment it succeeds. It pulls you back and then abandons you to the scramble. The alert solved "when," and left "what" entirely unsolved, and "what" is where your 10 minutes goes. A ping without a summary is just a faster way to start being confused.

So the thing you want, a lightweight summary of what happened while you were gone, isn't a nicer notification, it's a different unit. The payload is the product. "Agent's done" versus "agent changed these 3 files, tests pass, blocked on this one decision" is the difference between starting the reload and skipping it. The summary is what lets you pick up at full speed instead of cold, because the re-orientation already happened in the notification instead of in your head at the terminal.

That's exactly the bet behind Pushary, the alert carries the handoff, not just the fact that one's needed. Question, since you've clearly felt the reload tax precisely: what's the minimum that actually kills the scramble for you, just what changed, or do you also need what you'd asked it to do, the original intent, because that's the context that goes coldest fastest? I keep wondering whether the summary needs to remind you of your own plan, not just report the agent's work.

@sarveshsea 

"Workbench, not a chat box" is the right instinct, and it points at something most of this thread has been circling without naming: chat is a fundamentally bad container for multi-agent work. A chat box is linear and single-threaded, one conversation, scrolling down, but the actual work is parallel and branching, multiple agents touching specs, research, and Figma at once. You're forcing a parallel reality through a serial interface, and the visibility problem is partly just that mismatch. The workbench gives the work the shape it actually has.

Your second sentence is the one I'd underline, though: visibility matters as much as output. That's the part teams discover late and painfully. When one person and one agent share a chat, visibility is free, it's all right there in the scroll. The moment you've got multiple agents touching shared artifacts, output without visibility is actively dangerous, because two agents can edit the same spec or the same Figma file and you've got conflicting truth with no one watching the seam. At that scale visibility isn't a nice view, it's how you prevent silent collisions.

Sounds like we're attacking adjacent faces of the same shape. Memi is the spatial layer, a place where the parallel work lives and stays visible because it's laid out instead of buried in a transcript. I'm on the temporal layer, the alert when one of those agents crosses into a state that needs a human, blocked, done, waiting on a decision. A workbench shows you everything at once when you look, a notification layer taps you when you're not looking. Same goal, two senses.

Genuine question, since you've built the spatial version: on a workbench with multiple agents touching shared specs and Figma files, how do you handle the moment two of them want the same artifact, surface the conflict for a human, lock it, or let them branch and merge? Because that collision is the thing I can't see how to solve with notifications alone, and I suspect the workbench is actually the better place to catch it. Curious where you landed.