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:

text

□ 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 directly.

text

[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 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:

text

@notes-organiser(paste the meeting notes)

What to check

text

□ 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.

6. Publishing

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

What to do alongside publishing

text

□ 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?

Answer

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

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

Answer

The instructions themselves. Correcting it in conversation only fixes that instance; editing the instructions carries forward.

3. Why keep it private at first?

Answer

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

Now attach external tools → Connecting an MCP server