Thirteen labs. From one reliable function call to a team of agents that find, call, remember, coordinate, and ship.

Every call to an outside service returns a clear result object: did it work, what went wrong, and what kind of failure was it. Never a bare value, never nothing. This one habit is what lets an agent stop guessing and start handling failures on its own.

MCP (Model Context Protocol) is the standard way an agent calls your code. With one small library and one decorator you expose three tools, run it on your laptop, then flip a single setting to put it on the public internet. Your project goes from person-callable to agent-callable in ten minutes.

A tool's description is the only thing an agent reads to decide whether to use it. Watch a small model fail on a vague description, then fix it in one line. At real scale, whether a tool is readable matters more than whether it is clever.

A person finds your site with a search bar. An agent finds it by reading a small file at a known address that says what you are and how to call you. Publish that file and a passing agent can use you with no prior knowledge. Skip it and you are invisible to them.

Tell callers where to get a token, then check that the token is allowed to do the thing before you do it. The step everyone skips early and regrets later. A leaked key with no limits is a breach; a key limited to one job is a boundary.

An agent with no memory works out the world again from scratch every turn. Give it a store of facts on disk that it can look up by relevance. Then we plant a false fact it trusts forever, and build the guard that catches it before it acts.

There is not one kind of memory, there are four: the current scratchpad, a log of what happened, durable facts, and the rules the agent always follows. Put each in the right place and combine them into one clean context every turn. This is the mix that keeps an agent sane past turn thirty.

The prompt is one line. The context is everything the model sees at once, and models get worse as you stuff in more of it. Measure how much you are using, keep only the high-value parts, give each sub-task a fresh start, and save state to files. Adding more is usually the bug.

Stop hand-writing prompts. Write a prompt that writes the prompt, then improve it like code: make several versions, score each against a test, keep the best, and learn from what still fails. You will run, by hand, the same loop that tools like DSPy automate.

Two agents, one shared format, a real handoff. One agent posts a task, the other finds it, does it, and returns a signed result, with no person in the middle. This is the basic building block of a whole internet of agents working together.

One coordinator, a shared to-do list, many workers running at once, and a quality check that nothing gets past. Point ten agents at one problem, wait for them all, check the work, then combine it. This very set of labs was built that way, in parallel, while you were reading.

No public way in? Build one. Four layers: a browser sign-in for the keys, a client that looks like that browser, clear typed actions on top, and a command line on top of that. Turn a logged-in site you already use into something your agent can drive.

A green build is not the same as a correct one. Deploy, then prove it: check the live site is really serving your new version, test the real flow, and make every write safe to repeat so a retry can never do it twice. This is what lets an agent act while you are not watching.