Launching today
Runtime
Sandboxed coding agents for everyone on your team
387 followers
Sandboxed coding agents for everyone on your team
387 followers
Turn coding agents into teammates anyone can use from Slack, Linear, CLI, API or your browser. Ship features, query data, build dashboards, automate workflows. All within your company's context, skills, integrations, and security guardrails.
Runtime
@gustavo_trigos exciting! This might be exactly what we were looking for at CoGrader!
Runtime
@gilquadrosflores Great to hear! I am DMing you so we can set up some time to help you get started.
@gustavo_trigos Hey Gus, congrats on shipping 👋
Direct answer to your "what would your team build first" question, from someone running a few agents in prod today across Telegram, Discord, and an internal construction ops dashboard:
Mine would be a change-window enforcer. Every coding agent we run hits the same wall — agent decides at 3am that a migration is fine, executes, breaks something nobody notices until morning. Sandboxing + audit logs help post-mortem, but the actual primitive I'd want is "this agent cannot apply any write action against prod between Mon-Fri 09:00-18:00 in [timezone], unless an on-call human signs off in Slack." Half my custom orchestration code is reimplementing exactly that, badly.
Adjacent question: when an agent runs with BYO OAuth tokens, whose scope is enforced — the user who triggered the agent, the user who packaged it, or a service account the team owns? In multi-agent setups this gets weird fast, and the answer determines whether Runtime is "orchestration" or "real enterprise-grade permission infra."
The on-call inspector use case is what got me. An alert fires, the agent traces it back, and there's already a PR with a unit test before anyone even gets paged.. that's a complete autonomous loop, not just autocomplete with extra steps.
I've been building agentic systems myself and added LangSmith tracing specifically because without it you're just guessing what actually happened across tool calls. But that's solo use.. at team scale you also need sandboxing, spend caps, and audit logs all working together, otherwise one agent going off the rails becomes a company-wide incident. Runtime seems to be the layer that actually makes that manageable.
One thing I'm genuinely curious about.. when the on-call agent is pulling from PagerDuty, Sentry, and the repo at the same time, is that running as parallel subagents or a sequential chain? Asking because the failure handling is pretty different between the two, especially if one integration goes slow or flaky right in the middle of an incident.
Isolating each agent's execution environment per team member is the right call. We've dealt with the contamination nightmare where one engineer's agent config bleeds into another's session. The Slack integration is a clean distribution channel. How does the sandbox lifecycle work? Are environments persistent across sessions or spun fresh per request, and what's the typical cold start time?
Sandboxed agent execution with a Slack interface is the right call for getting coding agents to non-engineering teammates without security headaches. At RetainSure we've wanted to give our CS team self-serve data access via agents, but safe isolation has always been the blocker. Are the sandboxes ephemeral per run, or can users persist state across sessions? How do you handle secrets and credentials?
Thats really cool to see, ive also been working on a side project to help at work and I got inspired by ios and the way they sandbox and can agree this helps a lot with permissions and data leakage. Really cool to see others in this realm, i wasn't looking to make a product but rather just something to help with my team at work.
Just curious on the sandbox, do you just spin up some small alpine and run a vectored db on it or the agent lives within this sandbox as well, can sandboxes communicate to other sandboxes? I looked on the website and it might just be me but i didn't find too much info on that. If its proprietary then of course no prob at all as well :) . I work at a crypto company and keeping the data within the sandbox is a priority as employees have different rights and different private keys they can be granted to run automations on etc...
I will give it a try solo and if interesting ill introduce to the team. Inspiring stuff, good luck guys!
Sandboxed coding agents inside Slack is a genuinely good idea for teams — keeps the agent close to where decisions actually happen. My main question is around state: if an agent starts a task in one channel and needs context from another, how does Runtime handle that? Isolation is great until it becomes a silo.
Cosmic
The context/guardrails layer is the challenge here: most teams aren't blocked on the AI quality, they're blocked on trust and auditability. Curious how you're handling state persistence across agent sessions, especially for teams with long-running content or doc workflows.