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.
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.
Runtime
@maria_galindo2 @peter_barron glad to hear you've liked it Peter. Let me know how I can be of help!
Insane product!! And insane ability to cook 🔥
Sow questions:
How does it work for deploying across multiple repos? (Modular / micro service architecture vs monolith)
And across multiple products? (Can we connect it to notion where we keep all the specs?)
Runtime
@fredo Yes, you can create a template with multiple repos and set up multiple ports for microservices.
And you can also connect to Notion via API / CLI / MCP.
Runtime
@fredo works for modular and monolith repos! And there are a bunch of integrations already built in. Which integrations would you use more? We are thinking to add pre-defined ones. Notion works!!!
Sandboxing agents is the right call - giving an agent full system access is a liability. Does it work for solo devs or is it built around team workflows with permissions and roles?
Runtime
@imad_elkhafi most value is for teams, but you can def use us as a solo dev!
Runtime
@imad_elkhafi Works for solo devs too because it helps you keep your best practices and integrations in one place! Definitely more fun and useful in teams!
@manuel_angel Good to know it works solo too, keeping best practices in one place is exactly the kind of thing that slips when you're the only one on the project. Will check it out.
Runtime
@imad_elkhafi Agreed! Would love that you test it out and let me know your thoughts! Even if going solo!
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.
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.
Runtime
@tonyspiro sandboxes are durable, so state is persisted via snapshots. You can also pause and resume them so the state of whatever the agent was doing stays persisted. But a good way to persist context between teams is by having the agent store its memory in markdown. Teams then can version the memory via PRs.
Nice, congrats on the launch Gus!
The on-call inspector got me. Curious on how you think about trust as this scales. Once non-engineers are shipping real changes from Slack, what makes a team comfortable letting the agent run without someone reviewing every step?
Runtime
@josevchh good question! The idea is that there should still be some sort of review process. Most teams usually review the output of the agent at the session or the PR level.
Runtime
Thanks@josevchh ! Trust is really the core challenge here. Our approach is incremental. You don't let the agent ship complex changes on day one. You start with low-risk, well-scoped tasks and let the team build confidence in the output over time. The key insight is that the problem isn't really about the agent, it's about helping human reviewers know where to focus. As complexity grows, the guardrails and context around the agent's actions make it easier to audit, not harder. The engineer still has final say and Runtime is about making that review faster and more targeted, not removing it.
The "one agent expert whose setup nobody can reuse" is the most accurate description of where most eng teams are right now. Curious how you handle agent quality drift, when Claude or Codex updates under the hood, a packaged agent that worked last month starts producing different output. Is that the customer's problem to detect or does Runtime surface regression signals?
Runtime
@harshalvc_ai Really sharp question. The agent's behavior is tied to the packaged skills, instructions, and guardrails you define in Runtime so when the underlying model updates, you can detect drift through Runtime's observability layer (session traces, tool call logs). It surfaces regressions rather than silently shipping different output. It's not fully automated regression testing yet, but visibility is there!