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

@rahulbhavsar 

The word that earns its place in yours is "assuming," because the other three are states and that one's different in kind. What changed, what's blocked, what needs approval, those are facts about where the run is. What the agent is assuming is a window into why it's about to do what it's about to do, and that's the only one of the four that lets you catch a bad decision before it becomes a bad diff. The first three are reporting. Assumptions are the leading indicator. Most visibility tools surface the states and skip the assumptions entirely, which means they show you the crash, not the wrong turn that caused it.

It's also the hardest of the four to get, and worth being honest about why. Changed, blocked, approval-needed are observable, the system can see them happen. Assumptions are internal, they only exist if the agent surfaces its own reasoning, "I'm proceeding as if this API is stateless," "I assumed you want this in the existing module not a new one." An agent that doesn't declare its assumptions has them anyway, silently, and those silent assumptions are exactly where the plausible-looking-but-wrong output comes from. So the visibility layer can report three of your four by observation, and the fourth requires the agent to actually narrate what it's taking for granted, which is a prompting-and-hooks discipline, not just a display problem.

And your framing of the shift is the correct one: the bottleneck moved from output to trust and visibility. Raw output stopped being scarce the moment you could run four agents at once, so the constraint slid to the thing that didn't scale, your ability to trust what they produced without reading all of it. Visibility is just the mechanism by which trust gets manufactured at that scale, you trust what you can see, you fear what's opaque, and four opaque agents is four sources of risk no matter how productive they are.

The one caution, same one I keep landing on with the activity-layer idea: lightweight is load-bearing in your sentence, and the trap is that an activity layer you have to watch becomes the fifth thing competing for the attention you're already short on. The version that works shows you everything when you look but taps you when one crosses into blocked or needs-approval, so it's ambient until it's urgent. A layer that requires monitoring just relocates the bottleneck instead of removing it.

That's the shape of what I'm building, the four-field view you described with assumptions as the part I care most about getting honest. Question, since you put assumptions in your list deliberately: would you want the agent to surface assumptions continuously as it goes, or only bundle them at the blocked and approval moments when you're actually about to make a decision? Continuous is more complete but it's also more noise, and I can't decide whether assumptions are something you want streaming or something you only want at the gates where they'd actually change your answer.

@getosmo 

Direct answer: yes, gating on irreversibility rather than gate-everything is the design, because gate-everything is just bypass-all wearing a seatbelt, it trains the human to rubber-stamp and then the one approval that mattered gets the same reflexive yes as the hundred that didn't. The whole value is selective. But your comment makes me want to sharpen what the gate keys on, because you've actually exposed a flaw in how I'd been framing it.

I'd been treating reversibility as a property of the action type. You've shown it's really a property of the boundary the action crosses. Inside the sandbox, almost everything is reversible, a coding agent's diff, a file write, a local state change, git and undo cover it, so after-the-fact awareness is genuinely fine and a done-ping plus revert is the right, low-friction primitive. The moment the action crosses out of the sandbox into the world, reversibility doesn't degrade, it disappears, because the world has no undo. A placed call happened. A booking exists. There's no revert on a stranger's phone ringing. So the gate isn't "is this action risky," it's "does this action escape the sandbox," and the side-effect boundary is the thing worth detecting, not the action category. That's a cleaner rule than I had, and it's yours.

Which means your inversion is exactly right and I'd state it even harder: for irreversible real-world actions, a "done" notification isn't a weaker version of approval, it's a category error. It's reporting a fact you no longer have any power over. Awareness that arrives after an irreversible commit isn't awareness, it's a receipt. The only awareness that does anything sits before the commit, at the decision point, which means the entire job for outside-world agents is pre-commit approval with enough context to rule in five seconds, and the "five seconds" part is not a nice-to-have, it's the constraint that makes pre-commit gating survivable. If ruling takes thirty seconds and your agent makes forty bookings, you've rebuilt the bottleneck. The payload has to carry the whole decision, who it's calling, what it'll say, what it'll commit to, so the human can approve at a glance, or the gate becomes the thing people disable.

The hard part, and the place I'd be honest that it's genuinely hard, is detecting the boundary reliably. For your domain it's clean, place-a-call and make-a-booking are obviously side-effecting, you know them by name. The trouble is the general case: an agent that calls an API where some endpoints are reads, harmless, reversible, and some are writes that charge a card or send a message, and they live behind the same tool. The boundary isn't always legible from the action's shape, so a naive "ask on external calls" gate either over-asks on every read or under-asks and misses the one POST that bought something. So the real engineering is classifying side-effecting versus inert at a finer grain than tool-name, and for unknown tools the safe default has to be ask, because the failure modes aren't symmetric, an unnecessary approval costs five seconds, a missed irreversible commit costs a call to a real person you can't take back. Asymmetric danger means err toward asking when you can't tell.

So the model I'd actually build: declare or detect the side-effect boundary, auto-clear everything inside it, gate everything that crosses it, and for anything ambiguous, treat it as crossing until proven inert. That gives the coding-agent case its low-friction notify-on-done and the real-world-agent case its pre-commit gate, from one rule, without forcing your phone-calling agent into a primitive built for revertible diffs.

Genuine question, since you're living the irreversible case most acutely: for your agent, is the approval you want binary, yes-place-the-call, or is it really an approval of the content, here's exactly what it'll say and commit to, change it before it goes? Because those need very different payloads. Binary is a button. Content-approval is an editable draft the human can tweak at the gate, and if it's the latter, the pre-commit step isn't just a gate, it's the last point of authorship, which is a meaningfully bigger thing to build and might be the actual product for outside-world agents.

@galdayan 

Then I'll build for the heavy case, because you've told me something useful: the trivial approvals are nice-to-have, but the flag that says "open the editor for this one" is the part you'd actually rely on, and that's the harder, more valuable feature anyway. The cheap-yes-from-phone is a convenience. The "don't rubber-stamp this from your lock screen, go look" is a guardrail, and a guardrail you trust is worth more than a convenience you enjoy.

The interesting design problem your answer surfaces: the flag has to be trustworthy in the direction that costs you. If it under-flags, marks a real refactor as trivial, it lulls you into a lock-screen yes on exactly the thing you wanted to see first, which is the worst outcome, worse than no flag at all, because no flag at least keeps you honestly cautious. So the flag should err loud on the heavy side, when it's unsure, it says "worth opening," because the cost of a false "go look" is thirty wasted seconds and the cost of a false "it's fine" is you approving a refactor blind. Asymmetric again, same logic that runs through this whole space: bias toward the cheap mistake.

What makes it doable is that "worth opening the editor" correlates with things that are actually detectable, blast radius of the diff, whether it touches a sensitive path, how many files, whether tests cover it. A one-line change to a config and a fifteen-file refactor of your auth flow don't look the same to the system, so the flag isn't a vibe, it's readable from the shape of what the agent's about to do. That's the part I can make sharp for you.

And good luck with MadeDay, productized design-and-frontend for founders is a real wedge, the people who can build the backend but bounce off the frontend polish are everywhere. When you're closer to the PH launch, genuinely ping me, I've now done enough of this thread to have opinions about launch-day comment hustle that I'd happily trade. Connecting with someone in the same daily mess is half of why this thread's been worth it. Go ship it.

@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.