It is 9:14 p.m. on a Thursday. The fourth-year associate is at one of the most prestigious corporate law firms in the world, whose partners bill up to $4,000 an hour, whose merger agreements every other firm copies. The deal is the kind her firm closes a dozen of every quarter. She has her laptop open to the working draft of the merger agreement. Two browser tabs. The seller’s data room is on the left. The firm’s merger agreement template (last meaningfully revised in 2019) is on the right. Microsoft Word, Outlook, the disclosure schedule in Excel.
Her firm bought Legora last year. The contract was $800K. The seat license counts say she has access. She has logged in twice. The first time she could not figure out what the prompt was supposed to be. The second time the answer did not match the firm’s house style and she went back to drafting in Word. The partner overseeing the deal has logged in zero times. The two senior associates on the deal have logged in three times between them. Light prompting, never a workflow, none in the last six months. The Slack channel where the firm’s AI champions celebrate use cases has 20 members. The firm has 1,400 lawyers. [S: every firm bought it. Nobody opens it.]
The IP rep she is drafting tracks the firm’s 2019 template, lightly modified for the deal-specific facts. It uses the seven-category definition of “Intellectual Property” the firm has been using since 2014. It assigns the seller’s “Software” category to the seller’s source code repositories and SaaS deployment manifests. It assumes the seller’s value lives where her template says it lives.
She has never written a system prompt. She has never assembled a library. She has never seen a fine-tune. She has never wired up an agent. She does not know what the seller built. She does not know how to ask. She does not know what to ask for. Her partner does not either. The seller’s counsel, a peer firm, equal pedigree, equal hourly rates, equal command of the merger agreement, is in the same condition.
The target has an incredibly valuable asset class. None of these lawyers, on either side of the table, with thousands of deal closings between them, has ever encountered it. They have all completely missed it. The deal does not account for it. The merger agreement does not represent it. The escrow does not protect against its loss. Both parties will live with material ramifications they did not negotiate.
This is the story of every M&A deal in 2026.
What M&A used to value
Walk forward through the asset classes M&A actually priced over the last forty years.
1980s and early 1990s. Tangible assets. Factories, equipment, real estate, inventory, physical distribution. The asset purchase agreement carried a fixed-asset schedule, a real property schedule, and an inventory schedule. The reps were title reps. The buyer did a physical inspection. The lawyers verified deeds, liens, and UCC filings. The asset was tangible and the documents reflected the asset.
Mid 1990s and 2000s. Registered IP. Patents, trademarks, copyrights, registered trade secrets. The IP schedule appeared. The IP rep grew teeth. Patent searches became standard. Trademark watches became standard. The asset was filed with a government office and the documents tracked the filings.
Late 2000s and 2010s. Source code and customers. SaaS multiples replaced revenue multiples. Open-source license compliance became a rep. Source code escrow became a deal point. The customer contract schedule listed the top 50 customers, their annual run rate, their contract end dates, and their assignment provisions. The asset was the codebase and the cash flow it produced. The documents tracked them.
2010s and early 2020s. Data and platforms. GDPR and CCPA forced data-protection reps into the standard merger agreement. Cyber breach reps became standard. Vendor schedules grew. SOC 2 attestations became diligence items. Data processing agreements became their own exhibit. The asset was the data the company held and the platforms it operated on. The documents tracked them.1
Every era added a schedule. Every era added a rep. The standard 2024 purchase agreement is the layered accumulation of forty years of asset evolution. Each layer added when the asset emerged, none removed. The merger agreement reflects what M&A used to value.
It does not reflect what M&A is buying now.
How the documents encode the prior eras
Read the standard purchase agreement front to back. The asset framework is visible in the schedules.
Schedule 3.1: fixed assets. Schedule 3.2: real property. Schedule 3.3: leases. Schedule 3.4: inventory. The 1980s.
Schedule 3.7: registered IP. Schedule 3.7(a): patents. Schedule 3.7(b): trademarks. Schedule 3.7(c): copyrights. Schedule 3.7(d): domain names. The 1990s and early 2000s.
Schedule 3.8: software. Schedule 3.8(a): proprietary software. Schedule 3.8(b): open-source components. Schedule 3.9: material customer contracts. Schedule 3.10: material vendor contracts. The 2010s.
Schedule 3.12: data privacy. Schedule 3.12(a): privacy policies. Schedule 3.12(b): data processor agreements. Schedule 3.13: security incidents. The early 2020s.
There is no Schedule 3.X: application layer. There is no Schedule 3.X(a): system prompts and custom instructions. There is no Schedule 3.X(b): library and provenance. There is no Schedule 3.X(c): fine-tuned weights and embeddings. There is no Schedule 3.X(d): agent credentials and tool integrations.
The merger agreement does not have a slot for the asset that drives the premium.
What the application layer absorbed
This is the part the merger agreement misses, and the part that matters most.
For forty years, M&A documents tracked the asset by tracking its proxies. The asset itself, the company’s accumulated capacity to do what it does, was never directly inventoried. It was inferred from the things that surrounded it.
The IP schedule was a proxy for the judgment that had been formalized into protectable form. The patents stood in for the inventions. The trademarks stood in for the brand. The registered copyrights stood in for the authored works.
The key-person schedule and the employment agreements were a proxy for the people who carried the unformalized judgment in their heads. The senior engineer. The founding salesperson. The principal architect. The non-compete, the retention bonus, the earn-out vest were the buyer’s hedge against the proxy walking out the door.
The source code repository was a proxy for the executable encoding of every business decision the team had ever made. The customer contract schedule was a proxy for the relationships, the negotiated terms, the trust accumulated over years of operation. The trade secret rep was a proxy for the ad hoc institutional know-how that lived in internal systems.
The application layer collapses all of it.
This is not an additive change. The application layer is not a new asset class added to the existing list. It is the destination toward which every prior asset class has been quietly migrating for two years. The IP that mattered is in there. The people who mattered are in there. The knowledge that mattered is in there. The customer history that mattered is in there. The workflow that mattered is in there. Strip the layer out and the company is a brand, a customer list, and a cash flow that will not survive 18 months of competitive pressure.
The application layer is increasingly the company.
The merger agreement and your law firm don’t know that yet. [M: the merger agreement is a museum.]
Why the lawyers cannot see it
Three reasons, in increasing order of awkwardness.
Templates are conservative. M&A practice iterates by reference to last quarter’s deal. The merger agreement gets marginal updates. New schedules get added when an asset class becomes undeniable: when the CLE programs cover it, when the rep insurance carriers underwrite it, when the firm’s training program names it. The application layer has not yet crossed those thresholds. The merger agreement is two years behind, and two years is the entire life of the asset class.2
The asset is invisible to inspection. Tangible assets sat on the balance sheet. Registered IP sat in a government database. Source code sat in a repository. Customer contracts sat in DocuSign. The application layer sits on someone else’s platform, under credentials that may or may not transfer, in a configuration that may or may not be exportable. There is nothing to inspect physically. There is nothing to search. There is no inventory unless someone built one. The diligence checklist was built around inspection. The asset evades inspection.
The lawyers have not lived inside it. This is the part the profession is not yet talking about. None of the lawyers on either side of the deal, associate, partner, seller’s counsel, has assembled a library, written a system prompt, wired up an agent, or seen a fine-tune. They are valuing an asset class they have not, in their own practice, encountered. They cannot describe to the client what the seller built because they have never built one.
If the best M&A lawyers in the world have not used the artifact, the work they produce will not represent the artifact.
If you’re advising on a deal — buy-side or sell-side — where one of the parties is AI-native, the diligence checklist needs to be longer than your firm’s template.
Talk to a Talairis attorney →It is not just the IP rep
Walk the merger agreement top to bottom and the gap repeats.
The asset-class representation. Schedule 3.X does not list the application layer. The seller represents ownership of patents, trademarks, copyrights, source code, and trade secrets. The seller does not represent ownership of the asset that drives the premium.
The retention mechanism. Key-person retention is tied to the seat, not the artifact. Earn-out milestones are calibrated to revenue, not to layer transfer. Non-compete carve-outs were drafted to protect customer relationships, not configurations on third-party platforms.
The post-closing claims framework. Survival periods, baskets, caps, and indemnity scope are tuned to the assets the merger agreement represents. The escrow releases on a calendar that does not contemplate the layer’s drift, the embeddings’ degradation, or the platform’s terms changing under the buyer’s feet.
The material adverse change definition. The buyer’s walk right between signing and closing does not reach a change in the layer. The seller can lose the admin, swap the library, or migrate the fine-tune in week eight, and the buyer has no out.
The closing conditions. The list of things that have to be true at the bring-down (accuracy of reps, no MAC, third-party consents) does not include the application layer surviving in working condition into the buyer’s hands.
Five different parts of the merger agreement. Same gap. It does not see the asset. [S: blind in five places.]
And that is in a stock or merger deal, where everything the company owns transfers by operation of law. In an asset purchase agreement, the gap widens to a chasm. The buyer in an APA acquires only the assets specifically named on the transfer schedule. Assets not named stay with the seller. The standard asset-transfer schedule does not name system prompts, custom instructions, fine-tuned weights, embeddings, retrieval indexes, or platform tenancies as Acquired Assets. Under the literal text of the form, the seller keeps the layer at closing. The buyer pays for a company that just lost its asset class.
The source-code asymmetry
The strongest counter to this piece is that the merger agreement is more elastic than we have portrayed it. The IP rep sweeps “all Intellectual Property necessary to conduct the business as currently conducted.” The Software definition reaches “scripts, configurations, data, databases.” The trade-secret rep covers “confidential information.” In a stock deal everything transfers by operation of law. The further-assurances covenant patches misses. The catch-all indemnity backstops everything else. The buyer is fine.
The merger agreement is elastic. Elasticity is not enforceability.
Compare what the merger agreement does with source code, an asset class the elite M&A firms have agreed for forty years is too valuable to leave to a sweep clause.
Source code gets a definition in Article 1. A representation of exclusive ownership. A schedule listing every material proprietary application. A separate open-source compliance representation, drafted to head off copyleft and disclosure obligations clause by clause. A separate trade-secret representation that names source code as the protected asset. An employee-assignment schedule confirming every developer’s contribution was assigned to the company. A repository-transfer covenant with admin handover at closing. A third-party-licensee schedule. A mature diligence playbook with named vendors (Black Duck, FOSSA, Snyk, Sonatype) running open-source license scans, dependency audits, and vulnerability reviews on the seller’s repositories before the buyer ever opens the data room. In an asset deal, source code is named on the asset-transfer schedule and assigned at closing alongside the build pipelines and credentials.
Eight distinct touchpoints across the merger agreement, plus a parallel diligence shakedown. One asset class. The elite firms have decided source code is too important to leave to operation of law and a wish.
For the application layer, the asset that absorbs IP, people, knowledge, customer relationships, and workflow into one queryable artifact, the merger agreement has zero analogous touchpoints. No definition. No representation. No schedule. No open-source-style compliance subsection. No trade-secret call-out. No employee assignment confirming the system prompt is the company’s. No repository-transfer covenant for the project file. No platform-tenancy schedule. No admin-handover requirement at closing. No vendor scanning the seller’s Claude or OpenAI tenants for orphaned projects. No tool auditing the library for license provenance or training-data origin. No diligence checklist line item asking the seller to list every fine-tuned model trained on the company’s data, every embeddings index queried by production traffic, every system prompt deployed against a customer-facing surface. The diligence playbook for the application layer is empty. Nobody is scanning for it because nobody on the deal team is asking.3
The asymmetry is not that the application layer is too new to draft for. The asymmetry is that source code, an asset class with established economic value, gets every safeguard the elite firms have invented since 1990, while the application layer, where most of the company’s accumulated value now lives, gets a sweep clause and a wish. [S: lawyers run the last war.]
A weaker version of the counter-argument is that the application layer is a commoditized vendor tool, not an asset. A configuration on a third-party platform, like a Salesforce instance or a Looker dashboard, both of which have always been handled informally without their own schedules.
That was true two years ago. It is not true now.
The application layer in 2024 was a compliance dashboard run through a third-party vendor. A thin wrapper over a model API, swappable, commoditized, replaceable. The merger agreement ignored it for the same reason it ignores the company’s Slack workspace. It was infrastructure, not an asset.
The application layer in 2026 is not infrastructure. It is the company’s institutional judgment, written down in calibrated text, anchored to a private library of customer-specific material, refined across thousands of iterations, and statistically encoded in fine-tuned weights or retrieval embeddings. It is the senior solutions engineer’s eleven years on a thumb drive. It is the litigator’s six hundred and forty briefs in a project file. It is the VP of sales’s three thousand calls in a configuration she built on her personal account.
That is not a vendor tool. That is the asset class M&A has spent forty years building proxies for, finally directly captured in one artifact that travels at the speed of an API call.
And here is the sharper irony. AI is collapsing the value of source code itself. Code generation has compressed development cycles to a fraction of what they were two years ago. Reproducing a competitor’s proprietary codebase used to take a team of engineers 18 months. It now takes a project, a corpus, and a weekend. The “proprietary code” defense was the centerpiece of B2B SaaS valuation for two decades. The dramatic compression in SaaS multiples since 2023 is the market repricing source code in real time. Code is becoming the commodity. The application layer is becoming the moat.
M&A attorneys are investing more drafting effort in protecting an asset class whose value is dissolving, and ignoring the one that has absorbed it. The merger agreement is a lagging indicator. The market has already moved. Law firms need to catch up.
What this means in deal pricing
Two failure modes, both real.
The buyer pays an AI premium for a capability the IP rep does not represent. The application layer at the seller is on personal Claude accounts. The founder leaves at month three of the earn-out. The application layer leaves with her. The buyer’s only contractual recourse is through reps that do not name the asset, indemnities that do not cover it, and an escrow that releases on a calendar the buyer’s lawyer set against assets the rep was about. The price the buyer paid was for an asset the merger agreement will struggle to enforce against the seller losing.
The seller commands the premium and does not get credit for the layer being dialed in. Version-controlled prompts, a tagged library, an enterprise-tenant fine-tune with transferability, service-account credentials owned by the company. None of this raises the multiple, because the merger agreement does not have a place to give credit. The seller does not get paid more for being more buyable. The same merger agreement that lets the unprepared seller skate also flattens the prepared seller. [S: prep gets you the same rep.]
Both failure modes are produced by the same gap. The merger agreement encodes what M&A used to value. The deal is paying for what M&A values now. The mismatch is not closing on its own, and the lawyers tasked with closing it have not used the tool that would let them see it.
What to do
If you are buying, find a lawyer who actually understands the application layer and put them on the deal team. Your elite firm still closes the deal. The specialist makes sure the deal is for the right asset.
If you are selling, find counsel who can help you prep before you walk into the data room. The merger agreement does not credit the prepared seller. The right attorney does.
A closing thought
The associate is still at her desk at 11:42 p.m. The IP rep is done. The disclosure schedule is on its third pass. The merger agreement is the one her firm has been using since 2019. She has not opened Legora tonight. She has not opened it in eight months. The $800K seat sits unused, two icons to the right of Outlook.
The seller’s application layer, invisible to the merger agreement, invisible to her, invisible to the partner who will sign her work, is what her client is paying the premium for.
The rep her client is getting is for the assets of 1995, 2005, and 2015. Accreted, layered, refined, and silent on the asset class that has absorbed all of them.
In 2026 the application layer is increasingly the company. The merger agreement and your law firm don’t know that yet. Your counterparty’s counsel doesn’t either.
But now you do.
---
Postscript: what the recent agreements actually say
We pulled three recent material public-company merger agreements off EDGAR. We read them in chronological order. Each was drafted by one of the elite M&A firms in the country. These are the deals every other firm in the country grades itself against. Each side of each deal, both buyer and seller, closed under a merger agreement we are about to take apart.
HPE / Juniper Networks. January 9, 2024. Fourteen billion dollars. Section 4.16, the IP rep, covers patents, trademarks, copyright registrations, domain names, trade secrets (including source code), open-source compliance, and employee invention assignment. The Disclosure Schedule lists every item of Registered Company IP with title, application number, filing date, jurisdiction, and owner. Source code gets its own subsection. The rest of the merger agreement (the asset rep, the retention mechanism, the indemnity scope, the MAC, the closing conditions) is the standard 2018-vintage language. The full text of the agreement, scanned end to end, contains zero mentions of “artificial intelligence,” “machine learning,” “fine-tuning,” “system prompt,” “training data,” “model weights,” “large language model,” or “generative AI.” A fourteen-billion-dollar acquisition of a networking and security company in 2024 closed under a merger agreement that would have read clean in 1998.
Salesforce / Informatica. May 26, 2025. Eight billion dollars. Section 3.14, the IP rep, lists five categories of Intellectual Property, all tied to a government filing: patents, registered trademarks, domain names, copyright registrations, and “any other Intellectual Property that is the subject of an application, certificate, filing, registration or other document issued by, filed with, or recorded by” a government authority. The application layer fits into none of them. The agreement does mention AI in Section 3.9, the privacy and compliance rep, where the Company represents that it complies with laws governing the development, training, fine-tuning, and validation of “AI Systems,” and that it had legally enforceable rights to use the Training Data. It is a compliance rep, not an asset rep. It says the Company did not break any AI laws. It does not represent the existence, scope, ownership, or transferability of any system prompt, custom instruction file, agent configuration, fine-tuned weight, embeddings index, retrieval library, or tool integration. It puts none of them on a schedule. The retention package, the indemnity, the MAC, and the closing conditions all run on the standard merger agreement language, untouched by AI. The asset class is invisible across the document.
Electronic Arts going-private. September 28, 2025. Fifty-five billion dollars. Acquired by a consortium of the Saudi Public Investment Fund, Silver Lake, and Affinity Partners at $210 per share. Section 5.1(q), the IP rep, works through six subsections of the same forty-year-old asset framework: registered IP, infringement, trade-secret protection, employee assignment of inventions, government funding, source code, open source. Subsection (vii) is new. It reads, in full, that the Company and its Subsidiaries “(A) have obtained all licenses and consents, provided all notices and disclosures, and taken all other steps required by applicable Laws in order to collect and use all AI Inputs in the conduct of their business as currently conducted, (B) use all AI Technologies in compliance with all applicable license terms, consents, agreements and applicable Laws, and (C) have not been subject to any Actions regarding the Company’s or its Subsidiaries’ development or deployment of any AI Technologies.” Three subclauses, all compliance subclauses. Defined terms “AI Inputs” and “AI Technologies” carry the entire AI rep, and they carry it without representing ownership, scope, transferability, or location of any of the underlying artifacts. EA, a fifty-five-billion-dollar take-private of a software company that uses AI throughout product development, has its application layer represented by three compliance subclauses tucked into the seventh subsection of the IP rep. Nothing about the application layer is scheduled. Nothing in the retention package, the indemnity, the MAC, or the closing conditions reaches it. The asset class is invisible across the document.
Three deals, twenty months apart. Each more recent. Each one slightly more aware that AI exists. None of them representing the application layer as an asset. None of them protecting the buyer who paid for it. None of them giving the seller credit for having built it.
In every one of these merger agreements, source code, the moat of 2010, got eight schedules, six representations, and a parallel diligence shakedown that likely ran into the millions. The application layer, the moat of 2026, got nothing.
These were not bad firms drafting on a bad day. These were elite M&A firms drafting at the top of their game on the most-watched deals of the year. They did not see the application layer. The merger agreement they produced does not see the application layer.
Their clients pay the price.
Sources: HPE / Juniper Merger Agreement, Ex. 2.1; Salesforce / Informatica Merger Agreement, Ex. 2.1; Electronic Arts Merger Agreement, Ex. 2.1.
- Most M&A merger agreements still treat data as risk, not asset. Privacy compliance, breach disclosure, processor agreements, GDPR conformity. Defensive language all the way down. JPMorgan’s Frank disaster gets cited as proof of that gap. That’s actually not true. When the elite firms drafted around Frank’s user count, the User definition was tight and the customer-count representation was specific. Charlie Javice was convicted on those reps. $287 million in restitution was ordered. JPMorgan’s investor-indemnity claims run through them. The Frank failure was institutional diligence, not drafting. The elite firms know how to draft around an asset class once they decide it is one. The application layer is the asset class they can’t see yet. We give the Frank deal its own breakdown in Why JPMorgan Closed Frank. ↩
- M&A templates iterate by reference to last quarter’s deal. When source code became the asset, the elite firms spent five years building the eight-schedule, six-rep, parallel-diligence treatment around it. The deals closing today are closing under templates that predate the asset. ↩
- Application-layer diligence isn’t its own industry. Yet. Good luck finding an attorney who can run this. Tenancy audits, system-prompt inventories, library provenance, fine-tune transferability, embeddings indexes, agent credentials, tool integrations. ↩
