DEV Community: Kumar Deepanshu

Durable Email Workflows with Temporal and Lumbox

Kumar Deepanshu — Wed, 03 Jun 2026 18:00:34 +0000

Originally published at lumbox.co

Temporal solves the problem every async workflow eventually hits: what happens if the process dies mid-flow? For email, it's acute — you kick off a signup, the worker crashes, and now you have a Lumbox inbox waiting for an OTP that no one is listening for. Temporal activities make that durable.

The pattern: inbox creation as an activity

import { proxyActivities } from "@temporalio/workflow";
import type * as activities from "./activities";

const { createInbox, submitSignup, waitForOtp, submitOtp } =
  proxyActivities<typeof activities>({
    startToCloseTimeout: "5 minutes",
  });

export async function signupWorkflow(service: string, user: User) {
  const inbox = await createInbox(`signup-${service}`);
  await submitSignup(service, user, inbox.address);
  const otp = await waitForOtp(inbox.id, 120);
  await submitOtp(service, otp);
  return { success: true, address: inbox.address };
}

Long waits are fine

Some verification flows send a link that expires in 24 hours. Temporal can hold a workflow open for days with no resource cost — when the worker comes back, the state picks up. Lumbox inboxes don't expire unless you tell them to, so a workflow that sleeps for a day and then checks the inbox works exactly as expected.

Retries are automatic

If waitForOtp times out, Temporal retries per your activity policy. Lumbox's timeout is server-side — the HTTP call cleanly returns after the timeout window, and Temporal handles the rest. lumbox.co.

Mastra + Lumbox: TypeScript-First Agent Email in 30 Lines

Kumar Deepanshu — Sun, 31 May 2026 18:00:38 +0000

Originally published at lumbox.co

Mastra filled a gap: a genuinely good TypeScript framework for agents. LangChain.js never felt like a first-class citizen; Mastra does. Here's how to bolt Lumbox on in about 30 lines.

Defining email tools

import { createTool } from "@mastra/core";
import { Lumbox } from "lumbox";
import { z } from "zod";

const lumbox = new Lumbox({ apiKey: process.env.LUMBOX_API_KEY! });

export const createInbox = createTool({
  id: "create_inbox",
  description: "Create a fresh email inbox for a specific task.",
  inputSchema: z.object({ purpose: z.string() }),
  execute: async ({ context }) => {
    const inbox = await lumbox.inboxes.create({
      displayName: context.purpose,
    });
    return { inboxId: inbox.id, address: inbox.address };
  },
});

export const waitForOtp = createTool({
  id: "wait_for_otp",
  description: "Block until a verification OTP arrives.",
  inputSchema: z.object({
    inboxId: z.string(),
    timeout: z.number().default(120),
  }),
  execute: async ({ context }) => {
    const result = await lumbox.inboxes.waitForOtp(context.inboxId, {
      timeout: context.timeout,
    });
    return { otp: result.otp };
  },
});

The agent

import { Agent } from "@mastra/core";

export const signupAgent = new Agent({
  name: "signup_agent",
  instructions: "You sign users up for services. Use create_inbox, then wait_for_otp.",
  model: { provider: "anthropic", name: "claude-opus-4-7" },
  tools: { createInbox, waitForOtp },
});

Workflow orchestration

Mastra's workflows give you checkpointed, resumable flows. A signup that stalls at the OTP step can be resumed hours later — Lumbox keeps the inbox alive and the OTP retrievable. lumbox.co.

LlamaIndex + Lumbox: Treat Your Inbox as a Queryable Knowledge Source

Kumar Deepanshu — Thu, 28 May 2026 18:00:43 +0000

Originally published at lumbox.co

LlamaIndex made RAG something you can ship in an afternoon. Load docs into an index, attach an LLM, query. The gap most teams hit isn't the framework — it's finding a good data source. Your agent's own Lumbox inbox is a better source than most.

Why the inbox is good RAG fodder

It's high-signal, low-noise (it's already filtered by being sent to you).
It's structured — sender, date, subject, thread ID are all fields.
It grows organically as the agent does its work.

