Playbook · Build an agent — no code

Build an agent. Without writing code.

An "agent" is a thing Claude does — not a thing you build. It's a Skill, a Project, and a few Connectors, arranged so Claude can pull context, draft work, and surface it for you to decide on. The agent does the typing. You do the judging. Five build steps, one working example, and a clear-eyed look at where the human adds value at every step.

// A note on currency The Claude features used in this playbook — Skills, Projects, Connectors, Memory — are all current as of May 2026. Anthropic ships fast: new agent features arrive monthly. The shape of an agent doesn't change. The buttons and menus might. Verify the specifics in your own Claude.ai before you build.

// Who it's for

Anyone who's built a Skill already

// Time investment

~2 hours to build · keep refining

// You'll need

Claude.ai + 1–2 Connectors

// You'll walk away with

A working meeting-prep agent

01 —

// First — what we mean by agent

Agents come in three sizes.

"Agent" is one of the most over-loaded words in AI. Before we build, it's worth being honest about which kind we're building — and which kinds we're not. This playbook targets the smallest, most useful, and most under-rated of the three.

// LIGHT

The helper.

Claude with the right Skills, Project, and Connectors — chained to do a real job. You trigger it. You review the draft. You take action.

Needs · Claude.ai · no code

// MID

The workflow.

A scheduled or triggered agent that runs through a defined workflow with multiple tools. Some setup, possibly some scripting. Still human-reviewed at the key steps.

Needs · Cowork or scripting

// HEAVY

The autonomous.

Multi-step, long-running, recovers from failures, takes actions unattended. Real engineering. Powerful — and dates fastest, with the biggest failure modes.

Needs · real engineering

Why start light

Light agents are useful, safe, and immediate. They surface drafts for you to approve. They don't act unsupervised. Most of the value most professionals will get from agents in 2026 sits firmly in this column. Build light. Earn the right to go heavier.

02 —

// The working example

A meeting-prep agent.

Universal problem. Everyone goes to meetings. Everyone wishes prep was better. Everyone has the inputs already — calendar, past notes, action lists, prior emails. This is the agent we'll build across the five steps below.

// The job, in one sentence

Trigger

I type "prep me for my next meeting" in a Claude.ai chat inside the meeting-prep Project.

Action

The agent pulls my next calendar event, fetches relevant emails from that person, retrieves any past Claude chats about them, and drafts a one-page brief — who, why, three open actions from last time, three suggested talking points.

Review

I read the draft, fix what's wrong, add what's missing. The agent never sends, schedules, or commits anything. Everything that leaves my screen leaves with my signature.

03 —

// The five build steps

Step one. Define the job.

Most agents fail because they were never properly scoped. "An agent that helps with meetings" is not a job — it's an ambition. The first move is to write down exactly what this agent does, what it doesn't do, and what success looks like.

Before any tools, any prompts, any setup — write a one-paragraph job description for the agent. Then a list of three things it does. Then a list of three things it explicitly doesn't do. The "doesn't" list matters as much as the "does" list.

01

Write the one-paragraph job description.

Three sentences. What the agent is. Who triggers it. What it produces. Plain English. If you can't write it cleanly, don't start building.
02

List the three things it does.

Specific actions. Not "helps with meetings" — "reads next calendar event, fetches related emails, drafts a one-page brief". If the list has more than three items, the agent is doing too much. Split it into two agents (Playbook 08).
03

List the three things it doesn't do.

What stays your job. "Doesn't send emails. Doesn't update the calendar. Doesn't decide anything." Boundaries upfront prevent scope creep and protect the human-in-the-loop.

// Working example · job description

Description

"A meeting-prep helper that runs when I ask it. Given the next event in my calendar, it pulls the relevant context — past notes, recent emails, open actions — and drafts a one-page brief I review before the meeting."

Does

(1) reads my next calendar event · (2) finds relevant past chats and recent emails about that person · (3) drafts a one-page brief with three open actions and three talking points

Doesn't

(1) doesn't send emails or schedule anything · (2) doesn't decide what's important — flags items, lets me pick · (3) doesn't act without my prompt — only runs when I ask

★

// Where you add value

Deciding what's worth automating.

The agent doesn't know what's worth doing. You decide that. A good agent automates the part of the work that's mechanical — fetching, drafting, structuring — and leaves you the part that needs judgement. If you can't separate the mechanical from the judgemental, the agent will absorb both and quality will drop.

