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

@thenameisarian 

Yes, share the script, genuinely. But the part worth dwelling on isn't your notification hack, clever as the silence-or-finish trigger is, it's the second thing, because you quietly built the layer almost everyone in this whole thread has only been gesturing at.

"Agents that finish with wrong output are worse than agents that hang" is the correct and under-appreciated take, and the reason it's true is asymmetric visibility: a hang announces itself, it's obviously stuck, you'll deal with it. A confident-wrong finish disguises itself as success, ships a green check, and gets built on top of before anyone notices. The hang costs you minutes. The plausible-wrong finish costs you whatever you stacked on it before the truth surfaced. So gating on completion is gating on the wrong event, and you figured that out and did something about it.

Piping the run through a cheap secondary model scoring against the original spec, and only pinging on that, is the move. You replaced "did it stop" with "did it do the thing," which is the actual question. And the "dopamine waste of green checks that meant nothing" line is the sharpest framing of the failure I've heard, because the green check is worse than no signal, it actively tells you to relax at the exact moment you shouldn't. You're not notifying on done, you're notifying on probably-correct, and that's a different and better primitive.

The one place I'd push, and it's where I'd want to see the script: spec-matching is a weaker check than it looks, because an agent that misunderstood the spec can produce output that matches its misunderstanding perfectly, and a judge scoring against that same spec scores it green. The secondary model catches "drifted from what you asked." It's blind to "did exactly what you asked, but the thing built is subtly broken," because that needs ground truth tests, not spec alignment. So your scorer is a strong filter on drift and a weak one on correctness-of-a-faithful-implementation, which is fine as long as you know which one it's catching, the danger is trusting it for the second when it only does the first. Pairing it with actual test results would close most of that gap, the judge for "matches intent," the tests for "actually works."

Genuine question, since you're already running a model-judges-model loop: how often does the cheap scorer false-green, pass something that looked spec-matching but was wrong, versus false-red and nag you on output that was actually fine? Because the false-green rate is the whole ballgame, a judge that misses bad output quietly recreates the green-check problem one level up, just with more compute, and I'm curious whether the cheap model is good enough at this that you trust its pass, or whether you still spot-check the greens.

@alex_dev_user 

The Telegram-Mini-App insight is the smartest architectural move in this thread, and it's worth naming exactly what you did, because it generalizes: you didn't solve the notification problem, you avoided it by building inside a system where push is the native primitive. A web app has to bolt notifications on, devices, permissions, service workers, fallback to ntfy. A messenger app already is a notification channel that happens to have your app inside it. So "ping the user" isn't a feature you built, it's the substrate. You picked a host where the hard part was free. That's the kind of decision that looks like a platform choice and is actually a distribution-and-UX choice in disguise.

And the irony you flagged is the real lesson: the same person who architected push away from being a problem on the finance app just accepts the jank on the Cursor side. Not because you couldn't solve it locally, but because the local dev environment doesn't hand you a free push primitive the way Telegram did. There's no messenger your agent already lives inside. So you'd have to build the exact thing you elegantly sidestepped, and building it isn't worth it for your own setup, so you eat the wasted time. That gap, "I solved this beautifully where it was easy and gave up where it was hard", is precisely the local-agent-orchestration hole, and it's why the local case needs a dedicated tool while the messenger case doesn't.

Which is the honest framing of where Pushary fits for you: it's the missing push primitive for the environment that didn't come with one. Your Telegram app didn't need it. Your Cursor setup does, and not because the problem's different but because the local dev world has no native channel to your phone, so something has to manufacture one. That's the whole job, be the substrate locally that Telegram is for free remotely.

Go try it, and genuine question back, because you've thought about this at the architecture level most people haven't: on the Telegram side, do you also get the approval round-trip natively, can the user approve the shared-budget request right there in the chat and have your backend act on it, or is the bot only pushing outbound and the actual approval still happens elsewhere? Because outbound-ping is the easy half and inbound-approval-that-resumes-the-run is the hard half, and if Telegram's giving you both cleanly, that's a strong argument for the messenger-as-host pattern that I'd want to understand before I assume the local tool needs to rebuild it from scratch.

@g023 

That UPDATE.md trick is a genuinely good instinct and it's solving a real and distinct problem, worth separating from the notification thread because it's a different failure mode. Everything else here is about you losing track of the agent. This is about the agent losing track of itself, context window fills, session resets, and the agent forgets what it already did and why. The .md is external memory, a place the agent's progress survives outside the volatile context that keeps evaporating. That's correct, and it's the same pattern good engineers already use, leave notes for your future self because future-you has amnesia. Future-agent has it worse.