Wiring it up

from llama_index.core import VectorStoreIndex, Document
from lumbox import Lumbox

lumbox = Lumbox(api_key=os.environ["LUMBOX_API_KEY"])

def load_inbox_as_documents(inbox_id: str) -> list[Document]:
    messages = lumbox.inboxes.list_messages(inbox_id=inbox_id, limit=500)
    return [
        Document(
            text=m.text,
            metadata={
                "from": m.from_address,
                "subject": m.subject,
                "date": m.received_at,
                "thread_id": m.thread_id,
            },
        )
        for m in messages
    ]

docs = load_inbox_as_documents(my_inbox_id)
index = VectorStoreIndex.from_documents(docs)
query_engine = index.as_query_engine()
print(query_engine.query("What did Acme say about the Q3 timeline?"))

Keep it fresh with webhooks

Subscribe to Lumbox's email.received webhook and incrementally upsert new messages into the index. No re-indexing, no polling. lumbox.co.

AX (Agent Experience): What Email APIs Should Look Like for Agents, Not Humans

Kumar Deepanshu — Mon, 25 May 2026 18:00:38 +0000

Originally published at lumbox.co

Resend coined Agent Experience — AX — as the agent-first parallel to DX. The idea: APIs designed for humans reading docs on a Tuesday afternoon look different from APIs designed for LLMs calling tools in a tight loop. For email APIs, the gap is huge.

What bad AX looks like in email APIs

Polling required. Agent burns tokens checking "any new mail?" every 5 seconds.
Raw MIME. Agent has to parse multipart boundaries before it can read the body.
No first-class OTP field. Agent runs regex on HTML to find the code.
Opaque errors. Agent gets "500: internal error" with no recovery guidance.
No idempotency. Agent retries and sends duplicates.

What good AX looks like

Long-poll endpoints. One call, blocks until event or timeout.
Structured extraction. OTP, links, attachments, category — all as first-class JSON fields.
Typed errors. {"error": "timeout", "retryable": true, "wait_ms": 5000}.
Idempotency keys. Every mutating endpoint accepts one.
MCP-native. Tools are discoverable via a manifest, not scraped from HTML docs.
Machine-readable docs. OpenAPI + .well-known/agent-skills + llms.txt.

Lumbox's take

Every Lumbox endpoint was designed with a question: "how would a tool-calling LLM invoke this?" That's why waitForOtp exists instead of a listMessages + filter pattern. It's why responses include otp, links, and category alongside the raw body. It's why we publish an MCP server on day one.

AX isn't a checkbox. It's the shape of the whole API surface. lumbox.co.

Email as Memory for AI Agents

Kumar Deepanshu — Fri, 22 May 2026 18:00:18 +0000

Originally published at lumbox.co

Every agent framework now ships a memory module. Vectors, summaries, reflection loops, graph-based recall. They all miss the simplest and most reliable memory primitive on the internet: the email inbox.

What email gets right as memory

Append-only by default. You don't lose history.
Addressable. Every message has a stable ID and thread ID.
Searchable. Full-text search is built in.
Structured where it matters. Sender, subject, date, attachments — all first-class fields.
Pull model. The agent reads when it needs, not streaming 24/7.
Interoperable. The rest of the world writes to the inbox without you asking.

The agent-memory pattern

Give the agent an inbox. When the agent takes an action, send a record email to itself summarizing what it did. When it needs to recall, query the inbox. Lumbox's API gives you list, search, thread, and filter — the full memory surface.

// agent acts
await lumbox.inboxes.send(self.inbox_id, {
  to: self.address,
  subject: "[memory] signed up for stripe",
  text: "Account created with card ending 4242, verified at 14:22Z",
});

// later, agent recalls
const memories = await lumbox.inboxes.search(self.inbox_id, {
  subject: "[memory]",
  since: "2026-05-01",
});

When it beats a vector store

When you need verbatim recall, temporal ordering, and cross-agent handoffs. Vector stores excel at fuzzy semantic similarity. Inboxes excel at "what did I do last Tuesday and who did I talk to about it."

