On the Seam: Working Drafts · September 2026
Most of the Cargo Should Burn
The follow-up to Burning Ships. Two things are buried in your legacy configuration and they look identical from the outside: institutional knowledge paid for in failure, and technical debt in costume. Telling them apart is the whole exercise.
Last edition I told you the vendors were burning the ships and your cargo was still aboard. I told you to send agents into the legacy system as archaeologists — to read the configuration, reconstruct the logic, and write down what two decades of your business had encoded there before the lights went out.
Several of you read that as save everything. That is not what I meant, and I gave you half an argument, so the correction is mine to make.
Archaeology is not preservation. Archaeologists dig things up, decide what a find means, and leave most of the site in the ground. The point of documenting your configuration is not to carry it across. The point is to be able to tell the difference between the two things buried in there — and they look identical from the outside.
Two things wearing the same costume
One of them is institutional knowledge. A rule exists because a customer was harmed, or a regulator wrote a letter, or a claim went out wrong in 2011 and someone spent a quarter making sure it never went out wrong again. That rule is expensive. It was paid for in failure. It has no other home — it is not in a policy document, it is not in anyone's head, it is in a configuration table on row 4,318.
The other is debt in costume. A rule exists because the system could not hold two addresses per account, so someone invented a suffix convention. Because a VP reorganized the field in 2014 and the workflow forked. Because a batch window ended at 2 a.m. and everything upstream was shaped to hit it. Because someone left. None of that is process; it is scar tissue formed around a constraint that is about to stop existing.
The hard part is that configuration carries no provenance. Every rule in that table has the same authority — none of them are signed, none of them are dated, none of them say why. A rule that saved the company and a rule that accommodated a 1998 storage limit render identically on screen. That is why migration teams default to carrying all of it. In the absence of provenance, everything looks load-bearing.
What the agents are actually for
So use them differently. Not as a transcription service — as an interrogator.
An agent's real advantage here is not that it reads fast. It is that it will ask why does this exist forty thousand times without getting bored, tired, or political about the answer. Point it at the config, the code, the ticket history, the change records, the email threads that survived, and have it try to reconstruct intent for each rule. Then have it tell you where it failed — because a rule whose origin cannot be reconstructed from any surviving evidence is the most important output of the whole exercise. That is your candidate list for retirement.
Then triage. Four questions, asked of every surviving rule:
What breaks for a customer if this stops tomorrow? If the honest answer is nothing, you have found debris.
Can anyone name why it is here? Not defend it — name it. "We have always done it that way" is a retirement recommendation, not a defense.
Would we invent this today, given what we now do? Not given what the system can do. Given what the business is.
Does it encode a constraint of the business, or a constraint of the software? Constraints of the software leave with the software; take them with you and you have paid a migration budget to import the very limit you were trying to escape.
Most rules do not survive all four. That is the expected result, not a failure of the exercise.
Why this is the whole game
I have been arguing for a while that technology is never the catalyst — business model innovation is. The technology arrives, and it arrives for everyone, and it changes nothing on its own. What changes things is a company deciding to make money a different way and using the technology to do it.
Your legacy configuration is the fossil record of the old way of making money. It encodes the org chart you had, the channels you sold through, the handoffs you needed when the work was manual, the approvals you needed when you could not see the data in real time. If you lift all of that into the new platform, you have not modernized. You have built a museum of the previous business model and paid a premium for climate control.
This is the eighth R I keep coming back to. Rehost, replatform, refactor, and the rest of them are all answers to how do we move this. Reimagine is the only one that asks should this move at all — and it is the only one that gets you anything you did not already have. Carrying the configuration forward is rehosting your business model. It is possible to do that on the newest platform in the market and end up exactly where you started, with better latency.
What to do with the survivors
The rules that pass triage are not migration items either; they are requirements. Extract the intent, write it down in language a person can argue with, and rebuild it in an owned semantic and orchestration layer that sits above whatever platform you are on this decade. That layer is the thing worth building, because it is the only part of the stack that is yours and does not have a sunset date attached to it by someone else's product roadmap.
Everything that fails triage goes in a document with a date and a name on it. Not deleted quietly — retired deliberately, with someone accountable for the decision. If you are wrong about one, you want to know whose call it was and what they knew at the time. That is the difference between letting things die and losing them.
The bonfire is not the problem. Sorting the cargo on the dock in the dark, with the ship already burning and a vendor telling you the boat leaves in eleven months, is the problem.
Start sorting now, while there is still someone in the building who remembers why row 4,318 is there.
Dr. Trey Harper writes on trust, legitimacy, and the architecture of the agentic enterprise at treyharper.com and in the LinkedIn newsletter On the Seam: Working Drafts. The views expressed here are entirely my own and do not represent the policy or position of my employer or any customer.