I’m Ken. I keep payment systems operational in the cloud so you can keep arguing with strangers on the internet. I write about cloud architecture, operational nightmares, and the quiet dread of a 2 AM page. Everything here is my own opinion — my employer has better ones.
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. ...
Part 1 was for the person who signs the invoice. This one is for the person who gets handed the Jira ticket afterward. If you read that post and thought “yes, fine, I want this, how hard can it be” — this post is the honest answer to that question. It’s a deployment walkthrough with the bad parts left in. The code is at github.com/kenkitts/claude-apps-gateway-cdk. Five Python CDK stacks, a Docker image that fetches and verifies the claude binary at build time, and enough inline comments to reconstruct most of the decisions made under pressure. Clone it now if you want to follow along; the scars will make more sense with the code open. ...
Your developers are already using Claude Code. Right now. On personal Anthropic accounts or individual API keys, expensed on a T&E line that says “software tools,” with your source code as the payload. You can’t see the spend, can’t say who’s spending it, can’t cap it, and if you asked your CISO whether any of this is compliant with your data-handling policy, she would say something unprintable. That is the status quo an LLM gateway is reacting to. Not a hypothetical future where AI tools proliferate — the present, where they already have. ...
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: ...