Insurance at the speed of business
Why we built Agilis Ubiquity — and why insurance technology should reduce the distance between a business decision and its outcome.
Why we built Agilis Ubiquity
Two years ago, I was having lunch with a CEO who had recently taken office at an insurance company that had been using Agilis, our general insurance core platform, for many years.
I could sense his frustration. He asked me a fairly simple question: why does underwriting take so long?
Why, with everything technology can do today, were underwriters still spending so much time navigating screens and processes? Why was claims adjudication still so arduous?
That was the challenge that stayed with my core team and me: could we make these journeys dramatically faster, repeatable and accurate, without losing the judgement, governance and controls that insurance requires?
It was a good question. It was also slightly uncomfortable, because he was asking it about an industry we had been part of for more than two decades, and about a core platform we ourselves had built. It forced us to look at ourselves in the mirror.
When we looked at the market, the current offering by other vendors, including our own earlier generation of products, we felt that very little had fundamentally changed in the way insurance systems expected people to work.
The technology had changed. The interfaces had improved. We had cloud, APIs, portals, workflow, document management and analytics. And now AI was beginning to push the boundaries of what was possible.
But underneath it all, insurance technology vendors like us were still largely replicating the behaviour of systems designed 20 years ago. Perhaps that was the safest alternative rather than bringing in radical thinking.
Users navigated modules and complex screens, selected codes, entered information field by field, and moved a quotation, policy, endorsement or claim through the system step by step.
Despite all of those rules and processes, many important decisions still depended on people finding the right information, remembering what applied and interpreting it consistently. That inevitably creates the possibility of inconsistency, errors and omissions.
We could have rewritten Agilis General and Agilis Life on a newer technology stack. But increasingly, that felt like the wrong answer to the question we had been asked. We needed to question the operating model itself.
What if we took away the work that shouldn’t need doing?
If a broker emails us a submission with an Excel sheet of 200 employees, why should somebody have to rebuild that submission inside an insurance system?
If a customer wants to insure 2,000 vehicles and has already provided all the information, why should an underwriter have to work through them screen by screen? Or a tender, or a request for quotation, lands in via email — why does someone have to rekey that information?
If a claim comes in with photographs, invoices, reports and correspondence, why can’t the system read them, understand the policy and endorsements, establish what is relevant, and put the claims officer in a position to decide?
And if the system already knows the product rules, rates, underwriting and claims authorities, reinsurance arrangements and regulatory requirements, why are we asking people to remember all of it and find their way through it?
That thinking led us to Agilis Ubiquity.
The principle behind Ubiquity is simple: tell the system what you are trying to accomplish, and let it take away as much of the complexity as it reasonably can.
That does not mean letting AI make uncontrolled underwriting or claims decisions. Insurance does not work that way, and nor should it. AI is very good at some things: reading and interpreting information, understanding intent, bringing context together, identifying what matters and helping orchestrate a process.
Other things need to remain deterministic and governed: rating, authority limits, product rules, financial calculations, reinsurance, regulatory requirements and statutory controls.
We have tried to bring those two worlds together. The objective is not just automation, but to make insurance decision-making faster, repeatable, accurate, explainable and governed.
But as we questioned the way insurance transactions were being processed, we found ourselves questioning something even more fundamental.
Why does implementing an insurance system take so long?
Traditionally, when an insurer implements a new core, an enormous amount of work begins before anybody can write a policy. What country are you operating in? What currency? Which taxes and levies apply? What does the regulator require? What classes of business will you write? How will accounting work? What about reinsurance? Which documents are required? What channels will you use?
Then begins the configuration. At some point we realised something that, in retrospect, seemed rather obvious: a great deal of this information is not unique to the insurer.
If we already know that an insurer is operating in Canada, Mexico, Poland, the UAE, South Africa, Malaysia or another jurisdiction, why shouldn’t Ubiquity already understand much of the environment in which that insurer has to operate? And if the insurer tells us it wants to write General Insurance, Life, Health, Pensions & Annuities or Takaful, why should we start with an empty slate?
So we asked ourselves another fairly simple question: why can’t you select the jurisdiction, select the insurance business you want to operate, and have Ubiquity assemble the starting tenant for you?
That is what we have now built into Ubiquity.
Select the country or jurisdiction. Select General Insurance, Life, Health, Pensions & Annuities, Takaful, or the combination you require. Select the lines of business and attach your rules. Select how you want to distribute: direct, broker, agent, bancassurance, digital or other channels.
Ubiquity assembles the starting insurance operating environment. It isn’t an empty tenant waiting for everything to be configured from scratch.
The jurisdiction brings with it the regulatory and statutory context that Ubiquity constantly researches, learns and applies: currencies, taxes, levies, reporting requirements, compliance controls and other local requirements. The lines of business bring the appropriate insurance structures, product foundations, underwriting and claims journeys, accounting and reinsurance behaviour. The market research capability brings in deep understanding of how products need to be configured for each jurisdiction, and how their tariffs, rules and processes can comply with regulatory guidelines. The channels bring the appropriate journeys for customers, brokers, agents, banks and other participants.
Then our discovery can concentrate on what actually makes that insurer different: its products, rates, appetite, authorities, treaties, chart of accounts, workflows, branding and integrations.
That changes the starting point of an implementation quite considerably. Instead of beginning discovery with “tell us everything we need to know to implement our core insurance system for you”, we can increasingly begin with: “We know where you operate. We know the insurance businesses you want to run. Here is your starting environment. Now tell us what is different about you.”
For a greenfield insurer, the implications are obvious. But the same idea applies to an established insurer entering another country, adding a new line of business, launching a Takaful operation, opening a new distribution channel or establishing a new digital proposition.
This took the original challenge somewhere we had not initially expected. We had started by asking how we could reduce the time it takes to do insurance. We now found ourselves asking how much we could reduce the time it takes to become ready to do insurance in the first place.
And then there is the journey itself
Once that environment exists, we come back to the original challenge. How quickly can the insurer actually do business?
In implementations we are currently working on, we have already demonstrated complex underwriting and claims journeys that would traditionally take considerably longer being completed in minutes.
That matters to me not because “minutes” is a clever demo statistic, but because of what it means operationally. The underwriter can spend more time underwriting and less time operating the system. The claims officer can concentrate on the claim rather than finding and reconstructing the information needed to deal with it. And the insurer can respond to a customer or intermediary while the opportunity or issue is still in front of them.
That is what we mean by insurance at the speed of business.
Why should management have to keep asking the system what is going on?
As Ubiquity evolved, we started thinking about the people running the insurer. A CEO, COO, CFO, Chief Underwriting Officer, Claims Head or operations manager has a very different problem from somebody processing an individual transaction. They don’t need another screen. They need to know what requires their attention.
What has changed since yesterday? What is stuck? Which underwriting referrals are waiting? Which claims need intervention? Where are we outside appetite? What is outside the norm? Where is an SLA at risk? What needs approval? And perhaps the most important question of all: what am I not looking at that I should be?
Most enterprise systems answer questions when somebody asks them. Dashboards are useful, but somebody still has to open the dashboard, know what to look for, interpret what they see and then decide what to do about it. We began to wonder why that relationship could not be reversed. If Ubiquity understands what is happening across the insurer, why can’t it understand what matters to the people running it and watch the business on their behalf?
I have been writing a book, a business parable titled Not on My Watch, scheduled for publication in January 2027. Companies rarely fail because they lack information. They fail because people stop seeing what has gradually become normal. They fail because what they tolerate, they cultivate. The book presences that. So does Sentinel.
That thinking, and what Ubiquity had to offer, led to the creation of Agilis Sentinel: the AI Chief of Staff for the leadership of the insurer.
And I use “Chief of Staff” quite deliberately. Sentinel is not intended simply to be another chatbot sitting beside the core. Nor is its job merely to produce a better management dashboard. A member of the leadership team should be able to tell Sentinel, in ordinary language, what concerns them.
“I am concerned that large motor claims are taking too long to settle.” “Watch underwriting outside our normal appetite.” “I want to know whenever we are losing good business because of turnaround time.” “Keep an eye on overdue broker balances.” “Why are property claims in this branch deteriorating?”
Sentinel should understand that concern, determine what information across Ubiquity is relevant, watch it continuously and bring something back when there is a reason for that executive to pay attention.
That is only part of what Sentinel does. There is a difference between knowing that something needs attention and getting something done about it. If a member of the leadership team gives Sentinel a mandate — investigate this, get this resolved, find out why this keeps happening, make sure these outstanding items are cleared — Sentinel should not simply create another task on somebody’s dashboard.
It should be able to follow up with the relevant people, ask for what is required, track responses and progress, remind and escalate where appropriate, and continue until the mandate reaches its conclusion, while preserving the evidence and keeping the executive informed.
In other words: understand the concern. Watch the business. Recognise when something matters. Bring it to the right person’s attention. Take a mandate. Follow it through. All within the authorities and controls the enterprise gives it.
An AI Chief of Staff should not have unlimited authority simply because it can see across the organisation. What it can see, what it can do, whom it can contact, what it can approve and when it must come back to a human all need to be governed.
For me, this is one of the more interesting ideas to have emerged from Ubiquity. For years, enterprise software has required management to go looking for information. Sentinel turns that relationship around. The system increasingly understands what leadership cares about, watches for it, brings forward what matters and, when asked, helps see the resulting action through to conclusion.
Why should the insurer wait for business to arrive?
This was perhaps the question that took our thinking furthest beyond the traditional role of a core insurance system. By this stage, Ubiquity knows quite a lot about the insurer. It knows the markets our customers operate in. It knows the jurisdiction and regulatory environment. It knows the products they carry, what they can insure and, increasingly, their appetite for different kinds of risk.
So why should all that intelligence only be used after business arrives at the insurer?
Suppose an insurer writes property, engineering and liability business and a new hotel or factory is announced in its market. A company may announce a construction project, win a major contract, open a new facility, acquire a fleet or expand into another location. These are not simply pieces of news. They may be signals that new insurable exposure is being created.
If Ubiquity already understands what the insurer writes and where it operates, why can’t it continuously look for those signals, work out which ones may be relevant and put an opportunity in front of the right person while it is still an opportunity? Why can’t it begin to establish what may need insuring, what the potential insurance opportunity could be worth, and who the insurer should be speaking to?
That is what we are doing with Opportunity Signals. The objective is not another generic list of sales leads — plenty of systems already do that. What interests us is the insurance context. Ubiquity can consider a market event against the insurer’s jurisdiction, products, appetite and distribution capabilities. It can explain why that event may create an insurance need, what may need insuring and which of the insurer’s products could be relevant, while retaining the source and evidence behind the signal.
The insurer decides whether the opportunity is worth pursuing. And if it is, why should it leave the platform and start another disconnected process? It should be able to move from signal to opportunity, engagement, submission, underwriting, quotation and ultimately business written.
For me, this starts to change the economics of what an insurance platform can be. Traditionally, the core insurance system has been a cost of doing business. It waits for a transaction to arrive and then processes it. But if the same platform can help an insurer identify business it might otherwise never have seen, and help convert some of those opportunities into written premium, why shouldn’t the technology begin to pay for itself? That is an idea we are particularly interested in pursuing.
Insurance at the speed of business does not only mean underwriting a risk faster once it arrives. It also means recognising that the business exists while there is still an opportunity to insure it.
Not every insurer has to start afresh
Insurers are at very different points in their technology journeys. A greenfield insurer can begin on Ubiquity from day one. An established insurer may have a perfectly functional core it has no reason to replace today, but still want new digital channels, intelligent intake, faster underwriting, claims automation, Sentinel, Opportunity Signals or other Ubiquity capabilities. Another may ultimately want to replace its legacy environment but, sensibly, have no appetite for the risk of a big-bang migration.
So we see three broad ways of adopting Ubiquity:
Greenfield — establish a new insurer, product line, business unit or digital proposition on Ubiquity.
Orchestrate — introduce Ubiquity above and alongside an existing core, while keeping established systems of record.
Transform progressively — move products, portfolios and capabilities over time through a governed migration.
A word to our Agilis General and Agilis Life customers
Some of you have been with us for many years, some for decades, and you run substantial businesses successfully on Agilis General and Agilis Life. Ubiquity does not mean we expect you to suddenly replace them.
We will continue to support Agilis General and Agilis Life. There is no forced migration. You can keep operating your existing Agilis environment. You can introduce Ubiquity alongside it where it makes sense — perhaps first for a new product, a new channel, a new country, a particular journey, or capabilities such as Opportunity Signals and Sentinel. And if and when you want to move further towards Ubiquity, we will work with you on a progressive, governed transition.
Technology vendors sometimes decide that a customer has to modernise because the vendor has modernised. We don’t believe that is the right approach. Ubiquity gives our existing customers a road forward, but you decide when and how you travel it.
Where this goes next
There is still a great deal we want to do with Ubiquity, but the principle that started the journey remains the same. We did not want to take a 20-year-old way of operating insurance and simply rebuild it with 2026 technology. We wanted to see how much of the friction we have all come to accept as part of insurance could simply be taken away.
Initially, that meant the transaction itself. Could an underwriter spend more time underwriting and less time operating the system? Could a claims officer be presented with the policy, evidence and context required to make a decision rather than spending their time assembling it?
Then the same question moved upstream. If we already know the jurisdiction, the insurance business and the distribution model, why should every implementation begin with an empty tenant? Then we started thinking about management. If Ubiquity understands what is happening across the insurer, why should leadership continually interrogate systems and dashboards to discover what requires attention? That led to Sentinel: tell the platform what you care about, let it watch the business with you, and give it a mandate when something needs to be followed through.
And then the question moved outside the insurer. If Ubiquity understands the insurer, its products, its appetite and the market in which it operates, why should all of that intelligence only be used on business that has already arrived? That led to Opportunity Signals and the possibility that the core might not only process premium, but help the insurer find some of the opportunities that create it.
On the surface, these may look like very different capabilities. To me, they are all answers to the same challenge that began over that lunch two years ago: how much of the time, effort and friction we have come to accept in insurance is actually necessary?
The answer, we are discovering, is considerably less than we thought. And that has led us to a fairly simple ambition for Ubiquity: reduce the distance between an insurer deciding on the outcome it wants and actually accomplishing it.
Launching a business. Entering a new market. Underwriting a risk. Settling a claim. Acting on an exception. Following a management mandate through to conclusion. Finding the next opportunity. That is what we have built. Agilis Ubiquity — insurance at the speed of business.
Learn more about Agilis Ubiquity and Agilis Sentinel, or get in touch if you would like to see what we have built. This article was first published on LinkedIn.