The one thing that makes or breaks it, and it's worth flagging because it's the difference between this working and rotting: the agent has to reliably write to it, and reliably read it back after a reset. The writing is the fragile part. If updating the file depends on the agent remembering to do it, the exact moment it's most useful, deep in a long task right before context blows out, is the moment the agent is most likely to skip the update because it's busy. So the .md wants to be enforced, not hoped for, a hook or a step in the loop that writes progress automatically at each milestone, rather than an instruction in the prompt the agent honors when it feels like it. Instruction-based works until the run where it matters, then quietly doesn't.

There's a nice convergence here too, because that UPDATE.md is almost exactly the handoff trail this thread keeps circling, what's been done, what's in progress, what's blocked, just pointed at the agent's future self instead of at you. Same artifact, two readers. Which is the actual insight: if the agent maintains that running record well, it serves both purposes at once, the agent reads it to recover from a reset, and you read it to catch up without replaying the session. One trail, written once, consumed by both the amnesiac agent and the absent human. Build it for either and the other gets it for free.

Question, since you clearly run this: do you have the agent update it on its own, or have you wired the writes into something automatic? Because that's the exact reliability seam, I keep finding prompt-instructed self-updates degrade on the long runs that need them most, and I'm curious whether you've hit that or found a way to make the agent actually keep it current when it counts.

@kevinzrzgg 

You've now said "boring activity trail over fancy dashboard" a few different ways across this thread, and I keep agreeing harder each time, so let me name why the boring version is actually the correct architecture and not just a modesty preference. A dashboard optimizes to be looked at, charts, a hero number, something that rewards you for opening it. But the entire goal here is something you almost never open until you need it, and then it hands you the answer instantly. Those are opposite design targets. The moment a tool earns a glance, it's competing for the attention you're short on. The trail wins precisely by being unglanceable, it's a record you consult, not a display you monitor.

The reframe in your second paragraph is the sharp one: review the session like a handoff report instead of replaying the conversation. Replaying is the tax everyone pays without noticing, you come back and reconstruct what happened by scrolling the transcript, which is slow because the transcript is the agent's stream of thought, not a summary of its effects. A handoff report inverts that, it's effects-first, files read, files changed, commands run, where it stuck, so you're reading conclusions instead of re-deriving them. The difference is reading a colleague's PR description versus watching a recording of them typing for an hour. Same information, wildly different cost to absorb.

The field in your list that's doing the most work, and the one most tools drop, is "what files it read." Changed-files and commands are the obvious outputs, but read-files is the agent's input set, the context it actually based its decisions on, and that's where the silent errors hide. An agent that changed the right file for the wrong reason, because it never read the constraint living two files over, looks fine if you only see the diff. The read-set tells you whether it even looked at what it should have. It's the cheapest way to catch "confidently wrong because under-informed," which is exactly the failure a diff can't show you.

That's the whole product, honestly, the boring trail as the standard payload, read/changed/ran/stuck, structured so a session reviews in ten seconds. Question, since you've defined the report cleanly: would you want "where it got stuck" to include the agent's own account of why, or just the factual stopping point? Because the why is the most useful field and the least trustable, an agent narrating its own confusion is exactly where you'd expect a plausible-but-wrong story, and I keep wondering whether the self-reported why earns its place in a trail that's otherwise all hard facts.

@todd_merrill 

Ha, the blue accept bar becoming the thing you hate is its own little signal, because what you're actually sick of isn't the bar, it's how many times a day you're the one clicking it. The bar is just where the friction shows up. If it only appeared for decisions that genuinely needed you, you'd feel neutral about it, maybe even glad to see it. You hate it because it shows up for everything, the trivial and the critical wearing the same blue, so you've been trained to reflexively accept, and a thing you reflexively click is a thing that's stopped meaning anything.

That's the real problem hiding under the annoyance: when every action routes through the same accept prompt, the prompt stops being a decision and becomes a toll booth. You're not approving, you're dismissing. And the danger isn't the annoyance, it's that the one accept bar that should've made you stop and think looks identical to the thousand that didn't, so it gets the same autopilot click.

The fix isn't removing the bar, it's making most of the actions never reach it, pre-authorize the safe, repetitive stuff so it just proceeds, and save the prompt for the few things that actually warrant a human. Then the blue bar goes back to meaning something, because when it shows up, it's because something genuinely wanted your eyes. Rare enough to respect, instead of constant enough to resent.

That permission-tiering is most of what I'm building toward, so genuine question: when you hit the accept bar, is it mostly stuff you'd happily have auto-approved, file edits, safe commands, the routine churn, or is it a real mix where some of those accepts you're glad you got to see? Because if it's mostly routine, you don't have a notification problem, you have a permissions problem, and the answer is letting the agent just do more without asking, not pinging you about it faster.

