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. drovr owns AI Hero's email copy and geo; the AI Hero app owns the aihero.dev pages.
• 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.)

drovr models its business with Alchemy Domain. Joel, 2026-11-04: "we want to full adopt alchemy domains as part of our vision, aggressively." Each part of the business (access, signup, consent, content, broadcasts, delivery, send ops, flags, contacts and journeys) is one domain package of commands, aggregates, events, views, projections, policies, sagas and external systems. Stories test it in memory, and Durable Objects host it. apps/api shrinks to the Api and one thin hosting root per Worker. drovr already had this shape by hand: per-key actors decide, receipts record, projections answer, executors act. Alchemy Domain gives that shape one vocabulary, one runtime and one test style. The laws stay: journeys are data, tenant is in the types, seven ports, and receipts are the log. Where a law and Alchemy Domain disagree, the law holds until Joel rules. The adoption plan owns the order, the fit and the open questions.

The north star

Kit's core, agent-first

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 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.

Contact identity is ours

Contact identity is (tenantId, contactId), not an email address or a provider id. Email is a lookup claim, normalized by trimming and lowercasing only. Plus-tags and dots stay intact. Kit, PostShiba and AI Hero ids are aliases. Conflicting claims never auto-merge.

drovr owns consent, suppression and custom fields. AI Hero's active Kit subscribers count as consented because its list is fully double opt-in; inactive or unconfirmed subscribers do not. Existing suppressions still hold.

New-id minting, the transactional identity registry and a new identity port remain open design decisions. Crypto-shredding is under design, not a shipped erasure guarantee. The full active-list broadcast proof is met: C5 #05 went out on drovr and PostShiba with no Kit share.

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.
• Effect all the way, not Effect at the edges. Every Worker and Durable Object entry builds one runtime from composed Layers; nothing inside runs an Effect by hand, awaits a promise, throws, or reads the environment raw. Configuration comes through Config, and secrets are redacted. A provider's answer is a typed outcome (accepted, rejected or unknown) that the fold must handle case by case, so "the provider took it but we recorded a failure" cannot compile. Plain-async code is debt with a ratchet that only shrinks, and the send path pays it down first.
• 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)

1. 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.
2. 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.
3. Tenant in types from day one: contact identity is (tenantId, contactId) everywhere. Domain packages never import auth; the boundary parses it into domain values.
4. Authoring is agent-native: MCP, CLI, HTTP, code mode. Exactly zero drag-and-drop. The visual UI is read-only.
5. 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).
6. Projections never gain authority: actor snapshots are the state truth; receipts are the transition log; the SQL projections (PlanetScale MySQL), HUD and segments derive from them.

Owned storage, replaceable database

PlanetScale MySQL is the production store for main data: Joel expects drovr will need a full-featured database it can write and read fast to grow to its full potential (October 8). Joel chose it on October 4, 2026, and production reads and writes it through DROVR_DB. The main D1 is unbound from production and retained as a frozen archive; the auth and corpus D1s stay. The October 4 decision and the flip runbook own the details. We measured the move (a 2.2 GB, 3.9M-row export took minutes; the MySQL load took over 17), and those measurements shaped the cutover.

The database stays replaceable because drovr owns its storage contracts. Drizzle owns application queries through typed schemas in @drovr/database; the EventLog and ReceiptSink ports keep a second adapter honest by passing the same contract tests as the first. Cascades live in code and tests, not database foreign keys. Durable Object snapshots, alarms and DO-local SQLite are the state truth and do not move. AI Hero's PlanetScale database stays a read-only integration through AIHERO_DB.

MySQL has taken writes, so we keep the flip forward-only under the fleet's confirm-irreversible guardrail: fix forward, with no reverse copy into D1. Joel approved deleting the main D1 on 2026-10-28, and its code and resource go in steps. A limit nobody measured is a guess, so the cutover advances on measured evidence.

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.

