Another blog bites the dust

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.

Back in the Web 2.0 days, RSS and Atom feeds promised a better way to consume content. No more jumping between websites just to catch up on what’s new. You could open a single feed reader and get everything in one clean stream. It felt like the web finally worked for you instead of the other way around.

As the ecosystem grew, new tools appeared around it. One of the biggest was FeedBurner, which Google later acquired. It helped publishers track subscribers, manage feeds, and even monetize them by inserting ads directly into the feed. It was an early version of what we now call native advertising - ads that blended right in with regular content.

I was chatting with friends about context compaction and how hard it can be to carry forward important context from past LLM sessions without wasting tokens or repeating yourself.

We kept coming back to the same pain point: you finish a productive session, but when you start a new one, you have no clean way to bring that history along. Claude Code already keeps a full record of every session on your local machine. So why not make that data more accessible and usable?

Last Wednesday (Sep 10), I had the chance to attend a hackathon at Cursor’s offices - huge thanks to the Cursor team for hosting such a great event! 🙌 The focus was on Cursor CLI and their new Background Agents API.

When I started brainstorming ideas, I came across Eric’s post about running various rules during CI/CD to automate checks and actions. It got me thinking — setting up those rules often involves a lot of repetitive work: crafting similar prompt setups and then defining the actions themselves.

Command line interfaces used to be the domain of automation experts who knew how to wield the tool with precision. They scripted pipelines, chained commands, and bent systems to their will from a blinking cursor. That hasn’t gone away, but something new is happening. Large language models are now picking up these tools and wielding them just as effectively.

The key is design. If a CLI has clear help text and well described flags, an LLM can step in like an apprentice who suddenly knows the whole manual by heart. Add the ability to output JSON or another structured format, and the tool becomes not just usable but consumable. The LLM can run the command, parse the result, and carry the output forward into the next step.

Lately, I’ve been working on something I probably wouldn’t have pursued if not for the rise of AI coding agents.

It’s called pgsqlite - a Postgres wire protocol v3 compatible server, written in Rust, that runs on top of the standard SQLite library.

On the surface, it might sound like a niche tool. But it solves a very real and increasingly relevant problem. Why This Could Be Useful

As more developers integrate autonomous coding agents into their workflows, the need for lightweight, sandboxed environments grows. These environments often need a database - usually for tests, schema validation, or other backend tasks.

If you are using VSCode or any other non-integrated editor (even vim or emacs), chances are you are already using a language server. These servers power features that are specific to the language or framework you are working with. They provide documentation, autocomplete, code navigation, warnings, and more.

When you click on a function and jump to its definition, a language server is likely behind the scenes making that possible.