Tools are how the agent reaches outside the chat — to your calendar, your email, your past conversations. In Claude.ai, this is Connectors. The discipline isn't picking all the tools — it's picking the minimum needed for the job you defined in Step 1. Every tool you add is surface area for things to go wrong.

04

List the two or three tools the agent needs.

Cross-reference your "does" list from Step 1. For each action, what does the agent need to reach? Calendar? Email? Past chats? Drive? Aim for two or three. If you need more, the agent is doing too much.
05

Connect each one in Settings → Connectors.

Claude.ai's Connectors are one-click authorisations to services you already use. You sign in once. The connection stays. Claude can read what you've granted access to — and only that.
06

Decide read vs write deliberately.

Many Connectors let Claude both read and write. Default to read-only for a first agent. Write access is a fast track to mistakes that can't be undone. Earn write access by demonstrating the agent works reliably on read.

// Working example · the meeting-prep agent's tools

Calendar

Google Calendar Connector · read only. Pulls the next event, attendees, location, agenda notes.

Gmail Connector · read only. Searches recent emails from or to the attendee.

Past chats

Search past chats · built into Claude.ai. Finds prior conversations about this person or topic. Per Playbook 02 — already on if Memory is enabled.

Explicitly not wired

Calendar write. Gmail send. Drive. Slack. The agent doesn't need them for this job — and not having them is the safety net.

★

// Where you add value

Deciding what the agent can touch.

The agent will use whatever you give it access to. You decide what it gets. Read-only is the safe default — the agent can see, but it can't change anything. As the agent earns trust, you can grant more reach. The cost of an over-permissioned agent isn't measured in productivity; it's measured in the email that got sent before you read it.

"Loop" is the sequence of moves the agent takes — fetch, think, act, check. In Claude.ai, this is captured in two places: the Project instructions (where the standing rules for this agent live) and the Skill (the trigger phrase and the action recipe). Together they tell the agent what to do, in what order, and when to stop and ask.

07

Create a Project for the agent.

Per Playbook 02: Projects → + New Project → "Meeting prep". Project instructions describe the agent's job, the tone of the output, and the rules it must follow (e.g., "lead with the meeting time, name the attendee, list three open actions").
08

Build the Skill that runs the loop.

Per Playbook 03: use the skill-creator to write a Skill triggered by the phrase prep me for my next meeting. The Skill spells out the steps: (1) get next calendar event · (2) fetch emails from attendee · (3) search past chats · (4) draft the one-page brief.
09

Decide where the agent stops and asks.

Build pauses into the loop. "Before drafting, show me the three actions you found from past chats — am I missing any?" Or: "If you can't find any emails from this person in the last 30 days, ask me before assuming there's no context." Pauses are how the human stays in the loop.

// Working example · the loop, in plain English

Trigger

I type prep me for my next meeting in any chat inside the Meeting Prep Project.

Step 1

Agent reads Google Calendar · returns next event with attendees, time, agenda.

Step 2

Agent searches Gmail for last 30 days of email with that attendee. Pulls subject lines and key points.

Step 3

Agent searches past chats for prior context about that person or topic. Pulls open actions.

Pause

Agent shows me what it found before drafting. "Here are the three open actions I found. Want me to draft the brief now, or did I miss anything?"

Step 4

Agent drafts the one-page brief. House style from the Project instructions. Three sections: who/why · open actions · talking points.

Stop

Agent stops. Doesn't send, schedule, file, or commit anything. The draft sits in chat. I edit and use as I see fit.

★

// Where you add value

Deciding where the agent stops and asks.

The pauses you build into the loop are the most important design decision in this playbook. Without pauses, the agent races to a conclusion. With well-placed pauses, the agent becomes a collaborator. A good rule of thumb: pause before any step that depends on judgement, and pause before any step that creates something visible to others. Speed is cheap. Trust is expensive.

Guardrails are the rules that stop the agent from doing damage. They live in the Project instructions and in the Skill. The job isn't to prevent every mistake — agents will make mistakes — it's to prevent the kinds of mistakes that can't be undone: emails sent in your name, meetings scheduled without context, decisions taken instead of suggested.

10

Write the "never" list.

