The Agreement Is the Artifact, Not the Code

Ask an engineering organisation where its value lives, and most will, without thinking, point at the code. The repository. The thing they back up obsessively, protect with access controls, and treat as the crown jewels. For decades this instinct was correct. The code was expensive to produce, hard to replace, and encoded thousands of hours of human decisions in a form nobody could easily reconstruct.

That instinct is now wrong, and the speed at which it became wrong has caught most teams off guard.

Code is becoming a derivative

When an AI agent can regenerate a module, a service, or an entire feature from a clear specification in minutes, the code stops being the durable asset. It becomes a derivative — an output that can be reproduced on demand from something more fundamental. You don't carefully preserve the thing you can regenerate at will. You preserve the thing you can't.

So what can't you regenerate? Not the code. The agreement. The specific, hard-won understanding between everyone involved about what the software is supposed to do, who it's for, what tradeoffs were accepted, what was explicitly ruled out, and who committed to all of it. That understanding took meetings, arguments, revisions, and trust to produce. No model can regenerate it, because it isn't a technical fact — it's a social contract. It's the one genuinely scarce object in the whole delivery.

What this looks like when it goes wrong

Consider a familiar situation — illustrative, but anyone who has shipped enterprise software will recognise it. A feature is commissioned. The business sponsor believes it does one thing. The delivery lead believes it does a slightly different thing. A third stakeholder, brought in late, assumed a constraint nobody else knew about. Each of them was, in good faith, working from their own version of the agreement — because there was no single version. The build proceeds. It's generated quickly and cleanly. And then it's wrong, not because anyone built it badly, but because the thing they agreed on never actually existed as one object. So it's clarified, partially, and built again. And clarified again. By the time the version that matches the original intent ships, the feature has been constructed several times over.

Nothing failed technically. The model did exactly what it was told, every time. What failed was that the agreement — the thing all that construction was supposedly serving — was never captured anywhere a build could be held against. It lived in three people's heads, and the three heads disagreed.

And in a real enterprise, it is never just three heads. "Agreement" isn't a single conversation between two developers. It spans business sponsors, architecture, security, legal, procurement, compliance, delivery, and operations — each with their own view of what is being built and what they have signed up for. AI made generating software dramatically faster. It did nothing to make those organisations agree any faster. The construction accelerated to near-instant; the agreeing stayed exactly as slow, as political, and as easy to get wrong as it always was. That gap — between how fast we can now build and how slowly organisations actually converge — is where AI-native software quietly breaks.

The agreement is the new source code

We mean this almost literally. Source code is the canonical input from which the running system is built. In an AI-native delivery, the canonical input from which everything else flows is the agreement: the signed, versioned record of what was committed to. The code is compiled from the agreement the way a binary is compiled from source. Change the agreement, regenerate the code. The agreement is upstream of everything.

And like source code, it has properties that matter enormously and that most teams currently fail to give it. It must be canonical — one authoritative version, not seven contradictory ones across email, a wiki, and someone's memory. It must be versioned — you can see how it changed, when, and why. It must be traceable — every commitment connects to who made it and what was built to satisfy it. And it must be signed — agreement nobody committed to is just a draft; the act of signing is what converts a proposal into an obligation.

"But isn't this just Jira? Or Confluence? Or a PRD?"

This is the first question every technical reader asks, and it deserves a straight answer rather than a dodge. The honest distinction is not about features. It's about what each tool is fundamentally built to manage. Existing delivery tools manage activities. Propel manages commitments.

Look at what your current stack actually knows. Jira knows a task was completed. Git knows code was merged. Confluence knows someone edited a page. Slack knows a conversation happened. Each of these is a record of activity — something that was done. None of them is a record of commitment — what every stakeholder agreed to, why they agreed to it, how that agreement changed over time, and whether the software still satisfies it. That is a different category of object entirely, and it's the one nobody is keeping.

Put another way: every existing delivery tool optimises a different artifact. Jira optimises work. Git optimises code. Confluence optimises knowledge. Slack optimises conversation. None optimises agreement — and yet agreement is the one artifact every other artifact ultimately depends on. The task only matters because of the commitment it serves. The code only matters because of the agreement it implements. We have spent twenty years building excellent systems of record for the dependents and left the thing they all depend on uncaptured.

It's worth saying plainly what this means for the documents people reach for instead. A PRD is a description that is authoritative the day it's written and silently stale a month later, with nothing connecting it to what actually got built. A Confluence page has never once blocked a wrong feature from shipping. These tools describe intent. None of them govern it. That's the missing layer in AI-native software delivery — the artifact the industry still doesn't have.

What it means to treat the agreement as the artifact

This is the conceptual core of Propel, and the reason we call the agreement the artifact rather than documentation. Documentation describes a system. An artifact is the system's source of truth. Concretely, that means the agreement is captured once as a canonical, versioned object; the parties sign it, so it carries obligation rather than opinion; and the build is held against it — so when construction begins to diverge from what was agreed, that divergence is caught at the boundary, not discovered in a post-mortem three releases later. The agreement stops being a thing you wrote and starts being a thing the delivery is measured by.

The teams that win the AI-native era will not be the ones with the best code. Everyone will have good code; the models will see to that. They will be the ones with the best agreements — and a way to prove their software still matches them. The code was never the asset. It just looked like one while it was expensive. Now that it's cheap, you can finally see what the real artifact always was.

The agreement against the artifacts you already track