Dorothy + Ravi
Dorothy + Ravi
Dorothy is a polished Electron desktop app for running Claude Code, Codex, and Gemini agents in parallel. It ships with a Super Agent meta-orchestrator, PTY-isolated agent sessions, GitHub and JIRA automation pipelines, a Kanban board with auto-assignment, cron scheduling, Telegram and Slack remote control, a shared Vault backed by SQLite full-text search, and a skills marketplace. The architecture is built around five MCP servers — orchestrator, telegram, kanban, vault, and socialdata — exposing 40+ tools.
What Dorothy doesn’t have is credential or identity management. API keys live in JSON config files. Bot tokens sit in ~/.dorothy/app-settings.json. At ten or more parallel agents, that’s not a configuration quirk — it’s a liability. Every agent shares the same credential surface, and there’s no audit trail for who used what.
Ravi closes that gap cleanly, as Dorothy’s 6th MCP server.
The Problem
Dorothy is well-designed for orchestration. But the moment agents do real work in the world — registering for services, sending emails, calling APIs that log requester identity — the shared-credential model breaks down:
- No isolation between agents. Ten parallel agents share the same API keys. One rate-limit event or leaked token affects the entire fleet.
- Bot tokens in config files.
TELEGRAM_BOT_TOKENand similar secrets are stored in plaintext on disk, passed around as environment variables, and accessible to every process on the machine. - Blocked autonomous loops. Agents building sign-up flows, email verification steps, or SMS OTPs have no clean path without human intervention to provide credentials or handle inbox access.
- The Super Agent has no identity. Dorothy’s Super Agent is designed to be an autonomous operator. But it has no real-world contact point — no email, no phone — that could survive outside the local machine.
What Ravi Adds
Ravi as the 6th MCP server
Dorothy’s MCP pattern is proven and extensible. Registering Ravi as a sixth server gives every agent in your fleet direct access to ravi_email_compose, ravi_sms_send, ravi_passwords_get, ravi_secrets_get, and the full Ravi identity toolkit — without touching a config file.
An agent doing a GitHub PR review can email the relevant stakeholder when it needs a human decision. An agent signing up for an external service can complete the verification loop autonomously: provision identity → fill form → receive email → extract OTP → continue. Zero manual credential handling.
A real identity for the Super Agent
Dorothy’s Super Agent is an autonomous operator that coordinates the fleet, assigns tasks, and manages pipelines. Give it a Ravi identity — a real email address and phone number — and it becomes a first-class entity with a real-world contact point, not just a process with a Telegram token in a config file.
Other agents, external services, and humans can reach the Super Agent through its Ravi identity. That’s what accountable autonomous operation actually looks like.
Per-agent credential isolation
Dorothy currently gives all agents the same credential context. Ravi’s secrets store can gate access per agent, so agent-pr-review uses different keys from agent-onboarding-flow — each scoped, each auditable, each independently revocable.
After a run, you can trace exactly which agent used which credentials and what happened. That’s the difference between a fleet you can debug and one you can only restart.
Autonomous verification loops
Dorothy agents that need to register for external services currently block or require human intervention. With Ravi, an agent can provision a fresh identity, complete the sign-up, receive the verification email, extract the confirmation link, and continue — fully without breaking the automation loop.
Setup
Install and register the Ravi MCP server
Install the Ravi MCP package:
npm install -g @ravi/mcp-server
Register it in Dorothy by adding it to ~/.claude/settings.json (the shared MCP config Dorothy reads at launch):
{
"mcpServers": {
"ravi": {
"command": "ravi-mcp-server",
"args": [],
"env": {
"RAVI_API_KEY": "${RAVI_API_KEY}"
}
}
}
}
Set RAVI_API_KEY in your environment or in Dorothy’s app settings. Every agent session Dorothy spawns will now have Ravi tools available alongside the existing MCP toolkit.
Bootstrap the Super Agent with a Ravi identity
Create a dedicated identity for your Dorothy Super Agent:
ravi identity create "Dorothy Super Agent" --email dorothy-super
This provisions:
- A real email address (e.g.,
dorothy-super@yourdomain.ravi.app) - A phone number for SMS
- An encrypted secrets store scoped to this identity
Reference the identity in Dorothy’s Super Agent config so it signs outbound communications and receives replies under this identity rather than the machine user.
Store bot tokens and API keys in Ravi
Move secrets out of ~/.dorothy/app-settings.json and into Ravi’s encrypted store:
ravi secrets set TELEGRAM_BOT_TOKEN "your-token-here"
ravi secrets set GITHUB_TOKEN "ghp_..."
ravi secrets set OPENAI_API_KEY "sk-..."
Dorothy agents retrieve them at runtime via the Ravi MCP:
ravi_secrets_get("TELEGRAM_BOT_TOKEN")
No secrets on disk. No plaintext in config files. Each retrieval is logged.
Concrete Example: Autonomous Onboarding Agent
Dorothy’s strength is automation pipelines. Here’s what a Ravi-backed onboarding agent looks like end to end:
- Dorothy dispatches the task to a new agent: “Sign up for Sentry and configure error tracking for the project.”
- The agent calls
ravi_identity_createto provision a fresh identity for this task — isolated email, isolated phone. - The agent navigates to Sentry’s sign-up, fills the form using the Ravi email address.
- Sentry sends a verification email. The agent calls
ravi_inbox_emailandravi_read_emailto retrieve it, extracts the confirmation link, and follows it. - The agent stores the Sentry credentials via
ravi_passwords_create— domain, username, generated password — encrypted in Ravi’s vault. - The agent pulls the credentials back via
ravi_passwords_getto configure the project’s.env. - Dorothy’s Kanban marks the task complete. The entire loop ran without human input.
The same pattern works for any service that uses email or SMS verification. Dorothy provides the task dispatch and pipeline; Ravi provides the identity infrastructure that makes autonomous completion possible.
Why This Matters
Dorothy’s five existing MCP servers give agents tools to act. Ravi as the sixth gives them credentials to act as someone — an accountable entity with a real-world identity, not just a process with file system access.
That distinction matters more as fleets grow. A single agent acting with no identity is a script. Ten agents acting with shared identity is a liability. Ten agents each acting with their own scoped, auditable Ravi identity is what production-grade autonomous infrastructure looks like.
Dorothy already has the orchestration layer. Adding Ravi completes it.