Vision

drovr is deal flow, built for agents, rat-stack to the bone. It runs the whole path of a content business's customer: the first cold visit, the email course, the offer, the purchase, the support that follows, and the 1,500-seat team deal, in one agentic product. It starts as Kit rebuilt for agents: it takes the core of what creators use Kit for (subscribers, forms, sequences, automations, broadcasts, segments, deliverability and reporting) and turns each piece into a typed capability an agent can drive. Then it adds what Kit can't do, because Kit wasn't built this way: simulation before send, receipts for every email, content as git, vendors as swappable cartridges. Support and high-touch sales are part of the same flow, not separate products.

A drover moves the herd along a defined route over days: journeys, time edges, no stragglers. drovr is the commerce engine of the content business, made durable, portable and wholly owned. Journeys are data, providers are adapters, receipts are the truth.

Scope: badass-courses/drovr, the product. Multi-tenant from day one. AI Hero is tenant one, not a special case.

Audience: Joel, the agents that build and operate deal flow, and the creators who run their business on it. Not a drag-and-drop marketing suite, and not a helpdesk or CRM workbench UI.

Reference: rat-stack is how drovr is built: Effect for the hard parts, Alchemy for the whole cloud, and a fence that makes the easy path the right one. This is non-negotiable: drovr fully realizes rat-stack's goals and ambitions, and what drovr learns shapes rat-stack's vision in return. AGENTS.md holds the law; this file holds the intent.

Who we serve

Primary: Joel and agents who write, simulate, ship and watch journeys, deals, support and content over MCP, CLI, HTTP and code mode.
Secondary: creators (tenant organizations) running their lists, journeys, support, sales and content on drovr, at a realistic price.
Not for: visual workflow builders, cold email, purchased or scraped lists, or growth hacks that burn sending reputation.

Why it exists

Email lists, sending, automations and content are the commerce engine of the content business, and today that engine is rented. The best creator email methods (Brennan Dunn's, Amy Hoy's and others', distilled in badass-courses/skills) end up as workarounds on Kit: flag tags, glossary automations, link triggers, Liquid conditionals, Deadline Funnel bolted on. Provider-captive logic is debt, and it is invisible to agents.

drovr exists so the engine is ours and agents can run it: the patterns those methods describe become first-class, typed and observable.

Beyond email: the right message at the right time

drovr is not just email marketing. It is the personalization layer of the content business: it knows where each person is on their path and shows them the right message at the right time, in their inbox, on the website, and at the offer. It is what Kit, RightMessage, and Brennan's, Amy's and Nathan's playbooks taught us, built as one agent-driven system.

What that means

Email stays the heart. Sequences, broadcasts and newsletters (a Substack-grade newsletter is in scope) are where the relationship lives. Good newsletters sell.
The website is a surface too. The same profile and journey state drive on-site personalization: which CTA, which offer, which next step.
Journey mapping and active promotions are first-class. drovr knows what's running (launches, evergreen deadlines, sales) and who is eligible, so every surface speaks with one voice.
Connected to course-builder, not duplicating it. Commerce, checkout and course content stay in course-builder; drovr reads purchases, progress and entitlements as events and steers.
The goal is outcomes. We herd customers toward the outcomes they want, along a path filled with value. Every message has to earn its place on that path.

Deal flow: one product, a spiral

Deal flow is drovr's one product: a graph of machines that every account moves through, from a cold first visit to the biggest sale and back out wider. The seller calls it deal flow; for the customer, it is their path. The spiral is Kathy Sierra's: start at low resolution and rise. A stranger joins the newsletter or the free course, walks a path of value, meets the offer the path calls for, and buys: one seat, a subscription, a ticket, or 1,500 seats. A turn of the spiral completes on evidence of an outcome, not on payment. One buyer gets results, their team asks, and the next turn opens at higher resolution.

Accounts are how small and big become one flow. An account is a customer org inside a tenant, and a single buyer is an account of one, so nothing migrates when they grow into a team. Contacts join accounts through memberships, and a seat exists before its person accepts it.
Every purchase opens a deal. Team signals open one sooner: a "Team" answer, a quote request, a thread an agent judges to be a team purchase. The deal runs to adoption and a real outcome, and expansion opens the next deal.
Support is part of the flow. Whether you bought one seat or 1,500, you should feel heavily supported. A support conversation is a journey on the same account, and a support reply is transactional email. drovr owns the support inbox; Front is where it started, and drovr's own inbox replaces it over time.
Every account has a repo. Each account gets a git repo: a VISION.md for what the account is trying to achieve, and a PARA wiki that agents keep current from every conversation, call and label. A deal is a project in it, with its own vision and a level of agency.
Commerce stays honest about who owns what. drovr owns deals, quotes and entitlements. A commerce cartridge moves the money: Stripe by default, and course-builder for AI Hero. drovr sells itself to its own tenants through deal flow on drovr, as tenant zero.
What drovr sells is the method. The human surface is whatever you already use, plus your own agent. drovr provides the taught methods, business processes and workflows that move deals toward outcomes, and it integrates with other services at every point. A tenant can exit anywhere, or hand any stage to another service.

Agentic by default

This app is agentic. Agents run deal flow end to end: they triage, reply, offer, quote, invoice, grant seats and open the next deal. People take part when an agent brings them in, not as a gate on every act.

Each deal carries a vision and a level of agency: watch, suggest, draft, act and tell, or act. A one-seat purchase runs on its own; a 300-seat quote starts where the tenant's policy puts it, and either an agent or a person can move it.
Safety lives in what ships. An agent's behavior ships the way a journey does: versioned, replayed against real history, and run in a simulated world before release. Fast typed judgments (TypeSafe's System One) check each act against the deal's vision; a failed check drops a rung or hands the act up. Every act leaves a receipt that can be traced, explained and reversed.

