How Delphi Ships 100+ Deploys a Day With a Python Backend on Vercel

The Real Cost of Owning Infrastructure

Delphi is a platform that turns a person's knowledge into a digital mind you can talk to. With 10 engineers, no dedicated infra role, and product and design shipping code, the team needed a backend that could keep up with how fast user demands change.

Their frontend ran on Vercel from day one. The backend ran on AWS with ECS, Docker Desktop, and local databases. It worked early on, but onboarding a new engineer to their first deploy took a full day of environment setup. The team could have fixed it on AWS, but that meant designing and owning infrastructure they didn't want to own.

"We couldn't keep up with AI on our old infrastructure. If it took a human eight hours to figure out, an agent would have given up." — Spencer Schoeben, Founding Engineer at Delphi

For a deeper look at how AI agents are reshaping knowledge work, see our analysis of the organizational second brain and expert knowledge architecture.

Workflows and Queues Made the Move Possible

When Delphi was founded, Vercel Workflows and Vercel Queues didn't exist. Without them, the move would have been much harder, if possible at all. Delphi's backend depends on long-running work and queued background jobs: durable agents that generate content ahead of time, plus ingestion that turns a person's books and talks into a knowledge graph.

Workflows handles the long-running work. Queues handles the background jobs. Neither requires setup. A developer writes the workflow or queue handler as a function in the codebase, and Vercel provisions what's needed on deploy.

Here is the shape of a typical queue handler in a Python backend:

# queue_handler.py
# Vercel Queues handler: process ingestion jobs for a digital mind

from vercel.queues import QueueHandler
from app.services.ingestion import build_knowledge_graph

handler = QueueHandler("ingest-mind")

@handler.process
def process_ingestion(message: dict) -> None:
    # message contains mind_id and source_urls
    mind_id = message["mind_id"]
    sources = message["sources"]
    build_knowledge_graph(mind_id=mind_id, sources=sources)

And a workflow that generates content ahead of time:

# workflow.py
# Vercel Workflows: durable long-running content generation

from vercel.workflows import workflow, step

@workflow
def generate_mind_content(mind_id: str) -> None:
    transcript = step(fetch_transcript, mind_id)
    summary = step(summarize, transcript)
    step(store_summary, mind_id, summary)

The key insight: infrastructure is not a file you maintain. It's a side effect of deploying a function. That's what let Delphi's team stop treating backend changes as heavyweight releases.

100+ Deploys a Day, Straight to Production

Moving the backend to Vercel let Delphi skip staging and ship 100+ times a day behind feature flags, running A/B tests instead of batching changes into a release. Vercel Agent's anomaly detection watches production at that pace, flagging when something is misbehaving and why.

Preview Deployments Are How Agents Check Their Work

Delphi's engineers hand problems to cloud agents, with very little development happening locally. The preview deployment is where they first see what the agent built. Every push gets its own live URL, so anyone can check the result from a phone or a Slack thread without pulling the branch.

When an agent fails, it's usually because it couldn't get at the information it needed. Vercel exposes data and controls through the SDK, MCP, and CLI, so an agent can read logs, inspect a deployment, or change an environment variable through whichever it's using.

An Internal Agent on Sandbox for Customer Success

One internal agent on Vercel Sandbox simplifies working with the codebase. Customer success uses Slack to ask it about reported issues, find the problem, and hand an engineer a root cause and a proposed fix. Sandbox gives the agent an isolated environment with a file system, where it can check out the codebase, run it, and pull in whatever data a question needs.

AI Gateway Picks the Model for Each Mind

Every digital mind is different, and some come out better on one model than another. Delphi picks the model for each customer and adjusts as its own evals change. When a new model ships, open-source or otherwise, Delphi can route to it the same day. Gateway also handles failover, which used to require lining up fallback capacity with a model provider across clouds.

Comparison: Old vs. New Stack

For a look at how a competing agent platform handles real account work, see Cloudflare Agent Lee's AI dashboard assistant review.

Limitations and Cautions

This setup is not a universal answer. A few things to weigh before copying it:

• Vendor coupling: Workflows, Queues, Sandbox, and AI Gateway are Vercel primitives. Portability is limited, and migration costs grow with usage.
• Cold starts and execution limits: Long-running agents still hit platform limits. Verify timeout and memory ceilings against your workload before committing.
• Agent-first debugging: When agents are the main users of logs and CLI, human observability can degrade. Keep dashboards and alerts for humans, not just agents.
• Feature-flag discipline: Skipping staging only works if flags, tests, and anomaly detection are mature. Without them, 100 deploys a day becomes 100 incidents a day.

Next Steps

• Map your current backend jobs into long-running vs. queued categories before choosing a platform.
• Prototype one workflow and one queue handler on your target platform before migrating anything else.
• Invest in preview environments and anomaly detection early; they are prerequisites, not nice-to-haves, for high deploy frequency.
• Read the source write-up for the full story: Vercel blog on Delphi's Python backend.

Delphi's next chapter is building the interface beyond chat: a search page where you bring a question, get perspectives from several minds at once, and have the page adapt to who you are. That work runs as long-running agents on Workflows, with AI Gateway supplying whichever model each experiment calls for. The pattern to steal: make infrastructure invisible, so the team can spend its energy on the product.