Python

Last time I gave the agent real tools behind a real Gateway, then told you — in bold — that the front door was propped open with a brick. Anyone with the URL could list every note, write garbage, run your Bedrock bill for sport. “The fix has earned its own post,” I said. This is that post. But the lock isn’t even the interesting part. The interesting part is what comes after the lock: alice and bob become two different people instead of one undifferentiated “demo-user” sharing a single pile. The agent knows who’s talking to it, their notes are theirs, and the model had absolutely no say in making that happen. ...

Last time the agent learned to remember you: durable conversations, your preferences trailing you across sessions. It knows you like terse summaries. It knows the Q3 doc is in the shared drive. It does not have the Q3 doc. It has never had your notes. For three posts add_note has been dropping them into a Python list that lives in RAM and dies with the process, like a goldfish keeping a diary. The agent remembers the conversation about your notes. The notes themselves were a rumor it was too polite to correct. ...

Last time we put the agent in the cloud behind a real endpoint. It works, it scales, two users don’t trample each other — and it has the retention span of a mayfly. Notes live in a Python list that evaporates the instant the instance recycles. It remembers your note right up until it doesn’t, which is arguably worse than a goldfish: at least the goldfish never promised. This post gives it AgentCore Memory. Two kinds, in order of how much they’ll surprise you: ...

Previously I wrote a whole series about building an agent from scratch. The big reveal was almost insultingly simple: An agent is a while loop. The model asks for a tool, your code runs the tool, you hand the result back, repeat until it stops asking. Six hundred lines of Python, a babysitter wrapped around a language model, and you’ve got something useful, if not dangerous. I stand by every word of it. If you’ve never hand-rolled the loop, go read that series first — this one assumes you already know what a tool-call looks like coming back from the model. ...

Last time we built a notes agent with Strands and ran it in a terminal. It worked. It also ran exactly as long as I left the terminal open, which is to say: it was production-ready in the same sense that a campfire is central heating. This post fixes the “on my laptop” problem and nothing else. Same agent. Same tools. Same build_agent() from Part 1, not one line changed. The only new thing is where it runs — and the surprising part is how little code that takes. ...

In Part 2 we gave the model hands — tools that do things. In Part 4 we gave it longer arms — tools that do things on someone else’s machine. Both answered the same question: how does the model act? This post answers a different one: how does the model know how? Not facts. Facts are RAG — go fetch a document, stuff it in the context, done. I mean procedure. The gap between a junior who can write code and a senior who knows how to run a code review isn’t more data. It’s knowing the steps, the order, the things to check, the traps. You can’t bolt that on with a vector search. It’s a recipe, not an ingredient. ...

In Part 1 we built the loop. In Part 2 we handed the model some knives — tools, sandboxed so it couldn’t read your SSH keys. Both parts leaned on a thing I kept gesturing at and refusing to explain: the Session object. The agent’s memory. Time to explain it. Here’s the uncomfortable foundation everything in this post sits on: The model remembers nothing. Each call to Bedrock is a blank slate. The model that answered your last question has no idea it ever existed. It is a brilliant amnesiac, waking up fresh every single time, and the only reason it appears to “remember” the conversation is that you shove the entire transcript back in front of it on every request. Memory isn’t a model feature. It’s a thing your harness does, by hand, at a cost. And the bill — we’ll get to the bill. ...

In Part 2 we forged our own knives: a calculator that parses an AST instead of calling eval, file tools locked in a sandbox, every input frisked by code we wrote and could actually read. We trusted those tools because we built them. This post is about handing the model a knife from a stranger’s kitchen, sight unseen, and saying “go nuts.” That’s the Model Context Protocol, or MCP. It lets a tool live on someone else’s server, behind a login, and still show up on the model’s menu like it grew there. And here’s the part that should make the back of your neck prickle: ...

In Part 1 we established the simple truth: LLMs can only produce text. The harness is the babysitter that turns that text into action. Today we build the action part. The tools. The hands. This is the fun chapter, by which I mean it’s the one where we voluntarily give a probabilistic text generator the ability to touch the filesystem and then act surprised when it tries to read /etc/passwd. All the code below is lifted straight from the repo — a single agent.py file you can clone and run. Strap in. ...

You’ve seen the demos. AI agents booking flights, writing code, querying databases, probably filing your taxes while whispering sycophantic flattery. Very impressive. Very “the future is here, and it’s kinda scary.” Here’s the simple secret nobody mentions in the keynote: LLMs can only produce text. That’s it. They can’t run code. They can’t check the time. They can’t read a file. They are the world’s most confident interns — full of opinions, zero ability to actually do anything. All they do is predict the next token and hope you’re impressed. ...