AI Agents & Automation

Same job, two implementations: one where you wrote every edge of the graph, one where a model picks them at runtime. Knowing which you need is the highest-leverage decision in the whole build.

An agent has no memory, no state, and no inner life. It has a message array. Learn to read one and you can reconstruct any run, including the ones that went wrong.

Turn, step, iteration. Tool, function, skill, action. The same six ideas wear four vocabularies, and half of all agent confusion is a naming collision. Here is the translation table.

A tool has two halves: a description the model reads and an executor you wrote. The model can only see one of them, and it believes it completely.

One tool call is four legs: you send definitions, the model emits a request, your code runs it, you append the result. Miss a leg and the run stops in a way the error message will not explain.

The parameter schema decides what the model is able to say. Some of its promises are enforced at decode time and some are decoration, and knowing which is which is the difference between a control and a wish.

Five design rules for tool sets, each one anchored to a specific failure you can point at in a trace. Bad tool design does not look like an error; it looks like a model that is being stupid.

One request parameter decides whether the model may call a tool, must call one, must call a specific one, or may not call anything. Each setting changes the observable output, and one of them will hang your run.

One response can ask for six tools at once. That is a large latency win and a set of assumptions about ordering that the wire format does not actually make.

A sensor goes offline. In one design the run dies with a stack trace and a half-watered greenhouse. In the other the agent opens a work order and carries on. The difference is four lines of executor code.

Two programs can call the same model with the same prompt and only one of them is an agent. The difference is a loop, and the loop is what you engineer.

The complete greenhouse agent is about twenty lines of Python. Read every one of them until you could type it from memory, because everything later in this course is a modification of these lines.

Four ways a run should end, and the one everybody recommends and nobody implements: a no-progress detector, written out in full.

There is no hidden state anywhere in an agent. The message list is the whole machine, which means a run can be saved, resumed after a crash, replayed, and forked.

A sensor times out, a tool returns nonsense, the model calls a function that does not exist. Four in-loop failures and the loop code that survives each one.

A run finished, filed a work order, and was completely wrong. Here is the trace. Find the exact iteration where it went off the rails.

A chatbot turn costs roughly what the last one cost. An agent iteration costs more than the one before it, every time, and the arithmetic is worse than it looks.

Compaction as an engineering decision: a trigger threshold, a legal cut point, a written contract for the summarizer, and the failure where it swallows state the agent still needed.

Give the agent a tool it can write notes to and read back. Notes live outside the conversation, so compaction cannot eat them and the window never pays for them twice.

Key-value, vector, files, and tables. Four stores, one selection rule, and the mistake that turns an external store into a bigger context problem.

What the agent should still know next week, what it must forget by Thursday, and why a remembered fact is a reason to check rather than a license to act.

One function runs before every model call and decides what the agent gets to know this iteration. Here is the assembly order, the eviction ladder, and the arithmetic when it does not fit.

Three classes of fact no amount of prompting will produce, and why a loop walks into them far more often than a chat window does.

A fast refresher on similarity search, aimed squarely at the thing that changes when the agent writes the query itself.

A chunk that lands in an agent's history stays there for the rest of the run, re-sent and re-billed every turn. Design them accordingly.

Two numbers that tell you whether your search is working, and the hard ceiling that reranking can never lift.

The agent writes its own query, reads its own results, and can search again. Whether it notices a bad search depends entirely on what you return.

Five named failures, each with a detection signal and a fix, and one result set that contains three of them at once.

In a loop, the model's output is another program's input. A parse failure is not an ugly answer, it is a stalled machine mid-run.

One guarantees syntax. One guarantees shape. Neither guarantees that anything in the object is true.

Flat over nested, enums over free text, and one field whose only job is to let the model say it could not find out.

The Model Context Protocol is a protocol, not a product. Here is the problem it solves, the shape it actually has, and what it does not do for you.

Tools, resources, and prompts. Three different things with three different controllers, and picking wrong is a category error with consequences.

An installed tool server is code you are running, describing its own tools, and free to change that description tomorrow.

The oldest agent pattern with a name, and still the default. Reason one step, act once, look at what came back, reason again.

Write the whole plan first, then run it. You get an artifact a human can approve and steps cheap enough for a small model. You also get a plan that can go stale mid-run.

Adding a critic stage to the loop is easy. Making it earn its cost is not: a critic with nothing to measure against is just a second opinion from the same source.

One coordinator, several workers. The interesting part is not the fan-out, it is what the merge does when a worker dies, lies, or never comes back.

Not delegation, transfer. One agent stops and another continues the same job, with whatever the envelope carried and nothing else.

Splitting one agent into five feels like architecture. Here is the bill it generates, written out, and the short list of jobs that actually justify it.

A decision table and an escalation ladder that starts at a plain script. You climb a rung only when the rung below has failed for a reason you can name.

Two questions per actuator: what untrusted text can reach it, and what does it touch? The answers give you a tier table, and the tier table is your real security posture.

Anyone can add an approval step. The hard part is designing the screen, because an approval based on a vague summary is a signature on a document nobody read.

Against a chatbot, injected text changes a sentence. Against an agent, it reaches a valve. Same weakness, completely different consequence.

Layers ordered by where they act in the loop: at sense, at decide, at actuate, outside, and afterwards. None of them is a fix, and one of them is a guarantee.

Zone 3 has now been irrigated eleven times. No attacker involved. This lesson is the accounting: what counts as a turn, how you meter a run, and what a cap does when it trips mid-action.

You cannot make an agent's decisions correct. You can build actuators where a wrong decision is something you walk back on Monday instead of something you explain to the grower.

Agent runs do not fail in a hundred creative ways. They fail in six, and each one has a different fix, so naming the failure is most of the repair.

Every tool call crosses a network that is having a worse day than you are. Retry policy is arithmetic, not vibes, and the wrong policy turns one flaky service into an outage you caused.

A retried read costs you nothing. A retried actuator call waters the field twice. The mechanism that makes retries safe is one header, generated in exactly one place.

A run is a tree, not a list. Spans with parent links let you reconstruct exactly what the loop did, and there are fields that must never touch that record.

You cannot test an agent with an expected answer, because an agent does not produce an answer. It produces a path. Golden traces pin the path.

A single call has a price. A loop has a curve. Iteration 8 costs several times iteration 1, and the arithmetic that shows why is the arithmetic that sizes your ceiling.

One ticket, one trace, one full diagnosis. Everything in this module, applied to a run that went wrong at 19:42 and cannot be reproduced.

The first real shape: high volume, low stakes per item, and one actuator that must never fire unattended. A sketch of the design and the metric that lies.

Shape two, and the most honest lesson in the module: most pipeline work should not be an agent. Here is the narrow place where one earns its keep.

Shape three: the highest-variance, highest-risk surface an agent can be given. Why it breaks so easily, and the mitigation stack for when you genuinely have no alternative.

Four factors decide whether a task should become an agent, and one of them outweighs the other three combined. Score your candidates before you write a line.

The winning candidate, designed for real. An interview-scheduling operations agent, and a brief whose sharpest lines are the things it will never be allowed to do.

Nine tools, four permission tiers, one approval gate, and the idempotency keys that make a retry safe. The design decisions are the lesson.

Four golden traces, one cost ceiling, and a launch order that earns autonomy instead of assuming it. Then the end of the course.