@harperz9 

Notification versus receipt is the cleanest framing of this whole thread, and it's a tense distinction, not just a feature gap, because the two have opposite lifespans. A notification is built to be consumed once and discarded, it lives at the moment of the event and then it's gone. A receipt is built to be re-checked later, by someone who wasn't watching when it happened, possibly under adversarial conditions, "prove to me this is what occurred." Most tools in this space, including the naive version of mine, ship notifications and quietly inherit notification amnesia, faster to tell you, nothing to re-examine. You're pointing at the durable artifact underneath, and you're right that it's the harder and more valuable layer.

Your field list is good, but the one that makes it a receipt rather than a fancier notification is the last one, "what the agent did not verify," and it's worth dwelling on why it's load-bearing. Every other field is a record of what happened, which is the positive space. The unverified set is the negative space, and negative space is the thing a green check actively hides. An agent that ran three tests and skipped two looks identical, at the "done" level, to one that ran all five, unless the receipt explicitly carries the gap. So the unverified field isn't one item on the list, it's the field that converts the receipt from "here's what I did" into "here's what I did and here's where I might be lying to you by omission." That's the difference between evidence and a press release. It's also the hardest field to populate honestly, because it requires the agent to know and disclose what it didn't check, which is exactly the self-knowledge agents are worst at, an agent that silently skipped a check often doesn't represent the skip to itself as a skip. Getting that field to be trustworthy is most of the actual problem.

On the redefinition you slipped in, "done should mean a reviewer can inspect the evidence, not just that the agent stopped talking", that's the sentence I'd put at the top of the spec. "Done" is currently a claim the agent makes about itself, and a self-asserted done is testimony, not proof. Your receipt turns done into a verifiable state, the agent doesn't get to declare completion, it produces an evidence packet and the reviewer (human or automated) decides whether that packet constitutes done. That's a real inversion of authority, and it's the right one, because the entire failure mode everyone in this thread keeps describing, finished-but-quietly-wrong, is precisely an agent's self-reported done diverging from reality. A receipt is how you stop trusting the testimony and start checking the evidence.

Now the honest part about how Telos and Pushary relate, because your "per-task replay packet rather than another inbox notification" suggestion is sharp and I want to engage it straight rather than defensively. You're right that the receipt is the more durable layer and that an inbox notification is the more ephemeral one. But I don't think the conclusion is that one replaces the other, I think they're the two halves of a single object viewed at different times, and the relationship is temporal. The notification is the receipt at t=0, delivered while you can still act, when the action is pending and an approval can still change the outcome. The replay packet is the same record at t+N, durable, queryable, used to re-check after the fact when nothing can be changed and you're doing forensics or calibration. The reason you want both is that they serve different jobs: the notification's job is to let you intervene before commit, the receipt's job is to let you audit after. A pure receipt layer with no live notification tells you beautifully what went wrong, after it's too late to stop it. A pure notification with no durable receipt lets you act in the moment and then forgets, so you can't learn from the pattern. The complete thing is one record that's actionable when it's live and inspectable when it's history.

Which is to say I think we're building the same object from opposite ends, and the interesting question isn't "replay packet instead of inbox" but "what's the schema of the record such that it serves both the live-approval moment and the after-the-fact audit without being two separate stores that drift." That's the same one-write-path-many-read-lenses problem that came up elsewhere in this thread, the receipt and the notification should be projections of one canonical event log, not two systems. If Telos is going deep on the receipt schema and what evidence developers actually trust in a handoff, that's genuinely the part I care most about and would rather compare notes on than compete over, because the schema is the hard intellectual work and the delivery layer is comparatively mechanical.

So the real question back, since you said you're mostly trying to learn what evidence developers actually want: when you've put receipts in front of developers, what do they actually open and read versus what they say they want? Because my strong suspicion is there's a gap, everyone lists all six fields as essential, but in practice they glance at the diff and the failed checks and never open the rest until something breaks, at which point they want the unverified set and the tool-call trace they ignored at handoff time. If that gap is real, it changes what the receipt should surface by default versus keep available-but-folded, and it's the kind of thing only you can see right now because you're the one watching people use the receipt layer live. What are they actually reading?

@deepak_poojari1 

Buying a 43-inch screen to solve this is the most Tony Stark fix imaginable, throw hardware at it and call it strategy. Respect the commitment. I just hope nobody tells you a phone notification does the same job and fits in your pocket, because that would be awkward for the monitor.

Here's the thing the giant screen quietly can't fix: it only works while you're sitting in front of it. The second you get up for coffee, the agent freezes on an approval and your beautiful 43 inches of glass is now displaying a stalled terminal to an empty chair. Real estate doesn't help when the problem is that you walked away. And a stalled terminal looks exactly like a working one on a big screen too, just bigger.

