What is the TRACE Framework?
The TRACE framework is a comprehensive approach to building software when AI agents write most of the code. It emerged from a simple recognition: teams got dramatically faster at producing code, and no faster at trusting it.
The central insight is simple: you cannot judge agent-written work by the code alone. A change can pass every check and still be the wrong change, because nobody wrote down what it was meant to do. So TRACE looks at the whole path. What you asked for, how it got built, and how you know it worked.
The name "TRACE" is an acronym representing five parts of good agentic engineering:
TRACE is an open framework, it is free, and no vendor owns it.
- TTrustworthyYou can check the work without taking anyone's word for it.
- RRepeatableThe same request gives you the same result.
- AAgenticThe process is built around agents, not bolted onto them.
- CCollaborativePeople decide what gets built. Agents build it.
- EEngineeringThe bar does not drop because a machine wrote the code.
Why TRACE exists
Agents made the writing quick. Everything after it stayed where it was. Review, security checks, release. Those were already the slow part of most teams, and now they carry far more than they were built for.
There is a cost nobody budgeted for: the time it takes to check what the agent produced. Call it the verification tax. It is why teams adopt agents and then wonder where the speed went.
From there teams go one of two ways, and both cost you.
Some wave it through. Review turns into a rubber stamp, and quality slips without anyone noticing when it started.
Others pull the handbrake. They slow the agents down to a pace people can read, and give back the speed they paid for.
TRACE is the third way. Decide how you will check the work before it starts, then let the agents run.
The five parts of TRACE
Each part covers a different side of building software with agents. Reading all five together gives you a balanced view, and avoids the common trap of chasing speed on its own. The measures under each one are starting points. Pick the few you can actually count today, and add more as you go.
Trustworthy
You can check the work without taking anyone's word for it. Decide how you will know it worked before an agent writes a line. An agent saying it succeeded is not a check, and neither is a test it wrote itself in the same pass.
- Quality
- Escaped defects, regressions, review rework
- Security
- New critical and high findings, exposed secrets, vulnerable dependencies
Repeatable
The same request should give you the same result. Agents fill gaps, so write down what done means and what they may not touch. Watch for cognitive drift as well, when an agent's reasoning slides because its stored facts have gone stale. Re-run an old request now and then and compare.
- Reliability
- Change failure rate, rollback rate, time to restore
- Drift
- An old request re-run and compared, spread across repeated identical runs
Agentic
Build the process around the agents, because they do the work. Two week sprints and story points assume a person is typing. An agent finishes in minutes and tries again in seconds. Most teams keep the old process and bolt agents onto the side.
- Delivery
- Lead time, cycle time, deployment frequency
- Economics
- Tooling cost against business outcome
Collaborative
People decide what gets built. Agents build it. One named person owns the intent, not a role and not a queue. They also watch for intent drift, when what the agent is working toward slides away from what you asked for.
- Developer experience
- Flow, cognitive load, feedback loop speed
- Adoption
- Which parts of the work agents are actually used for, whether people come back, whether they say it helped
Engineering
The bar does not drop because a machine wrote the code. Agent output is software, held to the same standard as anything else you ship. Watch cognitive debt as well as the usual kind. Code nobody on the team understands is unmaintainable even when it is clean.
- Maintainability
- Complexity, duplication, architectural drift, cognitive debt
Where TRACE fits
TRACE does not replace Agile or Scrum.
Keep your planning. Keep your backlog, your roadmap, your retros. Those work fine and they are about people deciding what matters.
TRACE covers the part underneath. What happens between "here is the work" and "the code is done", now that a machine does the building. That gap is where existing methods have nothing to say, because none of them were written for it.
Common objections
"This will slow our agents down."
It does the opposite. Teams slow agents down when they cannot check the output. Give them a way to check it and the reason to hold back disappears.
"Our tests already cover this."
Only if the tests came first, and only if the agent that wrote the code did not also write the tests. A test written to pass is not a test. It is a description.
"Isn't this just spec-driven development?"
Spec-driven development is about getting an agent to build the right thing. That is most of the work and it is worth doing. TRACE covers that, and then asks how you prove the agent actually did it. It also stays independent of any tool.
TRACE, DORA and spec-driven development
These are the two frameworks TRACE gets confused with most often. All three are complementary. Each one answers a different question, and none of them replaces the others.
| Aspect | DORA | Spec-driven development | TRACE |
|---|---|---|---|
| Focus | Speed and stability of delivery | Getting the agent to build the right thing | Whether the finished work can be trusted |
| Covers | The delivery pipeline | The workflow before and during the build | The whole path, from the request to the proof |
| Takes the form of | Four numbers you track over time | A process, usually with tooling | Conditions the work has to meet |
| The question it answers | How is our delivery performing? | How do we tell the agent what to build? | Can we believe this change? |
| Best for | Tracking delivery health over time | Turning an idea into working code | Teams where agents write most of the code |
DORA tells you the pipeline is healthy. Spec-driven development gets the agent building the right thing. Neither tells you whether the finished work can be trusted. Run all three.
How to implement TRACE in your organisation
You do not need permission or a budget. Do these in order, and stop when the returns flatten. Each one serves a part of TRACE.
Trustworthy
One command that checks everything
A single command that runs the build, the tests and the checks. Under a minute, no network, no shared database. If the agent cannot run it, it stops checking and starts guessing.
Trustworthy
Write the tests in a separate session
Tests are adversaries. A test written in the same session as the code will confirm what the agent just built. Start a fresh session, give it the requirement and not the implementation, and let it try to break the thing.
Repeatable
Codify the rules instead of describing them
Anything a linter or an architecture test can enforce belongs there. Prose in a repo instructions file costs context on every task and gets followed most of the time. A rule that fails the build gets followed every time.
Repeatable
Freeze what is already broken
Switching on a rule surfaces hundreds of old violations on day one. Freeze that list and fail only on new ones, or the team turns the rule off by Friday.
Repeatable
Keep the repo notes short
Twenty lines. Commands the agent cannot guess, files that are risky, old code it should not copy. Everything else belongs in a check. For every line, ask whether deleting it would change what the agent does.
Collaborative
Ask for a plan before the code
For anything bigger than a small fix, have the agent say what it will change first. Read that instead of the diff. A ticket about a search filter that comes back touching nine files across billing is a problem you can spot in thirty seconds.
Trustworthy
Run a verifier agent
A different model from the one that wrote the code, in a fresh context window. Same model and same context means the same blind spots. Run it privately before push and publicly on the pull request. On a serious finding it should bring in a human rather than block the branch.
Engineering
Push standards centrally as policy
One place holds the rules. Local agents, remote agents and verifier agents all pull the same version. A standard that lives in one team's repo is a preference. The same standard executed everywhere is a bar.
Agentic
Count how often it passes first time
One number, watched over a few weeks. It tells you more about the quality of your instructions than anything else you can measure.
The first three are about a week of work, and they will teach you more than three months spent designing the perfect system.
What we publish
The Framework
The standard itself.
RFCs
How it changes. Anyone can propose one. No vendor holds a seat.
Patterns and Playbooks
How real teams run it, written by the teams running it.
Ready to put TRACE into practice?
EnWithAI turns product intent into validated software through a disciplined execution system.
Learn How EnWithAI HelpsTRACE itself stays free and independent. Any tool that meets the standard works.
Questions
What is TRACE?
A framework for building software when AI agents write most of the code. It sets out what has to be true before you can call the work done.
Is it a tool?
No. It describes what good looks like. Any tools that get you there are fine.
Does it only apply to AI-written code?
No. It applies to everything you ship. Agents made it urgent.
How is it different from spec-driven development?
Spec-driven development is about getting the agent to build the right thing. TRACE covers that and adds the proof that it did. It is also independent of any particular tool.
Do we have to drop Scrum?
No. Keep it for planning. TRACE covers the build loop underneath.
Is it a compliance standard?
No. Compliance frameworks govern companies and answer to auditors. TRACE governs work and answers to engineers.
Some rules say two people must review code before it ships. Where do agents fit?
Nobody has settled this yet. Over the last decade, passing a set of automated checks came to count as one of those two reviewers in some places. Agents reopen the question, because an agent is neither a person nor a fixed check. TRACE takes the position that whatever reviews the work has to be independent of whatever produced it. How regulators land on this is still open, and it is a good subject for an RFC.
Who runs TRACE?
It is independent and engineer led. No vendor owns it or holds a seat in how it changes.
How do I contribute?
Through an RFC. If you are running TRACE on a real team, a pattern or playbook is just as welcome.