Full disclosure: I have to give credit for the title to AI. Is it my best one yet? Definitely not. But it's "in my voice" and perfectly sums up the last month.

So let me catch you up. Where we left off, I finally unveiled Agent Runner. Then I was heads down preparing for my talk at SREday NYC on June 6. So I made some "slides" (as you will see, that term is a bit of an understatement). If you read nothing else, please check out the presentation. Because this is the entire thesis of my series of articles and work at Codagent in one presentation.

And then I went to my "cave" - a 10-day retreat on the beach in southern Maine (there was camping involved but no actual cave AFAIK). Then spent another 10 days catching up on stuff at home and enjoying the summer with family. So after a needed month of AI burnout prevention, I've cracked open my Codagent dev machine and am back at it.

The talk was called "Agent Harnesses: From Slot Machines to Safety Nets". An agent is the model plus the harness around it: the runtime loop, tools, context, instructions, memory, validation, workflow, and the pieces that make the agent's work repeatable enough to trust.

One part of the presentation I haven't written much about yet is sandboxing. For an SRE talk, it belongs in the reliability story: agents that can run commands, read files, and call tools need real security boundaries.

The more I use coding agents, the more convinced I am that "don't run agents in YOLO mode" is mostly bad advice. If the agent has to ask permission every time it inspects a file, installs a package, runs tests, or retries a command, the workflow breaks down fast.

The practical answer is: don't YOLO on your actual machine. Run the agent in a secure, isolated workspace where it only has access to the files, credentials, and network paths it needs. I started experimenting with a Docker/devcontainer sandbox path for Agent Runner eval work, and I'm thinking about how to turn that into a normal part of my portable outer harness setup.

The three pieces shaping that thinking right now:

Even with the sandboxing topic added in, framing coding agents as an SRE problem had me a bit nervous walking in. But that framing seemed to land - as did the visuals.

The recording will be posted on the SREday YouTube channel, but it isn't up yet.

Spoiler alert: Here is a key "slide" from the presentation:

If you haven't looked at the link above yet, calling this a "slide deck" isn't quite right. What is it then? Well, to start, it's a browser presentation; HTML feels like a much more natural medium for technical presentations in 2026. After building this one, I have a hard time imagining going back to PowerPoint.

There are plenty of HTML slide decks out there. But I believe this one is doing something different. It uses what I'm calling an "evolving-scene model": one shared diagrammatic canvas where a stable set of entities morphs across named steps. Boxes appear, move, connect, collapse, and re-label as the talk develops. The continuity between steps is the key differentiator.

And I came up with that model because that's basically how my brain works. I tend to understand things by building a map of concepts, then visualizing how they connect and layer on top of each other like building blocks. A "normal" slide deck typically treats each slide as a distinct departure from the previous one. Yes, PowerPoint has animations, but "evolving scenes" are challenging to make at best.

But once I had this method working, I knew I was going to use it again. So I turned the creation process into a skill: /and-scene:presentation. It interviews you about the topic, style, content, and what should happen in the visual “storyline”. Then it scaffolds the browser app if needed, codes up the presentation, and verifies the output in the browser.

Get it here: and-scene. The README has a couple of videos of example presentations too, which is probably the fastest way to get a feel for what it can do.

So why did I make this skill? What I told you above is the truth but not the whole truth. Here's the actual origin of my idea to make a presentation skill.

I was trying to come up with a good eval task for Agent Runner, so I could test my coding workflows repeatedly with different models, workflow steps, etc. Coming up with a good use case is harder than it sounds. If the task is too common or too simple, every decent model can chug through it and the eval doesn't tell you much. If it is too big or too weird, you are mostly measuring whether the agent got lost in the weeds. I wanted something in the middle: concrete enough to build, unusual enough that the agent couldn't solve it from muscle memory, and complicated enough to exercise the workflow around the model.

For a while I was unsure what to do, and then I thought: why not make the use case about creating a skill for making presentations like that SREday one, and kill two birds with one stone?

The eval task took the form of a spec for a skill that can make evolving-scene presentations. That spec had to describe the skill behavior, but also the technical underpinnings: the presentation kit, the evolving-scene model, the routing, the browser app, the verification loop, and a demo presentation proving the whole thing works.

Next issue, I will get into the actual eval results: how I am using this task to compare models, workflow steps, and the harness around them.

In the meantime, please try out the skill and let me know what you think! I'd love to hear if others find it compelling for making this style of presentation.