Nimbalyst + Ravi

What is Nimbalyst?

Nimbalyst (formerly Crystal) is a desktop application for running multiple AI coding agents in parallel. It combines a visual workspace — WYSIWYG editing, Excalidraw diagrams, diff review — with a parallel session manager that lets developers run 3–10 Codex or Claude Code agents simultaneously across isolated git worktrees.

The core workflow: agents work independently on separate feature branches, the human reviews diffs visually on desktop or mobile, approves or rejects changes, and queues follow-up tasks. A companion mobile app sends push notifications when any agent needs attention, lets you swipe-approve diffs, and lets you reply to agent questions by voice — all without touching a terminal.

Nimbalyst is local-first. Sessions, tasks, and files are stored on disk in open formats (Markdown, JSON, CSV), and sessions can be suspended and resumed across days.

The problem: parallel agents need distinct identities

When you run 10 agents in parallel, each agent is doing independent work. Some of that work requires external services — signing up for a staging API, verifying an account, receiving a confirmation email, or accessing environment-specific credentials. Without distinct identities for each session, agents collide: they share inboxes, clobber verification flows, and leak credentials across worktrees.

The naive workarounds (one shared email, one shared .env file for all agents) break immediately at any realistic scale. They also make it impossible to audit which agent did what.

Ravi solves this by giving each agent a real, provisioned identity with its own email address, phone number, and encrypted secrets store.

Where Ravi fits in Nimbalyst workflows

1. Per-agent verified identity during parallel runs

Each Nimbalyst session runs in an isolated git worktree. When those agents need to sign up for external services, verify accounts, or receive confirmation emails, each needs its own distinct contact info.

Ravi’s provisioned email + phone per identity means agent session A and agent session B don’t collide. Each gets its own inbox, its own OTP, its own verification flow — without the human developer having to intervene. The agent handles the full signup loop: trigger the verification email, read it via Ravi, extract the OTP, continue.

2. Mobile approval with identity context

The Nimbalyst mobile app shows “agent needs you.” Ravi makes it possible to say which agent, working as which identity, is requesting approval — important when agents are operating against different environments (staging vs. prod) or different service accounts. The approval notification carries the identity name rather than a generic session ID.

3. Credential vault per worktree session

Parallel agents working on different features often need different API keys — staging credentials for one feature, production read-only keys for another. Ravi’s E2E-encrypted secrets store gives each agent session clean, scoped access to exactly the credentials it needs. No shared .env files between worktrees, no risk of prod keys leaking into dev agents.

Each Ravi identity has its own isolated secrets store. You provision one identity per long-running project context, and that identity holds its own credentials separate from all others.

4. Session continuity via persistent inbox

Nimbalyst lets you suspend and resume agent sessions. Ravi’s persistent email inbox means an agent that triggered a service signup in a previous session still has access to the verification email when that session is resumed days later — the identity and its inbox outlive any individual session. The agent picks up exactly where it left off.

Concrete setup: Ravi + Nimbalyst

Prerequisites

Nimbalyst installed (macOS/Windows/Linux)
Ravi account with provisioned identities

Step 1: Provision a Ravi identity per project context

Create one Ravi identity for each major project or long-running agent context:

# Using the Ravi API or SDK
POST /v1/identities
{
  "name": "feature-auth-agent",
  "email": "feature-auth@yourdomain.ravi.app"
}

Each identity returns a provisioned email, phone number, and an empty secrets store.

Step 2: Load credentials into the identity’s secrets store

Store the credentials this agent context needs:

POST /v1/identities/{identity_id}/secrets
{
  "key": "STRIPE_TEST_KEY",
  "value": "sk_test_..."
}

Step 3: Bind the identity to the Nimbalyst session

In your agent’s system prompt or task instructions, inject the Ravi identity credentials:

You are working in a Nimbalyst session for the payment integration feature.
Your Ravi identity: feature-auth@yourdomain.ravi.app
Use this email for any account signups or verifications.
Retrieve your API credentials from the Ravi secrets store using the SDK.

The agent uses Ravi’s API to read its own inbox, respond to OTPs, and fetch credentials — all scoped to the identity assigned to its session.

Step 4: Handle verifications autonomously

When the agent needs to verify an account:

from ravi import RaviClient

ravi = RaviClient(identity_id="feature-auth-agent")

# Trigger signup with this identity's email
signup(email=ravi.email)

# Poll for the verification email
email = ravi.inbox.wait_for(subject_contains="verify", timeout=60)

# Extract and use the OTP
otp = extract_otp(email.body)
verify_account(otp=otp)

No human intervention. No shared inboxes. The agent handles the full loop.

Step 5: Resume sessions with full continuity

When a Nimbalyst session is resumed, the agent re-initializes with the same Ravi identity. Its inbox still contains the emails from previous sessions. Its secrets store still has its credentials. It can query recent activity and continue where it left off.

Why Ravi is the right identity layer here

Nimbalyst solves the coordination problem for parallel agents: one human, many agents, clean visual review. What it doesn’t provide is external identity for those agents — the credentials and contact info they need to operate against real services in the world.

Ravi provides exactly that. A persistent, verifiable identity with a real email address, a real phone number, and an encrypted credential store — one per agent context, scoped cleanly, auditable, and durable across sessions.

Together, Nimbalyst handles the agent coordination and human review layer. Ravi handles the identity and credential layer. The combination lets you run parallel agents at scale without sharing inboxes, leaking credentials, or requiring human intervention for every verification step.

Discord forum research: crystal → Nimbalyst