Ship Anything Autonomous.
The deployment pattern from the Morning Brief, abstracted. Supabase for state, Vercel for the dashboard, env vars from your password manager, a cron on your Claude subscription. Apply the same moves to any agent shape you want running on a daily loop.
- A four-layer pattern you can drop onto any agent that needs state, a read view, secrets, and a scheduled fire. Supabase, Vercel, password manager, cron, in that order.
- A picker for which agents fit Daily briefs, weekly digests, monitoring loops, and source-of-truth dashboards fit cleanly. Real-time event responders and ad-hoc one-shots do not.
- A second-build short-circuit The moves you spent a half day learning on the Morning Brief should take you an hour on your second build. This card is the runbook for that second build.
Apply this pattern to your next agent.
You already have an agent in mind. Hand Claude the shape of it and walk through the four layers in order. Claude proposes the Supabase schema, the Vercel project structure, the secrets list, and the cron line for your specific build.
How this fits in the OS.
One agent you have already built and run by hand. A working CLAUDE.md from Stage 01. Your MCPs (Claude Desktop calls these connectors) from Stage 02. Infisical or 1Password for secrets. And ideally one trip through the Morning Brief capstone, because the moves below are the moves you already learned there.
Supabase for state, Vercel for the read view, your password manager for environment variables, and a cron on your Claude subscription (or Task Scheduler on Windows, launchd on macOS) to fire the loop on a schedule.
A second autonomous agent in an hour instead of a half day. Once the pattern is in your hands, the build cost drops every time you reach for it.
The shape of the pattern.
The Morning Brief is one instance. The pattern is the lesson. Four layers, in this order, every time:
- Supabase for state. A tiny schema that captures what the agent produced, what it ran against, and what it delivered.
- Vercel for the read view. A deployed dashboard at a URL only you can see, so the agent's output has a home you can open from your phone.
- Secrets in your password manager. Every credential the scheduled run needs, stored once with the
PASTE_HEREplaceholder pattern, then loaded by the runtime. - A cron on your Claude subscription. A headless Claude Code session that wakes up, runs the skill, writes to Supabase, fires the delivery, and goes back to sleep.
The order matters. Vercel needs the Supabase URL and service-role key as environment variables at deploy time, so Supabase has to exist first. The cron needs the slash command to already work, so the read view has to exist before you schedule anything. Supabase, Vercel, secrets, cron. That is the sequence.
You will not run a slash command at the end of this page and have a new agent shipped. The build steps live on the agent's own card (the Morning Brief is the canonical example). This card is the runbook that tells you what each of those steps was for, so you can apply them to an agent that is not a Morning Brief without re-deriving the architecture every time.
The four layers.
Supabase for state
What it does. Holds the agent's output, the registry of what it pulls from, and the log of every delivery. Three tables is usually enough. Row-level security on, open read for the dashboard, service-role writes from the scheduled run.
The three-table shape:
- An output table. One row per run. Whatever your agent produces, that is what this table stores.
- A sources or inputs table. The registry of where the agent looks. Toggleable, dated, owned by you.
- A delivery log. One row per ping fired. The audit trail that proves the run happened while you were asleep.
briefs, sources, and delivery_logs. The migration lives at apps/morning-brief/supabase/migrations/0001_morning_brief.sql. The shape is generic on purpose.
digests, your sources table tracks the channels you summarize, your delivery log records the email or Slack post. For a monitoring loop, your output table is checks, your sources table is the list of endpoints, your delivery log is the alert history. Same three-table shape, different nouns.
Why Supabase and not a flat file. A markdown file is fine for a single-user, single-machine local agent. The moment you want a read view your phone can open, or a second machine that adds to the same record, or an audit trail you can query, you want a database. Supabase gives you Postgres plus row-level security plus an HTTP API plus magic-link auth in one signup. The free tier covers the whole pattern.
Vercel for the read view
What it does. Renders the agent's output at a URL you (and only you) can open. Vercel handles the build, the hosting, the SSL, the preview deploys, and the env-var management. Next.js is the default framework. The free tier covers the whole pattern.
Four rules that save students an hour of confusion the first time:
- Import your own private repo. In Vercel → Add New Project, import your own
agent-native-os-privaterepo (the private GitHub repo your local workspace pushes to), not the AI Build Lab /aibuild-laborg repo. - Set the Project Root during import. Your repo holds the whole workshop. The app lives under
apps/your-agent-name/. Vercel asks during import, and skipping this is the most common cause of a failed first deploy. - Add every secret to Production, Preview, and Development. Three checkboxes per variable. Missing the Preview checkbox is the second most common cause of a build that worked yesterday and fails today.
- Gate the URL. The output contains your private data. Turn on Vercel password protection, or wire Supabase magic-link auth in front of the read view, before you leave the deploy public.
apps/morning-brief/. The homepage reads from Supabase, renders the latest brief, the source registry, and the delivery log. Auth gate is on. The URL is only useful to the person who built it.
Why Vercel and not local-only. A markdown file on your computer cannot be opened from your phone at 7am. A deployed dashboard can. The difference between "agent running on my computer" and "agent running while I am at the coffee shop" is the read view that lives on a public host you control.
Secrets in your password manager
What it does. Holds every credential the scheduled run needs, in a place that the runtime can read but your chat with Claude cannot. The runtime signs in to Infisical or 1Password at the start of the run, expands the secret references, and the values never touch a file you might accidentally commit.
The pattern, every time:
- Create the entries with the placeholder
PASTE_HERE. Claude can create the entries. Claude cannot fill in the real values. - You type the real values yourself. Directly into your password manager, never into chat. This rule has no exceptions.
- Reference, do not embed. The runtime reads
op://or Infisical references at startup. Your scripts ship with the references in them, never with the secrets.
If Claude offers to enter real API keys for you, say no. The placeholder is the contract. You always type the real values yourself.
SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, plus a Telegram bot token and chat ID when that delivery channel is on. The same three Supabase variables show up in every Stage 06 build. The delivery variables are the part that changes.
Why this layer is non-negotiable. A scheduled run has no human at the keyboard. It cannot prompt you for a password. The whole point of the password-manager layer is that the agent can sign itself in to whatever services it needs, while the secrets stay in the one place you trust to hold them.
A cron on your Claude subscription
What it does. Fires the loop on a schedule, without a human at the keyboard. A headless Claude Code session wakes up at the time you picked, runs the slash command, writes to Supabase, fires the delivery ping, and exits.
The shape, regardless of operating system:
- A wrapper script. Signs in to your password manager, exports the secret references as environment variables, then runs Claude Code in headless mode with the slash command. Output is teed to a dated file so you can read what ran tomorrow.
- A scheduler. Cron on macOS and Linux, Task Scheduler pointed at Git Bash on Windows. The scheduler's job is to fire the wrapper script at the right time. It does not do anything clever.
- A kill switch. One line you can run from your phone (or remotely over SSH) to stop the schedule if something goes sideways overnight. Write this down before you turn the cron on.
claude --no-color -p "/build-morning-brief gmail,calendar,obsidian", and writes the output to ~/Documents/briefings/YYYY-MM-DD.md. The brief lands on your phone before you wake up. Tomorrow morning is when the pattern becomes real.
30 17 * * 5 (5:30pm Fridays). For a monitoring loop, you do not want a cron at all (you want a heartbeat instead, every few minutes; see the next-card row below). For a start-of-quarter planning agent, the cron fires four times a year and the wrapper script is identical otherwise.
The trust step. Run the wrapper script by hand a few times before you schedule anything. Verify the output is what you expected. Only then add the cron line. Autonomy is earned, not assumed. The first time the loop fires while you are asleep should not also be the first time it has ever run.
What fits this pattern, and what does not.
The pattern is designed for agents that produce a thing on a schedule and store the result somewhere readable. The fit table:
| Agent shape | Fit | Why |
|---|---|---|
| Daily brief. Sources collapse into one short ping plus a write-up. | Strong | The canonical Morning Brief instance. Cron, state, read view, delivery. All four layers earn their keep. |
| Weekly digest. Friday summary of the week's activity across channels. | Strong | Same four layers, slower cron. The read view also doubles as the searchable archive of past weeks. |
| Source-of-truth tracker. A nightly run that rebuilds a single canonical view of something that changes (lead list, OKR status, content calendar). | Strong | Supabase holds the canonical state, Vercel renders it, the cron keeps it fresh. The whole pattern, exactly. |
| Quarterly planning agent. Fires four times a year, drafts the plan, lands it on a dashboard. | Strong | Low frequency is fine. The pattern does not assume daily. It assumes scheduled. |
| Monitoring loop. Every few minutes, check if anything in the fleet broke. | Adjacent | State and read view fit, but the trigger is a heartbeat, not a cron. See Heartbeats and Crons for the picker. The Supabase plus Vercel plus secrets layers still apply. |
| Real-time event responder. Reacts to webhooks (new email, form submission, payment received). | Adjacent | Same three storage layers. The trigger is a webhook listener (usually n8n), not a cron. The pattern is the same shape with the cron swapped out. |
| Ad-hoc one-shot. A research run you do once, manually, and never repeat. | Skip | No schedule, no recurrence, no read view needed. Stay in your chat. The four layers are overhead you do not need. |
| Conversational assistant. Sits in chat, waits for you to ask things. | Skip | That is what Claude Code in the terminal already is. The four layers do not add anything. |
If the answer to "would I want to see this on my phone before I wake up?" is yes, the pattern fits. If the answer is "I would just ask Claude when I need it," the pattern is overkill. The schedule is what makes the four layers earn their keep. Without the schedule, you have built a dashboard for an agent that nobody is firing.
Every Stage 03 small build exercises a piece of this same pattern at smaller scope. Email Reply Queue exercises the schedule and delivery pieces against your inbox. Calendar Conflict Defender exercises the source-and-react loop. Stale Lead Follow-Up exercises the state-and-trigger pattern against a contact list. The capstone moves you are about to make are the moves you have already practiced. The new piece is the deployed surface that sits on top.
What changes for you.
The first Morning Brief is the build that teaches you the layers. The second autonomous agent is the build where the savings show up. Three shifts:
- Build time collapses. A half day for the first one. An hour for the second. The reason is not that you got better at coding. The reason is that the four layers stop being decisions and start being defaults.
- You stop asking "how should I host this?" The answer is Vercel. You stop asking "where should the state go?" The answer is Supabase. You stop asking "how do I schedule it?" The answer is cron on your Claude subscription. Decisions become reflexes.
- You start shipping things you would not have built otherwise. A weekly digest takes ninety minutes when the pattern is in your hands. That is below the threshold where "I should probably automate this" turns into "I just did."
This is the moment the workshop stops being a class and starts being an operating system you instantiate.
If you get stuck.
Failure modes on the second build look identical to failure modes on the first build. The shortlist, ranked by frequency in the workshop:
- Vercel build fails on "Missing SUPABASE_URL". You forgot to add the env vars to all three environments. Project Settings, Environment Variables, add them, Redeploy.
- First Vercel build fails on Next.js prerender or peer-dep conflict. Retry with
--legacy-peer-deps, or have Claude search the exact error message and patch the install command. - Supabase row never writes. Row-level security is blocking the service-role key. Ask Claude to verify the policies on the output table. Open read, service-role writes is the pattern.
- Cron does not fire on macOS overnight. Lid-closed sleep blocks the runtime. Enable "Keep computer awake when display is off" in Claude Desktop settings, or use
caffeinatewhile plugged in. - Vercel deploy went public. Anyone with the URL can read your private data. Turn on Vercel password protection or wire Supabase magic-link auth before anything sensitive lands.
- You pasted a real key into chat. Rotate it immediately, redo the credential step with the
PASTE_HEREplaceholder pattern. The rule does not have exceptions for any reason.
If the failure mode you hit is not in the list above, post a screenshot, the prompt you ran, and what Claude said in the workshop Slack. Someone on the team has hit the same thing.
Where to go next.
The pattern is the connective tissue. The natural next moves: