💭 in your head · nothing to type
Run through any real workflow you use every week — say, inbox processing.
Don't picture it as "steps that need to get done" — picture it as a puppeteer working several marionettes at once. Each string in a different hand, each figure doing its own thing. When one person holds all the strings, that's an art of coordination — not brute labor.
Look at your workflow as that system: which marionettes are you pulling yourself right now? And which ones could move on their own if the string were rigged correctly?
💭 in your head · nothing to type
The orchestration idea: instead of one big task on one agent — many small tasks across multiple agents (or across multiple steps of one agent).
Advantages:
Don't picture this as an orchestra — picture it as a loom. Each thread runs its own row, crosses with others at precisely the right moment, and weaves a pattern. One thread snapping isn't the end of the fabric: you see exactly where, you find the spot, you repair it. The fabric before and after that point stays whole.
This is a mindset shift: you're no longer "writing a prompt." You're designing the loom.
Catch the image: where in your pipeline do the threads cross? And at which point would a snap tear the whole fabric, not just a local row?
Real case: a Gmail agent
My Gmail agent runs in one Docker container on a rented server. About every two minutes it reads new personal mail through the Gmail API; LLM calls go through a model model gateway — one entry point to a pool of models. The dashboard is protected by Cloudflare Access and a PIN (explained in the next unit). The container port is available only locally and on a private network between my devices (explained in the next unit). The agent uses a cloud pool through the model gateway: this is personal mail, not medical data; u4 covers a separate pool for medical data.