Applied AI Academy

You cannot supervise an agent in a language you do not speak

Special primer — the coding vocabulary behind agentic AI: functions, the terminal, CLI, API, localhost, ports and MCP

The question: What do the words an AI coding agent uses in its first five minutes actually refer to — and which of them decide how much damage it can do?

Claude Code, Cursor and their peers rarely fail because you cannot write code. They fail because you cannot read what they are telling you. Every line an agent prints names a boundary: the folder it moved into, the server it started, the key it needs, the tool it just connected. This lesson teaches the boundaries rather than the syntax — enough vocabulary to approve, to refuse, or to ask the one question that stops the mistake.

What the lesson covers

An agent narrates its work in a dialect, and the dialect is not decoration. "I will cd into the repo." "The dev server is running on localhost:5173." "The API returned 401." "I have added the GitHub MCP server." If those sentences are noise to you, only two responses are available — approve and refuse — and you will approve, because refusing everything makes the agent useless. Understanding is what makes a third response possible: the question that changes what happens next. None of this requires you to write code. It requires you to know what the words point at, and there are fewer of them than you fear.

Start with the smallest unit. A **function** is a named machine: it takes inputs, it returns a value, and — the half that matters to you — it may change something in the world while it runs. That change is called a **side effect**, and it is the entire safety story. A function called `estimate_yield(price, rent)` computes a number and touches nothing; a function called `send_invoice(customer)` also returns a number, and has moved money. Identical shape, incomparable risk. So when an agent reports that it wrote a function, the useful question is never "is the code any good". It is: what does it return, and what does it change?

Three words that get used interchangeably and should not be. The **terminal** is a window. The **shell** is the program inside it that reads the line you typed, finds the right program and runs it — bash, zsh, PowerShell. A **CLI** is any program built to be driven from that line rather than by clicking. Agents live there for one reason: it is the only interface where every step is text. A text plan produces text commands, which produce text results, which the model can read and you can audit afterwards. The grammar never varies — a command, some flags, some arguments — and every command finishes by returning an **exit code**, where 0 means it worked and anything else means it did not. "It ran" and "it succeeded" are different claims.

"Why do I have to run it that particular way" has five ordinary answers, and not one of them is a bug in the code. The **working directory**: the shell is always standing in some folder, and a relative path means nothing until you know which. The **interpreter**: Python code needs Python, of a specific enough version. The **dependencies**: your code imports other people's code, which has to be present. The **environment variables**: the keys and settings that must never be written into the file itself. And the **port**: a running program claims a number, and a second program cannot have it. Every "it works on my machine" in history is one of those five differing between two machines, and the code being identical on both sides is the point.

Finally, three sockets at three distances. **localhost** — the loopback address 127.0.0.1 — is your machine phoning itself: when an agent starts a dev server and hands you http://localhost:3000, that address exists for you and nobody else, which is exactly why it is safe to break and why the world cannot see it until you deploy. An **API** is the contract by which one program calls another across a network: an address, a method, a key, a documented answer. And **MCP**, the Model Context Protocol, is the standard shape of that call when the caller is a model — one socket, so any agent can use any tool without bespoke wiring for every pair. The official analogy is USB-C, and it is a good one, including the part where a port is also a hole. Each of the three is a permission as much as a connection: an agent's reach is precisely the set of tools you plugged in and the keys you handed over.

Key points

Framework — Where · What · Who · Allowed

Four questions decode any step an agent takes. WHERE does it run — which folder, which machine? WHAT runs it — which interpreter, which dependencies? WHO does it talk to — itself on localhost, or an API somewhere on the internet? And what is it ALLOWED to touch — which tools are connected, which keys were handed over, which of its actions cannot be undone? A question you cannot answer is a risk you have not sized.

The lab

Say the words out loud on your own machine: run four harmless commands, start a real web server, call a real API, and draw the permission map of one agent.

Deliverable: A one-page "my machine, my agent" card: the four framework answers for one real task you would delegate, the exact command that checks each, and your permission table with every irreversible action marked.

Open this lesson, its lab and its quiz

Sources and further reading