Hybrid is fine

Use the inbox for durable, addressable, audit-able memory. Use a vector store for similarity search over summaries. They complement each other. lumbox.co.

Pydantic AI + Lumbox: Type-Safe Email Tools for Agents

Kumar Deepanshu — Tue, 19 May 2026 18:00:05 +0000

Originally published at lumbox.co

Pydantic AI leaned into the one thing Python agent frameworks were missing: type safety at the tool boundary. Define a tool as a function with Pydantic-validated inputs and outputs, and the framework handles the LLM-side schema and the runtime-side coercion. It's the right shape for production agents.

Lumbox as Pydantic AI tools

from pydantic_ai import Agent
from pydantic import BaseModel
from lumbox import Lumbox

lumbox = Lumbox(api_key=os.environ["LUMBOX_API_KEY"])

class Inbox(BaseModel):
    inbox_id: str
    address: str

class OtpResult(BaseModel):
    otp: str
    received_at: str

email_agent = Agent(
    "anthropic:claude-opus-4-7",
    system_prompt="You handle email verification for signup flows.",
)

@email_agent.tool_plain
def create_inbox(purpose: str) -> Inbox:
    """Create a fresh inbox for a verification task."""
    inbox = lumbox.inboxes.create(display_name=purpose)
    return Inbox(inbox_id=inbox.id, address=inbox.address)

@email_agent.tool_plain
def wait_for_otp(inbox_id: str, timeout: int = 120) -> OtpResult:
    """Block until an OTP arrives in the inbox."""
    result = lumbox.inboxes.wait_for_otp(inbox_id, timeout=timeout)
    return OtpResult(otp=result.otp, received_at=result.received_at)

Why type-safe tools matter for email

When an agent calls wait_for_otp with a timeout, you don't want a runtime error because the LLM passed "60s" instead of 60. Pydantic coerces at the tool boundary. Same for inbox IDs — Pydantic ensures you always get a well-formed inbox_id, never None.

Error handling

If the OTP wait times out, the tool raises — Pydantic AI surfaces the typed error back to the agent, which can retry or escalate. Cleaner than parsing string error messages out of generic HTTP responses. lumbox.co.

Infraforge vs Lumbox: Deliverability-First vs Agent-Native Email

Kumar Deepanshu — Sat, 16 May 2026 18:01:06 +0000

Originally published at lumbox.co

Infraforge appears on most "best AgentMail alternatives" lists because it targets the deliverability-first segment of email infrastructure. Lumbox targets the AI-agent-first segment. Both valid, different focuses.

Infraforge's shape

Managed outbound email infrastructure — warming pools, IP rotation, reputation management.
Focused on cold outreach, transactional at scale, and B2B email workflows.
Strong on deliverability tooling, domain authentication, and sender analytics.

Lumbox's shape

Agent-native — every agent gets its own inbox.
OTP / magic-link / verification-link extraction built in.
Long-poll endpoints so agents don't waste tokens polling.
MCP server so Claude and Cursor can treat Lumbox as a tool out of the box.
BYOS: bring your own SMTP/domain when you want full deliverability control.

When they overlap

If you're running outbound-heavy agent workflows (cold outreach, mass notification), you need both: Lumbox for agent identity + inbox, and a deliverability layer (either Infraforge, SES with warm IPs, or Lumbox's BYOS mode with your own SMTP). The inbox side and the deliverability side are different problems.

When they don't

If you're running inbound-heavy flows — signups, verifications, agent-to-service interactions — Lumbox is the primitive. Deliverability is not the constraint; per-agent isolation and OTP extraction are. lumbox.co.

Unipile vs Lumbox: Unified Messaging API vs Agent-First Email

Kumar Deepanshu — Wed, 13 May 2026 18:01:12 +0000

Originally published at lumbox.co

Unipile and Lumbox show up together in "best email API for AI agents" listicles, but they're solving different problems. Here's how to tell which you actually need.

What Unipile does

