The planner
Turns intent into requirements, scope, and acceptance criteria, and pairs every piece of work with the check that will prove it.
How it works
A team is only as good as its handoffs.
AceLM turns AI coding agents into coordinated teams that can carry complex software projects from an idea to working, verified software.
The problem
Agents are good at answers. Projects need more than answers.
A coding agent can write a convincing change and a convincing report about it, and still leave a requirement unmet, a test missing, or a regression undetected. On a long project those gaps compound, across tasks, branches, agents, and sessions. Nobody notices until something ships that should not have.
Good engineering teams solved this long ago. They write down what they are building, they have someone other than the author review it, they test against the agreement, and they remember what went wrong. AceLM brings those habits to AI teams, and keeps experienced developers at the helm of them.
The roles
Different jobs, different agents, one record.
Each role gets its own context and its own brief. The builder does not grade its own work, and the reviewer does not quietly fix what it was asked to judge. What they share is the project record: requirements, plans, decisions, and evidence, versioned with the code.
The builder
Makes scoped changes in an isolated Git worktree, and records what it changed, what it decided, and where it deviated.
The reviewer
Challenges the plan and the result from a separate context, with a brief to question assumptions rather than to agree.
The verifier
Checks the final revision against the accepted requirements, runs the tests and scans, and records evidence. Skipped checks stay visible.
You
Set the requirements, weigh the tradeoffs, grant authority, resolve ambiguity, and decide what can ship. AceLM supports that judgment. It does not replace it.
The record
Carries intent, decisions, and remaining work across sessions and clones, so the next agent, or the next developer, starts informed.
The hard parts
More agents could mean more cost, more waiting, and polite agreement. Here is how AceLM avoids all three.
A team of agents passing work around is not free. Every handoff can add tokens and time, and a reviewer that simply agrees adds nothing at all. We take those costs seriously, because a slower, pricier way to get the same result is not an improvement. Here is how we keep them in check.
The concern
The token tax
Four or more agents, each reading context and passing work along, could multiply calls and context size, and the bill along with them.
How we handle it
- Programs before models. A lot of the checking and bookkeeping that agents usually do in their heads, tracking what is left, running tests, comparing a result to its requirement, is done by ordinary software. Code is cheaper than a model call, and it does not hallucinate.
- The right model for the step. Fast, inexpensive, reliable models handle the many small, well-defined subtasks. The most capable models are saved for the work that needs them.
- Lean context. Each step gets the context it needs, assembled for that step, instead of one conversation that grows forever. We manage it dynamically and keep tuning it to cut churn.
- Measure everything, per step. Every step records its time, latency, tokens in, out, and cached, the cost when the provider reports it, and credits when they are available. From those we work out tokens per dollar and tokens per credit, and so what a credit is really worth in dollars. That level of detail is what lets us tune each class of subtask on its own instead of guessing.
- See through the credits. More and more vendors bill in credits, which makes it hard to know what anything costs. AceLM converts them back into tokens and dollars, so you can compare providers and plans on the same footing.
- Tune with real numbers. You get the cost, benefit, and risk of each step side by side, so you can turn rigor up where it pays off and down where it does not. De-identified telemetry about which approaches work best, never your prompts or code, also feeds back into AceLM's defaults, so the system gets cheaper and better for everyone.
The honest picture: in our own work, total development cost comes out about even in the short term. The savings arrive later. Better architecture, design, UX, functionality, and code quality mean far less rework, fewer fixes after release, and changes that stay cheap as the software grows. You pay about the same to build it, and much less to live with it.
The concern
Waiting on the loop
Developers want instant feedback. If a one-line change had to go through planning, review, and a merge you approve, it would feel slow next to autocomplete, and nobody would use it for small things.
How we handle it
- A small change takes one message. Ask for it in chat, for example "add a --sleep arg". If it is small and low risk, AceLM makes it, runs your tests and a separate check, and commits it to your current branch, without a spec, a plan, or a merge to approve. It never pushes. Anything larger, or anything touching a public API, data, security, or dependencies, stops before the commit and comes back to you.
- Not everything gets the full loop. For larger work, review depth and required checks fit the work. A typo should not wait for a release review. You set the dial.
- You always know what is happening. Constant feedback and progress indicators show which role is working, on what, and what comes next, so a longer job never looks like a frozen one.
- Fast where it counts. Program checks run in seconds, small subtasks go to fast models, and independent changes run side by side in their own worktrees.
- Smart routing. A novel agentic routing system sends each task to the model and method suited to it, so simple work stays quick.
The speed that matters is how soon the work is actually done. A change that comes back fast and then needs three more rounds of fixes was never fast.
The concern
A model checking its own work
Ask a model to check what it just wrote, in the same chat or the same product, and you mostly get agreement. It shares the assumptions that produced the work. The usual fix is a second, different model, which costs more and still has to be managed.
How we handle it
- Evidence beats opinion. Verification leans on things that run: tests, regression checks, builds, and scans against the final revision. A model's approval is never the only proof that work is done.
- Review that holds up against a second model. We have developed and proven a way to have a model review its own work rigorously. In our testing, its reviews find the same material problems a second frontier model finds. The difference between the two is negligible.
- Proven on real work. The method was refined and measured over nearly 2,000 logged agent sessions across several environments, on real projects rather than benchmarks. It works across the models we use, including ones that tend to report success too readily.
- A second model when you want one. You do not need one to get a rigorous review, so AceLM does not charge you for one by default. Each assignment can still use its own model and provider, so you can add a different one wherever your policy calls for it.
- People keep the last word. You approve plans, and releases stay a human decision at every setting.
Continuous improvement
Continuous improvement
Every review finding, failed check, and retry is a lesson the team can keep.
AceLM records them with the work, so the next plan can start from what the last one taught. The aim is better quality, speed, and cost over time, measured from evidence rather than taken on faith.
Where it comes from
Built from real agent-assisted delivery.
AceLM grows out of tools we use every day to help developers define work clearly, check it against its specification, and keep quality under control. AceLM carries that purpose into a connected environment for coordinated AI teams, with the rigor, collaboration, and oversight that complex software needs.
Experienced developers remain at the helm. When you come back to a project, or hand it to someone else, the record is waiting: the approach you accepted, the current revision, what has been verified, the open questions, and what is owed. Nobody starts from a blank chat.
Early access
Show us the work you would hand to a team.
Tell us what you want agents to carry and the checks your team relies on.