How coding agents work: loops, context and permissions

0:00 How coding agents actually work

If you have ever watched a coding agent do something brilliant and then, ten minutes later, forget a rule you told it at the start, this lecture explains why. By the end you will understand the agent loop, why context is the scarce resource, and how permissions, sandboxes and hooks keep agents safe.

0:23 Analogy: the contractor's whiteboard

Before we go deeper, here is an analogy that makes the rest of this lecture click. Think of the agent as a very fast contractor working at a desk with one small whiteboard. Everything it knows about your project has to fit on that whiteboard: your instructions, the files it has read, the output of every command. When the whiteboard fills up, someone wipes the oldest notes and writes a short summary in the corner. The contractor is brilliant, but it can only work with what is on the whiteboard right now. Keep that picture in mind: the whiteboard is the context window, and the wiping is compaction.

1:10 The agent loop

Every coding agent runs the same basic loop. It gathers context: your request, instruction files and whatever files it chooses to read. It plans. It acts by calling a tool, like reading a file, running a search, editing code or executing a command. It observes the result, like a compiler error or a test report. Then it repeats until it believes the job is done, hits a limit, or needs your input. The brand on the box changes the quality of each step, but not the shape of the loop.

1:49 Context is everything

Here is the most important fact about agents. The model is stateless. In any given moment, everything it knows about your project is what sits in its context window. The system prompt, your instruction file, the conversation, and every tool result so far. When a long session fills that window, the tool compacts older turns into a summary, and detail gets lost. That is why the rule you gave at turn five can vanish by turn eighty. The fix is simple: short, focused sessions with one clear goal, and fresh sessions for new tasks.

2:30 Tool risk ladder

Next, tools. Reading files is low risk, although an agent can read secrets if you let it. Writing files is medium risk, and git makes it reversible. Executing commands is high risk. A shell command can do anything, including installing packages or calling the network. And external tools, like MCP servers or web fetch, move data across your trust boundary in both directions. So the question is never just which agent. It is which tools, with which permissions.

3:04 Four controls

Vendors expose permissions differently, but the concepts are the same. Approval modes decide whether the agent asks before every edit or command. Allow and deny lists pre-approve safe commands like running tests, and block dangerous ones like force pushes. Sandboxes restrict what files and network the agent can touch. And hooks are deterministic scripts that run before or after a tool call. Here is the crucial distinction. Instructions in a Markdown file are advice to the model. Hooks, sandboxes and branch protection are enforcement. Anthropic's own docs make exactly this point about its memory file.

3:45 Reading a transcript

Let's read a short transcript. The agent is asked to fix a failing rounding test without changing the public API. First it runs the failing test, and sees nineteen point nine eight nine nine instead of nineteen point nine nine. It reads the pricing module, spots floating point multiplication, switches to a decimal type, and reruns the whole suite. All green. That is good agent behavior: reproduce, small change, full verification. But your job is not over. Did the return type change for callers? Passing tests are necessary. They are not sufficient.

4:25 Where the agent runs

One more design choice you control is where the agent runs. A local agent in your terminal inherits your permissions: your SSH keys, your cloud credentials, your browser cookies if a tool can reach them. A cloud agent runs in an isolated environment the vendor provisions, usually with a fresh checkout, limited network access and a scoped token. Neither is automatically safe. Local agents need allow lists and sandboxing; cloud agents need tight repository scopes and firewall rules. Also use subagents, which are separate context windows, for noisy jobs like searching a huge codebase, so the main session stays clean and focused on the task.

5:11 Example: 'always use pnpm'

A simple example to lock it in. Say you tell the agent at the start, always use pnpm, never npm. An hour later, it runs npm install. Why? Look at the whiteboard. Your instruction was one short line in the chat, buried under forty tool outputs, and compaction summarized it away. The fix takes ten seconds: put use pnpm in your instruction file, which is loaded fresh into every session, and start a new session for the next task. And if running npm install would actually cause damage, add a deny rule so the command is blocked no matter what the agent decides. Advice goes in the file. Enforcement goes in permissions.

6:00 Scenario: the accidental leak

Now a realistic scenario. A fintech team in Karachi lets an agent run with auto-approved commands on a developer laptop. The laptop also holds cloud credentials in its environment. A test script the agent runs happens to print environment variables when it fails, and the agent helpfully pastes that output into a pull request description. Nobody intended a leak, yet a secret ends up in a pull request. What would have stopped it? Denying the agent read access to environment files, running agents in a sandbox without production credentials, and secret scanning on pull requests. Three independent layers, any one of which would have caught it. That is the mindset: assume one layer fails, and make sure another catches it.

6:52 Deeper: what the tests didn't cover

One level deeper on the transcript example. After the agent switched to a decimal type, the suite passed. But the function used to return a float, and two callers in the reporting module compare it with plain numbers. A quick search for the function name shows those callers, so you ask the agent to add one test per caller before merging.

7:19 Watch me do it: the permission baseline

Watch me do it. Here is the permission baseline from the lesson, and I'll walk through it line by line so you know why each line is there. The allow list starts with Bash npm test colon star. That means any command starting with npm test runs without asking me, because tests are the agent's feedback loop, and I will approve them a hundred times a day anyway. Next, npm run lint, same reason. Then git diff and git status, read-only commands the agent uses to understand what it changed. Now the deny list. Bash git push colon star: the agent can commit locally, but pushing is a human decision, and branch protection backs this up on the server. Bash rm dash rf: no recursive deletes, ever. Then three Read rules: the env file, anything starting with dot env, and the secrets folder. Even reading those puts credentials into the context window, where they can leak. Now let me test it. I start a session and ask the agent to print the contents of the env file. The tool call is refused before it runs, and the agent tells me it is not permitted. Then I ask it to run the tests, and they run with no prompt at all. That is what a good baseline feels like: routine work flows, dangerous work stops. Commit this file, and every developer gets the same guardrails.

9:01 Recap

To recap. Agents loop through context, plan, act and observe. Context is the scarce resource, so keep sessions short and focused. Tool risk rises from read to write to execute to external. And real safety comes from enforcement, not instructions. Your next step: copy the permission baseline from the lesson, adapt it to your stack, and commit it to your repository so the whole team starts from the same safe defaults.