Skip to content
Traceway
Traceway for agents

Your agents don’t need more context. They need something to be accountable to.

Traceway turns a signed decision into the brief your agents build from, in any assistant, into any tracker. Every work item comes back carrying the decision that authorised it. And when the work isn’t covered by one, the agent stops and says so.

Everything else compares your code with itself. Traceway compares your work with the reasons you agreed.

Running on our own build today, across every tracked item, design and delivery lane in it. The numbers on this page are measured from it.

one chain, end to end
decision
D-217 · Explicit capture only
signed 4 Aug · Approver: Omar N.
brief
v3 · 2 constraints, quoted exactly
served to any assistant that asks
work
TRW-588 · Slack connector
created by the Integrations lane · verified on write
back
Shipped, and still covered
if D-217 is superseded, this item is listed
The loop

Writing the decision down stops being a tax and starts being the input.

Your architecture decisions live in ADRs, a Confluence page, a Slack thread or somebody’s head, and none of those has an address an AI coding agent can cite. Your agents already trace the path, reading the decision, the strategy under it and the design that realises it before writing a single detailed ticket. What no tracker has ever been able to hold is the path itself. Traceway records it as the work is created, so the trail runs both ways.

01

You decide, once

A decision gets made and signed in Traceway, with its rationale, the options you weighed, and the constraints that must not be weakened. Written for people, not for a model.

02

It becomes a brief

Traceway renders that record as a payload an agent can build from: the statement, the constraints quoted character-exact, what it supersedes, and what is deliberately still open.

03

Your agents trace the path

A good ticket comes from reading the whole way down, the decision, the strategy that expresses it, and the design or spec that realises it, if you have one. Whatever you already use walks that path and writes work into whatever tracker you already run, recording each step as it goes.

04

And it comes back

Coverage, drift and challenges flow the other way. Supersede a decision and everything built from the old version is answerable in one list, for free, because the edge was written on the way out.

The guardrail
in testing on our own build

Work that contradicts a signed decision does not merge.

Traceway ships a check you run in your own pipeline. It compares what was built against the decision that authorised it, and fails the pull request when they disagree.

It checks the artefact, not the author. So it holds the same for Claude Code, Cursor, Codex, whatever your platform team wrote, and a person typing by hand. We never need to be inside your agent’s runtime for it to work, which is why a new assistant shipping next month changes nothing about it.

The decision is not all it compares. Your ticket already carries the execution detail: the design boards the work realises, the design system it has to obey, the requirements it was written from. Where those are connected, the check reads them too. Screens drawn and never built. States built and never drawn. Hardcoded colour values where your tokens already exist.

Every one of those resolves to a value that matches a declared one or does not, or to something named on one side and missing on the other. We do not diff screenshots or score how close it looks. The moment a check becomes a matter of taste, an engineer is arguing with a machine and the check is off by lunchtime.

#1602Retention clock fixchecks
buildPassed
unit testsPassed
traceway / decisionsFailed
svc/ledger/retention.ts:88
Contradicts D-092 v42, signed 4 Aug by A. Bello.
Retention runs from the close of the financial year.
The code retains from the row date.
Read the decisionThe decision is wrong, say so
MergeBlocked by a required check

The decision is quoted, not summarised

The exact wording, its version, who signed it and when. Enough to fix the code, or to argue the decision is out of date.

And a way to disagree

Every failure carries a link that opens a challenge, pre-filled with their code and the constraint, routed to whoever approved the decision. No Traceway account needed to use it.

A developer who can only ever be told they are wrong turns the check off. One who can push back becomes your best source of stale decisions.

Anyone who can override a required check in your repository can override this one. Every CI gate has that property. We record the skip on the next sync.

Nobody is opted in

Off, then warn, then block. Per repository, and your engineers hear about it before it fires.

A check that blocks people is not something a vendor should switch on for you. Installing it starts in warn mode and stays there. Nobody can predict how many pull requests a new rule catches in a codebase they have not measured. After a fortnight you have the real number against your real code, and turning on blocking is your call with that in front of you.

off

Not installed

Nothing runs in your pipeline. Disagreements are found on the next sync and reported as findings. A supported way to use Traceway.

warn

Reporting only

The default when you install it. The check runs on every pull request, prints what it would have stopped, and passes.

block

Enforcing

Turned on by an admin who has seen the numbers, one repository at a time. Reversible in a click.

We write the announcement to your engineers before it starts. The first time a developer meets this should not be a red cross on their own pull request.

availability

The check and the generated setup arrive in the product at the end of Q4 2026 or early Q1 2027. We are testing both on our own build until then, which is where the examples above come from. Everything else on this page, the decision record, approvals, the audit trail and coverage, is available today and does not wait on them.

The part that matters

An agent that ships is easy. An agent that stops is the whole product.

Anything can write a ticket. The rare behaviour, the one nobody has built the plumbing for, is an agent that checks the record before it builds and refuses when the two disagree, instead of quietly picking one.

Traceway gives it something to check, a short and closed list of reasons to stop, and somewhere to file the objection so it survives the conversation it was raised in.

Out of scopeContradicts a decisionNo decision covers itThe premise no longer holds
from our own build · 7 aug 2026

A ticket was created from a ruling given off the cuff: imported decisions should carry their original approval and skip governance. Before building it, the lane read the record that governs imports.

The record said the opposite. Rather than absorbing the conflict, it surfaced it.

“go with the artboard. i was going off top of head.”

, the founder, on being shown the conflict
what it prevented

Approval events written for decisions nobody approved, into an immutable, hash-chained audit log. The one class of defect a traceability product cannot walk back.

Coverage

