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

@tristan666666 

"Agent runs should not own your attention" is the cleanest one-line statement of the whole problem I've seen, and Agent Island is a sharp take on it. Putting live state in the notch is the right instinct, ambient awareness your eyes catch for free instead of another thing you have to actively check. That's the move.

We landed on the same split from different ends: you're solving the at-desk, different-window case with something glanceable, I'm solving the away-from-keyboard case with push. The honest read is those are complementary, not competing. The notch is perfect while you're at the machine and can't help you the moment you walk away, and a phone push is overkill when the terminal's six inches from your eyes. Same underlying belief, two different distances from the screen.

The "rings when it's your turn" part is the one I'd dig into, because that's the hard bit, since a stalled agent and a thinking agent look identical from outside. Curious how you're detecting "your turn" for Claude Code and Codex, native hooks, or watching the output? That detection is where I keep finding the real work is. Nice build, genuinely.

@emoji_kitchen2 

just use pushary and you get the ping on your phone when your agents need you

@gdenterprises005 

You've named the failure that actually hurts, and the word carrying it is "confidently." Syntax errors are loud, they don't compile, they get caught, they're cheap. Confident business-logic changes are silent, they run fine, they pass, they look intentional, and they're wrong in a way only someone who knows the domain would spot. The dangerous failure isn't the one that breaks, it's the one that works while doing the wrong thing.

And your junior-developer framing explains why. A junior makes exactly this mistake, does something technically correct that violates an unwritten rule about how the business is supposed to behave, because they don't have the context yet. The difference is a junior gains that context over time and an agent starts fresh every session, so it never accumulates the domain sense that would stop it. It's a permanent junior, which means the guardrails can't be temporary training wheels, they're the permanent substitute for judgment it won't develop on its own.

The practical problem is these changes hide precisely because they look reasonable. A diff that alters business logic reads as plausible, so it slips past a tired review, and the agent won't flag it because it thinks it's helping. That's what makes it worth catching mechanically: the agent stating what it intended versus what it actually touched, so a change to logic you didn't ask it to touch surfaces as a deviation instead of blending into a green-looking diff.

Curious, when it does confidently change business logic on you, is it usually because your instruction was ambiguous enough to leave room, or does it invent an assumption even when you were fairly specific? Those need different fixes, and I keep going back and forth on which one bites people more.

@grace_lee26 

Direct answer: yes, interruption quality is the whole bet, and "otherwise every agent just becomes another inbox" is exactly the failure I'm trying to avoid. Faster pings without better payload just means you get overwhelmed sooner. A ping is only worth sending if it saves more attention than it costs, and most notification tools quietly cost more than they save.

The context loss you named is the sharper half, and I think it's underrated. The wasted 30 minutes is the visible cost. The reload, coming back and reconstructing what you even asked for, is the expensive one, because it's not just time, it's getting back into the headspace you left. A bare "done" ping fails precisely here: it pulls you back and abandons you to the scramble. That's why the payload has to carry the reload, the question plus the intent plus a tiny diff, so you pick up where you were instead of rebuilding it. The notification's real job is killing the reload, not announcing the finish.

And your rule set is basically the spec: notify only on blocked or done, carry the exact question and a snippet, gate only the risky stuff. The "only risky" part is what keeps it from becoming an inbox, gate everything and you train people to rubber-stamp, and then the channel is dead.

Curious about your "include the exact question plus a tiny diff" line, when you come back, do you trust the snippet enough to answer from it, or do you still open the full thing before you say yes? I'm trying to figure out how much people will actually decide from the payload versus treat it as a nudge to go look.

@galdayan 

The Slack-webhook-per-session-in-its-own-channel setup is smarter than it sounds, because the channel-per-agent gives you a persistent per-agent thread for free, so you're not reconstructing history, it's just there in scrollback. You routed around half the problem with infrastructure you already had.

But the change you flagged is the actual insight, and it's bigger than it looks: making the notification say why it's waiting is what turns a ping into a triage. "Done" makes you tab back to find out what "done" means. "Needs approval vs finished vs blocked on error" lets you decide before you move. That's the difference between a notification that relocates the work and one that carries the decision. The three-state why is doing all the work.

