Pushary
Control panel for AI agents on your lock screen
Start new thread

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

by
•

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.

5.1K views

Add a comment

Replies

Best

It's tough thing to do. I mean just go back and every time remember to go back is a hassle. Maybe at some point it's start mentioned where it need more inputs and informed once the job the done. This may help. !

 

Yeah that's the whole problem. You shouldn't have to remember. The agent should come to you.

That's what I built. Two things happen: it pings your phone when it needs input, and pings again when the job is done. You don't check back. It finds you.

Launching it this week actually. if you want to take a look.

    Love the 'agent finds you' framing — push on completion is the right primitive. The complementary problem I've been thinking about: what happens when the agent needs to send YOU an email because it hit a decision point and there's no phone to push to? Or needs to receive a reply from a service it just triggered? Curious if Pushary has plans for the agent-has-its-own-inbox direction.

   

@dannyheng Honest answer on the direction first: agent-has-its-own-inbox is a real and important primitive, and it's adjacent to Pushary rather than the center of it, which I think is the more useful thing to say than pretending it's all one product. Push and inbox aren't two features, they're two different assumptions about whether a human is even reachable. Push is human-present: it needs a registered device, it's a poke, it's ephemeral, and it degrades to nothing the moment there's no phone to hit, which is exactly the gap you're pointing at. An inbox is human-optional: the agent owns a durable address, messages persist, it works async, and crucially the recipient doesn't have to be a person at all. Your per-agent-email hack from earlier in this thread was already this primitive in disguise.

So the way I split it: Pushary is the routing-and-approval brain, the thing that knows which human to interrupt, at what urgency, with what payload, and how to get a yes back fast. The agent inbox is transport. I'd much rather sit on top of a good inbox than rebuild email, because the intelligence I care about is "is a human reachable right now, and is this worth interrupting them for," not "deliver bytes to an address." The clean composition is: agent has an inbox for the human-absent and service-to-service cases, and Pushary is the smart layer that, when a human is present and the decision needs them, upgrades that inbox message into a push with lock-screen approval. Channel chosen by recipient type and presence, same logic as picking ambient-vs-push, just one more rung down.

But the two halves of your question are wildly different difficulty, and I want to flag it because it's where I think the actual product is. Sending is easy, the agent hits a decision point and emails you, fine. Receiving is the hard 80 percent, and it's the more valuable half. When the agent triggers a service and needs to catch the reply later, that reply lands with no inherent knowledge of which paused agent run it belongs to. You need message-to-run correlation, the inbound reply has to join back onto the exact action that triggered it, and then it has to wake that specific run and resume it with the answer injected. That's the "wake an agent on a specific event" problem a few people in this thread have wished for out loud, and it's genuinely hard because it's the same id-binding discipline that came up two comments over: the reply is only useful if it carries the decision id back, otherwise you've got an inbox full of answers and no idea which questions they belong to.

So if you're building toward the receive-and-correlate-and-wake direction at Loomal, that's the part I'd be most curious to compare notes on, because the send side is a solved problem with a fresh coat of paint and the receive side is where the real engineering lives. Genuine question: when an agent triggers a service and goes idle waiting on the reply, how are you correlating the inbound message back to the right run, threading a token through the outbound request, matching on sender plus subject, or something the agent embeds and the service echoes back? Because the laziest version, match on email thread, breaks the second a service rewrites the subject or replies from a different address, and I haven't seen a clean answer to that correlation problem that survives uncooperative third parties.

    Token in the Reply-To address. Each outbound message from an agent run gets a unique subaddress — reply+<run_id>.dev — set as the Reply-To header. Inbound, we extract the run ID from the envelope To field and wake the right run.

This survives uncooperative third parties for one reason: a service can rewrite your subject, reply from a different address, mangle content-type — but it must preserve the Reply-To address to deliver the reply to you. The envelope To is the anchor they can't silently break without breaking delivery.

The one failure case: a service that synthesizes a new thread ignoring Reply-To entirely. Backup is a reference code in the email body — plain text survives relay rewriting even when headers don't.

Subject/thread matching is last resort only. You're right it breaks fast in the wild.

thanks for building this, very excited to find it!

We used aicosts.ai for this - per-agent cost tracking was the missing piece. It turned agent awareness from a tracking problem into an optimization one. The agents costing the most weren’t always the most productive.

 