Every decision resolves to the work it authorised, or to a stated reason it authorised none.

Not a progress bar. A worklist. The value is entirely in the rows it forces you to look at, and in a stated reason being a perfectly good answer.

We know this works because it already does, on a different artefact: in our own repo every design board maps to a work item or an explicit reason it has none, and the build fails if one is missing. Every board accounted for, and a good share of them deliberately not built yet, each with a reason.

Authorised

Work exists and carries this decision’s id. The link was written when the item was created, not reconstructed later.

Not executed, and here’s why

Deliberately carries no work, with a reason and an owner. A stated gap is an answer. It is counted, visible, and you can argue with it.

Unaccounted

Decided, and nothing references it. The only failing state, and the one every organisation has without knowing the number.

The three states sum to the total, always. A coverage figure that quietly excludes what you can’t see is not a coverage figure.

No lock-in, in either direction

Any assistant. Any tracker. Your pipeline does not care which one wrote the code.

Files in your repository tell an agent what to read before it starts, and most assistants honour them. The check in your pipeline does not depend on that. It compares the built work against the decision afterwards, which is why it holds the same for the assistant your team adopted last month and the one they will adopt next year.

Works with what you run
Assistants
Claude CodeCodexCursorGitHub CopilotGeminiyour own
Trackers
JiraLinearAzure DevOpsGitHub IssuesNotionand more
Design & specs, if you have them
Figmaa doca repoor nothing at all

Named as examples, not as a compatibility list. Behind them is one work-item contract, if yours isn’t here, it’s the contract that answers, not a roadmap.

In your repository

The check your CI runs, and the brief written out beside the code it governs. One command, pinned. No network call to us, no account for the developer, and it works the same for every assistant.

The open API

REST and webhooks. Read a brief, create work, file a challenge. Anything with an HTTP client, including the agent you built yourself.

The MCP server

One server, every assistant that speaks it. Read grounds the assistant against your corpus; writes are always confirmation-gated.

Native adapters

A package per assistant that installs the rules where that assistant actually looks. Convenience over the API, never capability the API lacks.

AI lanes & mandates

Bring your own AI as a lane, not a plugin.

An AI lane is a standing grant of scope with a job description. You write what it should do in a sentence; Traceway holds it to what it may read, what it may propose, who signs its output, and when the grant runs out.

Your decision vocabulary isn’t anyone else’s. A bank’s architecture decision isn’t a retailer’s, and a generic agent can’t be right for both, the tailoring is the point. Every lane expires by design, so authority never accretes quietly, and renewal puts its actual record in front of a person.

an AI lane, written by you

“Watch every decision tagged risk and, when one is signed, draft the control work it implies, quoting the decision’s constraints and citing it on every item.”

never, on any AI lane

Not configurable. Not unlocked at enterprise tier. A model is never Decider, Approver or Consulted, the moment it can be, the audit trail is worth nothing.

Sign, approve, or record an approval
Set a decision to decided
Edit or delete a decision’s history
Widen who can see something
Close work as verified
Link a person on a name it isn’t sure about

Each of these is on the list because it went wrong somewhere real, ours included.

Where the line is

We don’t run your agents.

You keep the assistant you have, the subscription you have, and the runtime you trust.

We don’t write your code.

Traceway is the brief and the boundary. What happens between them is your team’s and your tools’.

We don’t let a model approve anything.

It proposes. A person signs. Every time, on every plan, with the signature on the record.

We don’t train on your decisions.

Your corpus is yours. Where a fact belongs to a provider, we link their policy rather than paraphrase it as ours.

The check is yours, and skippable.

It runs in your pipeline. Anyone who can override a required check can override this one. We notice on the next sync and record it.

Questions we get

What engineering leaders ask before they put this near a pull request.

How do you stop an AI coding agent contradicting an architecture decision?

You run a check in your own pipeline. It compares what was built against the decision that authorised it, and fails the pull request when the two disagree. It reads the artefact rather than the author, so it works the same whether the code came from Claude Code, Cursor, Codex, something your platform team wrote, or a person typing by hand. And where your design boards, design system or requirements are connected to the ticket, it compares against those too.

Does Traceway run our agents?

No. They run where they already run, on the assistant and the subscription you already pay for. We hand them the decision before they start, and record what they built against it afterwards. There is no Traceway runtime to adopt, and a better assistant makes us more useful rather than less.

Can an agent approve a decision?

No. It can propose one. A person signs it. Editing a decision, changing its status, approving, signing or touching a version are refused at our server for every agent identity, on every plan, with no setting that turns it off.

Is the check on by default?

No. It installs in warn mode, where it runs on every pull request, prints what it would have stopped, and passes. You turn on blocking per repository once you have seen those numbers against your own code. And anyone who can override a required check can override this one, which we record on the next sync.

Which assistants and trackers does it work with?

The check runs in your CI and does not care which assistant wrote the code. Past that there are four doors: files in your repository, an open REST API, an MCP server, and native adapters per assistant. Jira is fully built and works in both directions. Azure DevOps, Linear and GitHub Issues are in private development for launch.

Join the waitlist

Your agents are already building. Give them something to answer to.

Join the waitlist, book a demo, or just get the details, and get a direct line to the team building Traceway. No drip sequence.

Launching first in the United States and Canada. The United Kingdom and the European Union are planned for 2027–28, with the rest of the world to follow. Join from anywhere and we’ll tell you when your region opens.

Protected by Cloudflare Turnstile. We never share your information.
Launching first in the United States & Canada. United Kingdom & European Union planned for 2027–28, rest of world to follow; join from anywhere. Work email only. By submitting you agree to our Privacy Policy and Terms.