Delivery Split

Who Implements the AI Solution —
Iternal, the Partner or the Integrator?

The three splits that work, the handoff point each one needs in writing, what Iternal brings to the work and where it stops, and which model applies by deal size and product.

Built from real buyer questions in our sales meetings

Two firms shake hands on an AI deal and each walks away assuming the other one is doing the install. Nothing in a partner relationship fails as quietly, or as expensively. Of everything partners ask us before they commit, the division of implementation labor comes up more than any other single question: who deploys, who supplies the server, and whether the customer IT provider ends up doing the install regardless. The split is not a preference you discover later. It is a decision you make once, in writing, before the first customer meeting.

Direct Answer

All three can deliver; the failure is leaving it unnamed. Three splits hold up: Iternal-delivered while the partner keeps the customer relationship; partner-delivered with an escalation route back to Iternal; and co-delivered, with a written boundary at a named handoff point — image acceptance, corpus validation or go-live. Publish which model applies by deal size and by product, and say plainly whether Iternal will ever sell an account directly.

The limit is what Iternal brings to the split, and it belongs in the agreement before the boundary is drawn. Iternal does a lot of education but not a lot of hands-on education — that part usually sits with the technical implementation team — and there is no training module for enterprise implementations, because they are highly variable. Its discovery tooling is product-agnostic and recommends the best approach even where none of Iternal’s own technology is involved, so on some of the deployment plans it produces, Iternal may have little to nothing to contribute. Regional coverage is uneven as well — Iternal has no established presence in Asia-Pacific yet.

Verify the escalation route before you price the work. Ask which items in a specific plan Iternal itself delivers, which party staffs each support tier, and who your engineer reaches locally when an install stalls at midnight. Where Iternal cannot escalate in your region, partner-delivered stops being a choice — it is the only model available, and the commercials should say so. The questions below are the ones to get answered in writing.

Delivery and the relationship are two different questions. Whoever holds the screwdriver, someone owns the account, and the two rarely have to be the same firm. For more information on program tiers and registration mechanics visit the channel program page; for what the work should cost, visit the packaging and margin page.

The Three Delivery Models, and the Handoff Point Each One Needs

A delivery model is not a philosophy. It is three facts written down together: who does the work, where the work formally changes hands, and who gets the call when something breaks after that moment. Miss the middle fact and the other two argue forever.

Model Who does the work The named handoff point Escalation route
Iternal-delivered An Iternal onboarding engineer walks the customer through install and use under the enterprise white-glove setup; the partner keeps the relationship and the paper. Go-live on the first production group. Tier one to tier three phone and chat support under the enterprise license.
Partner-delivered Partner engineers do the install. AirgapAI ships as a standard executable — a Windows build that drops onto a golden master image, and a macOS build alongside it — so installation services can be charged around it. Image acceptance — the moment the master image passes the customer security scan. Partner escalates to Iternal; post-sale support for air-gapped deployments runs through channel partners in each region.
Co-delivered Split by layer: the integrator or the customer stands up the model, update and Blockify servers as a services upsell; Iternal contributes the data-set work. Corpus validation — production handoff happens only after the customer team confirms the larger corpus performs as expected. Named on both sides of the line, per layer, before the project starts.

Asked who configures the servers at fleet scale, our answer is unromantic: the integrator as a services upsell, the customer alone, or both. All three work. None works by accident.

What Iternal Delivers, and Where It Stops

Iternal states its position without hedging: it delivers the implementation work described in the blueprint output. The commitment is real, and narrower than it sounds — for a reason worth knowing before you build a services plan on it.

The tooling is deliberately product-agnostic. Iternal built the blueprint builder to recommend the best approach even when none of its own technology is involved. The output is scoped well enough that an integrator can quote and deliver custom services from a single deliverable, and a customer is free to take the same document to any subcontractor. The consequence follows: some deployment plans that discovery recommends sit outside what Iternal builds, and on those Iternal may have little to nothing to contribute. Scope the commitment against a specific plan, never against the tool that produced it.

Enablement has the same shape. Iternal does a lot of education and not a lot of hands-on education; the hands-on half usually sits with the technical implementation team doing the install. There is no training module for enterprise implementations, because they vary too much to compress into one, and no implementation course inside the AI Academy. Treat that as a planning input: your first delivery capability gets built on a real install, not in a classroom beforehand.

Pin it down: questions for your evaluation
  • Which line items in this deployment plan does Iternal deliver, and which are ours to build?
    The delivery commitment against a specific plan, rather than against the tool that produced it.
  • Which party staffs each support tier in the bundle we are quoting, and who escalates in our region?
    Who your engineer actually reaches, and whether the answer changes by geography.
  • What hands-on enablement do our engineers receive before the first install?
    Whether your team is trained to deliver or expected to learn on a live customer.
  • At what moment does delivery formally hand over: image acceptance, corpus validation or go-live?
    The single date both firms point at when a customer asks who owns the next fix.

