The pitch lands for me, but the bottleneck on my team has never been sandboxing, it's been getting PMs and ops folks to write a good enough spec that the agent doesn't ship something subtly wrong. Curious whether you've seen non-engineers actually merge code through this, or if in practice it's still engineers using it 90% of the time.

Sandboxing per client is the real selling point for me. I run agents across four codebases right now and the mental overhead of making sure credentials and context don't bleed between them is the part that actually slows me down, not the agent quality. Does each sandbox get its own secrets scope, or is it shared at the workspace level?

We piloted something similar with about 40 non-engineer PMs and the sandbox part was easy, the hard part was wiring it into our actual repos with the right secrets scopes and review gates. Curious how you handle the case where a PM's agent opens a PR that touches code owned by a team that has no idea who they are.

We tried giving non-engineers sandboxed agents on our 12-person team and the bottleneck wasn't the sandbox, it was code review. PRs from PMs and designers piled up because engineers had no context on what was being attempted or why. How are you handling the review side, or is the assumption that most output stays in throwaway branches?

Curious whether the sandboxing extends to data isolation between users, not just code execution. I have 28 students sharing a class workspace and the failure mode I worry about is one kid's prompt leaking into another's session, which has already happened twice this year with a different tool.

Six months into my first dev job and half my standups are now "what did the agents do overnight." Genuinely unsure if I should be drilling fundamentals harder or getting fluent at orchestrating these things, because seniors on my team seem split. How are folks at companies using this stuff thinking about ramp for new hires?

We rolled our own sandboxed agent setup (firecracker + per-branch worktrees) and the hardest part wasn't isolation, it was making the artifacts legible to non-engineers on the team. Curious how Runtime handles handoff when a PM kicks off a run and an eng needs to take over halfway through, that's where our internal version still falls apart.

Curious how you handle state that lives outside the sandbox, like staging DB credentials or internal package registries. Every "sandboxed agent" product I've tried ends up with a long tail of "but our agents need access to X" exceptions that erode the isolation story within a quarter.

Our PMs already ship half-broken Figma plugins they vibe-coded over a weekend, and now they want a sandbox so they can do it without bugging eng. Curious how you handle the handoff when something they prototyped actually needs to land in the real codebase, because in my experience that's where the wheels come off.

We gave non-engineers on my 14-person support team access to sandboxed agents last quarter and the bottleneck wasn't the sandbox, it was getting them to write specs precise enough that the agent's output was reviewable. How are you handling the review loop for people who can't read the diff?