Designing Agents

How to design and plan an AI agent — before you write a line of code.

agent/instructions.mdskills/tools/memory/channels/

An agent is a designed system — written files first, code later.

First principles

An agent is not a chatbot

A chatbot answers. An agent acts — it runs a loop: read the goal, decide, use a tool, check the result, repeat until done.

1

Read

The goal and the context it has in hand.

2

Decide

What to do next — or when to stop.

3

Act

Call a tool — hands in the world.

4

Check

Did it work — and what’s next?

Don't brief a script. Brief the permissions — what it can do, and where it must stop.

Agents you know

You already work with agents

Before designing one, notice the ones on your desk. Each of these is a pre-configured agent — someone else already wrote its brief, chose its tools and set its limits.

1

Copilot, Codex, Claude code

coding agents.

Read your repo, write code, run commands — briefed by rules, skills and project context you supply.

2

Figma Make

the prompt-to-prototype agent.

Describe a product; it builds a working prototype in code. You supply intent and design context; Figma supplies almost everything else.

3

Figma design agent

the canvas agent.

Lives in Figma Design, works beside you on the canvas using your real components, tokens and variables — not placeholders.

Different jobs, same species — each one runs the loop from the last slide.

Agents you know

Same anatomy, different decisions

Run the three through the six parts and the design decisions surface immediately — someone made every one of these choices.

Copilot, Codex, Claude code

Figma Make

Figma design agent

Instructions

Mostly yours — rules, skills and project context re-brief it per repo

Mostly Figma's — you add the prompt and attachments

Figma's fine-tuning + your connected libraries and skills

Tools

Files, terminal, MCP servers — incl. writing to the Figma canvas

Code generation inside its own sandbox

Canvas edits with your components, tokens and variables

Memory

Your repo and session context

The project it's building

The file, your libraries, shared chat threads

Guardrails

Your review; command approvals

Sandboxed output — it can't touch production

Undo everything; it never publishes to your shared library — you do

Watch out: Pre-configured means pre-decided. Every cell above is a design decision somebody made — mostly not you.

Agents you know

The customisation surface is yours

You can't rewrite these agents — but each one leaves a surface open. Working that surface is agent design.

1

In coding agents

Write rules, skills and project briefs for your repo. That's instructions, skills and guardrails — the first three parts of this talk, in markdown.

2

In Figma

Connect the right libraries, write a skill for your team's conventions, decide what the agent may touch. Context in, quality out.

3

In both

Your design system's rigour now sets the ceiling. Well-named tokens and documented patterns are what agents build with; messy systems make messy agents.

When you write a rules file or a Figma skill, you're not configuring software — you're briefing a colleague. The rest of this talk is how to do that well.

How to design and plan agents

Design first, build second

An agent is a service, not a feature. It has users, journeys, failure states and trust to earn — so it deserves a discovery, not just a sprint.

Most of an agent is written, not coded — briefs, playbooks and rules in plain language
Boundaries come before behaviour — decide what it can touch and when a human steps in
Prototype with the cheapest material — a written brief you can critique before any build

1

Define the job

One user, one job, done well.

2

Design the boundaries

Tools, refusals and human checkpoints.

3

Build the smallest loop

Then test, learn and grow it.

Anatomy

Every agent has the same six parts

Whatever the framework, the same structure keeps emerging. The next six slides take them one at a time.

1

Instructions

Its role, voice and rules — the design brief, read before every turn.

2

Skills

Specialist playbooks loaded only when the moment calls for them.

3

Tools

Typed actions it can take. If it isn’t a tool, it can’t do it.

4

Memory

What it keeps — in the moment, and sometimes between sessions.

5

Channels

Where people meet it — web, Slack, email, API and scheduled runs.

6

Guardrails

Designed limits — approvals, sandboxes, refusals and cost caps.

Part 1 of 6

Instructions — the design brief

One plain-language file, read before every response, that gives the agent its job, voice and rules.

You decide

The role, and the one job it does well
Voice and tone — it's a persona and style guide
What it must refuse, written on day one
What a good answer looks like — give examples

Watch out: “Be helpful” is not a brief. Vague instructions produce vague agents.

instructions.md

You are a research assistant

for a design team.

- Plain English, no jargon

