Most AI browsers hide what the agent is doing. I wanted to see it happen live, and run it locally. So I built one.

Live visibility is a control only while somebody is watching, and the runs that hurt are the ones you walked away from.

The question I'd care about is what the replay gives you an hour later: can you point at the step that went wrong and see the page state the model was looking at when it decided? Recordings usually keep the clicks and drop what the model actually believed, which is the half that tells you whether the next run is safe.

Does Pickle store the page context fed to the model per step, or just the actions?

From a distribution perspective, I'm wondering if publishing it as a chrome extension would be better?

Everyone's converging on "gate the irreversible actions" — right call, but for browser agents that's mostly about data (deleted files, submitted forms, spent money). The trickiest irreversible actions for an agent acting on your behalf aren't destructive at all — they're social. A sent message or a submitted contact form can't be pulled back, but nothing was deleted and no money moved. There's no recovery path the way there is for a bad rsync — the damage is entirely in what another person now believes, and there's no undo for that.

Which makes the gating question harder than "pause before delete/pay/send," because the risk isn't computable from the action type alone. "Email a follow-up to this lead" and "email this specific person" can be the same action type with wildly different stakes, and the agent has no way to tell which one it's looking at from category alone.

Is Pickle's approval gate purely action-type-based (send/pay/delete always pause), or are you finding you need some notion of per-instance stakes, not just per-category?

Everyone here is converging on "gate the irreversible actions" — which is right, but I'd push on what counts as irreversible, because for browser agents that's mostly about data (deleted files, submitted forms, spent money). For the phone-agent version of this problem I'm working on, the trickiest irreversible actions aren't destructive at all — they're social. A sent text or a placed call can't be undone, but nothing was deleted and no money moved. There's no "recovery" path the way there is for a bad rsync — the damage is entirely in what another person now believes, and there's no technical undo for that.

Which makes the gating question harder than "pause before delete/pay/send," because the risk isn't computable from the action type alone — "send text to mom" and "send text to my ex" are the same action with wildly different stakes, and the agent has no way to know which one it's looking at without something closer to judgment than a permission list.

Curious if Pickle's approval gate is action-type-based (send/pay/delete always pause) or if you're finding you need some notion of stakes per instance, not just per category?

GregoryScottHenson's framing is the right one — reversibility, not visibility — and I have a concrete example of why the distinction matters.

Earlier this year I ran a deployment script using rsync with --delete. Script completed, exit 0, output looked like a normal deploy. What I didn't realize: my source path had a trailing slash, which changed how rsync scoped the target. It deleted everything in the deployment directory that wasn't in the source tree — .env.local, five .bak backup files, a week of generated content I'd been storing in the same folder.

I was watching the terminal. The damage happened in 200ms.

