When the deal is the whole network.

The unit of sale changed under everyone's feet

The single-tenant sale was simple to reason about. A buyer had a document problem, the vendor had a pipeline, the contract named one tenant and one price, and the renewal was a conversation between two parties who both knew the volume. The 2026 deals that actually move budget look nothing like that. The buyer is an anchor — a party that sits at the centre of a network of connected companies and has both the relationship and the incentive to push the same capability out to every node in that network.

The shapes recur across verticals. A professional-services firm certifies tens of thousands of its own people on an agentic toolchain and wants the document layer underneath to be the same everywhere. A bank that already intermediates a network of correspondent lenders wants those lenders to originate on the same extraction and KYB stack so the paper coming back is consistent. An insurance carrier distributes a submission-intake agent to the brokers who feed it business. A B2B marketplace offers its sellers an onboarding and invoice agent as a platform feature. In every case the party who signs is not the party who runs the documents. The anchor buys the deployment; the network runs the work.

The vendor still pitching "a deal per company" is competing for a line item. The vendor that ships "a deployment per network" is competing for a category of budget — and the anchor distributes the product for them.

This is not the reseller motion in new clothes. A reseller moves licences and disappears. An anchor stays in the loop: it sets policy for the network, it carries some of the data governance, it often takes a cut of the revenue, and it expects telemetry on whether the network is actually adopting what it paid to distribute. The vendor's product surface has to answer to two customers now — the anchor who bought it and the node who uses it — and those two customers do not want the same things.

The math: why a network beats a logo

The reason the network unit wins budget is not that it is bigger. It is that the cost of landing the second node, the tenth node and the thousandth node falls while the value per node holds or rises. The single-tenant motion pays full customer-acquisition cost on every logo. The network motion pays it once — at the anchor — and amortises it across the nodes the anchor distributes to.

The line that matters is "value per node rises with the network". A document AI platform improves when it sees more of the same document class — the schema stabilises, the low-confidence fields get characterised, the decision logic gets calibrated against more outcomes. In a single-tenant world that learning is trapped inside one tenant. In a network — with the governance done right — the platform can lift every node's accuracy from the aggregate signal without ever moving one node's documents to another. That is the network effect that makes the model defensible: the hundredth node onto the platform starts at a quality level the first node took six months to reach.

The three vendor effects in the first two quarters

The shift to the network unit does not announce itself as a strategy memo. It arrives as three concrete changes in how deals are scoped, what the buyer's technical team asks for, and how quickly the contract closes.

1. The deal anchor is the network, not the buyer

The first effect is commercial. The deal is no longer priced against one tenant's page volume; it is priced against the network's projected adoption, with a tiered model that rewards activation. The anchor does not want to pre-pay for 80,000 nodes that may never log in, and the vendor does not want to give the network away on the hope that it activates. The pricing that holds is a floor plus a per-active-node tier — the anchor commits to a baseline that covers the vendor's deployment cost, and the bill scales as nodes cross an activation threshold the contract defines.

The consequence for the vendor's commercial team is that the metric they manage is no longer "logos closed". It is "active nodes per anchor" and "time from anchor signature to Nth node live". A network deployment that signs a marquee anchor and then activates 4% of the network in two quarters is a deal that looks like a win on the press release and a loss on the revenue line. The vendor who measures only the signature is the vendor who is surprised at the first renewal.

2. Cross-node data governance becomes the differentiator

The second effect is technical, and it is where most vendors who try the motion fail. The moment a network shares a platform, the buyer's security team asks the only question that matters: can node A ever see node B's documents, extractions, or corrections — by bug, by misconfiguration, or by a feature we did not scope? In a network of competing brokers, competing lenders, or competing sellers, the answer has to be a provable no by default, and a precisely-scoped, opt-in, revocable yes where the network genuinely wants to share.

This is the same per-tenant isolation discipline that the sovereign-AI piece covered for single regulated buyers, raised one level. It is no longer enough to isolate one tenant from another tenant; the platform has to isolate one node from another node inside the same anchor's network while still letting the anchor see roll-ups and letting opted-in nodes share what they choose to share. Governance stops being a compliance checkbox and becomes the feature the deal turns on. The vendor whose multi-tenancy is "a tenant_id column and a query filter" loses the deal the first time the buyer's penetration test finds a query path that forgot the filter.

