If you’re like me and often create product specs and technical design docs for agents, I found these kind of specs(if LLM generates) mostly would be 10s of pages and you are subjected to fatigue from reading and reviewing them.
What worked for me was to ask Astra/Fable to include pseudo code in the design doc. which comes to 1-2 pages. Easy for me to skim and change the direction/approach. Rest all of the flowery language is for LLM giving context.
It also depends on your skills and tooling (test execution and verification- agent browser, functional/unit etc)
GPT 5.6 Sol lagging behind Kimi, GLM 5.3 is surprising to me.
I commit them to git(so complete team leverages them)., each repo has kind of different skills and the skills are the ones which I update at least twice a week. I’ve skills on how to add instrumentation , debug, code, code review, tech design review etc. I found most of the skills I find on skills.sh are not very useful for me., but I browse occasionally to get some inspiration. One more paradigm I’m seeing good results on adding new skills is ‘how to do X’, for instance ‘how to add logs’., “how to review code” etc., if i’m not able to frame it that way I don’t think it’s a good use case for me to add that skill to the llm arsenal.
Another thing i discovered is less is more (in case of skills as well)., don’t add lots of skills., keep them very handful - I’ve got 9 skills so far (many people have 100s installed from marketplaces and plugins)
Thats exactly how I use skills as well and I got great results with it.
I work in a proprietary codebase with a lot of niche or custom tooling, weird technical details and historical quirks.
What skills do for me, is essentially skip the "learning" phase of an agent working in the codebase.
With a fitting skill the agent does not need to read the tooling docs, look at existing repos and learn the coding style, but it can get to work immediately.
This is probably less relevant for code that exists a ton in the LLM training data already as an llm is probably competent to some degree in that anyway.
A big caveat here is though that now you need to treat your skills repo very carefully as mistakes in there can easily spread to all of the new code you write using a coding agent.
From quick glance I don’t think so that’s the case. copliotkit promises ag-ui compatiblity., which means it can work with codex cli, mastra, pi, claude agents sdk and other harnesses as well (there are ag ui adapters as well). I’m actually integrating this with claude agent sdk with ag ui adapter., which i don’t think is possible with vercel chat sdk.
I first found out about chat-sdk existence when I was upgrading my nanoclaw (its core feature is that it uses claude agent sdk under the hood as the harness) to v2 and they were migrating to chat-sdk as their base layer for supporting different channels.
It was pretty limited thought in terms of what I needed, so I had to through it away and build my own telegraf sdk based channel implementation for telegram, but that was a while ago, I assume they should have evolved a lot from the time I last touched it about 3 months ago.
Hey, I'm Nathan, DevRel at CopilotKit. That is a really interesting point you are making, and we've heard it a lot. One of the reasons this is so powerful is that it uses AG-UI as the transport, which enables a lot of flexibility depending on your use case. I would love to get your feedback if you decide to give it a spin.
Took me a bit to understand what Wire does, but then it clicked. we’ve built something similar at a smaller scale inside R2, though right now it’s only for .md files.
I can see this becoming much more useful once the docs get heavier: large PDFs, XLSX files, images, etc. At that point you probably need embeddings, reranking etc. But I think agents are smart enough to write scripts to retrieve what they want if we run them on a sandbox(which we are trying to do currently). bookmarking this for now.
You can check my profile for which one I like most :) I do think there have been efforts to benchmark different harnesses.
Personally I'm not going to choose one harness or another based on +/- a few percentage points in a benchmark. I'm going to use one the one that I find the most ergonomic, that isn't too bloated, etc. The models are the primary lever, not the harness.
What worked for me was to ask Astra/Fable to include pseudo code in the design doc. which comes to 1-2 pages. Easy for me to skim and change the direction/approach. Rest all of the flowery language is for LLM giving context.
reply