One Blueprint, Eight Parts of an AI Agent Plan

Many people write an agent plan like this:

Build a meeting-notes agent.
Features: summarize meetings, extract tasks, draft emails, remind owners, analyze risks.

That's a feature list, and it only says what results you want. To make a plan executable and checkable, you also need to answer what lies behind each feature: its sources, its process, its limits and its evaluation. A meeting-notes follow-up agent serves as the complete example below, putting instructions, sources, tools, state, flow, guardrails and evaluation into one blueprint, and then checks whether the parts support the same goal.

A plan has to survive contact with reality, so keep asking behind each feature: where does the evidence come from, who executes it and how, where does it stop, who gets the result, and how would a mistake be noticed?

Answer those and you end up with eight parts: goal, instructions, sources, tools, state, flow, guardrails, and evaluation. The meeting-notes agent's goal can't stay "summarize the meeting." It becomes two checkable results, a task table and an email draft.

And when a deadline changes midway, you find out whether the table and the email change together, which is when you see whether the parts really fit.

01 What a blueprint has that a feature list lacks

To make a plan executable and checkable, answer at least these questions:

Where do the meeting records come from?
What if the task owner isn't clear?
What must never be made up?
Can it send email automatically?
Does it need confirmation before reminding owners?
How do you tell whether the result is good?

A minimal agent blueprint contains at least eight items:

Goal
Task instructions
Input material
Tools
Memory or state
Process steps
Guardrails and approval points
Evaluation method

Keep asking about one feature: where does its basis come from, how is it carried out, where does it stop, who gets the result, and how are errors found? These questions connect features, sources, process, boundaries and evaluation, and that's what lets the blueprint test whether the plan is feasible.

02 Goal, instructions and material

"Summarize the meeting" is too vague. A more specific goal is:

Turn the meeting records into an actionable task table and draft a follow-up email for after the meeting.

This goal names two results that can be checked: a task table and an email draft. Next comes the task instruction:

This agent reads the meeting records and extracts confirmed action items, owners, deadlines, risks and open questions. It doesn't write discussion suggestions as confirmed tasks, guess owners or deadlines, or send emails automatically. Its output is a task table, open items and an email draft.

This instruction puts the goal, duties, boundaries and output together, which gives a basis for choosing material and tools. The material includes at least the full meeting record, the attendee list, project background and the history of the task table. When the material has gaps, say what's missing, which result it affects and who should fill it in.

An attendee list shows who was there, and the owner comes from an explicit assignment in the record. If the record says "finish the API changes next week" and names no owner, the task table should honestly say "owner not specified." Later the user confirms that Chen will handle it, and that confirmation is recorded as added evidence:

Meeting record: owner not specified
User later confirmed: Chen is responsible (record who confirmed it and which entry it changes)

These two entries stay separate, so a reader can see which one was confirmed after the meeting.

03 Tools and state, designed as needed

Whether a meeting-notes agent needs tools depends on the scope of the task. This example only delivers a task table and an email draft. With a complete meeting record at hand, the agent can work on the text directly, and it only needs read-only tools when it has to look up background and past tasks. Creating to-dos, saving drafts to a mailbox and sending email all write to outside systems, and since this example only delivers text, they aren't connected for now. If you add execution abilities, change the instructions, the tool permissions and the approval process together.

State lets a later step pick up the result of an earlier one. This agent needs to record at least:

Which meeting this is
Which action items have been extracted
Which owners or dates are unclear
Which changes the user has confirmed
Whether the email draft has been approved

This state avoids repeated extraction and missed confirmed items, and keeps the agent from writing unconfirmed content into the official email. If the user confirms only some of the owners, what next? Keep the state for the owners not yet filled in, deliver what has been confirmed, and list the remaining gaps in the draft. Tools and state both add maintenance cost. If the notes are only for personal use, "generate a task table" and "draft an email" are enough. Once it joins a team workflow, connect the task system, email tools and the history of the task table.

Anthropic’s guide to building agents likewise starts with retrieval, tools, and memory, and recommends the simplest approach that meets the task.

04 Flow and checkpoints

Break the meeting-notes agent into a flow:

Step 1: Read the meeting record and identify clear action items.
Step 2: Extract owners, deadlines and the source text.
Step 3: Mark risks and open questions.
Step 4: Generate the task table.
Step 5: Ask the user to confirm unclear items.
Step 6: Draft the follow-up email from the confirmed task table.
Step 7: Deliver the task table, open items and email draft, and let an authorized person decide whether to send or log them.

Put checkpoints before the higher-risk steps, so a person checks the basis before deciding whether to continue. This agent needs at least three:

05 Guardrails and evaluation

The guardrails for the meeting-notes agent can read like this:

Draw conclusions only from the meeting record and the material provided.
When an owner or deadline is unclear, write "unspecified."
Treat suggestions, guesses and topics under discussion as open items, and keep them out of confirmed tasks.
Leave sending to people: no automatic email.
Anything touching promises, budgets, contracts or launch dates must be confirmed by a person.

Each rule maps to one specific risk and one action, so it can be put to use right away. The evaluation method should also be simple and checkable:

These questions turn "does it work well?" into pass conditions and failure reasons you can see. Say the record reads "maybe ask Chen to hand in the first draft on Friday, pending her confirmation." Where the record says "maybe, pending confirmation," the expected output keeps "to be confirmed." Where the record clearly says "Chen submits on Friday," the expected output writes it as a confirmed task. Put both kinds of records into the test. If the agent marks everything "to be confirmed" or writes everything as confirmed, it fails.

For evaluation, Claude’s guidance on success criteria and tests starts with specific, measurable goals, then builds tests against them.

06 Check that the parts connect

The user moves the deadline from Friday to next Monday. The task table is updated, but the email still says Friday. The problem sits between the table and the draft: the new information, once confirmed, never made it across. Use this change to check whether the parts of the blueprint connect:

1. Update the task table from the confirmation record.
2. Record the current version in the state.
3. Generate the draft from that version.
4. Before delivery, check that the dates in the table and the email match.

Then look at five links between the parts:

Task instruction ---> does it decide the choice of material and tools?
Each tool        ---> does it appear in a specific step of the flow?
State            ---> does it record each step's output and support the next step?
Checkpoints      ---> do they sit before steps that have real consequences?
Evaluation       ---> does it check against the result the goal defines?

If any link doesn't connect, check whether the corresponding design is missing or redundant. Finally, put the meeting-notes agent's complete blueprint into one table:

After the blueprint is written, choose an implementation by how it's controlled:

Paste in text and produce a draft by fixed steps  -> an ordinary assistant or a fixed workflow is enough
Decide on lookups, clarifications and progress from information gaps  -> only then do you need an agent

That brings us back to the question in how to tell whether a product is a real agent. When you later study an agent SDK, RAG, function calling or evals, you can return to this diagram and see which part each one supports. It also helps to revisit the earlier articles on writing task instructions, choosing tools and setting up guardrails.