3. The deal cycle shortens because the anchor distributes

The third effect is the upside that pays for the first two. Once the anchor has signed and the per-node onboarding is templated, each subsequent node does not run a full sales cycle. The anchor distributes — through its existing channel, its existing trust, its existing contract — and the node's decision shrinks from "evaluate a vendor" to "turn on a capability the anchor already vetted". A motion that took 90–120 days per logo in the single-tenant world collapses to days per node once the network template exists. The vendor's job shifts from selling each node to making activation frictionless, because the anchor has already done the selling.

The architecture that holds

A network deployment is a multi-tenant system with a second axis. The first axis is the classic one — tenant isolation. The second is the anchor: a node belongs to an anchor's network, the anchor has rights over its network that no node has, and policy flows down from the anchor while data does not flow sideways between nodes. Five components carry the shape.

Per-node isolation by construction, not by query filter

Each node is a first-class tenant with its own isolation boundary — its own encryption context, its own document store partition, its own model-routing policy where it needs one. Isolation is enforced at the layer below the application, so a forgotten WHERE clause cannot leak a node's data to a sibling. The test that proves it is not a code review; it is a standing cross-node access test in the pipeline that tries to read node B's data while authenticated as node A and fails the build if it ever succeeds.

Opt-in data sharing with per-participant control

The default is no sharing. Where the network wants a shared benefit — a common schema, a shared vendor blocklist, a pooled fraud signal — it is an explicit, scoped, revocable opt-in held by each participant, not a default the anchor flips on for everyone. The sharing is mediated: a node contributes a signal (a corrected field pattern, a confirmed fraud marker) without exposing the underlying document, and a node consuming the shared benefit cannot reverse it back into another node's source data. The audit trail records who opted in, to what scope, and when — so the answer to "why did this node's pipeline change" is always on the record.

Anchor roll-ups without node-level exposure

The anchor paid for the deployment and is entitled to know whether the network is adopting it. That entitlement is adoption and outcome telemetry — active nodes, documents processed, auto-resolution rate, exception rate — at the aggregate and per-node-metric level, not the right to read a node's documents. The architecture draws the line explicitly: the anchor sees that node B processed 4,000 invoices last month at a 92% straight-through rate; the anchor does not see node B's invoices. Where the anchor has a genuine operational need to see content — a correspondent bank that is legally on the hook for its lender's files — that is a named, contracted, audited exception, not the default the platform ships.

Adoption telemetry as a product surface, not a dashboard

Because the vendor's revenue and the anchor's success both ride on activation, telemetry is not an internal dashboard — it is a surface both parties read. Per-node activation state, time-to-first-value, the drop-off points in node onboarding and the nodes that activated and then went quiet are the operating data of the deployment. The vendor who instruments this surface can tell the anchor "these 40 nodes stalled at step three of onboarding" and fix the funnel; the vendor who does not instrument it discovers a dead network at renewal.

Per-node revocation and a network kill switch

A node leaves the anchor's network — a broker is terminated, a seller is offboarded, a correspondent loses its licence. The platform has to revoke that node cleanly: cut its access, settle its data under the retention policy, and remove it from any shared signal it contributed to, without disturbing the rest of the network. And the anchor needs a network-level kill switch for the case the single-tenant world never had — a way to pause or pull the whole deployment if a systemic problem appears, the same shape the provider due-diligence piece argued for at the model layer, applied here at the network layer.

The revenue model with the anchor

The network unit changes the contract as much as the architecture. The single-tenant contract was a two-party document. The network contract is three-cornered even when only two parties sign it, because the anchor is distributing value to nodes it does not pay for directly, and everyone has to agree on how the money and the obligations split.

Three structures have settled into the deals we see, and each is defensible if the parties are honest about what it trades:

• Anchor-funded, free to nodes — the anchor pays the whole bill and distributes the capability to its network at no charge as a retention or enablement play. Simplest to operate; the vendor's risk is total concentration on one payer, so the contract needs a long term and a real exit clause.
• Floor plus per-active-node — the anchor commits a baseline that covers the vendor's deployment and integration cost, and the bill scales as nodes activate past a defined threshold. The fairest alignment of the three: the vendor is paid for the build and rewarded for adoption, and the anchor is not pre-paying for a network that has not turned on.
• Revenue share with the anchor — the node pays, and the anchor takes a defined cut for distributing and standing behind the product. Works where the anchor is a marketplace or platform whose business model is already a take-rate; needs a clean revenue-recognition and tax treatment that a two-party contract never had to think about.

