Build an AI agent, Part 2

Your client said yes. That's the moment most of the work quietly appears: a welcome email to send, a task list to build, and a handful of details nobody has pinned down yet. This is the job I hand my agent, and it's a good one because the answer is checkable. Either the kickoff is right or it isn't.

In Part 1, Build your first AI agent, we built the thing and set its four pieces. If you haven't read that yet, start there; this guide assumes you already have an agent with your context, memory, tools, and a trigger in place. Here's the part that doesn't fit in sixty seconds: the exact files I'd hand it, the kickoff prompt I'd paste in word for word, and one run walked all the way through so you can see what a correct handoff looks like and where it tends to go wrong.

The four pieces, mapped to this job

Same four pieces from Part 1, pointed at one task. This is the whole reason the earlier setup matters: with these filled in, "prepare the kickoff" is something the agent can actually run.

What to hand it

Before the prompt, give it the inputs. Three files cover almost every kickoff I've run. Hand it these, not a description of them.

1. The accepted proposal
   - deliverables, quantities, the deadline, the price and terms
2. The client's notes
   - anything they said in the thread: preferences, links, requests
3. My onboarding checklist
   - the steps I run for every new project, and what I need from the client to start

The kickoff handoff prompt

This is what I paste in once the files are attached. It sets the job, tells the agent to work only from what it was given, and holds the line on the two things it must never do on its own: send, or invent a commitment.

Prepare the kickoff from these supplied files. Create a checklist with owner and due date when provided, draft a welcome email, and list missing or conflicting details with their source. Mark unknown details as questions. Do not send, change scope or invent commitments.

The phrase carrying the weight is "with their source." It forces the agent to point at where each fact came from, which makes a made-up detail stand out instead of blending in.

One run, walked all the way through

Advice is easy to nod at and hard to check, so here's a real one. The client is fictional, but the shape is one I've hit dozens of times.

Say the proposal promises three videos by Friday. The client's notes are enthusiastic but never include their brand files, the logos and fonts you need to actually start. You attach the proposal, the notes, and your onboarding checklist, and paste the prompt above.

A correct handoff comes back with three things. The task list shows all three videos and the Friday deadline, pulled straight from the proposal. The draft welcome email is warm, confirms what was agreed, and asks for the brand files, because the checklist needs them and the notes never delivered them. And the missing-details section names exactly one gap: brand files not received, source being the onboarding checklist. Nothing sent, nothing guessed.

Then I run three checks on that output, and so should you:

• Did it keep the scope and the deadline? Three videos, Friday. Not two, not "a few," not next week. If the count or the date drifted, the agent rewrote the contract, and that's the first thing I look for.
• Did it catch what was missing? The brand files should show up as a flagged gap and as a request in the email. If it sailed past that, it would have you kick off a project you can't actually start.
• Did it invent anything? No colors it was never told, no "as discussed" for things that weren't. Every fact should trace back to a file you handed it.

Run it once, read the whole handoff against those three questions, and you'll know in two minutes whether you can trust it with the next client.

What goes wrong, and what to check

Every one of these has happened to me, and each has a plain fix.

It invents a missing detail instead of flagging it. The brand files never arrived, so the agent picks a color and moves on. That's a memory-and-instruction gap: it had nothing to read and wasn't told to stop. Keep "mark unknown details as questions" in the prompt, and check that the missing-details section is actually populated, not suspiciously empty.

It sends the email itself. You wanted a draft and it hit send, sometimes to the client, sometimes with a placeholder still in it. Asking nicely in the prompt is not enough. Send has to be off in the tool's own permissions so the action simply isn't available, the same guardrail from Part 1. The prompt says don't send; the app is what enforces it.

It silently changes scope or price. Three videos becomes "a video series," or Friday softens to "by early next week," or it offers the client a small extra to be nice. Any change to scope, deadline, or price should surface as a flagged question for you, never a quiet edit. If you see the numbers move, that's the run to reject.

It starts from a blank chat with no memory of the client. It re-asks for things the client already sent, or forgets what was agreed last week. That's the memory piece from Part 1 not wired in. Point it at the saved client record and tell it to read that record before it drafts anything.

The boundary that keeps this safe

This workflow does real work, and it will still get things wrong, which is exactly why the guardrail matters. Everything the agent produces is a draft. The welcome email waits for you to read and send. Any change to price or scope waits for your yes. The agent's job is to prepare the kickoff and surface the questions; the decisions stay with you. Run it that way and a bad handoff costs you two minutes of reading, not a mis-sent email to a brand-new client.

If you want to see one more agent built end to end before you try this, the AI invoice assistant walkthrough is the same shape on a different job. Otherwise, take the prompt above, run it once on a single sample client, and check the whole handoff.