Will Iternal Take the Account Direct?

Partners who sell services hear any mention of the word direct as a threat, and they say so plainly: the fear is that the software company favors a competing firm or lifts the opportunity away. The reverse risk comes up just as often — an end customer refusing to work with a proposed integrator. Reassurance is worth nothing here. Specifics are worth a lot.

The position, stated first-party. Iternal very rarely sells an account directly, and only where it held the customer relationship from the beginning. It does not dictate which firms represent the product; technical skill is the filter, not favoritism. Opportunity claims follow a standard first-registration-plus-qualification approach.

The part that is not reassurance. Iternal’s case for staying out of your accounts rests on commercial self-interest and reputational cost, not on a clause you can wave in a meeting — and the enterprise version with full white-glove support can be bought straight from the Iternal website without a sales conversation, so a customer always has a path that does not run through you. Both facts point the same way: get named-account protection written down, and treat the incentive alignment as a reason to expect good behavior rather than a substitute for paperwork. On the reverse risk, one habit removes most of the damage — ask the referring advisor which integrators the customer will accept before any introduction is made, so a refusal surfaces as information rather than as a lost deal.

Which Model Applies by Default: Deal Shape and Product

Publishing a default per deal shape kills most of the argument before it starts. These defaults follow the product, not the customer logo, because delivery labor is set almost entirely by what has to be stood up:

Shape of the work Default model Handoff point
One device or a small team, base license Customer self-installs. AirgapAI is a one-click executable on Windows or macOS, so a buyer can decide, install and be working the same day. None. The base license carries no white-glove setup.
Fleet rollout across a managed image Partner-delivered. The executable goes onto the golden master and is managed through existing device tooling, so imaging services can be charged around it. Image acceptance.
Enterprise license with white-glove Iternal-delivered. An onboarding engineer dedicates hours to getting the customer deployed, with tier one to tier three phone and chat support behind it. Go-live.
Server-backed models or Blockify on-premise Co-delivered. A larger model gets deployed by your side, which is more technical than the client install; Blockify containers ship with Helm charts for an implementation partner to stand up. Corpus validation.
Multi-use-case program scoped from discovery Partner or integrator delivered under a custom statement of work, which is how broader AI data-center builds are handled. Quote acceptance against the deliverable.

One arrangement inverts the usual assumption: a customer can order through an existing partner and have Iternal fulfill the services underneath as the subcontractor — the partner keeps the contract and the renewal, Iternal supplies the hands. For more information on the deliverable that scopes the larger programs, visit the blueprint builder page.

Answered elsewhere
FAQ

FAQ: Splitting the Implementation Work

Three splits hold up: Iternal-delivered while you keep the customer relationship, partner-delivered with an escalation route back to Iternal, or co-delivered with the boundary written at a named handoff point — image acceptance, corpus validation or go-live. Set which one applies by deal shape and product rather than negotiating it per account.

Yes — Iternal states it can help with the server, the language models and the interface, with deployment guidance covering server setup versus a completely local install. Scope one thing carefully: pointing AirgapAI at a larger model requires that model to be deployed by your side, which is materially more technical than the client install. Name the owner of that server before the statement of work is signed.

Iternal very rarely sells an account directly, and only where it held the customer relationship from the beginning; it does not dictate which firms represent the product, and technical skill is the filter. The caveat: the enterprise version with full white-glove support can be bought straight from the Iternal website without a sales conversation, so a customer always has a path that does not run through you. Get named-account protection in writing rather than relying on intent.

The partner, in almost every arrangement. The go-to-market leans on reseller relationships that already exist rather than on net new prospecting, and at the top of the market volume flows through integrators that own the end customer outright. Even when Iternal does the hands-on work, a customer can order through its existing partner and have Iternal fulfill the services underneath, so contract and renewal stay with the partner.

Partly, and the limit is worth planning around. Iternal does a lot of education but not a lot of hands-on education; the hands-on half usually sits with the technical implementation team. There is no training module for enterprise implementations because they are highly variable, and no implementation course inside the AI Academy. Expect your first delivery capability to be built on a real install, and price that curve into the first engagement.

Write the Split Down First

Every argument above is settled by one page of text agreed before a customer is in the room: the model, the handoff point, the escalation contact, and what happens to the account if the software is ever sold directly. Write it once and you stop renegotiating it per deal. Leave it to good intentions and you find the gap on the day an install fails.

John Byron Hanby IV
About the Author

John Byron Hanby IV

CEO & Founder, Iternal Technologies

John Byron Hanby IV is the founder and CEO of Iternal Technologies, a leading AI platform and consulting firm. He is the author of The AI Strategy Blueprint and The AI Partner Blueprint, the definitive playbooks for enterprise AI transformation and channel go-to-market. He advises Fortune 500 executives, federal agencies, and the world's largest systems integrators on AI strategy, governance, and deployment.