Whichever structure the deal uses, the clause that does the real work is the one that names what happens to the nodes if the anchor relationship ends. A node that built its operations on the platform through the anchor should not be orphaned the day the anchor walks. The contract that survives diligence on the node side names a continuity path — direct conversion, a wind-down window, a data-egress guarantee — so that the node's risk of depending on the anchor is bounded. The vendor who can offer that continuity wins the anchors whose nodes are sophisticated enough to ask.

Four anti-patterns that leak the network

The network motion fails in four recognisable ways. Each one is invisible at signature and expensive by the second quarter.

Multi-tenancy that isolates by query, not by construction. The most dangerous and the most common. A platform built for single tenants and stretched to carry a network relies on every query remembering its tenant filter. In a network of competing nodes, one missed filter is not a bug — it is a breach that exposes one node's documents to its competitor, through the anchor's own platform, and it ends the anchor relationship and every node with it. The isolation has to be enforced below the query, and proven by a standing cross-node access test, before the network motion is even pitched.

No per-node SLA — only an anchor SLA. The vendor signs an SLA with the anchor and assumes it covers the network. It does not. A node experiencing a degraded pipeline does not care about the network-wide uptime number; it cares that its invoices are stuck. A network deployment without a per-node SLA and per-node support path turns every node problem into an anchor escalation, and the anchor — who is not operating the documents — becomes an unpaid support tier that eventually resents the deal. The SLA has to reach the node, or the anchor carries a burden it did not sign up for.

Single-anchor dependency with no diversification path. A vendor whose revenue is one anchor's network has built a business with one renewal conversation. When that anchor renegotiates — and an anchor distributing to 80,000 nodes knows exactly how much leverage it has — the vendor has no alternative. The same concentration discipline the due-diligence piece applied to model providers applies in reverse here, on the customer side: a healthy network book has more than one anchor, and no single anchor past a stated share of revenue.

Treating the node as a feature of the anchor, not a customer. The vendor who builds only for the anchor — the buyer who signs — ships a node experience that no node would have chosen. The nodes do not activate, the network looks dead, the anchor's enablement play fails, and the renewal is a post-mortem. The product has two customers. The node's onboarding, the node's SLA, the node's support and the node's data rights have to be designed for the node, even though the node never signed the contract — because the node's adoption is the only thing that makes the anchor's deal real.

The concentration trade-off the model invites

The honest case against the network unit is concentration. The single-tenant book spread risk across many uncorrelated renewals; lose one and the others are unaffected. The network book concentrates risk at the anchor: one anchor relationship can gate the revenue of an entire network, and the anchor knows it. The leverage that made the deal cheap to land is the same leverage the anchor holds at every renewal.

The model does not remove the trade-off; it makes it survivable with three moves alongside the deal. A book of multiple anchors, so no single network past a stated share of revenue can dictate terms — the customer-side mirror of a multi-vendor model portfolio. A node continuity path written into the contract, so the vendor can convert nodes directly if an anchor leaves and the nodes are not hostages to the anchor relationship. And a governance and evidence envelope — the per-node isolation proof, the audit evidence, the residency and revocation guarantees — that a cheaper entrant pitching the same anchor cannot match in the first 12 months, so the anchor's leverage is bounded by the cost of replacing a platform its whole network now depends on.

The vendor who lands a network on price and a query-filter multi-tenancy has built a deal that the next entrant takes on price. The vendor who lands it on a provable isolation boundary, a per-node SLA and a node continuity path has built a deal the anchor cannot cheaply walk away from — which is the only thing that makes the concentration acceptable.

A 90-day plan — vendor side and anchor side

Converting a single-tenant platform and a single-tenant sales motion into a network deployment is one quarter of work on each side. The deliverables are an isolation proof, a node-onboarding template, a telemetry surface and a contract structure — not a re-platforming.

For the IDP vendor

Days 1–30: the isolation proof and the second axis. Establish per-node isolation below the query layer and write the standing cross-node access test that fails the build if node A can ever read node B. Add the anchor as a first-class object — a node belongs to an anchor, policy flows from anchor to node, data does not flow node to node. The output is an isolation boundary you can put in front of a buyer's penetration test without flinching.

