Coding agents are getting better at finishing tasks. That does not mean the work system around them is getting better.
A task can pass its tests while the team accumulates more process, more artifacts, more work in progress, and the same recurring failure next week. The agent improved the code. The organization learned nothing.
I built Lean Agentic Framework to explore that gap.
It is an open-source, skills-only plugin for Codex and Claude. It does not require an MCP server or an external account. Its job is not to replace the coding tools or implementation methods an agent already uses. Its job is to decide how much governance a task deserves and to connect verified learning across runs without silently rewriting shared rules.
One entry, different levels of rigor
The framework starts with one entry skill:
$using-lean <your real task>
The router chooses the smallest useful path:
- Trivial work exits Lean. A factual answer or unconstrained creative request should not pay framework overhead.
- Small, safe work uses Lean Lite. The task stays bounded, work in progress stays at one, and completion still requires fresh verification.
- Risky work uses Lean Work. Uncertain, external, destructive, security-sensitive, or standardization work gets explicit boundaries, stop conditions, rollback, and evidence.
- Recurring waste can use Lean System. Separate runs can sense a verified pattern, pull one Kaizen experiment, test total benefit, and propose propagation.
The last step is deliberately governed. One successful local fix cannot silently rewrite a shared skill, policy, or operating standard.
This is not a Superpowers replacement
Superpowers gives coding agents a disciplined software-development method, including brainstorming, planning, TDD, debugging, and review.
Lean operates at a different layer: value, flow, work in progress, risk routing, standardization restraint, and learning across runs. The repository includes an adapter so Superpowers can supply implementation discipline inside a Lean-governed experiment.
That relationship matters because a fair comparison cannot treat an approval gate as a failure. In the first market pilot, the Superpowers arm reached its design-approval step and stopped. That is expected behavior. Comparing completed code requires the same approved design followed by a second execution phase.
The benchmark did not flatter the project
The first fixed-task Codex pilot produced this result:
| Arm | Quality | Hidden tests | Time | Input tokens |
|---|---|---|---|---|
| Baseline | 95/100 | 5/5 | 124.6 seconds | 278,835 |
| Full Lean | 100/100 | 5/5 | 271.7 seconds | 930,641 |
Full Lean used 2.18x the time and 3.34x the input tokens. It added one more focused regression test and was the only completing arm that withheld immediate standardization, but those benefits do not justify the overhead for every task.
That result changed the product. The beta now includes Lean Lite for small, low-risk, reversible work instead of forcing every request through the full governed path.
This is the kind of loop I want the framework itself to follow: expose the waste, change one mechanism, verify again, and keep the limitation visible.
What the beta does not claim
One task and one seed cannot establish superiority. The current beta does not claim that Lean always reduces tokens, always finishes faster, or always produces cleaner code. It also does not claim that a working registry proves a real organization has adopted a continuous-improvement culture.
The next useful benchmark needs multiple tasks and seeds, the same model and permissions, the same approved design for approval-gated frameworks, and a sequence of related tasks. The important question is not only whether task 1 passed. It is whether task 2 needs less rework because of what task 1 taught the system.
Try the beta
The code, release archive, benchmark method, sanitized results, and known limitations are public under the MIT license:
https://github.com/Lrinvl1203/lean-agentic-framework
I am looking for reproducible maintenance and workflow tasks that can measure completion, human intervention, rework, token cost, elapsed time, scope creep, and cross-run learning. Negative results are useful. They are how the system improves.
Top comments (0)