The model is the commodity. The skills around it are not.
What a skill is
Two layers, and a solution needs both.
One carries the engineering every production system requires. The other carries the judgement one particular problem requires. What each actually contains is below.
The engineering every solution needs.
None of it is intellectually novel, which is precisely why teams under-budget the calendar it consumes. It is reused identically across deployments, because the patterns are the same everywhere.
- Authentication
- Role-based access control
- Audit logging
- Pipeline monitoring
- Security scanning
- Document parsing
- Data connectors
In a demo: Five documents held in memory.
In production: Fifty thousand, with spiky traffic. Async queues, worker pools, caching, batched model calls. Chunking quality decides whether retrieval works at all.
In a demo: Clean inputs, responses that hold.
In production: Schema drift, partial failures, rate limits, provider regressions. Each needs a handler, a fallback, a circuit breaker and structured-output enforcement.
In a demo: Two cents a prompt on a laptop.
In production: Twenty thousand dollars a month at real traffic. No attribution means no cause for a spike; no budgets means a retry storm spends the month in a day.
A client came to us after a retrieval system built on a cloud vendor's reference stack worked on the demo dataset and cliffed in production, with no observability on retrieval relevance to show why.
The judgement one problem needs.
The design decisions, reference architectures and calibration built up across many deployments of one use case. Invoice reconciliation, to make it concrete.
Learned the hard way: After the first wrong payment.
What the skill already knows: ACME Corp, Acme Corporation and ACME are one vendor. Accounts payable needs strict matching, because a wrong match sends money to the wrong account. Procurement tolerates a looser rule.
Learned the hard way: By watching numbers go wrong under real load.
What the skill already knows: Which models hold up at production transaction volume and which start returning wrong numbers. Not from a benchmark paper: from running this kind of workload repeatedly and recording how each model behaved.
Learned the hard way: By failing an audit, which is not a method any finance team funds twice.
What the skill already knows: Whether a record that will not reconcile is resolved automatically or flagged for review. Only some patterns survive an auditor's questioning, and the skill knows which.
How a skill is used
Loaded before the architecture is drafted.
A skill is not a document someone consults. It enters the build as an input, at a fixed point, before any design decision is made.
- 01
Read the customer's own material
In a recorded build the agent works through fourteen concept files from the customer's bundle before proposing anything.
- 02
Load the skills that gate the plan
It then loads two: the platform capability catalogue, and the vertical playbook for the problem at hand, in that build invoice reconciliation.
- 03
Draft against them, not from scratch
Only then is an architecture written. What it can propose is bounded by what the platform already knows how to run and by what the domain has already taught us.
Verified against the shipped recording of that build. The same session is shown running on the Implement page.
What it changes
Four layers arrive already built.
Work often reaches us as a working prototype, and a prototype is the easy thirty percent. What is left is integrations beyond flat files, a pipeline that holds at real traffic, the error tail, auth and audit, and cost governance. None of it exists yet, and all of it has to before launch.
That is the productionisation tax. Every project owes it. The only question is whether you pay it once, or on every one.
Auth, deployment, audit, access control and monitoring, inherited unchanged from the horizontal layer.
Otherwise written again, on every project.
Already wired, running under the access posture your estate already enforces.
Otherwise built and credentialed per project.
Matching thresholds, exception handling and calibration carried from prior deployments of the same use case, with the failure modes already known.
Otherwise learned again, usually the hard way.
Held in your Context Engine and already mapped, so this solution meets the same trusted schema as the last one.
Otherwise re-elicited in workshops at the start of every project.
Everything above arrives because it has been built before. This has not. Your processes, your exceptions, and the judgements that make this business different from the last one: that is where the engineering goes, and the only place it should. About seventeen modules on a recent build.
Skills and context
One is shared. The other never moves.
The two get collapsed into one idea, and the line between them is the one worth being precise about: it decides what improves for everyone and what stays inside your account.
Engineering practice, and only that. The reference architectures, the patterns that hold at production volume, the failure modes worth designing around. It is the craft that improves, in the way any engineering discipline improves with practice.
Your data, your definitions, your business rules and your configuration are not part of it and never enter it. Nothing that identifies your business, or could be recognised as yours, is carried into anyone else’s solution.
Your terminology, your approval hierarchies, your tolerance for particular exceptions, and the way your data is actually structured rather than the way it is documented.
This sits in a Context Engine inside your own account, scoped to your enterprise. It is never shared across customers, and that is a property of how the system is built rather than a setting somebody has to remember to switch on.
Popular Reads
View all resources
Enterprise AI Skills: Where the Moat Lives
The long form of this page: why the model is rarely the constraint, and what the horizontal and vertical layers around it actually contain.
Context is Your New IP
Why enterprise AI agents fall short in real-world decisions, and how closing the context gap is what makes them reliable in production.
Full AI Autonomy Is a Myth. Managed Autonomy Is a Moat.
How companies get more out of AI by combining agentic systems with human judgment instead of chasing full autonomy.
Got questions? We're here to answer them for you
Have more questions?
Contact our support team to get what you need.
