Runtime

Sandboxed coding agents for everyone on your team

Slack

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product HuntTwitter ⧉

Embedding actual code execution inside Slack is a much bigger deal than it sounds, most "AI in Slack" tools just generate text and call it a day. The sandboxed environment is what makes this viable for teams, since nobody wants an agent touching production. Curious about long-running tasks though; if a test suite takes 8 minutes to run, does Slack handle that without the bot timing out?

the company context and skills layer is the part that differentiates this from just wrapping an API but it's also the part that takes the most setup to be useful. how long does it actually take to get Runtime to the point where it knows enough about your stack, your data schema, your workflows to give useful output rather than generic responses? that onboarding investment is usually what kills team AI tool adoption before it starts

Sandboxed coding agents sound intriguing. How do they handle permission issues when running scripts on a shared server? Seems like a neat way to let everyone experiment safely.

Really like the sandboxed approach here. Giving coding agents isolated environments feels much safer and more scalable for teams than shared setups. Curious how you manage resource limits for long-running agent workflows.

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?

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.

Good job guys, I think it should be clearer how the whole flow works and if at any point you guys have access to our repos and if so how do you manage it, I understand it's sandboxed and you delete the filesystem afterwards but it's not entirely clear if you have access somehow so that made me hesitate to use it

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?

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?

Love that list of integrations! Will forward this to my team

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?)

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?

Used Runtime as soon as it launched and it was super useful to get non-technical folks setup and contribute code to a mature codebase while having the right guardrails in place.

As a small bootstrapped company building a product that has many dependencies and environments, we found that over time, each engineer became very siloed on the part of the stack that they could work on because setting up the right dev environment on another computer took forever.

Runtime solves this issue for us and now every engineer can contribute pretty effortlessly at any part of the stack at a moments notice. Pretty game changing stuff going on here.

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