One engine, knowledge on top: how we package agents for the enterprise

Every enterprise AI platform now claims the same list: agents, workflows, a choice of models, connectors, a knowledge graph, guardrails, an audit trail, evaluations. We have that list too, and we are proud of how it is built. But we have stopped pretending the list is what a buyer is buying.

With coding agents, an engine and an audit layer can be rebuilt far faster than they could two years ago. What is hard to copy is knowledge: how a particular industry works, how an end-to-end process really runs, what the people who run it need, and how all of that fits the system of record the customer already owns. This post explains how we package that knowledge, and why.

Buyers pick what they recognise

The market has moved quickly. Menlo Ventures estimates enterprises spent about $37 billion on generative AI in 2025, roughly three times the year before. At the same time, MIT's NANDA initiative found that 95% of generative AI pilots showed no measurable impact on profit and loss. Money is flowing, and most of it is not yet coming back.

In that environment, enterprise buyers do what they have always done when a category is noisy. They choose a named offer they can recognise, price and compare; they look for proof from a peer; and they want a clear, small way to start. "A platform that can build almost any agent" is a capability. It is not an offer.

One engine, five dimensions

Our answer is to keep one engine, the same code for every customer, and to package knowledge on top of it along five dimensions.

Processes follow APQC's cross-industry process framework, so "order to cash" means the same thing to us as it does to a finance operations team. Industries follow standard industry groupings. Teams are the people who will actually use the agents: one order-to-cash process can need an operations crew to run it, an engineering crew to integrate it and a customer support crew to answer questions about it.

An offer is one intersection of those dimensions. Order to cash, for operations, on NetSuite, at the Ready edition is an offer. So is issue to resolution, for operations, on ServiceNow, in communications and technology. We build each intersection once, and offer it on every platform we fit.

The platform is the socket

The platform dimension does the most commercial work. An enterprise that runs SAP or ServiceNow has already spent heavily on it, and has a programme, a budget and a team around it. An offer that fills a gap in that platform, rather than asking to replace it, can be bought from that programme.

So we treat each platform as a socket. The knowledge on top, the process logic, the checks, the evaluation cases, stays the same; the build underneath is native to each system. Our Order-to-Cash Revenue Leakage Monitor is a good example. The NetSuite build reads sales orders, fulfilments, invoices and credit memos with SuiteQL and records recovery as NetSuite tasks. The SAP build reads SAP's own sales order, delivery and billing services and raises debit memo requests on billing block, for the billing team to release. Both run the same evaluation suite, case for case, and a platform build is listed only once that suite passes against a live system.

Swap the platform, and the knowledge on top stays the same. That is what makes it worth building once.

Three editions, one core

The edition is how deep we go inside an intersection. Each adds a layer around the same core, so a customer can start small and go deeper without starting again.

• Ready: the standard offer, installed as it is. Often the first step, and often for a smaller company.
• Configured: the customer's settings, rules, approvers and data mapping. In the product, the important ones are asked at install and never guessed: a materiality threshold, a company code, the team that releases a document.
• Tailored: logic built only for this customer, by our delivery engineers, on the same core. Often a large enterprise.

What it looks like in the product

This is not only a slide. The Camaan Marketplace now opens on a sentence: Find offers for any process that serve any team on any platform in any industry. Each blank is one of the dimensions. Every offer is described along the same lines, and platform builds of one product are grouped under it, so a buyer sees "Order-to-Cash Revenue Leakage Monitor, runs on NetSuite and SAP" rather than two unrelated listings.

Installing an offer adds a working set to the customer's organisation: agents with their tools and rules, a workflow that runs the process with the arithmetic in code, a report that can be run again next month, and an app pointed at all of it. The install asks for a connection to each system the offer uses. What is installed is a copy the customer owns and can change.

There are 23 offers today, across all four of the first dimensions. That is a start, not a catalogue.

How offers mature

We think about offers in three stages, and we try to be disciplined about moving between them.

1. Packs. Knowledge for a process, team or platform, bolted on to the engine, built only where a live opportunity needs it.
2. Products. When one combination wins more than once, it gets a name, a page and a price.
3. A category. When two or three customers can be named as proof, the offers together start to define something larger than "another agent platform".

The category we think this adds up to is AI-native process orchestration: what business process engines have done for twenty years, done natively, with agents handing work to each other through fixed workflow steps across many systems. That is a claim to earn with proof, not to print on a banner. In the near term Camaan works alongside the platforms customers own, not as a replacement: replacement deals are long and political, and nobody needs another one.

Where the knowledge comes from

Knowledge is the asset, so how it is gathered matters. Camaan is delivered with engineers from our services partner, Relevance Lab, who already work inside specific processes and technologies at many enterprises. We harvest from that work deliberately: structured interviews with subject experts about how a process really runs, where it breaks, what good looks like and which systems it touches; industry research to fill the gaps; and evaluation cases written in business terms. Customer specifics are removed before anything enters a reusable layer, and confidentiality terms are settled first.