"The agents costing the most weren't always the most productive" is the finding that matters, and it lines up with something Carolina said elsewhere in this thread: raw spend measures activity, not value. The expensive agent might be doing deep work or might be thrashing in circles, and the bill looks identical. Cost alone can't tell ambition from flailing.

Which is why the real unlock is the ratio, not either number: cost per output that actually shipped. Spend on one axis, survival of the work on the other. An agent that burns double the tokens but produces code nobody has to rewrite is cheap. An agent that's frugal but quietly wrong is the most expensive thing you own.

You're tracking the denominator's cost side, I'm building the status-and-outcome side, what each agent changed, what got approved, what held up. Same triangle, different corners. Curious what you did with the finding, did you kill the expensive low-output agents, re-prompt them, or move their tasks to the cheaper ones? The diagnosis is fun but the treatment is where the money is.

   The thing 'cost per shipped output' doesn't catch yet: shipped isn't the same as correct. The agent that worries me most isn't the expensive one visibly thrashing — it's the cheap one that ships fast and confidently, then costs someone else two weeks of debugging once the mistake surfaces downstream. Is anyone actually tracking a 'had to be redone later' rate alongside cost, or is that still an unsolved corner?

 Reframing it as cost per shipped output is a great insight. Raw spend really does hide whether an agent is doing deep work or just thrashing.

  Totally agree, the remembering part is the real friction. The agent flagging when it needs input and pinging when it's done would solve most of it.

this is the same problem but bigger when you're running non-coding agents too. an agent that books meetings or sends emails and you don't know what it did until after the fact is scarier than a coding agent waiting for approval. notifications are table stakes but what I really want is a dashboard that shows me what every agent is doing right now across everything

 

You're right, and that's where this goes. Coding agents are the entry point because the pain is obvious and the feedback loop is tight. But the architecture underneath doesn't care if it's a coding agent or a booking agent or anything else that speaks MCP.

The dashboard piece exists already. Live status, pending approvals, full audit trail. Right now it's scoped to coding agents but the plumbing is agent-agnostic.

Launching this week.

  The non-coding agent angle is so underrated, finding out after the fact is way scarier. A single live dashboard across every agent would be a game changer.

 "scarier than a coding agent waiting for approval" is exactly right, and it gets worse once it's not one agent but a handful of them spread across separate businesses. I've been building an AI chief-of-staff for founders running multiple companies at once, and the dashboard-of-everything instinct is right but it wasn't the whole fix for us. The dashboard told you what happened; it didn't tell you how sure the agent was that it read the situation correctly. We ended up grading every surfaced item (Verified, Very Likely, Needs Review, Monitor Only) so a booked meeting or a sent email doesn't get the same visual weight as something the agent is genuinely unsure about. Otherwise a busy dashboard just becomes a wall of green checkmarks you stop reading. Curious if Pushary's audit trail carries any confidence signal, or if it's a flat log of what happened.

The more agents you run, the worse your security blind spot gets. There's no unified way to know what's happening across them, what they changed, what they committed, what env vars they read, what endpoints they called, what they added to your codebase, etc.

It's a security surface area problem.

Startups shipping fast with Claude Code, Cursor, and Codex are moving faster than their security posture can keep up. That gap is where breaches happen.

[Full disclosure: I'm co-founder of , and that's exactly why we built it]

 

Valid point. The audit trail side is real and mostly unsolved. Pushary handles the permission layer before execution, not the forensics after. Different problem, same blind spot. Probably complementary honestly.

 Exactly 💯. Pre-execution control and post-execution audit are 2 sides of the same problem. You've got the "ask-before-act" layer, we've got the "what did it actually do to your security posture" layer.


Would love to chat sometime

 

Of course, feel free to book a slot

  Great point, the security surface angle gets overlooked in all the speed talk. Knowing what each agent touched is just as important as knowing when it finished.

 we are about to launch the audit trail for autonomous coding agents!

I was supporting an initial SOC2 for a client and realized that Dark Factory style coding wasn’t going to fly with the auditor.

Nothing else is in the market so we wrote so we can go faster.

 Same problem, different angle. You're framing it as security surface area, we started from the audit trail side. Guess, that's a sign it's a real gap.Would be fun to compare notes at sometime.

I have the same problem. Starting the agent is easy but remembering to check back at the right time is the messy part. A simple notification when it finishes or needs approval would already help. I'd also want to know whether it actually completed the task or stopped because it needs a decision

 

That's exactly why I built this. Three notification types: task done, task failed, task needs your decision. The third one is the killer. Agent wants to run something sketchy? Phone buzzes. Tap approve from your lock screen. It keeps going.

Launching the next version tomorrow actually. Good timing.

if you want to try it.

 Yes, knowing whether it finished vs stopped for a decision is the key distinction. A status-aware ping beats a generic done alert every time.

running one agent at a time for important tasks avoids confusion, even if it slows overall speed.

 

Works until it doesn't. One agent at a time is fine today but the whole industry is moving toward parallel agents. At some point you'll want to run three things at once and not lose track of any of them.

Better to solve the visibility problem now than to bottleneck yourself later.

  That's a clean approach for high-stakes work. The tradeoff is speed, but the focus you gain is probably worth it for anything critical.

custom /handover skill with kanban-based task system with like 6-7 terminals running at the same time. Each agent is isolated to its worktree, alongside --dangerously-skip-permissions can net autonomous sessions of 4+hours so I'd just visually click through terminals to see how they are doing. In addition to that, PowerShell has this neat feature where it shows that the agent is either in progress or 'done' and when it's done I would check that terminal and answer its questions / verify the results / do tests.

 

This is genuinely one of the more dialed-in setups I've seen, the /handover skill + kanban combo is smart, especially keeping each agent boxed into its own worktree so the 6-7 of them don't step on each other.

The part that jumps out to me is "I'd just visually click through terminals to see how they are doing." That's exactly the loop I'm trying to kill. The PowerShell in-progress/done indicator is a clever hack, but it still means you are the polling mechanism, you have to physically look. With 4+ hour autonomous sessions, the gap between "agent finished / agent is blocked on a question" and "you noticed" is where all the wasted time hides.

That's basically the whole thesis behind what I'm building: instead of you scanning terminals, the terminal pings you - done, blocked, or waiting for approval - so you can approve/answer from your phone without babysitting the grid.

Quick Qs since you're clearly further down this path than most:

  • When an agent stops to ask a question mid-session, how do you currently catch it - only when you happen to click that terminal?

  • Would a "needs approval" push that lets you respond remotely actually fit your worktree-isolated flow, or do you prefer to verify in-terminal anyway?

Really appreciate you sharing the actual mechanics - this is the kind of setup I want to make sure I'm not breaking.

 yes to both. I do have a separate workflow I don't want to be broken - having --dangerously-skip-permissions on requires me to set up hooks for push approval, and I have two mechanisms for that: one that uses AskUserQuestion type of response where it suggests Approve/Deny commands, and another where I have to type the exact phrase "Approve". I'd like to see Pushary support both of these methods. Otherwise sounds really neat to have this shared space for all running agents in one convenient place. Excited for what you're building!

  That's a seriously dialed-in setup. The worktree isolation across 6-7 agents is clever, though visually clicking through terminals is exactly the polling loop a push notification could remove.

That's where certain solutions need to be put in place both as guardrails and greenlights for your agent to continue on with tasks or wait on your approval. Sounds like this is the solution you're building towards as are we with out current solution called AgentPays (). Our solution is a security layer for agents to be able to have automatic approval flows, which for an agent making payments mainly centers around it making payments under an approved threshold amount and from whitelisted domains, otherwise it gets sent for human approval.

In terms of your approval workflows it sounds like some kind of a dashboard would be useful to construct and integrate the agents into. Just like most of us have some app or website that notifies us and that we consistently keep open throughout the day (Slack, Teams, etc.) this could be one of those that is somewhat "kept in the background" until you receive a notification from it. Could also go the route of having them shoot you emails, though that can certainly get cluttered very easily.

 
Orchestrated peer-respectful response acknowledging complementary solutions and dashboard strategy

"Guardrails and greenlights" is the cleanest framing of this whole problem I've seen, because it captures that approval isn't one thing, it's two jobs: stop the dangerous, wave through the safe. Most people only build the stop and then wonder why every session is just clicking yes.

