Launching today
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."
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.
Honest question from a non-dev: what’s a realistic first use case for someone like me — a small business owner who wants to automate workflows but doesn’t code? Would love a concrete example
Runtime
Hi @maria_galindo2 the most successful use case to start with usually depends on where your data lives. Connecting the apps your team already uses like Notion, Granola, Gong, Slack, or Zendesk gives the agent the context it needs, and adding a few instructions via skills about how your business works yields really good results. All triggered from Slack so no coding needed to get started. What tools does your team live in day to day?
@maria_galindo2 Hey I've been building some stuff in runtime. I built a CRM instead of buying one and linked it in to my data sources. I deployed it from runtime and was able to track and drive sales using it. You could also create a dashboard/agent based tool for finding potential customers. As long as you have data sources its real and you can keep using plain text in the UI to improve or add functionality.
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.
Runtime
@ashishbhosle7889 Isolation is by default but you could give the agent access to Slack's CLI or API so it can read other channels or threads.