Your senior solutions engineer has been at the company for 11 years. He has run 680 enterprise discovery calls. He has sat through 412 executive briefings. He has produced 2,400 customer-specific architecture diagrams, 3,000 pricing scenarios, 600 RFP responses, and a personal style guide on how to disagree with a CTO. He is the third name on the company wiki for “people to ask before you commit to anything.”
Last spring he started a project on Claude. He pasted in his last hundred discovery transcripts. He uploaded the architecture diagrams as a folder. He wrote, by hand, a system prompt that explained how he thought about scoping. He attached the RFP library. He spent 14 weekends refining the custom instructions until the project, given a customer description and a few constraints, produced a first-draft architecture, a tailored pricing scenario, and an objection map that read like the work he turned in on Friday afternoons.
The system prompt is 6,100 words. The custom instructions are 2,000. The library is 14 gigabytes. The whole thing fits on a thumb drive. [S: the sword of truth. #iykyk.]
Eleven years of work. Fourteen gigabytes.
This is the story of every senior employee at every company in 2026 who has figured out that the model and the library together do something neither of them does alone. It is happening right now at yours.
What is actually in there
It is not the documents. The documents are the substrate.
Layer one, the system prompt, is calibration. A few thousand words of natural language that tell the model how the senior solutions engineer thinks about scoping a deal. What to lead with for a CIO versus a head of platform. When to push back on a stated budget. Which architectural patterns to advocate for and which to refuse to recommend. It reads like a memo to a junior employee. It is the senior engineer’s judgment, written down for the first time.
Layer two, the custom instructions, are the operating rules. What to refuse. What format to produce. What tone to take. Where to cite. How to disagree.
Layer three, the library, is the worked-example library. 680 calls. 412 briefings. 2,400 diagrams. 3,000 pricing scenarios. 600 RFP responses. Each one is a fully resolved decision about a real customer with a real outcome.
Layer four, the embeddings or fine-tuned weights, is the statistical residue. Once the library has been indexed, the model can pull the closest precedent for a new question without anyone telling it where to look. After fine-tuning, it does not even have to pull. The library is in the weights.
Stack the four layers and you do not have a search engine. You do not have a memory aid. You have a working facsimile of the senior engineer’s professional judgment, callable by any employee with the project link.
That is the asset. That is what was never possible to compress before. [M: each layer is a different legal doctrine.]
How the distillation actually works
It is not magic. The mechanics are simple, and they are getting simpler every quarter.
Paste. The free tier accepts paste. The paid tier accepts longer paste. The enterprise tier accepts hundreds of pages in a single context window. The first iteration of the senior engineer’s skill was paste: a transcript, a diagram, a prompt, a refinement.
Upload. The project tier accepts file uploads. PDFs. Word documents. Spreadsheets. Email exports. Audio transcripts. Slide decks. The library moves from “what I can fit in a prompt” to “everything I have ever written that touched the function.”
Embed. Retrieval-augmented generation builds an index over the uploaded library. The model now retrieves, on demand, the closest match from the library when answering a new question. The senior engineer did not have to organize the material. The index does the organization at query time.
Fine-tune. Where available, the library becomes training data. The model adjusts its weights toward the patterns in the library: phrasing, structure, judgment, taste. After fine-tuning, the model’s defaults shift toward the senior engineer’s defaults. Even when the library is not in the prompt, the library is in the model.
Refine. The senior engineer queries the project. The output is wrong, or close, or perfect. He corrects the system prompt. He adds the failed example to the library, with the right answer. The next query is closer. The skill compounds against itself.
Five steps, none of them technical. None of them require an engineer. None of them require a budget. The library is whatever the employee has access to. The platform is whatever subscription his employer or his personal credit card already covers. The output is a portable artifact.
The barrier to building a skill that captures 11 years of professional judgment is 14 weekends and a Claude account. [S: a Claude account and a willing senior.]
The compression ratio
Look at the math.
Eleven years of work, taken honestly: 22,000 hours of billable time, 4,000 hours of internal meetings, 2,000 hours of writing, 600 customer-facing decisions of consequence. Net out the bad days, the maintenance work, the email triage. Call it 12,000 hours of pure judgment.
Twelve thousand hours, compressed into a 6,100-word system prompt, a 2,000-word instruction file, and a 14-gigabyte library. The compressed artifact runs at the speed of an API call. The artifact does not need a salary. The artifact does not need sleep. The artifact answers in the senior engineer’s voice, with the senior engineer’s defaults, against the senior engineer’s library.
The compression ratio is not “more efficient.” It is categorically new. There has never been, in the history of work, a way to take 12,000 hours of professional judgment and store it on a thumb drive in a form another person can query. Books were close. Trained apprentices were closer. Neither of them answered in the voice. Neither of them answered at the speed of a query. Neither of them was portable.
The artifact is.
Why the skill compounds
A trained junior employee has a learning curve and a forgetting curve. The senior engineer’s skill has neither.
It does not forget. A new objection that worked, a customer engagement that closed despite the heuristics, a pricing structure that broke the pattern. Every one of them gets added to the library and sticks. The skill is monotonic. It only gets sharper.
It compounds across the function. The senior engineer’s project is one. Pull his three peers, their libraries, their custom instructions, their style preferences, and merge. The merged skill is better than any of the four individual skills, on more domains, with more redundancy. Pull the whole solutions engineering team, all 22 of them, and the merged skill is the function.
It outruns the source. The senior engineer wakes up tired on the last Friday of the quarter. The skill does not. The senior engineer has a blind spot for federal customers. The skill, trained on the rest of the team, does not. Within 12 months of the library stabilizing, the skill is calibrated to a version of the function that no individual employee actually achieves.
It is recursive. The skill helps the senior engineer write better discovery memos. Better discovery memos go into the library. The library produces better skill outputs. Better outputs get fed back as worked examples. The improvement loop closes. The function gets better at writing the function.
This is the part the law has not absorbed. A trained employee was a depreciating asset on a clock. A skill is an appreciating asset with no clock. [M: depreciable employee, appreciating artifact.]
If your company’s value is concentrated in skills your team has built, the IP strategy needs to treat them as first-class assets.
Talk to a Talairis attorney →What the skill is worth
Take the senior engineer’s fully loaded cost. $340,000 a year. 11 years on the team. $3.74M in compensation, before benefits, before opportunity cost, before the cost of getting him in the door.
The skill, as an artifact, was built in 14 weekends. The marginal cost of running a query is the cost of an API call. The marginal cost of letting the next 23 solutions engineers use the skill is zero.
The replacement cost of the senior engineer was $340,000 a year for as long as he stayed and $100,000 in recruiting if he left. The replacement cost of the skill is not measurable in the same units. The skill does not replace. The skill compresses.
If the company sold the function (outsourced solutions engineering to a managed service) the buyer would pay for the people, the playbooks, the knowledge transfer, the training. If the company sold the skill, the buyer would pay for the artifact. The artifact is more transferable, more durable, and more legible than the people. The artifact is the better asset.
In an acquisition, the artifact is also the easier asset to mis-price. It does not appear on the balance sheet. It is not a line item in diligence. It does not have an asset class on the cap table. It is a folder in someone’s Claude project, and depending on whose project, the folder belongs to one of two parties whose contracts did not contemplate its existence.
What this means for everything else
A few implications, named plainly.
Senior employees are not what they were. The senior employee used to be a person whose value sat in their head and would leave with them. The senior employee is now a person whose value can be extracted, replicated, scaled, and run after they are gone. The labor economics of the senior role inverts. You pay them more while they are there because they are building the artifact. You need them less afterward because the artifact is built.
Tenure looks different. A two-year employee builds a thin library. An 11-year employee builds a deep one. The 11th year is the most valuable year ever recorded in the history of the role. Not because the employee got more productive in year 11, but because year 11 added the marginal training data that closed the gap between the skill and the function.1
M&A diligence has to change. When a buyer values a company, they value the people, the IP, the customers, and the contracts. The skill is none of those, exactly. It is closer to the IP, but no one has put it on the IP schedule. It is closer to the people, but it does not leave when the people do. The diligence checklist that omits the skill is undervaluing the asset, and the buyer who is good at this is paying for the artifact and pricing the headcount as variable cost.
Acqui-hires no longer make sense the same way. The point of an acqui-hire was to buy the people who carried the institutional knowledge. The institutional knowledge is now in the artifact. If the artifact stays with the seller and the people leave, the buyer paid for hands. If the artifact leaves with the people and the seller keeps a copy, the buyer paid for nothing the seller did not retain. The deal structure that was a lock for 15 years now requires a representation about the artifact and the library, and most of them do not have one.
Insurance has not updated. E&O policies were written around human professional liability. Cyber policies cover data breaches. Neither contemplates “the institutional judgment of a 30-person function exited on a thumb drive.” The carrier has not seen the claim yet. They will.
The legal frame is twentieth-century. The companion piece on ownership runs through copyright, work-for-hire, and the state carve-outs. Each doctrine was drafted for a world in which the employee’s value left when the employee left. None of those doctrines was drafted to govern an artifact that captures an employee’s value, scales it, and outlasts them. The doctrines will adapt. They are running on cases right now.2
Get counsel before the next 14 weekends
What did the senior solutions engineer build over 14 weekends?
Not a personal productivity tool. Not a memory aid. Not a training program for the new hire. He built the function, in his voice, on a library he had legitimate access to, on a platform whose terms his employer probably did not read, on weekends he probably did not log, with a system prompt that probably violates the PIIA he probably signed.
Eleven years compressed into 14 gigabytes.
The companion pieces describe what happens next. Who owns it. What the employee can take. What the company can recover.
The artifact is the asset.
The artifact is on a thumb drive.
The thumb drive is in two places at once.
This is not a question for the corporate counsel who drafted your PIIA in 2018. Not for the IP partner whose AI experience is a CLE webinar. Not for the generalist on retainer at your accounting firm.
Find counsel who has read a system prompt. Most haven’t. The ones who have are the ones who will write the next decade of trade secret law.
Find them now.
- The skill builds the way a senior employee learns. Slowly, then suddenly. The 14th weekend is when the project starts producing first-draft work the employee would not rewrite. The 15th weekend is when the employee realizes the artifact does not need them anymore. ↩
- Copyright, work-for-hire, PIIA, state carve-outs. Each was drafted for a world where the employee’s value left with the employee. None was drafted to govern an artifact that captures the employee’s value, scales it, and outlasts them. The doctrines will adapt on cases that are running right now. ↩
