In enterprise technology, we usually know how to talk about products and projects. A product is something you buy, configure and use. A project is something built from scratch for your specific context and needs.
For reasons having to do with AI-enabled innovation, we find ourselves working more and more with something in between. Something reusable enough not to start from scratch, and flexible enough not to force a generic fit. It helps us accelerate the delivery, yet allowing to be shaped around a customer’s processes, data, systems and decisions. The end result, from a client perspective, is a business outcome achieved faster, with less compromises.
That is what I mean when using the term asset in this context.
Assets bring reusable headstart, tailored to context
An asset is a proven, hardened starting point that covers the engineering nobody should have to reinvent. The repeatable parts of every AI-infused solution (model gateways, observability, approval gates, agent runtime, delivery patterns,…) arrive pre-built and battle-tested, so the engagement begins further ahead.
What gets built together is the part that must belong to the customer, and usually involves the workflow logic, business rules, integrations, data access, and human approval decisions that carry the actual competitive differentiation. The result is product-grade speed with the fit of a custom solution, shaped around how your organization actually works.I believe that the real value of an asset is not in the asset itself but in the distance it removes between the current state and the desired business outcome.
New question: how does it fit in the procurement buckets?
In the Enterprise AI and IT world, buyers often try to put assets into one of two familiar buckets: software license or services engagement. The problem is that AI-based assets fit neither of these buckets perfectly, and most buyers don’t yet have the vocabulary or evaluation criteria for the third category.
The reality is that we need a hybrid buying category for this. The one that would allow for some characteristics of a product (pre-built pieces of engineering, a runtime, potentially some recurring costs, maybe some form of maintenance…), and also accommodate for necessary custom work to make it fully fit to your organization.
Asset’s value is contextual
The same asset can create very different value in two organizations. In one context, it may save a few weeks. In another, it may reduce months of uncertainty, avoid wrong architectural decisions, or make a complex transformation possible at all. As an example, the value of Carbon.run to a bank with 40+ internal AI agents already in production completely differs from a smaller bank deploying its first AI agents. The asset is the same in both cases, the starting position of the buyer determines almost everything. Similarly, the value of Carbon.modernize is not the same when it is used to modernize a large COBOL-based legacy system for a social insurance agency, compared with migrating a handful of satellite core-banking applications written in ASP.NET.
Assets have two lifecycles
Assets age differently depending on who is looking at them.
From a customer’s perspective, an asset is almost like a tool. It exists to help achieve a specific business outcome faster, with less risk and less reinvention. Once that outcome is achieved, the asset may no longer be needed in its initial form. Unless the same type of outcome needs to be repeated in another part of the organization.
From the builder’s perspective, the lifecycle is different. An asset does not end when one customer outcome is delivered. It has to stay aligned with what is happening in the market. If we do not evolve it, it becomes stale. If we over-customize it, it stops being reusable. So the real discipline is keeping the asset alive enough to remain relevant, but flexible enough to remain an asset. I’ll let you know how that’s going in a couple of months 🙂
How to start? With the outcomes!
Theoretical considerations aside, the fact is that the concepts of AI-assisted engineering have made it possible for us to experiment faster and build great AI-based assets for various business and technology domains. I believe there is great value in using them, both for our customers and for us as vendors.
Btw., this does not make existing or future platform investments less important. Quite the opposite: good assets can and should complement the platforms customers already trust, whether that means Red Hat, IBM, AWS, Azure or similar ecosystems, and help translate those investments into business outcomes faster.
When the repeatable engineering is already handled, the conversation with a customer changes. Instead of spending the first weeks debating architecture, runtime choices, and governance plumbing, we can get to the question that actually matters faster – how much sooner will you see the business outcome? The shift from talking about how to build, to talking about what gets achieved and when, is where assets earn their place.