Simulated worlds, all day, every day

drovr can spin up fake business worlds for agents to live in. A world is a sandboxed tenant with fake cartridges, customer agents built from the patterns of real history (never its text), drovr's own agents running the business, and a clock that runs a quarter in days. Worlds run around the clock on local intelligence. They are how a new drafter, policy or journey earns its way into production, and how drift gets caught before customers see it.

How it's built

The rat-stack way. rat-stack's own vision is to build the best Effect + Alchemy application we can, and drovr moves toward it with every path it finishes. (That north star lives in rat-stack's vision, not here.)

The north star

Kit's core, agent-first

Kit	drovr
Subscribers, tags, custom fields	The contact directory: one Schema-typed profile per `(tenant, contact)` with a full timeline from receipts
Forms and landing pages	Capture routes that are rate-limited and captcha'd from day one; abusers hunt for open forms
Sequences and visual automations	Versioned XState journeys shipped as data; zero drag-and-drop
Broadcasts	A one-shot journey over a segment of the directory, honoring suppressions, sent in configurable batches (for example 500/hour, or a target window of 6–8 hours), most engaged recipients first, and pausable and editable while sending
Segments	Projections over the directory, receipts and engagement events
Deliverability	Suppressions, one-click unsubscribe, and warm-up as code
Reports	Receipts and Analytics Engine grouped by journey, message, version and segment

Every capability is one Schema-described action. CLI, HTTP (with OpenAPI), MCP and code mode are projections of it, rendered from one catalog. The HUD is read-only.

Methods become primitives

The Kit workaround (from the skills)	The drovr primitive
Flag-tag events, glossary automations	Typed events that journeys react to directly
Link triggers ("click to tell us who you are")	Answer events (`value-path.answer-selected`), with click-intent filtering so mail scanners don't count as answers
Custom fields, surveys, Liquid offer funnels	A typed profile, `next_offer` as a projection, MDX components instead of Liquid `if` blocks
Deadline Funnel	Per-contact deadlines as durable timers (the evergreen bridge already runs one)
Time-zone sends	The tested calendar code
Lead scoring, behavioral segments	Derived from receipts: the transition log is the behavior log
A/B tests	Content variants as git branches, deterministic assignment by contact hash, simulated before sending
"Why didn't you buy?", post-purchase accountability, launches	Journey templates started by purchase, non-purchase and calendar events

The eight sequence types in email-sequence-architect become journey templates plus MDX scaffolds. Three already run in production: the value-path course, the evergreen bridge and the shadow newsletter. The skills are rewritten against drovr's catalog and ship with its MCP server, so an agent that connects gets the methods as well as the tools. The extracted source material stays private; drovr encodes patterns, never their text.

Content is code

Each tenant's emails live in a Cloudflare Artifacts repo as MDX: Schema-checked frontmatter (subject, preview, sender, variables) and a markdown body with a few components.
A push is a deploy. The pushed event runs checks (frontmatter, variables, links, a test render per client, a lint for spam and length). Green publishes an immutable email version keyed by the commit; red blocks it with the reason.
Journeys reference message ids. Each send carries the exact version it rendered and each receipt records it: for any person, which words went out and when.
Rollback points at an older commit. Preview renders any branch. A contact mid-sequence can be moved to a new journey or content revision in flight. Joel: "They can be moved. I don't necessarily want to be looking at it every time, but we need to analyze that every time and use intelligence to come up with the graph or new graph or next condition... with full telemetry and the ability to trace it back and good version histories." Every move is analysed automatically before it runs and dry-run against every contact it would touch; a model may propose a mapping, and deterministic checks must accept it. Each move is recorded as a receipt naming both revisions' git versions, so it can be traced and explained afterward. A contact nobody moves stays on the revision they started.
A proposed rewrite is a fork an agent works in; the merge is the release. This is the same shape as the system that syncs Matt's course content.

What Kit can't do