- Cite a source for every

claim, or say you can't

- Never invent findings —

ask for the data instead

Part 2 of 6

Skills — playbooks on demand

Markdown playbooks the agent loads only when the topic comes up — progressive disclosure, applied to prompts.

You decide

Which procedures deserve a playbook at all
The trigger — when should this knowledge load?
The steps, the quality bar, the edge cases
One skill = one procedure; keep them small

Watch out: Skills that overlap or quietly contradict the instructions.

skills/

usability-testing.md

service-assessment.md

design-handoff.md

accessibility-audit.md

user-story-writer.md

ui-planner.md

information-architect.md

loaded only when relevant — the agent stays focused

Part 3 of 6

Tools — the hands

Typed actions the agent can take. If it isn't a tool, the agent can't do it — the tool list is your safety boundary.

You decide

The fewest tools that get the job done
Read vs write — reading is cheap, writing needs care
Which tools pause for human approval
What each tool returns when things go wrong

Watch out: Giving it every tool “just in case”. Scope is the whole point.

tool scope

read_research_repo

search_web

connect_figma

read_figma_frame

draft_report

publish_report

“publish” and Figma writes wait for a human — by design

Part 4 of 6

Memory — what it carries

The context an agent keeps — within a session, and sometimes across them. Memory is an expectation-setting problem.

You decide

What's worth remembering vs deliberately forgotten
Whether the user can see, edit and delete it
How memory is signalled — surprise erodes trust
Privacy: what must never be stored at all

remembers

project context

preferences

past decisions

forgets

credentials

sensitive data

one-off asides

Watch out: Hidden memory. Users assume either too much or too little — both break trust.

design both lists on purpose — and show users where they stand

Part 5 of 6

Channels — where people meet it

The same agent can serve many surfaces — web chat, Slack, email, an API. Each channel is a different context of use.

You decide

Which surface actually fits the job to be done
Tone and length per channel — Slack ≠ formal report
How interruptions and approvals appear in each
Where the human handoff lives when it's stuck

one agent, many doors

web chat

slack

email

api

scheduled runs

Watch out: Designing only for the demo channel, then shipping to Slack unchanged.

same brain, channel-appropriate manners — a classic service design pattern (one service, many touchpoints)

Part 6 of 6

Guardrails — designed limits

Approvals, sandboxes, refusals and limits. This is error prevention — classic interaction design, applied to an actor.

You decide

Which actions are irreversible — gate every one
What happens on failure: recovery, not dead ends
When it should escalate to a human, and how
Rate and cost limits, so mistakes stay small

the approval gate

1agent proposes
2human approves
3action runs

Watch out: Bolting safety on at the end. Guardrails are architecture, not paint.

automate the work, not the accountability

Planning

Five questions before any code

1
Who is it for, and what one job does it do?
An agent with two jobs does neither well — scope like a service, not a feature
2
What must it never do?
Write the refusals into the instructions on day one
3
What does it need to touch?
List the tools and data — fewest possible
4
When must a human step in?
Place approval gates on anything irreversible
5
How will you know it's working?
Write evals: test cases with pass criteria — usability tasks for an agent

Anti-patterns

How not to build an agent

Six mistakes designers are perfectly placed to catch — because they're all design mistakes, not code mistakes.

Starting with the framework

Pick the job first. Tech chosen before purpose is a solution looking for a problem.

Writing “be helpful”

Vague instructions produce vague behaviour. Brief it like you'd brief a new hire.

Granting every tool “just in case”

Each extra tool widens what can go wrong. Scope is the safety model.

Skipping human checkpoints

Automate the work, never the accountability. Gate the irreversible.

Hiding the agent's limits

Say what it can't do. False confidence costs more trust than honest limits.

Shipping without evals

You'd never launch a service without usability testing. Test cases, pass criteria, every release.

Start small

Ship one loop, then grow it

1

Write the instructions first

No code, no framework — just the brief. Critique it like any design artifact.

2

Add one skill and one tool

The smallest useful loop. Resist the platform temptation.

3

Version it like design work

Briefs, playbooks and evals live in git — reviewable, diffable, shared.

Designers are already equipped for this. Agents are briefs, playbooks and guardrails — and those are ours to design.

Thank you