My Thoughts

The question I keep coming back to is what a single interaction costs once the product is real, because the demo is the cheapest it will ever be: a lone user, a short context, no retries, no safety checks, no evaluation traffic. Production adds all of that, and the awkward costs are the ones that scale with success.

The other trap is assuming falling prices will rescue the design. Unit prices do fall, but ambition rises faster: cheaper inference invites longer contexts, more autonomous behaviour, more calls per task, and the bill climbs while the rate card drops.

What I want at design time is not a precise figure, which would be false comfort anyway, but an honest shape: which costs are fixed, which scale with users, which scale with the quality bar itself. If an interaction costs more than the work inside it is worth, that is a design decision still waiting to be made: a narrower promise, a shorter context, a cheaper model on the routine path, a person doing the step that was never worth automating.

Every dependency is a bet on someone else's roadmap, and in this field the roadmaps move quarterly. What I find myself weighing is not whether to depend on a model provider, a vector store, a hosting layer, since dependence is the whole point of buying rather than building, but which dependencies stay cheap to leave and which are quietly becoming marriages.

I have come to think the true portability layer is the evaluation suite. If quality is measured independently of any provider, a replacement candidate can be judged in days; if quality is a feeling, switching becomes an argument nobody wins, and incumbents win arguments by default.

The point is not to abstract everything, because a wrapper around every vendor is its own tax and most wrappers never pay for themselves. It is to decide, dependency by dependency, which seams are worth their cost: the commodity layers, where offerings are converging anyway, get seams; the genuinely differentiated dependencies are accepted with eyes open and an exit that has been rehearsed rather than merely documented.

Replaceability is also a commercial posture, not just an engineering habit: a vendor prices a renewal on how expensive they believe leaving would be, and they are rarely wrong about that.

Interfaces have never died faster, and knowledge has never been poured into them faster, which is a bad combination. The pattern I keep turning over is how much organisational memory now lives inside whichever tool is currently fashionable: the assistant's built-in memory, a vendor's proprietary store, the sediment of endless chat transcripts. When the tool goes, and every tool goes, that memory goes with it, and the organisation quietly re-learns what it already paid to learn.

So the principle I hold on to is a hard separation: knowledge kept in durable, portable, frankly boring formats, dated, attributed, with a named owner; and above it an access layer that is allowed, even expected, to be disposable. The test is blunt: if the interface were deleted tonight, what survives? If the answer is a corpus the next interface can ingest straight away, the architecture is sound; if the answer is whatever the vendor's export produces, it is not.

What makes this urgent is that a well-kept body of plain, dated, attributed prose is now directly usable capability for machine systems rather than shelf documentation. Careful writing has become infrastructure, and it deserves the same seriousness as anything else the organisation runs on.

There is a gravitational pull in any large organisation toward shipping each new capability as a new application: an application demos well, launches well, and makes a legible achievement with an icon. I distrust that pull. The scarcest resource in a big firm is not compute or budget but behaviour change, and every new destination spends it: another login, another tab, another habit that has to form, and most habits never form. Adoption goes to die at the login screen.

The alternative I keep testing proposals against is capability delivered as skills: small units of ability that appear inside the tools people already have open, the document editor, the spreadsheet, the chat client, the queue where the work already arrives. A skill asks the user to change almost nothing, which is precisely why it works; it borrows an existing habit rather than trying to purchase a new one.

The trade-offs deserve honesty, though. Skills inherit the host tool's constraints. They are harder to discover, harder to attribute, and politically weaker: an invisible improvement inside an existing tool never draws the applause an application launch draws, which is exactly how the wrong architecture keeps winning meetings. And sometimes a destination is right, when the work itself is genuinely new and no natural host exists, or when a workflow needs its own state and its own front door.

But the question I would put to every proposal is whether the capability deserves its own place or belongs inside a place that already exists, and the unglamorous work that makes the latter possible, identity, permissions, audit and data access handled centrally so a capability can land anywhere, matters more than any front end.

Demand is never the problem: every team arrives with a use case, and most arrive with urgency attached. The judgement that actually shapes a portfolio is what gets turned down, and the habit I trust here is treating refusal as a set of recognisable categories rather than a mood.

What earns a place is duller and rarer: work that is frequent, expensive in human attention, tolerant of an imperfect draft, and verifiable for less than the cost of doing it by hand. Even then a portfolio has a carrying capacity that has nothing to do with build effort, because everything that ships takes on permanent obligations: evaluation upkeep, model migrations, support, risk review. In financial services the product that misbehaves also taxes the credibility of every product that follows it, so a yes is a claim against a maintenance budget that never closes.

The part I try to hold myself to is keeping the no legible: a written reason, and the conditions under which it would become a yes. An unexplained refusal reads as politics, and work refused politically does not disappear; it goes round the side, unsupported and unwatched.