I really don't think any of these SOTA labs are doing agentic engineering correctly. Skills are the universal language of all agent harnesses. If you abstract the taste and prescription out of the skills and into guidance docs, then leave the skills as basically just workflow scaffolding, you can build task-specific workflows that work with any harness like Claude Code, Codex, Antigravity, etc. Technically, you only really need 2 skills, work and review, and with these you can build infinitely complex workflows including self-improving loops. I built this out and have been using it for months. It's been extremely nice. <a href="https://github.com/DanMcInerney/orchflows" rel="nofollow">https://github.com/DanMcInerney/orchflows
How does your criticism relate to the specifics of what OP posted? <a href="https://github.com/google/ax/blob/main/docs/concepts.md#workspace" rel="nofollow">https://github.com/google/ax/blob/main/docs/concepts.md#work... This says it has skill registries.
Overly complex; yaml files, heavy framework. Same mistake as Claude Code's Dynamic Workflows. Why not just use the dehydrated skills as the workflow skeleton and use custom guidance docs to hydrate the skills with taste and preference depending on the domain of the task? Now you can build a library of small workflows that compose into larger workflow, and you can export any workflow as a single skill to be used in other harnesses. For example, I have a code.md. It's really small, just a bit of taste preference. If I'm using it to hydrate orch-work for coding tasks, then maybe I want to create a code.api.md which hydrates for further specificity if the task is about creating APIs. Then when new models come out, I can just delete code.api.md and leave it as code.md for /orch-work to read from within a workflow because newer models won't need as much prescription.
Part of what's happening is this is running on Kubernetes, which is oft described as "Overly complex; yaml files, heavy framework" but has value regardless, as perceived by being an industry standard. All the things you describe are well and good, but do not address how one runs many of them reliably (from an infra stand point)
DanMcInerney · · focus · HN ↗
handfuloflight · · focus · HN ↗
DanMcInerney · · focus · HN ↗
verdverm · · focus · HN ↗