Unipile is a unified communications API. One SDK, many channels — LinkedIn, WhatsApp, Instagram, Telegram, Gmail, Outlook, IMAP. You authenticate your users' accounts, then send and receive on their behalf across channels. Use case: building a multi-channel inbox product where end users connect their own accounts.

What Lumbox does

Lumbox provisions net-new email inboxes for AI agents. Every agent gets a fresh identity — not piggybacking on a user's Gmail, not sharing an account. Plus OTP extraction, long-poll, MCP server, and per-agent isolation. Use case: autonomous agents that need their own email to interact with the web.

Pick Unipile if...

You're building a product where end users connect their own accounts.
You need multi-channel reach (LinkedIn + WhatsApp + email).
You're building on behalf of humans, not agents.

Pick Lumbox if...

Your agent needs its own email identity, not a user's.
You need OTP/verification-link extraction out of the box.
You need long-poll endpoints so agents don't burn tokens polling.
You need per-agent isolation and fast lifecycle (create/destroy in seconds).

Can you use both?

Yes. A common pattern: use Unipile for the human-facing side of your product (LinkedIn DMs, WhatsApp replies) and Lumbox for the autonomous-agent side (signups, verifications, outbound to third-party APIs). Different problems, different tools. lumbox.co.

Give Your Replit Agent a Real Email Inbox with Lumbox

Kumar Deepanshu — Sun, 10 May 2026 18:00:14 +0000

Originally published at lumbox.co

Replit Agent makes a promise that sounds almost too good: describe the app you want, and it'll scaffold the code, deploy it, and wire up the third-party services. The reality is that 80% of those "third-party services" require email verification. If the agent is using your personal Gmail, you're one step away from a ban.

One inbox per agent session

Before the Replit Agent run starts, provision a dedicated inbox:

curl -X POST https://api.lumbox.co/v1/inboxes \
  -H "X-API-Key: $LUMBOX_API_KEY" \
  -d '{"displayName":"replit-session"}'

Expose the inbox address and waitForOtp endpoint as tools in the agent's prompt. Every signup during the session uses the dedicated address, and every OTP arrives at the right inbox.

The "deploy-then-verify" pattern

Replit Agent's strength is end-to-end flows — code, deploy, test. When the deployed app asks the user to verify their email, route it through Lumbox so the agent can confirm deployability before handing off. If verification works, the app ships. If it doesn't, the agent fixes and retries.

Custom domain for the agent identity

For production-y Replit apps, point an MX record at Lumbox and give the agent a custom-domain inbox: hello@myapp.com. The third-party services see a branded sender, and the agent keeps its own identity separate from any human's. lumbox.co.

Give Your Sim Studio Agent an Email with Lumbox

Kumar Deepanshu — Thu, 07 May 2026 18:00:35 +0000

Originally published at lumbox.co

Sim Studio's pitch is speed: build a working agent by dragging blocks instead of writing loops. It works — until your agent needs to sign up for anything. Visual builders are great at orchestrating steps but they can't see past the verification wall without an email primitive.

The Lumbox block

Sim Studio exposes HTTP blocks for any REST API. Lumbox becomes three blocks:

Create inbox → POST https://api.lumbox.co/v1/inboxes → output: inbox_id, address
Wait for OTP → GET https://api.lumbox.co/v1/inboxes/{id}/otp?timeout=120 → output: otp
Send email → POST https://api.lumbox.co/v1/inboxes/{id}/send

A complete signup flow in blocks

Create inbox block at the top of the flow
Feed address into the Browser automation block that submits the signup form
After form submission, call Wait for OTP with the inbox_id
Pipe the returned otp into the next browser block to complete verification

Why this beats shared Gmail in a visual tool

Sim Studio flows are often deployed in parallel — multiple concurrent executions of the same template. Shared Gmail means multiple OTPs collide in one inbox. Lumbox gives each execution its own inbox automatically, with zero collision risk. lumbox.co — grab a key, paste it in Sim Studio, ship.

LangGraph + Lumbox: Email as a State Transition