• Effect is stable at 4.0.5. Artifacts, its CI Workflows, PostShiba and Alchemy are pre-release. Journeys stay on XState 5.32.5. Pin exactly, keep adapter seams, record drift.

How we ship

drovr is agentic: Joel, 2026-10-23, “i want drivr agentic af”. Agents decide and act within the worker autonomy ladder, including fixing their own CI and using the authority the code already grants. Joel sets direction; his attention goes to decisions his words reserve, not desk settings presented as his gates. Before asking him, read the code and current rulings, act where they already decide, and keep independent work moving.

Small continuous releases, automated gates, a canary tenant and rolling deploys are the direction. Minimal CD comes first; a design or a green build is not proof that CD is enabled.

Release speed is a product feature. Waiting is the cost we measure first: on October 7 most of a change's time from merge to live was spent queued behind policy, not in code or gates. So:

• The vector clock is law. A post-deploy gate passes when every component of its event vector is met on the new version and trips the instant a limit breaks. No release step waits on a time window or a fixed fire minute; a gate is judged against a measured background rate of the same kind of traffic, never against silence.
• Pipelined releases. The next range is cut, checked and planned while the current gate fills. Only the deploy is serial, and one gate is open at a time.
• The accountable owner lifts. GitHub CI is the qualification gate on the exact candidate. Production-path code touching real data or email gets one independent review; the desk reviews tooling, scripts, tests, fences, lint and docs. No duplicate local qualification run stands between proof and merge.
• CI owns the native gate. The required checks job depends on native MySQL suites, running MySQL 8.4.11. No separate pre-PR fresh-fixture native run is required; local natives debug a red CI result. CI's own queue replaces the heavy lock for qualification tests. The heavy lock guards benchmark timed rounds and copy runs only.

Push each failure to the fastest layer that can catch it: lint, types, model/property tests, workerd integration, stage E2E, then production canary E2E.

Don't guess. Test, benchmark, eval. We learn what a platform actually does by pushing it until it breaks, not from conservative theory or a doc's caution. Our D1 "budget" turned out to be our own 3-second deadline. A limit nobody measured is a guess, and we label it as one.

A test earns its place by failing when behavior breaks. Hand-written mutant suites and property tests are how we know: a test that kills no mutant another test does not already kill is redundant, and a test that restates the implementation or asserts a mock is not a test. The count of tests is not a measure. Tests are written the rat-stack way: Vitest with @effect/vitest, it.effect for anything that runs an Effect, Layers for every service a test needs, TestClock for time, and property tests (it.prop) over Schema-derived inputs for every function that decides something. One runner, no node:test. The deep runs (properties at high counts, stage E2E) belong to pennywise. Following the Bitter Lesson, incidents become executable checks, not more prose rules. Validation and cutover phases end on event coverage: every required event kind meets its threshold with reconciled evidence. Missing events hold the phase; elapsed time never passes it.

The arbiter handles each risky step in four classes: real-reader email, SQL schema changes, binding/route/secret/resource changes, and provider-account writes. The arbiter also owns every release gate: plan, arm, verdict and rollback. In drovr practice, a change in none of the four classes ships without an arbiter GO; the lift fence still refuses any diff on a class path that has no logged GO. The risky-class approvals protect against irreversible harm under the fleet's confirm-irreversible guardrail. Port and durability changes still need owner sign-off. This direction grants no deploy, merge, send or CD enablement.

Outcomes

• AI Hero's automated email (value path, shadow newsletter and team track) sends through drovr and PostShiba. The C5 launch broadcasts moved onto drovr, and C5 #05 went out on drovr end to end. What's left is loose ends: Kit-native sequences and automation, forms and double opt-in, the changelog and one-off broadcasts, readers still pinned to Kit, and the Kit-coupled side paths. Joel wants AI Hero fully off Kit. Kit retires for AI Hero once the exit counts hold. Retirement depends on evidence, not a date.
• 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.