The old node process kept running (I'd used --exclude .next, so build artifacts survived), site stayed up, checkout worked. I found out an hour later when I went to check something. The "observation" I had — watching terminal output in real time — gave me zero ability to intervene.

The moment that would have mattered was before --delete ran. Not during. A prompt saying "this will permanently remove 47 files from your production target" would have changed the outcome. A live feed of the rsync output wouldn't have.

That's the distinction I'd want Pickle to be explicit about: is "step in anytime" a pause gate before irreversible operations, or is it a continuous stream where stopping is entirely on the user to catch? For fast operations, the first is a safety feature. The second is mostly theater.

Visibility would help, but for real tasks I’d need more than a live view. The agent should begin with narrowly scoped permissions, show its intended steps before acting, and pause for approval before sending messages, making purchases, deleting data, or submitting forms.

An activity log, a clear stop button, and limits such as allowed domains and maximum spend would make the trust model much stronger. Running locally helps with privacy, but it doesn’t by itself prevent a bad action. Does Pickle currently support per-action approval rules, or is intervention mainly manual while watching the session?

The strongest wedge may be what happens after an agent fails, not only showing the actions while it runs. For each session, I’d keep a replayable artifact: the page state before an action, the model’s intent, the tool call, the result, and any user intervention. That lets you measure time-to-diagnosis and replay a fixed workflow without touching a live site again. Live visibility helps the first run; replayability turns a strange failure into a regression test and gives a solo builder leverage. I’d also measure the 32x token claim as completed task per token and recovery quality, not compression alone. How are you storing run traces so a failure can be reproduced locally?

I would make trust measurable with an autonomy ladder. Start each workflow in shadow mode, then show five successful replays, intervention rate, risky actions prevented, and recovery time before asking the user to grant unattended execution. Different task classes should earn different permissions instead of treating trust as one global switch. The paid value becomes fewer supervised tasks without increasing the blast radius, which is a business outcome you can demonstrate rather than a general promise of visibility.

This is a really interesting approach because I think trust is one of the biggest blockers for AI agents right now. A lot of people are comfortable letting AI suggest things, but giving it full control to click, purchase, or submit forms feels like a much bigger step.
I’m curious — are you planning to add features like action approval checkpoints (for example, requiring confirmation before purchases or sending messages), or do you see visibility alone being enough for users to trust agents?

Watching is supervision, not trust, and supervision does not scale: if I have to sit there, the agent has not saved me anything. What earns trust is a bounded blast radius, a written list of actions it can take unattended, a hard stop on anything that spends money or sends a message, and a log I can hand to an auditor. The local model option is a bigger wedge than the live view, because every regulated buyer I deal with has a policy problem, not a visibility problem.

The observability problem in agent systems is genuinely underrated — most solutions are either a transcript after the fact (tells you what happened but not in time to matter) or a constant attention tax where you're watching every click in real time. Both miss the point.

The right frame is probably reversibility, not visibility. Watching every action doesn't reduce risk if you can't undo what just happened. The moment that matters is the pause before an irreversible step — a purchase, a form submission, a sent message.

What does "step in anytime" actually look like in Pickle at that decision boundary? Is there a pause-before-irreversible mode, or is it a continuous live feed where stopping the agent is entirely on the user to catch in time?

Also — the 32x token reduction feels buried as a side effect. For enterprise or high-frequency use cases where token cost is a real line item, that might be the leading hook rather than the transparency angle. Depends on who shows up first.

That’s a really smart angle — most agent tools feel like a black box, so watching the steps unfold locally builds trust and makes debugging way easier. I’ve seen teams burn hours on “why did it do that” with cloud-only setups. We’re actually exploring a similar niche for dev workflows, where transparency is non-negotiable. What’s your biggest friction point so far — model speed or UI complexity?

Once an agent can click and submit, a black box session stops being a convenience and becomes a liability you find after the damage. Local execution with live step streaming is the bar for anything past a demo. If you can pause on the action that spends money or changes account state before it lands, that is the control surface people will pay for, not another chat wrapper.

The black box issue with cloud agents is so frustrating. There's nothing worse than waiting two minutes for a task to finish, only to realize the agent got stuck on a cookie banner on step one haha. Watching it perform DOM actions live feels way more like pair-programming with a virtual assistant. Smart move putting this out early for feedback.

Showing the agent's steps live is the right call — the trust problem with agent browsers is that you only find out something went wrong after it's already submitted a form. Two things I'd prioritize before more features: an undo/confirm gate on irreversible actions (payments, sends, deletes), and a visible log you can copy out when the run goes sideways, since that's what people paste into bug reports. Shipping desktop/local software as a solo dev also means distribution is your real bottleneck, not the model — worth planning that early.

This resonates a lot with something I've been thinking about. Transparency into what an agent is actually doing step-by-step feels like it matters even more than the final output being correct, especially once agents start taking real actions instead of just generating text. Curious whether you're logging the full decision trace anywhere, or is it purely a live view that disappears after the session ends?

Trust needs more than visibility. I would give users a simple permission ladder: observe, suggest, execute reversible actions, and require approval for irreversible actions such as sending, paying, deleting, or changing an account. Pair that with a receipt showing inputs, actions, and outcomes. The local-first approach is compelling, but clear boundaries are what make people comfortable delegating real work.

What stands out to me is the visibility aspect. I think the biggest barrier to wider agent adoption isn't necessarily capability, but trust; especially when an agent can take actions that are difficult to reverse.

Being able to watch the agent work and step in before a risky action could make a big difference. I'd be interested to see how you handle permissions for things like purchases, account changes, or submitting forms. A clear “approval required” layer could be just as important as the visual interface itself.

Visibility gets you the demo; it doesn't get you the daily. Watching costs attention linearly — the first week you watch every step, and the moment the agent is actually useful you stop, which is exactly when you'd want to be looking. What made me comfortable handing over real tasks was auditable after-the-fact receipts (what it called, with what arguments, what came back) plus a hard gate on the irreversible subset: send, pay, delete. Everything else runs unattended. Live view is for debugging, receipts are for trust.

One thing worth designing while it's still cheap: a local browser on the user's real profile inherits every session cookie they have, so your page representation is the sharp edge. If a snapshot fires right after a login form is filled, the password field's value lands in the model's context verbatim. Mask on serialization, not on render.

On the 32x — is that measured against raw DOM or against screenshots? And does it hold once the conversation is long, or is the page the small half of the bill by step 20?

The “watch it happen” part is a clear contrast with agents that operate out of sight. Curious which part people react to most when they see Pickle in action.