That's the whole point of pushary.com, the approval finds you instead of you guarding the wall. But honestly, if the monitor's working for you, ride it out. Try Pushary the day your back hurts from never leaving the desk, or the day you add a fourth agent and run out of screen. No rush. The wasted time will still be there waiting.

@somesh_putatunda 

Direct answer: we're already there, policy-based approvals aren't a someday, they're in now, because notification-first alone is only half a product. A pure notify layer makes you aware of every stall faster, but if the agent keeps stalling on the same repetitive confirmations, I've just made you really efficient at being interrupted. Awareness without pre-authorization is a better alarm for a problem you shouldn't be having. So the policy layer isn't the eventual upgrade, it's the other half of the same idea: notifications for the decisions that genuinely need you, pre-approved classes for the ones that never did.

And you've drawn the line in exactly the right place, because the repetitive confirmations are pure tax, the agent asking "can I edit this file" for the fortieth time isn't a decision, it's a toll booth, and every yes you click there is training you to autopilot, which is how the one approval that actually mattered eventually gets the same reflexive yes. Pre-approving the safe, repetitive classes does two things at once: kills the stalls and protects the meaning of the prompts that remain. When the agent does ask, it's because something genuinely crossed a line, not because it hit the same routine gate again.

Where it gets interesting, and where we're actively building, is that a static allowlist is the floor, not the ceiling. The next step is the policy learning from your own approval behavior, we're putting reinforcement learning around the approval mechanism so it watches what you consistently wave through versus what you stop to scrutinize, and starts clearing the patterns you've effectively already approved a hundred times. So similar future permissions resolve themselves and the task just gets done faster, without you re-confirming a class you've demonstrated you trust. The allowlist you'd have to maintain by hand becomes one the system proposes from your actual decisions.

The one discipline I care about getting right there, because it's where learned approvals can go wrong: the learning should only ever loosen with evidence and should never quietly auto-clear a high-risk class just because you happened to approve it fast a few times. Speed of approval on a trivial action means trust, speed on a risky one might just mean you weren't looking, and the system has to tell those apart or it learns to rubber-stamp on your behalf. So the RL proposes, the risky tiers still surface, and trust expands deliberately rather than drifting. Learned-faster on the safe stuff, never silently-permissive on the stuff that bites.

Question back, since you've clearly thought past the notification layer: when you imagine pre-approving classes of actions, do you want to declare those upfront yourself, or would you rather the system infer them from watching you and just propose "you've approved this 30 times, want to auto-clear it"? Because the declared version is precise and a bit of setup friction, the learned version is zero-effort but you're trusting it to read your behavior right, and which one you'd actually live with tells me how aggressive to make the RL versus how much to leave in your hands.

@atherkildsen 

Yeah, cycling through six works right up until it doesn't. The moment agent #2 finishes or gets blocked while you're looking at #5, you've already lost the time. You're basically doing human round-robin scheduling, and the gap between cycles is where the waste hides.

That's the whole reason I'm building Pushary: instead of you cycling through them, the one that's stuck or done taps you. Six agents cost you nothing until one actually needs you.

Curious, when you cycle, what bites you more: finding one finished 20 minutes ago, or one that's been blocked waiting the whole time?

@jitenoswal 

Straight answer: right now it's closer to bespoke per integration than a clean normalized schema, and you're pointing at exactly the thing that decides whether this scales or turns into a maintenance swamp. Each runtime exposes state differently, Codex gives a native approval hook, Claude Code is solid on shell and file edits, Cursor only exposes a shell hook so edits are a blind spot, and today those differences leak further up the stack than they should.

Where I'm heading, and where your telemetry background is more informed than mine, is a normalized internal event schema with thin per-runtime adapters that map each tool's native signals into it. The adapter absorbs the runtime's weirdness, everything above it speaks one vocabulary of states and events. The bet is the same one you've lived: the value isn't the dashboard, it's the normalization layer underneath, and if I get the schema right the surface stuff gets easy.

The part I keep chewing on, and where I'd genuinely take your read given the patents: the runtimes don't just differ in format, they differ in what they can even tell you. Codex can say "I'm blocked for approval" natively; Cursor structurally can't tell me an edit happened. So it's not only normalizing schemas, it's normalizing across different capability floors, and I don't want to design a schema that quietly assumes the richest source. In cloud telemetry, did you force a lowest-common-denominator schema, or let events carry a capability/confidence marker so consumers know a missing signal means "didn't happen" versus "this runtime can't see it"? That distinction feels load-bearing and I'd rather learn it from someone who's already hit it than discover it the hard way.