# Creating a sub-agent

> **What you will learn**
> This is a chapter for **doing**, not reading. We build one.

## What to build

Pick **a request you keep repeating.** Candidates look like this:

```
□ you produce the same kind of document every time
□ you review material against the same criteria
□ you often write emails in the same tone
□ you organise data the same way
```

In this chapter we build **"meeting-notes organiser"** as the example.

## 1. Start creating

Press **Create** at the top right of the agents screen and choose **Sub-agent.**

## 2. Basic information

| Item | Example | Tip |
|---|---|---|
| Name | `notes-organiser` | invoked as `@notes-organiser`. Keep it short |
| Description | "Turns meeting notes into an action item table" | one line a teammate can judge from |

**Do write the description.** As "no description" entries pile up in the list,
teammates stop knowing what to use.

## 3. The instructions — the most important part

Write [the four parts of a good instruction](/guide/ai-intent-context) directly.

```
[Role]
You organise meeting notes into an action item table.

[What you do]
When the user gives you meeting notes, produce a table in this form:
| Topic | Decision | Owner | Deadline |

[Rules]
- Include only decisions. Exclude anything still under discussion.
- If no owner is named, leave "TBD" and do not assign one.
- If no deadline is given, leave "TBD".
- Do not guess at anything not present in the source.
- Keep each cell to one short line.

[After the table]
Below the table, list "needs confirmation" items separately:
- items where the owner or deadline is TBD
- items where it is unclear whether it was a decision or a discussion
```

### The structure of these instructions

| Part | Corresponding element |
|---|---|
| Role | goal |
| Rules | **scope** (what not to do) |
| Format specification | done condition |
| After the table | additional output |

**All four lines under "Rules" are things not to do.** Exactly as
[writing scope as what not to do is effective](/guide/ai-intent-context) said.

## 4. Keep it private and test

**Leave it private at first.** Use it a few times, refine it, then publish.

Invoke it in a conversation like this:

```
@notes-organiser

(paste the meeting notes)
```

### What to check

```
□ did items still under discussion stay out of the table
□ did it avoid filling in TBD items
□ did "needs confirmation" come out correctly
```

## 5. Refining

When it does not come out as you want, **edit the instructions.** Correcting it
each time in conversation does not carry forward; editing the instructions does.

| Symptom | Add to the instructions |
|---|---|
| The table is too long | "at most 10 rows per meeting" |
| The tone is stiff | "informal internal document tone" |
| It misses something important | "always include budget and headcount items" |
| The format varies | put an example in |

**The last is especially effective.**
[One example is more precise than ten lines of explanation](/guide/ai-how-to-ask).

## 6. Publishing

When you are satisfied, switch it to **public.** Now the whole team can use
`@notes-organiser`.

### What to do alongside publishing

```
□ recheck the description (is it a sentence a teammate can judge from)
□ tell the team (built and unannounced means nobody knows)
□ share one example of when to use it
```

## What a good agent looks like

| Trait | Why |
|---|---|
| It does one thing | doing several makes the instructions vague |
| It states what not to do | the scope is clear |
| The format is fixed | results are consistent |
| The description tells you when to use it | teammates actually use it |

## Common mistakes

### Making one agent do several things

A do-everything agent that "organises documents and writes emails and
translates" does not work well. Build **one per job.**

### Writing short instructions

Writing only "organise the meeting notes" is no different from an ordinary
conversation. **The rules and format are what make building an agent worthwhile.**

### Building it and not telling anyone

Publish it without telling the team and nobody knows.

---

## Check yourself

**1. What should the "Rules" section contain to be effective?**

<details>
<summary>Answer</summary>

**What not to do.** Listing everything to do is hard, the things that must not be
done are few, and it clarifies the scope.
</details>

**2. Where do you fix it when the results are not what you want?**

<details>
<summary>Answer</summary>

**The instructions themselves.** Correcting it in conversation only fixes that
instance; editing the instructions carries forward.
</details>

**3. Why keep it private at first?**

<details>
<summary>Answer</summary>

**To use it a few times and refine it.** Publish it under-refined and teammates
try it, are disappointed, and never come back.
</details>

---

Now attach external tools → [Connecting an MCP server](/guide/cn-mcp)