10 standalone screen-recorded walkthroughs of the live chat.dev app, narrated by Matthew Mirman (AI avatar + cloned voice), each with a different face overlay. Real footage, no slides.
In this video we're going to create a real agent on chat dot dev and launch it. The thing to understand is that an agent here isn't a chat window — it's a process on its own machine in the cloud, with a shell, a repo, and tools. So let's actually make one and watch it start up.
I'll click New Agent. First a name, so I can find it later — I'll call it joke-app. Then the repository. An agent can attach to an existing repo, create a fresh GitHub repo, or run with no repo at all. For a quick demo I'll pick no repository, so it just spins up a clean machine.
Below that is the runtime and model — this is where you choose a Claude Code or a Codex agent and the exact model. And here are the toolpacks and skills you can attach, to give the agent real tools and specific know-how before it even starts.
Everything else has sensible defaults, so I'll just hit Launch Agent. Watch what happens — it provisions a real machine and drops me straight into the agent's own view.
This panel is the agent's live terminal. You can watch it boot, and the status up here moves from starting to running. On the right there's its cost, and the SSH details, so you can drop into the shell yourself whenever you want.
From here you give it tasks, watch its output, change its settings, or share it with your team. It's running on its own machine now — I can close this tab and it keeps going. That's the whole foundation: name it, pick a repo or none, and launch.
Let's look at Loop Recipes — the feature that turns one agent into a working team. A recipe is a saved template of a whole team: each agent's prompt, its model, its repo, its toolpacks, and its first prompt, all baked in. I'll open one so you can see what's inside.
This is the Deep Research Pod. Up top there's a description and a Use this recipe button, and below it, the agents that make up the team. Each one has a name, a runtime — Codex or Claude — a repo type, its toolpacks, the skills it loads, and a system and first prompt.
That first prompt is where the loop lives. You'll often see something like slash loop, one hour — that tells the agent to re-run itself on an interval instead of stopping after a single pass. On the right, the exposes and uses panels show how the agents call each other's tools to coordinate.
Now instead of just talking about it, let me actually spin it up. I click Use this recipe, give the team a name, and hit create. chat dot dev is now creating every agent in that team, each on its own machine, wired up exactly like the template.
And here they are on my dashboard — the whole pod, already running. I can click into any single agent to watch its terminal, or let the team run as a unit. That's the power of a recipe: a real, coordinated team standing up in one click.
And it works the other way too. Any team you build yourself, you can capture with Share Recipe — it saves this entire setup so you can reuse it or hand it to someone else. Build the team once, stamp it out whenever you need it.
This is marketing automation that actually runs on its own. We're looking at the Growth Squad recipe — a team of agents that keeps your top-of-funnel moving without you babysitting it. Let me open it and then spin it up live.
Each agent in the team has a focused role and its own first prompt. The key thing for marketing is the loop interval in those prompts — instead of one burst of posts and then silence, the agents wake on a schedule, do a round of work, and go back to sleep.
Look at the toolpacks attached to each agent. To do real marketing the team needs to reach the outside world, and that's what toolpacks plus your connected integrations are for — posting to socials, reading analytics, dropping drafts into a doc, in your real accounts.
Everything here is editable in plain language before you launch — the tone, the cadence, whether it posts automatically or just queues for your approval. So let me name the team and hit create.
And the squad is up — every agent spinning on its own machine, on the schedule baked into the prompts. I can open any one to see what it's doing right now. My honest advice: start it in draft-and-queue mode, watch a few cycles, and only flip on full auto-posting once you trust it.
Here's a recipe aimed at content — the Content Studio. The idea is a small team that turns a steady stream of ideas into finished, on-brand posts on a schedule, so your channels don't go quiet. Let me open it and launch it.
Look at how the agents divide the work — typically one doing research and ideation, one writing drafts, and one acting as editor. Each has its own first prompt, which is the brief for that role, and a loop interval so it re-runs on a cadence instead of stopping after one batch.
Notice you can attach skills to each agent. A skill is just a markdown file that teaches the agent something specific — for content, that's perfect for loading your brand voice so every draft sounds like you and not generic AI.
Let me actually spin up the studio. Use this recipe, name the team, create. And there it is — the agents are live and starting their first cycle right now. I can click into the writer to watch it draft.
Start it in draft-and-queue mode, correct the drafts it gets wrong for a few cycles so the editor learns your taste, and once it's consistently good, let it publish. The whole thing is now a running engine instead of a one-off.
This is outbound that doesn't feel like spam — the Sales Outreach recipe. It's a team that finds prospects, actually researches each one, writes personalized messages, and follows up on its own. Let me open it and spin it up.
See the division of labor in the agents — one builds a prospect list, one enriches each prospect by reading their site and recent posts, one writes the message, and a follow-up role keeps the thread warm. The personalization is genuine because the writer works from facts the researcher gathered.
To send through your real inbox and log to your CRM, the team uses integrations — you connect accounts like Gmail, Outlook, LinkedIn, and Slack once, and the agents act through them. The follow-up cadence and a do-not-contact list are just text in a prompt you can tune.
Let me launch it — Use this recipe, name the team, create. And the outbound team is live, each agent on its own machine starting its work. I can open any one to see what it's doing.
Set your volume low at first to protect your sending reputation, keep yourself in the loop on replies, and let it tighten its own messaging over time as it sees what actually gets responses.
Now bug fixing. This is the BugFinder recipe — a team of agents that act like users, find bugs, and email you every few hours with what they found. It's a perfect loop because the work is genuinely never done. Let me open it and run it.
Look at the agents. The runtime is Codex, and the toolpacks are agent introspection and system admin — those let it manage its own machine, schedule itself, and send you notifications, which is how it can email you on its own.
And look at the first prompt — it literally starts with slash loop, then says to spin up a pack of agents to hammer your website for bugs. There's an environment variable, product website, that you point at your own app. That's the loop made concrete.
Let me spin it up. Use this recipe, name the team, create — and the BugFinder team is live, already starting to exercise the target like real users would. I can click into an agent to watch it poke at the app and write up what breaks.
Point it at your own site, and you start getting digests of real, reproduced bugs while you sleep. Every part of it — the interval, the target, what counts as a bug — is editable right in those prompts before you launch.
This recipe keeps things healthy in production — the On-call SRE. It's a team that watches your systems around the clock, triages what goes wrong, and only pulls you in when it actually needs a human. Let me open it and launch it.
Look at the roles — typically a watcher keeping an eye on signals and a responder that investigates. The watcher runs on a tight loop, which you can see in its first prompt, so checks happen continuously instead of when you remember to look.
The toolpacks are the key part — with system admin and introspection tools plus your connected integrations, the team can read logs, hit health endpoints, and notify you through whatever channel you wire up. The triage thresholds are written in plain language, so you tune how noisy it is.
Let me spin it up. Use this recipe, name it, create — and the on-call team is live and watching now. I can open an agent to see its checks.
What makes this calmer than a normal pager is that the first responder is an agent — by the time it wakes you, it's already gathered context on what changed and what it checked, instead of just throwing a red alert at you at three in the morning.
This is the recipe for actually building product — the Full-Stack Feature Team. The goal is to take a feature request and have a team carry it from description to working code in a real repo. Let me open it and stand it up.
The agents split the work the way a real team does — an architect plans the change, a backend and a frontend engineer implement it, and a reviewer checks it. Each attaches to the repo where the work happens, so they're writing real code, not pasting snippets.
Notice the repo type on each agent — the team can work in an existing repository or spin up a new one. And the exposes and uses panels matter here: the reviewer can call the implementers' tools to poke at what they built, so they reach agreement before it comes to you.
Let me actually create the team. Use this recipe, give it a name, create — and here's the whole team, four agents, already running. I can open the architect to watch it write the plan and hand tasks to the others.
You stay the gatekeeper — you review and merge the pull request. But the heavy middle, turning a sentence into a tested change in your repo, is handled by the team you just spun up.
Let's talk about Skills — the cheapest way to make any agent dramatically more capable. A skill is just a markdown file, a SKILL dot md, that teaches an agent how to do something specific, and the agent loads it on demand when it's relevant. Let me make one.
This is the Skills page. Up top are my skills, and down here is a public library of skill packs from people and companies who know what they're doing — packs from Garry Tan, Anthropic's own agent skills, and more, free to pull from.
Let me create one. I'll hit New Skill, give it a name, and write a short instruction — the format is just plain markdown, instructions plus any details the agent needs. I'll save it.
And there it is in my skills. From now on I can load this into any agent, and it'll pick the skill up automatically — in a Claude or Codex agent it surfaces through slash skills. So instead of cramming everything into one giant prompt, the agent reaches for the right skill at the right moment.
You can also mark a skill as learning, so your agents refine it as they work, and every edit is versioned so you can roll back. The practical move when you set up an agent: check the library first — the capability you need may already exist as a skill you can just drop in.
Last thing to understand is what's under everything else: toolpacks and integrations. This is what lets an agent do things in the real world instead of just talking about them. Let me show you both.
This is the Toolpacks page. A toolpack is a bundle of tools — under the hood, MCP servers — that an agent attaches to. Agent introspection is thirty-three tools for an agent to manage its own ports, domains, funds, notifications, scheduling, and credentials. System admin is another set of mutating actions.
Let me open one so you can see it's concrete. Inside a toolpack you can inspect every single tool — its endpoint, its input schema, and a description you can edit. So you know exactly what capability you're handing an agent before you attach it.
These are the tools behind an agent's real powers — scheduling itself, exposing a port to hand you a live URL, texting you, even holding and spending funds from a wallet. That all comes from toolpacks.
Now the other half — integrations. This is how agents reach your real accounts. Look at the list — GitHub, Google, Gmail, Calendar, Slack, Discord, LinkedIn, Stripe, Supabase, and many more. You connect an account once here.
After that, any agent you give the matching toolpack to can act through that account — commit to your repo, send from your email, post to Slack, charge through Stripe — in your real environment, not a sandbox. Integrations connect your accounts, toolpacks expose capabilities, skills teach know-how, and recipes wire teams together.
Generated end-to-end on chat.dev: Playwright screen-capture of the real app + HeyGen avatar narration + ffmpeg circular overlay compositing.