AgentPays is solving the highest-stakes version of exactly this. "Auto-approve under threshold and from whitelisted domains, escalate everything else" is a risk-tiered policy, and payments is the one domain where getting it wrong is immediately, financially painful. Same shape as what I'm building, different blast radius, you're gating dollars, I'm gating code changes, but the engine is identical: a policy that knows what's safe enough to greenlight and what earns a human. The fact that we independently landed on the same threshold-versus-escalate model from opposite ends of the stack is a decent sign the pattern is real.

And you nailed the form factor. The Slack-shaped thing, always-on, background until it taps you, is exactly right, and email is the trap, it clutters into noise and trains you to ignore it, which is the one thing an approval channel cannot afford. The channel only works if a ping from it genuinely means "your brain is required."

Honestly feels complementary more than overlapping. A payment approval and a risky-code approval landing in one inbox isn't a stretch. Curious how you handle the policy-tuning UX, do users set thresholds and whitelists manually up front, or does AgentPays suggest them from observed behavior? That onboarding step is where I expect the friction lives.

The way you framed it as "guardrails and greenlights" is the perfect way to think about it, in my opinion. With regards to agents, I feel the best way to think of them is high potential, perpetually new employees. There's no question on the abilities, only the trust. The trust can only be established so much considering the agent doesn't have "skin in the game". Guardrails will minimize the screw ups and prevent their exploitability by bad actors. Greenlights are what allow them to ACTUALLY speed up operations.

Totally agree on the complementary nature of the two as well. For AgentPays, we're emphasizing human oversight on the agent's behavior with audit trails and required agent responses of why it proposed a transaction. This seems like something you guys could definitely integrate with Pushary where the agent is required to respond with reasoning it has for doing something a certain way, and the human manager can get an understanding as to if the agent is completing tasks properly.

In the same way that a manager reviews a new employee's work and asks that employee questions on how they did it, this would give a better understanding of how the agent is working and help it to improve particularly in the early stages of its use. Eventually, as the work is dialed in, then it can simply serve as a quick skim and then approve from the notification.

In terms of the onboarding, we're beginning to transition more to AgentPays-suggested whitelisted domains and thresholds. Friction definitely lies in making it a simple and trustworthy process for the user and that's something we're aware of. The thresholds more serve as a function of what the user would be comfortable with, which could vary wildly, but for now we're suggesting small amounts of $15-$20 to emphasize the safety in this nascent use case.

 

"High potential, perpetually new employees, no question on ability, only trust" is the sharpest version of this framing yet, and the word "perpetually" is doing the heavy lifting. A human junior stops being new, they accrue context, reputation, skin in the game. An agent is new every single session, so the trust never compounds the way it does with a person. Which means the trust has to be manufactured externally and re-established structurally every time, because the agent won't carry it forward on its own. Guardrails and greenlights aren't training wheels you eventually remove, they're permanent prosthetics for an employee who never gains tenure. That reframes why this is a product category and not a phase.

Your integration idea is genuinely good and I want to build on it, because you've described something better than an approval flow, you've described a learning loop. "Require the agent to respond with its reasoning, manager reviews the why, not just the what" is exactly how you onboard a real junior, and you nailed the arc: heavy scrutiny early when trust is zero, skim-and-approve later once the reasoning has proven sound. The reasoning attached to each proposed action is the thing that lets a human calibrate trust over time instead of forever. That's the part a bare approval can't do, a yes/no teaches you nothing, but "here's why I did it this way" lets you catch a bad mental model before it ships, and lets you relax once the model's clearly good.

Here's where AgentPays and Pushary slot together cleanly. You own the reasoning capture and the financial guardrail, the agent must justify a transaction and it's bounded by threshold and whitelist. Pushary owns the delivery and the calibration surface, that reasoning lands on the manager's phone as a reviewable proposal, and over time the system learns which categories of reasoning the human consistently waves through versus scrutinizes, so the skim-and-approve graduation you described becomes automatic rather than vibes. Your "why" is the payload. My job is making the why answerable from the lock screen and tracking which whys earned trust. Reasoning plus risk-tier plus a calibration history is a genuinely strong combined object.

