Put the model where the work is

Tags: embedding, integration, adoption

A capability built as its own destination has to be remembered, navigated to, and briefed on every single visit. That cost is paid per use rather than once — which is why AI features with genuinely good output still see usage decay after launch.

The destination tax

Consider what using a standalone assistant actually involves. The person is mid-task somewhere else. They notice they could use help. They switch to the other app, re-establish what they were doing — paste the document, describe the situation, explain the context the original tool already had — get an answer, and carry it back.

Every step there is overhead the capability did not remove. And it recurs: the tenth visit costs roughly what the first did, because the context lives in the tool they came from, not the one they went to.

So people make a quiet calculation each time, and increasingly the answer is that fetching the help costs more than doing without it. The usage curve of a good destination is the curve of that calculation, not of the output's quality.

Deliver into the surface that already has the context

The alternative is to put the capability where the work is happening, and let it inherit the context that surface already holds.

This changes the design problem significantly, and it is worth being honest that it gets harder:

• You are fitting inside someone else's interface. Their layout, their conventions, their constraints. A destination is yours to design; an embedded capability is a guest.
• The context comes free, and so do its limits. The host surface knows what the user is doing — and knows only that. The capability has to be useful with the context it is handed.
• The entry point is small. A button, an inline suggestion, a panel. There is no home screen to explain yourself on.

That difficulty is the reason it works. A capability that fits inside the task costs almost nothing to reach, so it gets reached.

When a destination still earns its place

Standalone views are genuinely good for deliberate, deep sessions — exploring a corpus, drafting something long, working through a problem from scratch. The failure is not having one; it is having only one, and expecting people to go there for every small moment the capability could have helped with.

Grounded in

Nakatomi's embedded-finance model is the same idea delivered twice, in two very different places.

On the consumer side, a loan lives inside a partner's car checkout. Application, decision, contract, down payment and account validation all happen without leaving the purchase, instead of redirecting the buyer to the bank at the moment they were about to commit.

On the business side, working-capital financing ships as an installed ERP module, so real-time balances and receivables and payables financing appear in the tool a controller already has open. A controller does not go to their bank to discover a cash shortfall; the shortfall and the facility to cover it show up where they are already doing the reconciliation.

In both cases the bank stopped being a place people had to go. That is the whole move.

Anti-patterns

• A separate AI app for help with work that happens elsewhere. Every use starts with a context transfer.
• An embedded entry point that opens a destination. A button in the host that redirects out has the discoverability of embedding and all the costs of a destination.
• Embedding without the host's context. A panel that sits inside the tool but still asks the user to paste what the tool already knows.
• Only the destination. Fine for deep sessions, abandoned for every small moment.
• Carrying answers back by hand. If the output has to be copied into the place it is needed, the capability is still, functionally, somewhere else.

The smallest version worth building

Find the single most common moment a user leaves their main tool to use the capability. Put one entry point there, pass it the context that screen already holds, and write the result back into that screen.

Then measure how often it gets used compared with the destination. The gap is usually large, and it is the clearest argument available for doing the next one.

Related patterns

• Pair every insight with its action — the same instinct applied to output: carry the remedy to where the user is, rather than pointing at it.
• Work without being asked — an embedded capability can notice things in context that a destination never sees.
• Wizard or conversation — an embedded capability is rarely a chat; it is usually a step inside a flow that already exists.