Every email is inspected before it can ship. A publish runs link, image, accessibility and code checks and renders client previews (Gmail, Outlook, Apple Mail, dark mode) through Mailgun Inspect behind an EmailInspection Layer. A failing check blocks the publish. Addresses are validated before a cohort or broadcast. Agents can call inspect_email and validate_addresses on any draft too.
Simulate first. Replay a journey over thousands of synthetic contacts on a virtual clock and read every email and every timer before anyone gets one.
Receipts for everything. Each contact is a durable actor with a full trace: why this email, which version, when it was due, when it was confirmed, how late.
Vendors are cartridges. PostShiba, Postmark and Kit each sit behind the send port as an Effect Layer. Routing between them is a percentage; swapping one is a line in the Stack. Front and drovr's own inbox sit behind the conversation channel the same way.
Batching is a first-class control. Every broadcast spreads over hours instead of minutes, which Jesse Hanley (Bento, PostShiba) calls almost always better for deliverability. Rate and window are settings on the broadcast, changeable mid-send, next to pause, resume and edit.
Warm-up is code. A ramp router plus a gate that will not advance until bounce and complaint rates are clean. That is the road to full-list broadcasts.
Multi-tenant from the start. Each tenant gets its own content repo, actors and receipts.

Machines for time, Effect for everything they touch

An automation of any complexity is a composition, and each part has one owner.

The journey is an XState machine whenever something waits or branches over time for one contact: states, timers, guards on data, the intents it owes. It is folded purely (decide), persisted between events days apart, versioned, and replayable. That purity is what makes it simulatable and idempotent.
Everything around the machine is an Effect program. Before the fold: enrich events (score, segment, profile facts, click intent) so guards read data, never call services. After the fold: resolve the content version, personalize, render, choose a provider, send, fold the result back. Beside it: Streams over the directory for broadcasts, segment recompute, list hygiene and re-surveys, which emit events into machines.
Cartridges are how drovr composes. With Alchemy, an Effect Layer declares the cloud resources it needs, and providing the Layer provisions them on the next deploy; Sam Goodwin calls this "SaaS as NPM". A port is the contract, a Layer is one vendor's implementation carrying its own infrastructure, and typed errors are the SLA. Every cartridge passes rat-stack's cartridge test: labeled, pushes in with one Layer.provide or Stack line, pulls out with the build still green, self-contained, and easy to trash. Journeys decide and emit intents; executors carry them out through each tenant's chosen cartridges, and a world swaps in fake ones.
Layers make it a kaleidoscope. The same journey runs against different Layers: a test clock and synthetic contacts to simulate, fake providers to test, a personalization service per segment, one Layer per sending vendor, telemetry that records every span. Change the Layer, not the journey, to test a thousand variations, personalize by segment, or swap a vendor.
Journeys can be generated. An Effect program can build journey data from a template and parameters (a launch with these dates, a course with these lessons), so the methods in the skills become functions that produce machines, then get simulated before they ship.

Shape (settled at charter 2026-08-29, still true)

Journeys are XState v5 machines: pure, serializable, versioned data. The machine plans; actions emit intents; executors do provider work; completion receipts advance the actor. At-least-once with idempotency keys.
One contact and journey = one Durable Object: snapshot, alarm and fold in one primitive. The alarm is memoryless: time edges live in storage, one alarm arms for the soonest, due work is re-derived on fire.
Tenant in types from day one: contact identity is (tenantId, contactId) everywhere. Domain packages never import auth; the boundary parses it into domain values.
Authoring is agent-native: MCP, CLI, HTTP, code mode. Exactly zero drag-and-drop. The visual UI is read-only.
Ports, not providers: every provider sits behind a port, and a second adapter must pass the same contract tests as the first. Adding a port needs owner sign-off (AGENTS.md).
Projections never gain authority: actor snapshots are the state truth; receipts are the transition log; D1, the HUD and segments derive from them.

Guardrails

Agents act at each deal's level of agency. A behavior reaches real customers only after it has run clean in a world; until Joel raises a lane, real sends to anyone but Joel go through Joel.
Support and deal text is sensitive. Raw text lives only in account repos and the channel it arrived on; receipts, projections and logs carry ids, hashes and commit shas.
Artifacts, its CI Workflows, PostShiba, Effect, XState and Alchemy are pre-release. Pin exactly, keep adapter seams, record drift.

Outcomes

A creator's list, journeys, content and sending run on drovr end to end, with Kit as an optional adapter rather than the engine.
An agent can take a method from the skills to a simulated, reviewed, versioned, sending journey without a UI.
For any contact, drovr can say which email went out, which version, why, and how late.
A vendor swap is a routing change, proven by contract tests.
For any account, drovr can say where it is on its path, which deals are open, what each deal is trying to achieve, how much agency its agents had, and what they did.
A one-seat buyer and a 1,500-seat org run on the same flow, and both feel heavily supported.
Every agent behavior in production has run clean in a simulated world first.
drovr bills its own tenants through its own deal flow, by active accounts, email capacity and agent work, never by human seats.