On your onboarding, the move to suggested whitelists and thresholds is right, and the $15-$20 starting point is smart precisely because it's psychological, not just financial, the small number is what lets a nervous first-time user say yes at all, and the trust to raise it comes from watching the audit trail behave. You're using a low threshold to buy the user's confidence, then letting demonstrated behavior earn the higher one. That's the same trust-compounding arc, applied to the human's comfort instead of the agent's track record.

One question, since you've thought hard about the suggestion engine: when AgentPays suggests a threshold or a whitelisted domain, is that suggestion based on the individual user's observed behavior, or a population default across your users? Because the trust dynamics are really different, a population default is fast but feels generic, a personalized suggestion is slower to earn but feels like the system actually understands this user's risk appetite, and I keep wrestling with the same fork on the risk-tier side. Curious which way you're leaning and why.

I think the biggest bottleneck with AI agents is shifting from execution to coordination.

As agents become capable of handling more tasks in parallel, the challenge becomes knowing:

  • what is running;

  • what is blocked;

  • where human input is needed.

Notifications alone may not be enough — we probably need an “agent operations layer” that helps manage handoffs between autonomous execution and human judgment.

Curious to see how this space evolves.

 

"Agent operations layer" is the right name and the shift you named is the real one: execution stopped being scarce, so the constraint moved to coordination. Every problem looked like an AI problem when the models were the bottleneck. They're not anymore, so the limiting factor is now a human's ability to know the state of a fleet, which is an ops problem, not a model problem. It rhymes hard with how we went from "can the server run this" to DevOps and observability the moment there were more servers than one person could watch.

And you're right that notifications alone aren't enough, though I'd be precise about why: a notification is the delivery mechanism, not the layer. It's necessary because a state you have to go check is a state you'll check late, but it's insufficient because a bare ping tells you when to come back and nothing about what you're walking into. The layer is the thing underneath, one state model across every agent, so the notification can actually carry the handoff: what changed, what it needs, what's risky. Ping without the layer is just a faster way to start being confused.

Your three-item list is basically the spec, and the third one is the interesting one, "where human input is needed" is exactly the handoff boundary you're describing. That's the point where autonomous execution runs out and judgment has to take over, and getting that boundary right (surfacing the calls that genuinely need a human, silently clearing the ones that don't) is most of the actual work. Too many handoffs and you're a captcha; too few and the agent quietly decides something you'd have wanted in on.

That's what Pushary is, the ops layer plus the handoff, so it's fun watching people arrive at the same architecture independently. Curious which of your three you think is hardest to get right, my bet is "what is blocked," since a stalled agent and a thinking one look identical from outside, so it's the one state you can't detect without the agent declaring it.

This is such a massive pain point right now! That loop of leaving an agent to run, only to come back and realize it’s been stuck on a basic 'Y/N' approval prompt for 30 minutes is incredibly frustrating. Right now, I mostly just try to keep a split terminal visible, but it completely breaks deep work focus when you constantly have to babysit the screen. Building a unified push notification + approval flow layer sounds like exactly what the agent ecosystem needs. Would love to see how you're handling the webhook/notification triggers for this!

 

Split terminal is the worst. You're technically not babysitting but you're also not doing anything else because half your brain is watching for movement in the corner of your eye.

The hook intercepts the agent's tool-use event before it executes, checks your permission rules, and if the tool needs approval it routes to your phone as a push notification. You tap approve or deny from your lock screen. Answer flows back, agent continues. Whole round trip is a few seconds.

Launching this week with full details on the hook architecture.

That lock screen approve/deny flow sounds absolutely frictionless, Aadil! ⚡ You completely nailed the split terminal struggle—that 'half-brain monitoring' is exactly what drains cognitive energy without you even realizing it. Intercepting the tool-use event before execution and routing it straight to mobile is a brilliant way to handle the round trip in just a few seconds. Staying tuned for the hook architecture details this week. Definitely checking out pushary.com/ai-coding. Good luck with the upcoming launch!
Exactly, Aadil! 'Doing two things badly' is the perfect way to put it. Looking forward to reading those hook architecture details when you share them—definitely keen to see how it resolves that split-terminal friction. Keep us posted!

Interesting thread. It feels like we're moving from agent execution to agent management. The tools that win may not be the ones building better agents, but the ones helping humans supervise dozens of them effectively.

 

That's the bet. The agents themselves are getting better fast. The supervision layer barely exists. Someone has to build the control plane.

123
•••
Next