Agentic Work

011. The loop

The loop

messages = [system_prompt, task]
while True:
    reply = model(messages, tools)
    messages.append(reply)
    if not reply.tool_calls:
        break                       # the model considers the task done
    for call in reply.tool_calls:
        result = execute(call)      # your code, your rules
        messages.append(result)

That is the whole idea. The intelligence sits in the model. The reliability comes from everything around it: the tools, the brief, the feedback and the limits. The software that supplies those is called a harness. Part 7 covers the tools.

Workflow or agent

Use the simplest design that works. Many things proposed as agents are better built as workflows with a model call at two or three points. Reserve agents for work where you cannot write down the steps in advance.

What makes an agent succeed

• A clear goal and a definition of done. “Fix the failing test in the payments module without changing its public interface” works. “Improve the code” does not.
• Feedback from the environment. Tests, compilers, type checkers and linters tell the agent whether a step worked. This is the verification theme from parts 2 and 3 of the language models module, and it is the largest single factor in agent reliability.
• Good tools, designed as part 7 describes.
• A plan before action, for anything sizeable. Have the agent write a plan, review it, then let it proceed. A wrong plan caught early costs a minute. Caught late it costs the whole run.
• Limits on steps, spend and time.

Levels of autonomy

There are three broad levels of autonomy: the agent suggests and a person acts; the agent acts after each approval; the agent acts freely inside a sandbox and reports at the end. The first two run at human speed, because a person is in every step. Only the third runs at the AI’s speed.

The third level is safe only where nothing in reach can do lasting harm and the result can be checked automatically. So the engineering goal is to make that true for as much work as possible: sandboxes, scoped credentials, strong tests and easy rollback. Every piece of that groundwork moves another class of task from supervised to delegated.

022. Surviving a long task

Managing context

Part 3 of the language models module shows that a filling context degrades quality and raises cost. Agents counter this in four ways:

• Compaction. Summarise progress and continue from the summary.
• Notes files. The agent records decisions and progress in a file and re-reads it. This is memory outside the context, and it survives a restart.
• Sub-agents. Exploration is delegated to a fresh context that returns only a summary. The main context stays clean, and sub-agents can run in parallel. Section 4 covers them.
• Just-in-time loading. Keep file paths and references in context, and load contents only when needed. Skills, in section 3, apply the same idea to instructions.

Compounding error

Part 3 of the language models module gives the arithmetic: 98% reliability per step gives 36% over 50 steps. The counters are checkpoints to return to, such as a commit after each working step, and automatic verification between steps. Human attention is best spent at the start, on the plan, where a minute of review prevents an hour of wasted work. Review at the end should be proportional to risk, which section 6 sets out.

Multi-agent systems

An orchestrating agent can hand parts of a task to worker agents. This suits broad, parallel work such as researching many sources or searching a large codebase. It multiplies token use several times over and adds coordination failures. Do not begin there. Add agents when a single one demonstrably runs out of context or time.

033. Delegation and running in parallel

Sub-agents at run time

Part 4 covered what a sub-agent definition declares. What matters here is what delegation does. The helper starts with an empty context holding its own prompt and the task it was handed, works, perhaps reading fifty files, and returns a few paragraphs. The fifty files never touch the main context.

That buys three things: the main conversation stays clean, several helpers can run at once, and a helper can be given narrower tools than its parent, which is one of the defences in part 9.

It costs two. The helper knows only what it was told, so the hand-off is a brief, and part 3’s contractor test applies to it in full; agents are not always good at writing briefs for one another. And a summary loses detail the parent cannot see it has lost.

Several agents at once

An orchestrating agent can hand parts of a task to worker agents. This suits broad, parallel work such as researching many sources or searching a large codebase. It multiplies token use several times over and adds coordination failures. Do not begin there. Add agents when a single one demonstrably runs out of context or time.

The same caution applies to a person running several agents side by side, each on its own branch. It is the pattern that gets the most out of these tools, and it moves the constraint onto the person: you can direct three agents and review one at a time.

What the measurements show

A production-scale study of one coding agent in June 2026, covering 3.2 million users and 13 million sessions, found the shape of this work plainly. A session is a few user turns, each unfolding into a long autonomous loop of model calls almost always paired with running a tool. Cached context is reused about 90% of the time within a turn and only about 55% across turns, and is thrown away entirely when the model is switched or the context is compacted. The idle gaps between turns, while a person reads and decides, are far longer than the agent’s own bursts of work.

Two things follow. The cost of an agent is dominated by what happens inside a turn, which is why the context work in section 2 pays. And the person is the slow part, which is the argument for parallel work and for part 1 of the AI in the organisation module.

044. Where the agent runs

Cloud agents in particular

By 2026 every major vendor offers one: you assign a task and it works alone, in an isolated environment, for minutes or hours, then returns a pull request. They are billed by usage rather than by seat, and the published rate cards put active use in the range of a hundred to a couple of hundred dollars per developer per month, which is small against a developer’s time and large against the seat prices teams are used to.

