Detailed content
🧠 An agent that runs everything
The video scene is tempting: you send a message—"put together a summary of my notes from today"—and a single assistant, nicknamed "IT guy," figure it out. It loads the right model, finds the files, sends parts to another machine, and returns the finished result. There's no magic here. There's an orchestrator: an agent that receives the objective in natural language and coordinates the pieces you assembled in the earlier tracks.
🆕 New here?
"Orchestrator" is the maestro agent: it doesn’t play every instrument; it decides who handles what and when. Instead of you opening the terminal, choosing the model, copying files, and putting everything together by hand, the orchestrator turns a request into a sequence of steps and runs each one by calling the right tools.
🔑 The central idea
The video’s “IT guy” is the sum of three things you already have or will have:
- •One brain: your local LLM served via API (module 3.5).
- •Arms: tools — run commands, read/write files, call APIs.
- •One loop: the logic that decides the next step until the goal is achieved.
📊 What to watch
- The orchestrator doesn’t need to be “as smart as the top cloud model” — it needs to be reliable in following steps.
- Everything it does, you could do by hand. It just automates the sequence.
- The clearer the goal and the more restricted the tools, the better the agent behaves.
🔁 What an agent really is
Take the mystery out with a short formula: agent = LLM + tools + loop. An LLM by itself only generates text. It becomes an agent when you put it in a loop that reads what it asked for, actually executes it, and returns the result so it can decide what to do next.
🆕 New here? — four words
- Agent: an LLM with permission to act (not just answering), inside a loop.
- Tool / tool-calling: an action the model can request (run a command, read a file, call an API). The program executes it and returns the result to the model.
- ReAct loop: the default Reason + Act — the agent reasons the next step, age (uses a tool), observes the result and repeats.
- Orchestrator: an agent whose job is to coordinate other components (models, machines, tools).
This is the heart of any agent ReAct loop: Think → Use a tool → Observe and comes back. It only exits the loop (in cyan) when it decides the goal has been met—then delivers the response.
Think (reason)
The LLM looks at the goal and what it already knows, then writes the next step — e.g., "I need to list the files in the notes folder".
Uses the tool (age)
The program actually executes what the model asked for — it runs ls, reads a file, calls the API. The model doesn’t touch the system; it asks for, the runtime does.
Observes and repeats
The result goes back to the model, which decides: finished? Then it delivers. Not finished? It thinks about the next step. The loop continues until it reaches the goal or a step limit.
🧰 Real orchestration tools
Time for some honesty. The video captions jumbled names and made something that's really just a open and available software. You don’t need a magical “Hermes”: you need a coding agent or a agent framework pointed at your local endpoint (module 3.5). It’s the same thing, without the marketing.
✗ What the video implied
- ✗A single proprietary assistant that "does everything on its own"
- ✗Confusing names (incorrect captions) that look like secret tools
- ✗Indecipherable magic you couldn't put together
✓ What it's really like
- ✓Code agents / CLI (e.g., Claude Code, Aider, OpenHands) and frameworks (LangGraph, CrewAI, n8n)
- ✓They all speak HTTP—you point to http://localhost:11434/v1
- ✓It's open source: you can read it, run it, and customize it yourself
⌨️ What “pointing to the local model” means
Objective: show that connecting an agent framework to your local model only takes changing 2 lines. Any tool that accepts an "OpenAI-style API" will work.
How to check: run echo $OPENAI_BASE_URL and make sure it points to localhost:11434. Then the agent framework uses these variables, and no calls leave your machine.
💡 Practical tip
Start with the simplest solution that works: a CLI coding agent already reads files, runs commands, and edits folders — it é a useful orchestrator on day one. Frameworks like LangGraph/CrewAI are worthwhile when you need several coordinated agents (topic from modules 4.2 onward). Don’t increase complexity before it’s time.
🛰️ Routing tasks between machines
The part of the video about "distributing across machines" is where two earlier pieces fit together: Tailscale (module 2.4) connects your computers to a private network, and the Local API (module 3.5) is each model's doorway. The orchestrator just needs to know which machine to call for each task.
🆕 Recap (from tracks 2 and 3)
Tailscale assigns each device a fixed IP on your private network (something like 100.x.y.z), accessible from anywhere without opening ports. The Local API listens on the port 11434. Putting it together: http://100.x.y.z:11434/v1 is “the model on that machine, wherever you are.”
Classify the task
Is it heavy (large model, reasoning) or light (summarization, classification)? That determines where it goes.
Choose the machine
Huge model → the Mac with lots of unified memory. Fast responses → the machine with a dedicated GPU. Each has its own IP on the tailnet.
Call and collect
The orchestrator sends the request to the right IP and combines the results. To the user, it looks like a single agent — behind the scenes, there are several machines.
⌨️ Sending a task to another machine
Objective: run a prompt on the large model that lives in other computer on your tailnet, without leaving where you are.
How to check: if a JSON response comes back with the answer, the machine-to-machine route works. First, confirm with tailscale status that the other device appears online and that it serves with OLLAMA_HOST=0.0.0.0.
🛡️ Giving tools safely
An agent with the power to run commands is useful — and dangerous. It can misinterpret a request and delete the right folder for the wrong reason. The golden rule: give only the minimum permissions needed to complete the task, and require confirmation for anything irreversible.
✓ Provide tools safely
- ✓Scope: limit it to a specific folder/project, not the whole system
- ✓Sandbox: run in an unprivileged container/user, isolated
- ✓Confirm destructive action: delete, overwrite, send — only with your “yes”
- ✓Read-only by default: start by observing before letting it write
✗ Pitfalls to avoid
- ✗Give full access to the machine "for convenience"
- ✗Auto-approve everything, including rm -rf e git push
- ✗Running as administrator/root without a need
- ✗Letting the agent access the internet when the task is local only
🔓 Why scope matters so much
The model has no “intent”: it predicts the next step based on the text. If the request is ambiguous, it will guess — and a root-level guess can cause serious damage. Restricting the scope isn’t about distrusting the model; it’s about turning possible errors into errors small and reversible.
💡 Practical tip
Create a dedicated working folder (e.g., ~/agente-sandbox) and give the agent access only to that. Version it with git: that way, any mistake can be undone with a git checkout .. Manual confirmation for destructive actions takes 2 seconds and saves you from a bad day.
⌨️ Your first useful agent
No abstract theory: let's build the simplest agent that already delivers value—one that summarizes a notes folder. It’s the ReAct loop in its simplest form: for each file, it thinks ("summarize this note"), acts (calls the local model), observes (stores the summary), and repeats.
⌨️ Practical example: an agent that summarizes your notes folder
Objective: generate a resumo.md with 3 bullets per note, using only your local model. Prerequisite: Ollama running (module 3.1/3.5) and a folder ~/notas with files .md or .txt.
The instruction (the prompt the agent follows)
The loop (paste into the terminal — Linux/mac)
How to check: open resumo.md — there should be one section per note, each with up to 3 bullets. If a summary “makes something up,” reinforce the “don’t make anything up” rule in the instruction. For organize files instead of summarizing, change the request to "suggest a destination folder for this note based on its subject" and review it before moving it.
Self-check (optional): what actually turns an ordinary LLM into a agent?
📌 Module summary
Next module:
4.2 — The always-on paradigm: 24/7 agents