While reading, I had an idea about how to turn competition between agents into something useful. What if we use competition only at a higher, strategic level: a kind of product committee of agents that argue which ideas or policies to implement, with budget, justification and some form of consensus. Curious what you think about this direction.
I actually set up a Telegram digest for Hacker News using OpenClaw, and today that digest brought me to this very post. Nice little full circle moment.
I'm in a similar spot and very curious about the transition path, not just the end state.
We have several projects and different teams. In one of the more “advanced” ones we already run on a fairly standard enterprise stack: Jira for work tracking, Confluence for docs, and a dedicated repo for SDD/technical specs. That’s also the place where I’m closest to getting something that feels like real autonomy: the agentic dev loop is running and integrated into the existing tools, but there are still plenty of manual guardrails and workarounds.
My question is less about wiring up specific tools and more about the change‑management / rollout side. In practice this is a digital transformation: it’s not enough to define the target “agent‑first SDLC”, you also need a sane path to get there from a messy reality with ingrained habits and existing tooling.
Have you seen any concrete adoption patterns or approaches that worked well for teams already mid‑project?
I'm currently at the stage where my agentic dev loop is running and feedback is flowing, but I haven't reached true autonomy yet. I still have to control things with manual workarounds constantly. That's exactly why I'm curious about others' experiences.
The most interesting challenge to me is the transition path in practice: how do you get from the messy reality to that clean ideal picture when a team is already mid-project with their own ingrained habits and tooling preferences?
I manage 18 microservices with heavy LLM usage and kept running into the same problem: when I talk to my teams about treating context as a scarce resource, there is no single term for what I mean. "Token efficiency" is a cost metric. I needed a design principle I could name, reference in code reviews, and enforce.
Core idea: a context is parsimonious when nothing in it can be removed without introducing ambiguity or degrading the result. The goal is not fewer tokens — it's conscious allocation of a finite budget between instructions and artifacts.
Does this distinction hold, or is it just a subset of token efficiency?
What existing formalisms would you apply here?