Free course 3
Agents. Set up and lead.
In this course you will learn to
- build a project on three levels in your own folder
- give a worker a task from a template and accept the result by report and check
- move the work to a new chat without losing anything
Task or project
Big work is a project: it needs a folder, not one long chat
One long chat
“Let us discuss everything about the book exchange here”
The longer it runs, the more junk piles up: rejected versions, edits, side topics. The model (the program that writes the chat's answers) gets confused and forgets.
Five signs of a project
- Too bigone chat will not finish it
- Several filesthe result is not one document
- Stagesfirst one stage (sprint), then another
- Memorydecisions must outlive a stage
- You will return laterin a day or a week
One task lives in a chat. A project lives in a folder: chats come and go.
AI as a member of staff
An agent does exactly what you asked, and no more
- A vague task misses the goal. An agent (a chat you gave a role and a task that carries out the steps itself) will not do what you did not name.
- No control, no result. An agent remembers only what is in front of it (its context) and the files.
- No feedback, no improvement. Once finished, the agent forgets you.
A rough first version is raw material: criticising it is easier than writing from scratch. The goal, the numbers and what becomes a task are yours to decide.
Levels of a project
Project, stage, work chat
| Level | What it is | The book exchange |
|---|---|---|
| Project | The whole: the goal everything else serves | hold the exchange on Saturday |
| Stage | An intermediate result that is checked before moving on | announcement, schedule and rules are ready |
| Work chat | One separate task | write the announcement text |
One chat, one task: materials go in, a known result comes out. Two tasks in one chat get mixed up.
Three levels
Three levels of agents, and you above them
The owner (you)
Agents, top to bottom, each a separate chat with its own role
The navigator leads, holds one plan, asks you where a choice has to be made (a fork in the road), and never edits the work itself
The orchestrator plans and is the only one who changes files
Workers do one task each and end
Never handed to agents
The goal and priorities
Dates, money, limits
What becomes a task
In our example you are the owner, the navigator leads the preparation, the orchestrator prepares the files, a worker checks the dates. Whoever produces does not judge.
The navigator
The navigator leads: one plan and questions at forks
- One plan: a single place that says what comes next. There is no second list.
- A task needs your yes: before it, a proposal; after it, an obligation.
- A question to you has four parts: the question; the context; three options with a plus and a minus; its own argued answer.
- Accepts after a check, and hands big work to the orchestrator instead of editing it itself.
While a question to you is open, the work that depends on it does not start: work done before the answer gets redone.
The orchestrator and the worker
The orchestrator changes files, a worker does one task
| Role | Does | Files |
|---|---|---|
| Navigator | Gives the orchestrator an assignment (the overall job), accepts the result | never edits them |
| Orchestrator | Plans the assignment, writes each worker a brief (a written instruction), calls them and checks their reports | the only one who changes them |
| Worker | One task from a written brief, then ends | reads and reports |
A worker does not plan, widen the task or decide for you: at a fork it returns the question.
Stages and checks
A stage: start, work, result, check
- Start: what must happen for the stage to start. Example: you approved the date and place.
- Work: several work chats, one task in each.
- Result: the files left in the folder: announcement, schedule, rules.
- Check: a concrete criterion, not “seems fine”: three files in place, dates checked, no contradictions.
Only tasks that change different files run side by side. Two tasks on one file overwrite each other.
Project memory
The project folder is the memory, a chat is a consumable
- Everything important leaves the chat for the folder. What was not taken out is lost to the project.
- A result is something you can open: a file, a table or a written decision. No such result, the task is not closed.
- The pointer file at the top level of the folder: stages and their status, key files, open questions. A new chat gets up to speed from it.
A month on, you open the book exchange folder and from the pointer file understand in a minute where you stopped.
A gift
The folder template and the roles card
Practice: set up the book exchange project folder in one hour
- The folder template: the pointer file “Start here”, the files “Plan”, “Decisions”, “Questions” and the folders “Work”, “Reports”, “Summaries”.
- The roles card: owner, navigator, orchestrator, worker on one sheet: what each does and what each never does.
Setting up
An agent's rules must arrive by themselves, not by request
By request
“First read the rules file”
The agent may skip it, you may forget. Not read, and the work carries on as if nothing happened.
Automatically
- Loadingan assistant on your computer reads the rules file by itself as soon as you point it at the project folder; a plain chat does not do this, so paste the file as your first message (see slide 12)
- Contentrules only, no history and no stories
- Fileone file per role
- Checkask first thing which rules the chat has loaded
If the rules did not arrive, the agent works with no plan. So the first question to a new chat: “Which rules have you loaded?” Assistants on your computer do this (slide 12); in a plain chat, paste the rules file as your first message.
Where to run agents
Three places to work, from simple to strong
| Place | What it can do | Take it if |
|---|---|---|
| A plain chat | One task; nothing is kept between conversations | you need a one-off text or answer |
| A chat with files and projects | Keeps the materials and instructions of a project | you lead a project of several documents yourself |
| An assistant on your computer | Reads and changes files in the folder you choose, runs several workers | you need the three levels of this course |
Do not climb higher than the task needs.
If you do not have an assistant on your computer, do the practice in three plain chats: copy the files between them by hand, and the orchestrator sends you the finished text of each file. Product features change: check the product's own description.
A gift
The worker's brief: five blocks
A worker knows only what you wrote in the brief: what is not there does not exist for it
- 1. Goal and how to tell it is done: one sentence on what must exist, and a clear way to check it is done.
- 2. Context and inputs: 3 to 5 facts this task needs, and the files to read first.
- 3. What you may change, and what you must not: the exact list; working notes in one place, deleted before the end; if a decision is needed, stop and return it.
- 4. Steps or constraints: numbered steps, or limits: length, tone, allowed sources.
- 5. What to hand back: the files and a report in the seven-field shape.
The orchestrator's cycle
The orchestrator's five steps
- Take the assignment from the navigator and write down what the output must be.
- Cut it into tasks and write a brief for each from the template.
- Start the workers: together if they touch no common file, otherwise one after another.
- Wait for all of them and check their reports itself, not take them on trust.
- Make the changes to the files and hand the result to the navigator as a report.
One cycle, one assignment. A decision that is not its own, the orchestrator returns to the navigator.
A gift
Handing work back: a report of seven fields
The report reads in seconds, and a gap in it shows at once
- The same seven fields every time: 1. what was done; 2. files changed; 3. how it was checked; 4. what was not done; 5. open questions; 6. risks; 7. status. Write “none” only after you looked.
- Five honest statuses: DONE, FAILED, CANNOT VERIFY, PARTIAL, BLOCKED (cannot go on without your decision or someone else's file). FAILED, CANNOT VERIFY and BLOCKED are honest answers; never upgraded to DONE because the claim sounds plausible.
Checking
Whoever produces does not judge; a check can be repeated
- Another party judges: a fresh chat or you. A chat does not catch its own blind spots.
- A check can be repeated: claim, how it was checked, result, status side by side. “Looks fine” is not a check.
- “No errors” counts only if the check can find them: plant a known error and make sure it is found.
The worker writes: “all dates match”. The orchestrator runs the check itself and plants a date that is known to be wrong. If it is not found, “no errors” means nothing.
A gift
The navigator's checklist: eight checks
All eight, every time: one fails and the work goes back with the check number and the reason
- 1. the result matches the brief's criterion for done; 2. it was checked by someone who did not make it.
- 3. the check can be repeated; 4. it is clear how much was checked and how we made sure the check works.
- 5. nothing changed outside the allowed scope; 6. every figure says where it came from and when it was taken.
- 7. open questions and returned decisions went to the owner; 8. the plan and the pointer file are updated.
A gift
A tired chat: move it, do not repair it
Every agent's memory is finite. A chat that drifted is not repaired: it is replaced by a new one.
- A hand-over summary (snapshot) of seven parts: goal; decisions taken; where things stand now; next step; open questions; files to read first; what went wrong. Take figures and file names from the folder, not from the chat's memory.
- Only the next chat can test the hand-over summary, not its writer: have the new chat say where the project stands. Keep the old one open to answer questions, but give it no work.
Practice · one hour
Prepare the book exchange on three levels
- Folder: create it from the template and fill in the pointer file.
- Navigator (first chat): state the goal, let it draw a plan of three stages and ask you about date and place. Answer before work starts.
- Orchestrator (second chat; best in an assistant on your computer, see slide 12): assign the announcement, the schedule and a list of rules; let it change the files.
- Worker (third chat): from a five-block brief, check the dates and find contradictions; a report in seven fields.
- Acceptance: the navigator accepts after a check. Whatever is yours, you decide.
How it went. The course author answered and checked in the owner's place. The navigator held the task until three questions were answered. The orchestrator added “tea” on its own. The worker only read the dates (14 of 14), without a rule-based check. A new navigator returned the work: a return is a normal outcome.
A stalled project
Four signs and the repair
| Sign | What you see | Repair |
|---|---|---|
| The navigator mixes up stages | answers with yesterday's situation | move to a new chat from the hand-over summary and the pointer file |
| Contradictory briefs | different wording for similar jobs | close the chat that mixed levels; briefs from the template |
| The folder is a dump | nobody knows what is where | stop, tidy up, rewrite the pointer file from what is there |
| You do not remember where you stopped | you dread opening the chat | a strong signal: check the folder against the pointer file |
One sign is normal; two or three together mean act. The owner's good habits: do not treasure chats, do not mix levels or tasks, do not carry unfinished things forward, keep the pointer file.
Course summary
All your tools
05
The project lead kit
Six files: roles, folder, brief, hand-back, checklist, hand-over summary.
Download the kitNext, course 4: we launch a small project by a strict order of work (a protocol).
Nothing irreversible happens without your yes: no payment, signature, deletion or publication
We plan the demo version for November 2026 and the working version, with licences on sale, from 1 January 2027.
Go to the SANKORD site and subscribe there to the project’s updates.
Choose another course