Kumar Deepanshu — Mon, 04 May 2026 18:01:03 +0000

Originally published at lumbox.co

LangGraph pushed LangChain into a direction many people had been asking for: explicit state, explicit transitions, deterministic control flow. It's a better fit for production agents than a freeform ReAct loop. It's also a perfect fit for modeling email-driven workflows — because "wait for email" is literally a state.

Email workflows as graphs

Consider the most common agent task: sign up for a service, verify the email, complete the flow. Modeled as a graph:

create_inbox → submit_signup → wait_for_otp → submit_otp → done

Each node is a concrete step with inputs and outputs. The edges are deterministic. If OTP times out, transition to retry or fail. This is exactly what LangGraph's StateGraph was built for.

Wiring Lumbox as graph nodes

from langgraph.graph import StateGraph, END
from typing import TypedDict
from lumbox import Lumbox

lumbox = Lumbox(api_key=os.environ["LUMBOX_API_KEY"])

class AgentState(TypedDict):
    inbox_id: str
    address: str
    otp: str | None
    target_url: str

def create_inbox_node(state: AgentState) -> AgentState:
    inbox = lumbox.inboxes.create(display_name="signup")
    return {**state, "inbox_id": inbox.id, "address": inbox.address}

def submit_signup_node(state: AgentState) -> AgentState:
    # browser automation fills form with state["address"]
    return state

def wait_for_otp_node(state: AgentState) -> AgentState:
    result = lumbox.inboxes.wait_for_otp(state["inbox_id"], timeout=120)
    return {**state, "otp": result.otp}

def submit_otp_node(state: AgentState) -> AgentState:
    # browser automation enters state["otp"]
    return state

graph = StateGraph(AgentState)
graph.add_node("create_inbox", create_inbox_node)
graph.add_node("submit_signup", submit_signup_node)
graph.add_node("wait_for_otp", wait_for_otp_node)
graph.add_node("submit_otp", submit_otp_node)
graph.set_entry_point("create_inbox")
graph.add_edge("create_inbox", "submit_signup")
graph.add_edge("submit_signup", "wait_for_otp")
graph.add_edge("wait_for_otp", "submit_otp")
graph.add_edge("submit_otp", END)
app = graph.compile()

Durability

LangGraph's checkpointing plays perfectly with Lumbox — the wait_for_otp node can run, resume, or replay. If your process crashes mid-flow, the state is persisted and picks up where it left off. Lumbox inboxes persist server-side, so the OTP is still retrievable when you come back. lumbox.co.

Email as Identity for AI Agents: The First-Class Primitive

Kumar Deepanshu — Fri, 01 May 2026 18:00:35 +0000

Originally published at lumbox.co

Every major web service treats email as the primary identity. Not your phone number, not your OAuth account, not your crypto wallet — your email. It's the recovery path, the login fallback, the ticket lookup, the receipt address. The web runs on email.

Humans solved this in 1996

A human developer has Gmail. They use it to sign up for hundreds of services over the years. Each service builds a record tied to that address. When the human forgets a password, the service emails them. It works.

Agents are still stuck in 2004

When an AI agent needs to interact with the internet — book a flight, subscribe to an API, claim a free credit — it has no email of its own. Builders force agents to share the developer's Gmail, which immediately breaks scaling (see: our Gmail-bans post), or hard-code an account that belongs to no one in particular.

Email as a first-class agent primitive

Give every agent its own email address the moment it's instantiated. Not a shared pool. Not an alias. A real, deliverable inbox with a full identity footprint.

Signup: the agent enters its own address. No collision with other agents.
Recovery: if the agent forgets a password, the reset email comes back to it.
Audit: every external system has a record of this specific agent acting on its own behalf — not hidden behind a human developer's identity.
Revocation: kill the inbox, kill the identity. Clean shutdown.

The design principle

An agent without an email is like a microservice without a URL. It may exist, but it can't be addressed by the rest of the web. Lumbox's thesis is simple: provisioning an email should be as fast and programmatic as provisioning a container. lumbox.co ships that primitive.