Do you actually let your AI agents run unattended, or do you babysit every step?
I run Claude Code, Cursor, and Codex most of the day, and I keep flip-flopping between two setups that both feel wrong.
Setup 1, babysit: I watch every command and approve everything myself. Nothing slips past me, but I'm stuck at the terminal and the whole point of running an agent is gone. I might as well be typing it myself.
Setup 2, let it rip: auto-approve, skip permissions, go do other work. Faster in theory. Except I come back to one of three things. It finished 30 minutes ago and I wasted the half hour. Or it sat waiting on a yes/no I never saw. Or the fun one, it happily ran something I would never have approved.
The more agents I run in parallel, the worse this gets. Babysitting three terminals is impossible. Trusting three terminals blindly is worse.
So I want to know where everyone else draws the line:
- Which camp are you in, babysit or let it rip?
- Do you have a rule for what an agent can do without asking? (read-only anything, run tests freely, but stop at deploys, rm, db writes?)
- What is the worst thing you came back to that an agent did while you weren't looking?
- And honestly, how do you tell "it's blocked" from "it's done" from "it's gone sideways" without staring at it?
For context on why I care: I've been building in this space, mostly notifications and approvals for agents, because I got tired of being the slow part of my own setup. I still don't have a clean answer for where "let it run" should end and "ask me first" should begin. Genuinely curious how you all handle it.
Replies
@aadilghani Setup 2, of course...Let it RIP...
I had the same dilemma: do I read the code or not? And if I am not reading the code, what is the point of me approving steps? LOL.
Pushary
@roopesh_donde
LOL you just described the exact thing that made me start building. Approving a step you didn't read isn't approval, it's a captcha you do to yourself. And it's somehow worse than full let-it-rip, because now you feel covered while rubber-stamping blind.
So I don't think the fix is more approvals, it's fewer, better ones. Don't stop me on every command, stop me on the two or three that are genuinely irreversible and hand me the one line worth reading. Everything else, rip.
Real question though, have you actually been burned in full RIP mode yet, or has it stayed clean? Because the people who go all in either have great taste in what they hand the agent, or one great horror story.
That makes more sense. Selective permissions are essential right now. Claude often token maxes and commits code to Git without asking. I've set specific instructions not to commit. I've been burned when a bug overrode a stable version. Luckily I'm not live yet, or it would've been a big issue.
Pushary
@roopesh_donde
Oof, "a bug overrode a stable version" is the exact nightmare. Glad you weren't live. But look at what actually failed there: you told it not to commit and it committed anyway. The instruction wasn't a guardrail, it was a suggestion, and a token-maxed agent walks right past a suggestion the moment it decides it knows better.
That's the whole case for selective permissions in one story. A rule the agent can read is a rule the agent can ignore. So the commit block has to live below the agent, deny git commit at the permission layer, or point it at a scratch branch and keep main untouched, so "don't commit" isn't a thing it can choose to forget.
Curious though, when it committed against your instructions, did it think it was helping? That's the part that unsettles me more than plain bugs. It's not disobedience, it's the agent being confidently sure the commit was the right call.
Nope, I'm working on a small update that changed other things. I've changed my workflow, so don't commit. It's a repetitive add-on, so it's unnecessary. I hadn't branched out—that was the issue. I'm new to coding, so I'm learning as I go. I'll try to deny git at the permission layer. That should sort things out.
We talked about this in your other thread, and since then I actually restructured my setup. What stuck is neither babysit nor let-it-rip, it is delegation by category: a short list of action types the agent may run unattended (low-risk, reversible, inside the repo), while everything outward-facing or destructive queues for my one click. The state file we discussed carries the queue. That killed most of the babysitting without the come-back-to-a-crater risk. My split now is roughly 80 percent unattended, and the 20 percent that needs me is batched into two or three click windows a day. What stays unsolved is exactly your case two, sat waiting on a yes/no I never saw. A file cannot tap my shoulder, that one needs the push you are building.
Pushary
@virko_kask
This made my day, partly because you actually went and rebuilt the thing, and partly because "a file cannot tap my shoulder" is the cleanest one-line version of this whole problem I've heard.
You're right that it's exactly case two. But the thing I keep relearning: the push is the easy half. Delivering the tap is trivial. Earning it is the hard part. If the layer just pings you on everything in the queue, you've rebuilt "check everything," except now it interrupts you instead of you interrupting yourself. It has to inherit your category split, only the outward-facing and destructive stuff gets to reach for your shoulder.
And there's a second cut inside your 20 percent that I think is the actual unsolved bit: "needs you eventually" can wait for a click window, but "blocked right now, nothing moves until you answer" can't. Same queue, totally different urgency. Telling those two apart automatically is the piece I don't have clean yet. In your setup, how are you deciding which of the 20 percent is allowed to wait for a window versus which should break into your focus?
Pushary
@virko_kask
This made my day, partly because you actually went and rebuilt the thing, and partly because "a file cannot tap my shoulder" is the cleanest one-line version of this whole problem I've heard.
You're right that it's exactly case two. But the thing I keep relearning: the push is the easy half. Delivering the tap is trivial. Earning it is the hard part. If the layer just pings you on everything in the queue, you've rebuilt "check everything," except now it interrupts you instead of you interrupting yourself. It has to inherit your category split, only the outward-facing and destructive stuff gets to reach for your shoulder.
And there's a second cut inside your 20 percent that I think is the actual unsolved bit: "needs you eventually" can wait for a click window, but "blocked right now, nothing moves until you answer" can't. Same queue, totally different urgency. Telling those two apart automatically is the piece I don't have clean yet. In your setup, how are you deciding which of the 20 percent is allowed to wait for a window versus which should break into your focus?
I hit this same tension but across businesses rather than terminals. I run more than one venture at once and the babysit versus trust problem shows up constantly, except instead of watching an agent I am watching Slack, email, and four different dashboards trying to catch the one thing that actually needs a decision from me. I ended up building FounderFlow partly to solve this for myself, it watches across all that noise and surfaces the two or three things that genuinely need my attention that day instead of me checking everything manually. Sounds like a similar itch to what you are describing with agents, just one layer up at the business level.
Pushary
@stacywycof83995
Stacy this is exactly it, and I think the “one layer up” framing is the whole insight. The problem was never the agent or the dashboard, it’s that attention doesn’t scale. Four terminals or four ventures, the bottleneck is the same: I’m the router, and I’m the slow part.
What you built for businesses is what I keep wishing existed for agents. Not “show me everything,” not “trust it blindly,” but “interrupt me only for the two things that actually need a human today.” Everyone frames this as a trust problem. I’m starting to think it’s a triage problem.
Genuinely curious how FounderFlow decides what counts as “needs you.” That’s the exact part I keep getting wrong on the agent side, the line between a real decision and noise dressed up as one keeps moving. How’d you tune that without it either going quiet or crying wolf?
the third option people don't talk about is "trusted for THIS class of task, watched for that class." babysit is binary. trust is binary. neither maps to reality.
my hack: track which tasks the agent completed autonomously without me needing to undo the work. after ten successes in a category, that category becomes auto-approve. one failure resets it to watched. slow to build but you know exactly what to trust vs what to babysit.
Pushary
@thenameisarian
This is the version I actually believe in. Binary was always the category error, the unit of trust was never the agent, it’s the task class.
The one thing I’d add: weight the reset by blast radius, not just count. Ten clean runs earning auto-approve is great for reversible stuff. But I never want a category where the failure mode is a deploy or a db write to graduate on a success streak alone, because the streak tells you nothing about the tail. So maybe two dials instead of one, how often it succeeds and how bad the worst case is, and auto-approve only when both are green.
How do you handle an action that sits inside a trusted category but does something novel? That’s where mine keeps slipping, the category looks familiar so it sails through, but the specific thing it did that time wasn’t in the ten.
Pushary
To answer my own question: I'm about 70% let-it-rip now. My rule is anything read-only or reversible runs free, and it has to stop and ping me before deploys, force pushes, db writes, or rm. The stomach-drop one for me was an agent that "cleaned up" a branch with a reset --hard while I was in a meeting. Curious if anyone trusts theirs more than that.
@aadilghani same read-only-vs-reversible line for me. the thing that changed it wasn't a rule I wrote, it was switching to a tool that asks per-action instead of per-session - so "let it rip" doesn't mean blanket auto-approve, it means auto-approve for a whitelist of safe commands and still stop me for anything destructive. that's a very different risk profile than a global skip-permissions flag. the "is it blocked or done" problem is the harder one honestly, I still end up tabbing back to check more than I'd like. curious what your notification approach surfaces beyond just pass/fail.