What to know before adopting one:

• The sandbox is the safety. The agent has its own environment, its own credentials and no access to yours. That is what makes it safe to leave alone, and it means the environment has to be good enough to build and test in, or the agent is working blind.
• It cannot ask you a question. Anything ambiguous will be guessed. That puts all the weight on the brief, which is part 3.
• The bottleneck moves immediately. Agents that open pull requests faster than people can review them create a queue, not throughput. That is the finding in part 1 of the AI in the organisation module, and it is the single most common way a cloud agent programme disappoints.
• Benchmarks are not the job. The published scores on standard task sets rose from about 2% to nearly 80% between late 2023 and early 2026, which is a real advance and still says nothing about your codebase. Run your own.

What adopting agents did to real repositories

A longitudinal study published in January 2026 compared open-source repositories before and after their first agent-generated pull request, against matched controls. It found large early gains in velocity, but only where the agent was the first AI tool the project had used; where an AI-assisted editor was already in use, the throughput gain was small or short-lived. The quality signals moved the other way and stayed moved: static-analysis warnings up by roughly 18% and cognitive complexity by roughly 39%.

Read that as the same lesson the rest of this course keeps arriving at. The agent produces more; whether that reaches anyone depends on the verification around it, and what it costs shows up later, in code nobody wants to touch.

055. Coding agents in practice

How one works

The tools are file search, file read, file edit, a shell and version control, often with web or documentation search and MCP servers on top. At the start of a session the agent loads the instruction files from part 3 and the descriptions of its skills. Then it loops: explore, plan, edit, run, observe, adjust, and finally summarise what it did.

Four form factors are common:

• Editor assistant: inline completion and chat, with the developer driving every step
• Interactive agent: runs in the terminal or editor, carries out multi-step tasks while the developer watches and steers
• Background agent: takes a ticket, works in its own cloud environment, and returns a pull request
• Pipeline agent: runs in CI to review pull requests, triage failures or draft release notes

Working patterns that hold up

• Plan, review, execute. Approve the approach before code is written. This is the cheapest and most valuable place for human attention.
• Test first. Have the agent write a failing test from the bug report, confirm that it fails, then fix the code. This guards against the reward hacking described in part 2 of the language models module.
• Commit often. Small commits are checkpoints to roll back to.
• Fresh session per task. This avoids the stale context problems from part 3 of the language models module.
• Independent review. Have a fresh session, with no knowledge of the author, review every diff before a person sees it.
• Review by risk, not by habit. A person remains accountable for what is merged. How they discharge that changes. Automated checks and AI review cover everything. Human reading concentrates on design decisions and on high-risk paths such as money, security, personal data and regulated logic, with spot checks elsewhere.

Working at the agent’s pace

The common first pattern is one developer, one agent, watching it work and then reading every line it wrote. This feels responsible, and it caps the gain. The agent waits for the person, and total throughput is set by human reading speed.

Teams that get much more from these tools change the shape of the work:

• Run agents in parallel. One engineer directs several tasks at once, each in its own branch or environment, and moves between them as they need input.
• Hand off to background agents. Well-specified tickets go to agents that return tested pull requests. Nobody watches them work.
• Shift effort to the two ends. The engineer’s time moves to specifying the task well and to deciding whether the result is acceptable. The middle belongs to the agent.
• Invest in verification you can trust. Reading every line is a substitute for tests, types and checks you do not have. Each improvement to automated verification reduces how much must be read.
• Do what was not worth doing before. Build three prototypes to choose between instead of debating one. Backfill tests on legacy code. Complete the migration that was always deferred. Write the internal tool nobody had time for.

Measure whether it worked. Directing five agents at once feels enormously productive, and that feeling is not evidence. In the best-known trial, experienced developers took 19% longer with AI tools and still believed they had been 20% faster. Before changing how the team works, record a baseline: how long work takes from start to release, how much comes back as rework, how many defects escape. Then watch those figures and not the activity, since pull requests opened, lines written and tokens spent all soar whether or not anything reaches a customer sooner. Section 7 of part 2 of the AI in the organisation module sets out the evidence and the measures.

None of this removes accountability. It changes where assurance comes from. Skipping review without stronger automated verification simply moves the cost to production. Part 2 of the AI in the organisation module covers how to make this shift across a team.

Where they still struggle

• large cross-cutting changes in code without tests
• ambiguous requirements, where the hard part is deciding what to build
• proprietary frameworks with no documentation in the repository
• subtle concurrency and performance problems
• visual fidelity in user interfaces, unless the agent can see the rendered result, which part 6 covers
• differences between its sandbox and your real environment

The whiteboard version

An agent is a model in a loop with tools, a brief, feedback and limits. It is reliable in proportion to how well it can check its own work, so tests and types matter more than the model. On a long task it runs out of room, so it summarises, takes notes and hands work to helpers. It can run in your editor, your terminal, or on someone else’s computer and come back with a pull request, and that last kind moves the bottleneck onto whoever reviews it.