Just because they can doesn't mean inventing a new framework "for agents" is going to be superior to letting agents use what's in their training data. I suspect it'll be worse, but the time/resources needed to prove that is beyond what I'd be willing to invest.

What makes something like this "for agents", anyway? It's opinionated...a human's opinions, I assume, since agents don't want anything and thus can't have opinions. But, many existing tools are opinionated. Types are good for agents, because it keeps them honest, but many existing things in this space have types. Python is good for agents, because there's a shitload of Python code and documentation in their training data, but many existing things are built with Python (and TypeScript, Go, and Rust are also typed languages and well-represented in the training data).

I dunno. I think a lot of folks are sitting around with an agent thinking, what can I build? And, a lot of things "for agents" are being built, as a result. I think most of them don't need to be built and don't improve software development with agents. They often just chew up context and cache with extra arbitrary rules the agent needs to follow without delivering improvements.

> we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.

Doesn't this end up being way more expensive, because you don't pay for model parameter activations but for the tokens in/out, meaning that anything not in the training data (and therefore, the model) will cost you. I could make Opus use a new language I came up with if I wanted to and it'd do an okay job with enough information... but it'd be more expensive and wasteful than just telling it to write the same algorithms in Python, and possibly a bit more error prone. Same with frameworks and libraries.