# Why Ren? import ComparisonTable from "@docs/ComparisonTable.astro" ## The problem Every company that wants to put AI agents to work hits the same wall. A coding agent in your terminal is impressive. It reads files, writes code, runs tests. But the moment you need that agent to operate as a real member of your team, a cascade of infrastructure problems appears: - **Where does it run?** An agent that modifies production code needs a real machine with real compute, not your laptop. - **How does it authenticate?** It needs API keys, cloud credentials, database access, and those secrets can't live in a chat window. - **How does it talk to your tools?** Slack, GitHub, your CI pipeline, your browser. Each integration is bespoke glue code. - **How do you watch it?** When an agent runs for hours, you need to know what it did, why, and whether it went off the rails. - **How do you scale it?** One agent is a prototype. Ten agents coordinating across a codebase is an engineering problem. Most teams solve these problems with duct tape: a Docker container here, a `.env` file there, a cron job, a Slack webhook. It works for a demo. It falls apart in production. ## What Ren is Ren is a **managed agent deployment platform**. It runs coding agents (powered by [opencode](https://opencode.ai)) inside managed sandboxes and gives them everything they need to operate as reliable, observable members of your engineering organization. Instead of stitching together infrastructure yourself, Ren provides: - **Managed sandbox compute**: [Pods](/docs/deep-dives/concepts/compute/pods/) provision isolated environments with real CPUs, memory, and filesystems. Agents run on dedicated infrastructure, not on someone's laptop. - **Multiplayer sessions**: [Sessions](/docs/deep-dives/concepts/agents/sessions/) let humans and agents collaborate in the same session at the same time. Watch an agent work, jump in to correct course, hand off again. - **Vault and credential management**: A [Vault](/docs/deep-dives/concepts/stores/vault/) stores encrypted secrets and injects them into agents at runtime. No `.env` files, no leaked keys in chat logs. - **Native integrations**: Slack, GitHub, browser automation, and more are first-class. Agents don't need custom glue code to interact with your existing tools. - **Scheduling and webhooks**: Agents can run on cron schedules, react to webhook events, or be invoked on demand. Long-running tasks stay alive for hours or days. - **Multi-agent coordination**: [Agents](/docs/deep-dives/concepts/agents/agents/) can be composed into societies where specialist agents hand off work to each other, each with its own skills and permissions. - **Org-level skill and MCP registry**: Skills and MCP servers are shared across your organization, versioned, and scoped. No copy-pasting prompts between team members. - **Session replays**: Every agent action is recorded. Replay a session to audit decisions, debug failures, or onboard new team members. - **Model-agnostic**: Swap the underlying model without rearchitecting. Ren's agent runtime is decoupled from any single LLM provider. ## What Ren is not Ren is opinionated about what it is not, because the boundaries matter: - **Not a chat wrapper.** Ren doesn't put a thin UI over an API call. Agents run in full sandboxed environments with real tooling and real state. - **Not a no-code workflow builder.** There's no visual drag-and-drop canvas. Agents are configured through code, skills, and MCPs: the same primitives your engineers already use. - **Not a single-agent chatbot.** Ren is built for multi-agent systems from the ground up. If you need one agent in one chat window, simpler tools exist. ## How Ren compares to the status quo Choosing an agent platform means understanding what each one actually gives you, and where the seams show. Most "AI agent" products solve a narrow slice of the problem. Here's how Ren stacks up against common alternatives, feature by feature. ### When each platform makes sense **Ren** is built for teams that need to run agents as reliable infrastructure, not as one-off chat sessions. If you're deploying agents that touch production code, manage secrets, coordinate across multiple systems, or need to run unattended for hours, Ren provides the full stack: managed compute, credential vaults, multi-agent coordination, and session observability. The trade-off is commitment. Ren is an opinionated platform. If you need a single agent for ad-hoc tasks and don't care about organizational scale, a simpler tool may be faster to start with. **Claude Managed Agents** offers real managed sandboxes and long-running task execution. It's a strong choice if your team already lives in the Anthropic ecosystem and only needs Claude models. It's Claude-only, lacks native third-party integrations and an org-level registry, and doesn't support multiplayer sessions. **ChatGPT Workspace Agents** brings scheduling and Slack deployment to OpenAI's agent offering. Agents run on GPT models only, sandbox infrastructure is partial, and there's no multi-agent coordination, session replays, or org-level registry. **Manus** excels as an autonomous agent for ad-hoc tasks, with real managed sandboxes and long-running work. It stops at organizational infrastructure: no vault, no native integrations, no scheduling/webhooks, no org-level registry. **Viktor** shines as a Slack-native task assistant with a massive integration catalog (3,000+). But it's a task assistant, not an agent deployment platform: no managed sandboxes, vault, scheduling, multi-agent coordination, replays, or registry. ### The pattern The consistent distinction is between **agent tools** and **agent infrastructure**. Manus and Viktor are capable agent tools. Claude Managed Agents and ChatGPT Workspace Agents add some infrastructure within ecosystem boundaries. Ren is agent infrastructure: the compute, secrets, coordination, observability, and sharing layer that turns individual agents into a reliable organizational capability. ## The ambition: L5 autonomous companies Ren's design is shaped by a longer-term thesis. Today's AI agents operate at roughly L3 autonomy. They handle well-scoped tasks with human oversight. The trajectory points toward L5: **autonomous companies** where humans set intent and review outcomes, and agents handle entire operational domains. Getting from L3 to L5 isn't a model problem. It's an infrastructure problem. An L5 agent needs: - **Reliable compute** that doesn't disappear when someone closes their laptop. - **Safe credential access** that doesn't require a human to paste keys. - **Coordination primitives** so multiple agents don't step on each other. - **Observability** so humans can audit, correct, and trust what agents did. - **Persistence** so an agent can pick up where it left off after a failure. Ren builds these primitives now, not because every team needs L5 today, but because the infrastructure you adopt at L3 determines whether you can reach L5 at all. A chat wrapper won't scale into an autonomous system. A managed platform will.