Days 31–60: the node-onboarding template and the telemetry surface. Templatise node activation so the Nth node onboards in hours, not a sales cycle. Build the adoption-and-outcome telemetry surface the anchor reads — active nodes, time-to-first-value, onboarding drop-off, per-node outcome metrics — with the line drawn so the anchor sees metrics, never node content. By day 60 you can tell an anchor exactly where its network is stalling and fix the funnel.

Days 61–90: the network contract and the continuity clause. Write the three-cornered contract — the revenue structure (anchor-funded, floor-plus-per-node, or revenue share), the per-node SLA, the opt-in data-sharing terms, and the node continuity path if the anchor leaves. Test it against one real anchor deal and calibrate. The output is a repeatable network deal you can run with the second and third anchor, which is what keeps the book from concentrating.

For the network anchor

Days 1–30: the isolation and governance bar. Before distributing anything to your network, make the vendor prove per-node isolation — not describe it, prove it with the cross-node access test and a third-party penetration result. Define what you, the anchor, are entitled to see (adoption and outcome metrics) and what you are explicitly not (node content), and get it in the contract. The output is a deployment you can put in front of competing nodes without becoming the party that leaked one node to another.

Days 31–60: the activation plan, not the signature. The deal is not done when you sign; it is done when the network adopts. Build the per-node onboarding plan with the vendor, agree the activation telemetry you will both watch, and set the activation thresholds the pricing keys off. The output is a realistic curve of how fast your network turns on — which is the number that determines whether the deployment paid for itself.

Days 61–90: the node's protection and your exit. Your nodes are building operations on this platform through you; you owe them — and yourself — a continuity path. Get the node data-egress guarantee, the wind-down window and the direct-conversion option into the contract, and get your own network kill switch and exit terms. The output is a deployment whose risk to your network is bounded, which is what lets you distribute it with confidence.

What this means for document AI specifically

Document AI is unusually well-suited to the network unit, for three reasons that also set the bar the vendor has to clear.

The same document classes recur across a network. A network of brokers feeds the same submission types; a network of correspondent lenders originates the same loan files; a network of sellers raises the same invoices. The schemas are shared by construction, which is exactly the condition under which the network effect — every node starting at the quality the platform has already learned — actually pays off. A document AI platform that cannot share a schema and a calibrated decision layer across nodes while isolating their documents is leaving the network's main benefit on the table.

The corrections are the shared asset, and the documents are not. The thing a network can safely pool is the signal — the corrected field pattern, the confirmed fraud marker, the schema refinement — without ever pooling the source documents. A platform built to separate the learnable signal from the confidential document can lift the whole network's accuracy from the aggregate while keeping every node's files inside its own boundary. The platform that cannot make that separation has to choose between sharing nothing (no network effect) or sharing too much (no isolation), and both lose the deal.

The evidence is what bounds the anchor's leverage. The single thing a cheaper entrant cannot replicate quickly is the evidence envelope — the per-node isolation proof, the opt-in sharing audit trail, the per-node SLA history, the residency and revocation guarantees. A network deployment priced only on processing cost is a deployment the next entrant underprices. A deployment priced on processing plus a named governance envelope is one the anchor cannot cheaply replace, which is the only thing that makes a concentrated network book a business rather than a single renewal waiting to go wrong.

Closing thought

The move from selling a logo to deploying a network is not a bigger version of the same sale. It is a different product, a different architecture and a different risk. The vendor who treats it as "the same pipeline with more tenants" leaks the network through a forgotten query filter or starves it by building only for the anchor. The vendor who treats it as a two-customer product — provable per-node isolation, opt-in sharing of signal not documents, a per-node SLA, adoption telemetry the anchor reads, and a node continuity path that bounds everyone's risk — turns the network effect into the moat the single-tenant motion never had.

At Cogneris we build the document layer for exactly this shape: per-node isolation enforced below the query, an audit trail that records every opt-in and every cross-node exception, and a deployment model that serves the anchor who signs and the node who runs the work as two customers, not one. If you are an anchor sizing a deployment across your network, or a platform deciding whether your multi-tenancy survives a network of competitors on it, see our product page, the marketplaces solution, or talk to our team. The logo is what the old motion sold; the network is what the deployment turns on.