So, one thing I’m doing, and it’s really powerful, is creating Controllable Autonomous Agentic Loop (CAAL), which are observable and pausable workflows with agentic loops.
When combined with meta-prompting, it allows an agent to work end to end across the entire development flow, or the SDCL (Software Development Life Cycle) which typically includes: requirements → specification → design/architecture → implementation → testing → review → deployment → maintenance.
It’s somewhat similar to the concept of spec-driven development, but amplified through an autonomous loop, which can be controlled and is observable. Actually, rather than spec-driven development, it may be closer to RALPH loops but with controllable state.
It is a workflow that can run autonomously, but also allows you to stop at different states, if you want, and check the status, see the prompt it generates, inspect the meta-prompting, run evaluations, and assess whether what it has produced is good, and if so, run it.
Or if you don’t want you can let it run autonomously through all the steps.
In other words, I can let it run completely on its own and then review everything afterward like this
# caal stands for Controllable Autonomous Agentic Loop
node caal.js run user-story01.md --agent "bash call_agent.sh"
or I can stop it while it’s in progress like this:
node caal.js stop
or
just control + c
review what has been generated till that point, and resume from there or execute specific steps, changing the agents.
How it works? Once started, it runs by itself, generate itself the prompt to execute the current task (Metaprompting based on my base prompt that references important documents and tell important rules to follow), execute the task and move to the next one; some tasks are deterministic and some tasks are agentic (they could use whatever coding agents or agentic harness you want); always guided by the workflow, of course.
In my first implementation of a CAAL, there are a series of steps in the autonomous development workflow that are necessary, for example:
– generating a lot of BDD tests (gherkin) and unit tests
– implementing the code using the Luminous architecture
– running the tests: if they fail, use a skill to debug and debug autonomously until it pass (till a max retries though)
– reviewing the generated code to check whether it is sound and whether it has broken anything at the architectural level. For example it could run the luminous checker to verify if any Luminous principles were violated.
– run security audits
– run GDPR checks
So the workflow can be fairly advanced, and it runs by itself in a loop that can be controlled, paused, and advanced. It can be controlled because I can pause it whenever I want and I can execute specific steps in the workflow, even using different agents for it:
node caal.js step generate_gherkin
#$WORKFLOW_PROMPT is set by the caal and contains the generated prompt for the current task
node caal.js step generate_code --agent "claude < $WORKFLOW_PROMPT"
It is observable because I use tracing to log each important execution and step. Moreover I made it log each important artifact like the prompts used as base prompt for the workflow, the prompts used to generate the prompts for the task, the prompts generated by the agents, the logs of the agents and the state (it’s a basic state.json)
It’s incredibly powerful, because with the level of intelligence we currently have, it really is possible to build very high-quality software in less time. And by less time I mean 50-90% less time (depending on the skill set of the team)
That’s simply the case, because I’m using it myself, and that’s what I’m seeing.
PS: I made it in a single javascript file that can run with nodejs. Why not a repo? because I want it to be flexible and portable (maybe I could do a repo). You can do it in whatever language you want.
Leave a Reply