Hard rules. Things the agent must never do, regardless of how the request is phrased. "Never send an email. Never accept or decline a meeting. Never delete anything. Never invent attendees, dates, or actions." Paste these into the Project instructions in plain language.
11

Add the "don't guess" rule.

Per Playbook 01 (Pattern 04): tell the agent what to do when information is missing. "If you can't find an open action, write 'No open actions found' — don't invent one. If you don't know the meeting topic, write 'Not stated' — don't guess." This single rule prevents most of the visible failure modes.
12

Add a review prompt at the end.

After the draft, the agent should explicitly hand off. "Draft ready. Please review for accuracy before using. Anything I should add to the standing instructions for next time?" Makes the review step impossible to skip — and lets you sharpen the agent in the same chat.

// Working example · the guardrails section of the Project instructions

Never

Never send an email. Never accept, decline, or schedule a meeting. Never modify the calendar. Never invent attendees, dates, action items, or commitments. Never assume the meeting is confidential or non-confidential — treat all content as potentially sensitive.

Don't guess

If you can't find an open action from past chats or emails, write "No open actions found from prior context." If the agenda isn't clear from the calendar event, write "Agenda not stated — suggest asking the attendee." If the attendee's role or relationship isn't obvious, write "Relationship not stated."

Review prompt

End every brief with: "Draft ready. Please review for accuracy before using. If anything was missing or wrong, tell me what to add to my standing instructions so the next brief is better."

★

// Where you add value

Reviewing before any action that can't be undone.

Guardrails are written by the agent's designer. You. The agent can't decide what would be embarrassing if it got sent, what would damage trust if it got wrong, what would breach confidentiality if it got shared. Those judgements are human. The guardrails encode your professional judgement so the agent can operate within it — and stops, asks, or refuses when it would step outside.

An agent earns trust gradually. The first ten times you use it, you read every word. The next ten, you read most of it. By the time you're skimming, the agent has earned that skim — through a track record you can point at. Trust is a function of evals (Playbook 05), not optimism.

13

Run it on five real meetings.

Not invented test cases. Five meetings you actually have this week. After each one, ask yourself three questions: was the brief useful? did the agent get anything wrong? did it miss anything important? Note the answers somewhere you'll see them.
14

Sharpen the instructions after each run.

When the agent makes a mistake, the fix isn't to retry — it's to update the Project instructions or Skill so it doesn't make that mistake again. "Stop suggesting 'discuss roadmap' as a talking point — that's not actionable." Per Playbook 05: every change triggers a re-run on the next few meetings.
15

Watch for the shape of the mistakes.

After 10–15 runs, patterns emerge. The agent is always missing one kind of context. The agent always over-confidently summarises one kind of email. The agent always proposes the same kind of talking point even when it doesn't fit. Patterns are addressable. One-offs are background noise. Spend your time on the patterns.

// Working example · two weeks of testing

Week 1

Five meetings prepped. Three useful, two slightly off. Pattern noticed: agent over-weighted recent emails and missed older context. Added rule: "When searching past chats, look back 90 days, not 30."

Week 2

Five more. Four useful, one wrong about an action. Pattern: agent assumed an action was open that I'd actually closed in another channel. Added rule: "For each open action, show the source — date and channel — so I can verify."

Trust earned

By week 3, the briefs are usable on first read. By week 5, I'm skimming — but I'm only skimming because I tracked the failures. Trust isn't a feeling. It's a record.

★

// Where you add value

Judging whether the output is actually right.

The agent can't tell you whether its draft is good. Only you can. Reading every output, in the early days, isn't a sign the agent isn't working — it's the work. The reward for that review isn't the brief in your hand; it's the sharper agent next week. Skip the review step and you skip the learning loop. The agent stays as good as it was on day one, forever.

The agent does the typing. You do the judging.

04 —

// Common pitfalls

Four ways the agent goes wrong.

Even simple agents fail in predictable ways. These are the four I've seen most — and the four I'd watch for in the first month. They're easier to fix early, before they become the reason you stopped using your own agent.

// Pitfall 01

The over-scoped first agent.

You write the job description and it has seven bullet points. The agent is a meeting-prep / note-taker / scheduler / follow-up / digest / approval-router / personal-assistant. Nothing in there works well, because nothing in there has been properly built.

