Launched this week
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 keep shipping Gus! 🚀🚀🚀
Runtime
@johannes_dancker thanks johannes!
@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."
Runtime
@artem_fedorovich thanks! I like the idea of change-window enforcer. Sounds like something you can enforce with our API and create business logic for that!
Good question, so Oauth tokens allow us to do IAM to track who's triggering the agent. Even when using an org-scoped key, team members will still need to log-in individually some way or another and that let's us get full audit trail.
@gustavo_trigos Makes sense, per user login + IAM gives you the clean audit trail. That's the right tradeoff over org scoped service accounts where you lose attribution.
Good luck with the rest of the launch day. Will be following Runtime, this is the layer most teams reinvent badly 🤝
@gustavo_trigos excited to give this a try! we def need it
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?
Runtime
@retain_dev thanks! environments are persistent from the template / snapshot that you created. They auto-pause and auto-resume but the idea is to have them be durable. Cold start ranges but it can go from subsecond to a couple of seconds depending on the size of the image / environment.
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?
Runtime
@anand_thakkar1 thanks anand, every run is ephemeral, but we snapshot your environment so you can have virtually infinite replicas of it. State gets persisted with snapshots or by auto-pausing / auto-resuming the sandboxes.
For secrets, you can use a secrets manager of your choice, or store credentials in our encrypted vault. We created a proxy that encrypts secrets to avoid giving them to the coding agents.
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!
Runtime
@andrewb23 thanks Andrew! the agents are coding agents under the hood (Claude Code / Codex, etc). They are pretty good at search and tool use already so we didn't find any use for vector dbs or indexing codebases. Sandboxes and communicate with other sandboxes via our API. You'd spin up a sandbox that has access to our API, and the coding agent can call the other Sandboxes as long as it has permissions to do so.
Let me know if I can be of help. Happy to jump on a call! https://cal.com/gustavo-trigos-q80bop/runtime-demo-meeting
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.
Runtime
Thanks @akshaypal_bishnoi. So the on-call agent specifics are totally up to you. Runtime gives you an agent harness in a sandbox with your integrations pre-wired, so you define the orchestration. What we've seen work best for incident-style agents is fanning out to PagerDuty, Sentry, and the repo in parallel with independent timeouts per integration, then a synthesis step once results are in. Sequential chains tend to be too brittle when third-party APIs get flaky at 2am.
The sandboxing, spend caps, and audit logs apply however you wire it, so one integration going sideways stays contained. Full trace visibility per session too, no guessing what happened.
The ephemeral sandbox handles execution isolation cleanly, but what happens to data that flows through the agent to external services it calls during a task? If a non-engineer asks the agent to "query the customers table and post a summary to Slack," the sandbox is destroyed after, but the data already left to Slack. Is Runtime enforcing data-path policies at the integration layer, or is the security boundary scoped to the execution environment itself?
Runtime
@binu_george with Runtime, you can enforce data-path policies beyond the sandbox. Org admins configure network egress allowlists and command-level gating so unauthorized destinations are unreachable and unapproved commands are blocked before execution. These controls govern where data can go, not what is sent (no payload-level DLP), and are org-scoped/opt-in.
The support trigger + finance agent combo made me think immediately about a gap we have in product: a lot of our prioritization decisions still depend on analysts pulling data manually from multiple sources before we can even have the conversation. Would love to know if teams are using Runtime to automate that kind of pre-decision data prep — pulling usage metrics, transaction trends, support tickets, user experience research data, etc. so all teams go into backlog sessions with context already synthesized.
Runtime
@aidymdz great question and yes! What I love most about Runtime is that you can have an agent connected to different integrations like your Bigquery database, your customer support tickets, and your Datadog logs and your customer economics. Context will be much more synthesized by the agent! What integrations are you using nowadays that would be useful to build?
@manuel_angel Thanks! Mostly Mixpanel for product analytics, Jira for backlog, and a few internal dashboards pulling from BigQuery (and honestly some excels) — that's actually where most of the manual work lives. If an agent could cross-reference feature usage data with support ticket volume and UX researches (ppt / pdf / reports) before a prioritization session, that alone would save us hours every sprint. Definitely going to try it.