A few weeks ago I wrote about how I stopped coding and started orchestrating. Ten terminal tabs, three startups, me pressing Enter all day. Then I moved the whole setup to a Mac mini, put an orchestrator agent in charge of a pool of workers (coding agents, a design agent, a DevOps agent, an accounting agent), and went from 1 PR a day to 22.
I called myself an orchestrator. Then a manager of orchestrators. Both titles felt a bit grand for what I was actually doing.
With my daughter a couple of weeks away, I started re-reading my favorite book of Adler psychology, the courage to be happy. One idea stuck: the job of a parent is not to do things for the child, or to tell the child what to do all day. The job is to educate the child so that one day they can fend for themselves.
I read that sentence with my phone on my knee and the orchestrator asking me for the third time that morning whether it could run a migration.
And it clicked. I had the wrong job title all along.
You are not a product manager. You are an educator.
The industry has settled on two words for what humans do with AI agents: product manager and orchestrator. I think both are wrong, and the wrong word leads to the wrong setup.
A product manager writes a ticket, hands it over, and waits for the result. That is how I used my first workers. Every task started from zero. The agent didn't know my codebase conventions, didn't know we deploy with Kamal, and didn't know I hate service objects with more than one public method. So I wrote it all in the ticket. Every. Single. Time.
An orchestrator is worse. An orchestrator decides every move. That is the setup that turned me into a finger pressing Enter. The agents had no autonomy because I had given them none. I was not slow because the AI was slow; I was slow because I was the bottleneck in every decision.
An educator does something different. Adler is careful with the word: a teacher transmits facts; an educator shapes a person who can live on their own. An educator spends time up front so that later the child does not need them. You explain how the world works, you let them try, you correct, and you step back a bit more each time. The goal of the educator is to become unnecessary.
That is exactly what happened with my orchestrator without me noticing. It did not become useful because I gave it better tickets. It became useful because it knows how I work, what security I need, which decisions it can take alone and which ones to escalate to me. I educated it, mostly by accident.
Once I saw it as education, I started doing it on purpose.
Human knowledge, and AI knowledge
Adler makes a distinction I found useful. There is the knowledge you learn at school (maths, history, how to read), and there is a second kind of knowledge nobody writes an exam about: the shared rules for living with other people. You stop at a red light. You don’t talk in the cinema. You bring something when you are invited to dinner. Nobody is born with this. Every generation learns it from the previous one, and a child who does not learn it cannot function in society no matter how smart they are.
AI agents are in exactly that situation. The model is the smartest kid in the class. It knows Rails better than I do, it has read more Postgres documentation than any human alive. What it does not know is how to live in my house.
I started calling this AI knowledge: the basic set of rules an agent needs to perform tasks and fulfill its goals inside a specific environment. Not model weights, not prompts. The equivalent of knowing where the traffic lights are.
For my setup, AI knowledge looks like this:
Where things live: which repo is which startup, where the Obsidian vault is, which folder is the accounting drive.
How we ship: branch naming, PR size, what a green pipeline means, that nothing deploys on Friday evening Bali time.
What is dangerous: which commands need a human, which tables you never touch in production, what counts as a customer-facing change.
Who does what: the orchestrator dispatches, coding workers write and test, the design agent owns the UI, the DevOps agent deploys and monitors, the accounting agent does the books, I do strategy and the final say on money.
What already happened: decisions from co-founder meetings, bugs we already fixed last year, features we tried and killed.
None of this is in the model. All of it is in markdown files, a vault, and a handful of CLAUDE.md files that I keep adding to every time an agent does something that makes me say “no, not like that”.
The test is simple. If a brand new worker spins up tomorrow, can it fend for itself in my codebase with zero instructions from me? If the answer is no, I have not finished educating it. I have just written a very long ticket.
Knowledge only survives if it gets passed on
Human knowledge persists for one reason: people pass it forward. My parents taught me, I will teach my daughter; she will teach hers. Nobody re-derives the rules of society from scratch every morning.
Agents, by default, do exactly that. Every session starts from zero. Every worker is a newborn. Whatever a worker learned yesterday (that the test suite is flaky on the mailer specs, that the staging database has a weird extension) dies with its context window.
So the second part of the educator’s job is to make sure the knowledge outlives the one who learned it.
In practice, this means agents educating agents. Here is how it works in my setup:
A worker finishes a task and writes what it learned into the vault: a gotcha, a decision, a convention it discovered by breaking something.
The orchestrator reviews it. If it is a real rule and not a one-off, it goes into the shared AI knowledge. If it is noise, it gets dropped.
The next worker that touches that area reads it before starting.
I am not in that loop. That is the point. If I were the only channel through which knowledge moves between agents, I would be back to being the bottleneck, just with a nicer job title.
The nice side effect: when the orchestrator stops me from building a feature we already tried and killed last year, that is not the orchestrator being smart. That is a worker from eight months ago educating a worker from today, with me doing nothing.
What a well-educated agent looks like
Adler says a well-educated child has two things: they can take care of themselves, and they can live in harmony with others. I have found no better definition of a good agent.
1. Self-reliance
The agent can get from a task to a merged PR inside my environment without asking me anything. It knows where to look, how to run the tests, how to deploy, when to stop. The number I track for this is interruptions per task. When I started, it was 10 to 15 “allow this command?” per worker. Today the orchestrator absorbs almost all of them and escalates maybe one real decision a day to me.
This is also the one that lets me close the laptop. An agent that cannot fend for itself needs a human at the keyboard. An agent that can needs a Mac mini and a UPS.
2. Harmony with the environment
This is the one most people skip, and it is where agents do the most damage. A self-reliant agent with no sense of the environment is a toddler with a credit card. Very capable, very fast, zero awareness of what is around it.
Harmony means three things in my setup:
Not recreating what already exists. The worker checks the vault and the codebase before writing a new service, a new helper, a new landing page section. The number of duplicated utility classes I had before this rule was embarrassing.
Calling the right tool when needed. If there is a connector for Gmail, use it. If there is a script that generates invoices, run it, do not re-implement it in Ruby from scratch because you can. The right tool includes other agents: a coding worker that hits an accounting question hands it to the accounting agent; it does not improvise Singapore tax law. A worker that needs a new screen asks the design agent, it does not invent its own button style.
Operating in sync with everyone else. Workers run in parallel. Thirty of them on a good night. One worker rewriting the User model while another one is adding a column to it is the agent version of two kids fighting over the same toy. The orchestrator’s job is to sequence them, and each worker’s job is to check what is in flight before it starts.
Self-reliance without harmony gives you fast chaos. Harmony without self-reliance gives you a polite agent that asks permission for everything. You need both, and you only get both by educating the agent, not by writing better tickets.
In Summary
If you take one thing from this post: stop asking “how do I write a better prompt” and start asking “what does this agent need to know to live here without me”.
Your role with AI is not product manager and not orchestrator. It is an educator, in Adler’s sense: someone whose job is to become unnecessary.
AI knowledge is the set of shared rules an agent needs to fend for itself in your environment. It lives in your repo and your vault, not in the model.
Knowledge persists better if agents pass it to other agents instead of simple .md files. If you are the only channel, you are the bottleneck.
A well-educated agent is self-reliant and in harmony with its environment. It does not rebuild what exists; it calls the right tool, and it stays in sync with the other agents.
Now, let’s educate.
Dani,