The fix Cut the scope to one job. Three actions. Three things it doesn't do. The other six bullet points are the seeds of the next six agents — which is exactly what Playbook 08 is about.

// Pitfall 02

The over-permissioned agent.

Write access to everything from day one. Gmail send. Calendar modify. Drive write. The first time it gets something wrong, it gets it wrong in your name — and you can't quietly undo it.

The fix Read-only by default. Every write permission is a deliberate decision, not a default. Earn write access by demonstrating the agent works reliably on read. The discipline of "ask me before any action" is what makes the agent trustworthy.

// Pitfall 03

The silent agent.

No pauses. No "I found these — should I continue?". The agent races from prompt to output in one shot. You don't see what it did until the draft is done, and by then the wrong assumptions are baked in.

The fix Build at least one pause into the loop, ideally two. After data-gathering and before drafting is the sweet spot. The pause looks like friction; it's actually the leverage.

// Pitfall 04

The untested agent.

You built it, you tried it once, you declared it working, you forgot about it. Three months later you use it for something important and discover it's been quietly wrong for ten weeks. No-one was watching the failure rate, because no-one was tracking it.

The fix Playbook 05 applies here as much as anywhere. Run an eval on the agent. Five real meetings, scored against a simple rubric. Repeat any time you change the instructions. Trust is a record, not a feeling.

05 —

// Pre-flight checklist

Five questions to answer before you build.

Most failed agents fail because they were never properly scoped. Answer these five questions in plain English before you open Claude.ai. If you can't answer one, stop building and go figure that out first.

What is the one job this agent does?

In one sentence, no jargon. "It drafts a meeting brief from my calendar and recent emails." If your answer needs an "and" linking two ideas, you've described two agents.

What are the three things it does, and the three it doesn't?

If the "does" list has seven items, cut it back. If the "doesn't" list is empty, write one. Boundaries before behaviour.

What's the minimum tool access it needs?

Two or three Connectors, read-only. If you've listed five, the agent is doing too much. Every tool is surface area.

Where does it pause and ask you?

At least one pause in the loop, before any drafting that depends on judgement. If your loop is one straight line from trigger to output, add a pause.

What's the "never" list?

The hard rules. Never send. Never schedule. Never delete. Never invent. Write them down before you build, not after the first incident.

06 —

// What's next

What gets harder with a second agent.

A single agent is the simplest case. Add a second one — say, an agent that captures meeting notes after the meeting, or one that routes the open actions to the right channels — and three new problems show up that weren't there before.

// Playbook 08 · Build an agent team

Three things change when there's more than one.

The five build steps in this playbook still apply to each agent. But the moment you have two agents working on related jobs, you also have to think about what passes between them, who decides what runs when, and how you stay in the loop without becoming the orchestrator. That's a different playbook.

Handovers. What does Agent 1 pass to Agent 2 — and in what shape? Bad handovers create silent failures across the chain.
Orchestration. Who decides what runs when? A human? A schedule? A trigger from one agent to the next? Each has trade-offs.
Visibility. When something goes wrong three agents deep, how do you know which one was responsible? Single-agent debugging is easy. Team debugging needs design.

Read Playbook 08 →

Using this in practice?

The agent in this playbook is deliberately small. One job. Three actions. Read-only. Pauses for review. A "never" list. It looks unambitious next to the autonomous-agent demos in the keynote — and it's the version that actually works in the week-to-week, week after week.

The thread running through every step is the same: the agent does the typing, you do the judging. AI doesn't replace your judgement. It compresses the work between your decisions so you spend more time deciding and less time typing. That's the bargain. That's the unlock.

This playbook builds on every one before it: Skills as the loop, MCP / Connectors as the tools, Evals as the way you earn trust, Prompting as the language inside the instructions, Memory and context as the Project around it, Rollout as how it spreads. Playbook 08 picks up the next thread — what happens when one agent becomes a team.

Build an agent. Without writing code.

Agents come in three sizes.

A meeting-prep agent.

Step one. Define the job.

Write the job description.

Wire the tools.

Set the loop.

Add the guardrails.

Test and earn trust.

Four ways the agent goes wrong.

The over-scoped first agent.

The over-permissioned agent.

The silent agent.

The untested agent.

Five questions to answer before you build.

What gets harder with a second agent.

Using this in practice?