And your last line is the thing most people miss entirely. The 30-40 minutes isn't mostly the waiting, it's the reload, rebuilding what the agent was even doing when you come back. Which means the fix isn't a faster ping, it's a ping that carries enough context to skip the reload. The why-state gets you the triage; the next step up is a line of what-changed so you don't just know why it stopped but where it was, and you pick up cold instead of scrambling.

Curious, with the per-agent channels, did you ever want to answer from Slack, approve the thing right there, or was it purely one-way and you still tabbed back to the terminal to act? That send-vs-respond line is the one I keep poking at.

@imed_radhouani 

"The terminal is not a good notification system" should be the first line of the spec, and you're right about why: it demands active looking, and the whole premise of running agents is that you've looked away. A notification system you have to watch isn't one. The external ping isn't a nice-to-have, it's the only thing that survives the fact that your attention is legitimately elsewhere.

Your Slack setup being "not sophisticated, just consistent" is the actual lesson, and it's the one most people skip past chasing features. Consistency beats cleverness here because the value is trust, if it pings reliably on start/finish/approval every time, you stop checking terminals, and that's the whole win. A fancy notifier that fires 90% of the time is worse than a dumb one that fires 100%, because the 10% gap puts you right back to babysitting.

The activity logging is the part I'd underline, because you logged the right thing: not just output, but decisions, prompts, reasoning. Output tells you what changed. The reasoning tells you why, and the why is what you actually need when you come back cold, because reconstructing intent from a diff is the expensive part. Most people log the cheap half.

Your pending-approval queue is the piece I'd push furthest on, because it's where per-agent notifications stop scaling and orchestration begins. One inbox of all open requests across every agent is the difference between N notification streams and one control surface, and it's exactly right that the answer to more agents is better orchestration, not fewer agents.

To your question: consistent state-change pings (done/blocked/needs-input) with a payload that carries the why, plus that unified approval queue, is basically the setup, we're building the detection and the cross-tool inbox as the core. Genuine one back, since your queue is further along than most: when a request sits in the pending queue, do you order it by anything, urgency, how long it's been waiting, risk of the action, or is it just chronological? Because that prioritization is the thing I keep chewing on, a queue that treats "approve a file write" the same as "approve a prod migration" loses the plot fast, and I'm curious whether you've hit that yet.

@olli_paloviita 

This is a genuinely well-tuned setup, and the part I respect most is that you optimized for the thing most people sacrifice first: "I never interrupt my thinking based on agent timeline." You built the whole workflow around protecting your focus rather than the agents' idle time, which is the right priority for a solo dev. The worktree-per-task plus tab rotation plus modular repo is a coherent system, each piece is solving a real failure (collisions, merge hell, focus fragmentation), and it clearly holds at 6-7 agents, which most people can't say.

But look at your own three "bad" points, because they're not really three problems, they're one problem wearing three hats: you are the scheduler. Maximum context switching, agents waiting while you guide the other five, hard-to-review output, all of it traces back to you being the single serial resource that every agent has to queue behind. The rotation is you hand-executing round-robin, and a human round-robin has a hard ceiling: throughput is capped by how fast you can cycle, and every agent that finishes or blocks while you're on a different tab is idle until your rotation comes back to it. Your system scales the agents beautifully and doesn't scale you, which is why the pain shows up as your context-switching cost.

The interesting bit is that your "I skip if it's ongoing, clear if it's done" check is already a state-poll, you're manually reading done-vs-running every rotation. That's the exact signal worth pushing to you instead of polling for. If "done" and "blocked" tapped you rather than you tabbing through to discover them, the rotation stops being mandatory and becomes on-demand: you only visit the tab that actually needs you, which collapses the context-switching from "cycle all 7 every loop" to "handle the one that pinged." Same setup, minus you being the polling loop.

Your hardest "bad," though, is the review one, and it's the deepest: reviewing output across 6-7 worktrees is hard because the diffs are scattered and you're reconstructing what each agent did from cold context every time you land on its tab. That's the reload tax, and it's separate from the notification problem. A ping tells you when to look; it doesn't make the looking fast. The thing that'd actually help there is each agent handing you a tight what-changed summary at finish, so landing on a done tab is a ten-second scan instead of re-deriving the session.

Congrats on the ScreenCI launch today, by the way. Genuine question, since you've run this longer than most: when an agent finishes and you're deep in guiding another, do you lose more time to the switch itself, or to reloading what the finished agent was even doing when you get to it? Because those point at different fixes, and your setup is the best real-world test I've seen of which one actually dominates.