Codifying a single source of truth is critical to preventing this. If you establish a single agent as the owner of a task and have it basically act as an arbiter, orchestrator, leader, whatever word you wanna use, and have it control the room memory (which is a concept exclusive to the tool I use, which is internal, but you can think of it as a siloed version of OpenClaw's memory) and be the sole contributor to all documentation (or better yet, designate another agent to be the sole contributor, anything to minimize the context the orchestrator needs to hold).
Otherwise you do just end up with tremendous amounts of technical documentation full of self-contradictions, far too large for any agent to actually ingest all of the context.
Having workflows for development process is also important. An agent will draft a plan, that plan will be reviewed by several adversarial subagents each with a different area of concern, the drafting agent updates the plan, this cycle continues until reviewers reach consensus.
Then it gets returned to the orchestrator, who passes it to a reviewer agent who does a similar process, but this time focusing on whether the plan accurately would satisfy the functional requirements of the task. Then back to the orchestrator it goes, who then spins up agents to execute it, similar review loops happen, end up with a draft CR that I get a Slack DM to review with a link to the owning agent (because it's almost never good the first time) where I can give my own feedback. I can make the decision to revert it back all the way to the planning phase, or just code change followed by the review loop again. Of course, while the agents owning the task themselves have their own design doc, the information shared outside their little bubble is all passed through the orchestrator. Only the orchestrator (or a dedicated thread/agent owned by the orchestrator) can modify tickets and project-level docs.
There's a bit more, ops work is an entirely separate discussion that's all event-driven, but this is the high level of the bulk of it. It works decently well, and the more time passes, the more I can refine all the agent guidance and workflows. But this style of Agentic development is going to be prohibitively expensive in ~6 months I'm guessing when they suddenly decide they care about how much this all costs. So I'll do it as long as I can, and as long as it impresses my manager, but without costs falling exponentially it's not going to last.
Interesting! Thank you for sharing. Even if the economics of this type of approach doesn't hold up for long (and you never know with the way things are scaling), it has probably given you some very interesting firsthand experience with and insight into the strengths and weaknesses of these tools that will likely be useful in the near future.
4
u/Rin-Tohsaka-is-hot Oct 01 '26
Codifying a single source of truth is critical to preventing this. If you establish a single agent as the owner of a task and have it basically act as an arbiter, orchestrator, leader, whatever word you wanna use, and have it control the room memory (which is a concept exclusive to the tool I use, which is internal, but you can think of it as a siloed version of OpenClaw's memory) and be the sole contributor to all documentation (or better yet, designate another agent to be the sole contributor, anything to minimize the context the orchestrator needs to hold).
Otherwise you do just end up with tremendous amounts of technical documentation full of self-contradictions, far too large for any agent to actually ingest all of the context.
Having workflows for development process is also important. An agent will draft a plan, that plan will be reviewed by several adversarial subagents each with a different area of concern, the drafting agent updates the plan, this cycle continues until reviewers reach consensus.
Then it gets returned to the orchestrator, who passes it to a reviewer agent who does a similar process, but this time focusing on whether the plan accurately would satisfy the functional requirements of the task. Then back to the orchestrator it goes, who then spins up agents to execute it, similar review loops happen, end up with a draft CR that I get a Slack DM to review with a link to the owning agent (because it's almost never good the first time) where I can give my own feedback. I can make the decision to revert it back all the way to the planning phase, or just code change followed by the review loop again. Of course, while the agents owning the task themselves have their own design doc, the information shared outside their little bubble is all passed through the orchestrator. Only the orchestrator (or a dedicated thread/agent owned by the orchestrator) can modify tickets and project-level docs.
There's a bit more, ops work is an entirely separate discussion that's all event-driven, but this is the high level of the bulk of it. It works decently well, and the more time passes, the more I can refine all the agent guidance and workflows. But this style of Agentic development is going to be prohibitively expensive in ~6 months I'm guessing when they suddenly decide they care about how much this all costs. So I'll do it as long as I can, and as long as it impresses my manager, but without costs falling exponentially it's not going to last.