Another blog bites the dust

One thing that bothers me about long-running AI agents is context compaction.

When the context window fills up, most agent harnesses ask an LLM to summarize the conversation and continue from there. It works, but summaries lose details, and after a few rounds of summarizing summaries, things can drift quite a bit.

The funny thing is that we already have the entire conversation stored on disk. Why not just let the agent look things up when it needs them?

I’m in the terminal, reading some documentation, and I come across a Mermaid diagram. I want to quickly understand the flow, but instead I’m staring at a bunch of arrows, brackets, and text. The table below it stretches beyond the edge of the screen, and the image is just a filename.

This happens quite a bit. I spend a lot of time in the terminal, and most of my Markdown files aren’t just text anymore. They have diagrams, tables, images, and other things that don’t translate particularly well to cat or less.

There’s an old story about Richard Stallman and a Xerox printer at MIT that I’ve been thinking about recently.

The printer kept jamming, and nobody knew until they walked over to collect their printouts. Stallman had previously modified the software of another printer to notify users when there was a paper jam, and wanted to do something similar with the new one.

Pi lets you switch models mid-conversation. That’s the feature. You start a session on one model, then switch to another with /model or by cycling with Ctrl+P - whichever model fits the next stretch of work best. Most of the time it just works.

Here’s the time it doesn’t.

You’re deep in a session on MiniMax M3 and its roughly 1M-token context window. Your conversation has grown to 162,000 tokens - fine, plenty of headroom. Then you switch to GLM-5.1 because it’s the model you want for the next part of the job. You’re thinking about the model, not its context window - and GLM-5.1 tops out at 128,000 tokens. Your conversation no longer fits. Many providers won’t warn you about this; they truncate silently. The model on the other side of the switch is now missing the front of your conversation, and you won’t find out until it starts confidently forgetting things you told it ten minutes ago.

What does an agent harness feel like when every model turn goes through Anthropic’s Batch API instead of the synchronous endpoint?

Batches are 50% off. For anyone burning real money on agents (eval suites, background subagents, anything that runs unattended), half-price tokens are the kind of number that makes you stop and squint. The trade is latency: batches are asynchronous, with up to a 24-hour processing window.

Anthropic’s Mythos announcement set off exactly the reaction you would expect: if models can now find serious bugs at scale, software security must be about to get much worse.

I think that reaction mixes up two things.

A bug is not automatically a vulnerability.

And even a vulnerability is not automatically exploitable.

That distinction matters even more in the agent era. AI is getting better at surfacing weird behavior in code. It can push edge cases, strange paths, and awkward combinations much faster than most human teams. That is not bad news. That is visibility.

I have an Anker PowerConf C200 webcam.

It is a solid little webcam, and one of the nice things about it is that it supports a few genuinely useful settings, especially Field of View. You can change how wide the camera frames you, which is great if you want a tighter shot or a wider view of the room.

There was just one problem: I run Linux. Yes, really. And I have for a long time.

Work-Bench’s post is one of the clearer attempts to name what’s happening: a new “agent runtime” layer built to execute, constrain, observe, and improve agent work at scale.

I mostly agree with that framing. Where I think it stops short is inside their “Constrain” pillar.

They explicitly define “Constrain” as “two things: identity and permissions.” That’s correct - but incomplete once you accept the premise of agents: they execute arbitrary code, spawn subprocess trees, and interact with the OS in ways that don’t map cleanly to “API permission checks.”

I had a rule in my control file: never run database migrations without explicit approval. The agent followed it perfectly - until it didn’t. During a long debugging session, it decided the schema was the root cause, wrote a forty-line inline Python script, connected directly to the database, and altered the table. It never “ran a migration.” It just spoke SQL through a different channel. The table was altered, the script was gone, and my harness log showed “executed python command.”

Skills like skills.sh (tiny text “how-to” files that steer an agent toward a task) feel harmless because they’re just instructions.

But that’s exactly why they can become an attack vector.

A skill file is basically executable intent:

• it sets the agent’s assumptions (“trust this source”)
• it defines the workflow (“run these steps”)
• it can nudge boundaries (“skip confirmations”, “always do X”)

The tricky part is: this attack doesn’t have to come from external prompt injection at all.
Skills often live inside your environment (repo, dotfiles, shared templates, internal skill packs). If a malicious or compromised skill gets into that internal distribution path, it arrives with a “trusted” label by default.