Jentic CEO on universal agents and digital twins at scale

Jentic co-founder and CEO on how universal agents and digital twins could unlock enterprise AI at scale

Sean Blanchfield is helping Jentic's customers manage what he considers the most critical AI bottleneck: not model quality, but rather enterprise AI integration, governance and oversight.

Sean Blanchfield's experience spans large scale infrastructure, from the backend systems that powered Call of Duty, Guitar Hero and many other gaming titles (later acquired by Activision, where he became a VP) to his latest venture, Jentic, which he co-founded in 2024.

According to Blanchfield, the biggest AI integration challenge is what he describes as the 'geological layers' of enterprise IT: essentially legacy systems that are built layer by layer over time, eventually becoming a serious bottleneck for AI transformation projects. Using AI agents to map and clean up sprawling API estates and create digital twins, Jentic helps customers safely plug into legacy systems with minimal operational risk.

In this conversation, Blanchfield explains why these 'geological layers' of IT are stalling enterprise AI integration, proffers some solutions, and sets out why he is increasingly bearish on vertical AI tools as universal agents become more powerful.

The Bottleneck Is Not the Model

Lara Williams: What is the most common point of failure in enterprise AI adoption?

Sean Blanchfield: The bottleneck at this point is not the model at all. It is connecting the AI to things in the right way. And more subtly than that, it is not just connecting it, which, if they do it the wrong way, is still hard if you do it the traditional way. You end up with systems integrators and consultancies writing code, which is the old fashioned way.

And after you have got it connected, do you have any control? Do you have any oversight? Do you have any central governance, actual oversight and the ability to control what can connect to what? Do you have the ability to scale this out and maintain it? That is where things are hung up. That is the case with nearly all of our customers now.

From our perspective, starting in 2024, it took a little while for the market to catch up. In 2024 I was thinking about this space and where to build my next business. I was able to triangulate that this integration piece is always hard, and now it needs to be done in a whole new way for agents.

LW: That is a really rapid scale up isn't it? From 2024 to now you are already working on a pretty large scale.

SB: The revolution is on. The capital is available, and everything is getting built with AI as well as for AI.

We have been moving very quickly and making a lot of rapid progress. Mostly we have been waiting for the market to catch up with the problem we were solving. But it is bad now, the problem is acute.

We are working mostly with Fortune 500 companies, trying to get their API estates into shape so that they can reliably connect AI to them, and then govern that access.

Why Enterprises Need a Neutral Layer

LW: It is quite a niche layer. What is stopping some of the bigger companies from providing this and wrapping it into their own offerings?

SB: To some extent they will, but there is a need for a neutral layer. If you look at companies like Microsoft or Amazon, and we are partnered with them, by the way, as they solve these problems, they tend to solve them first party. They will have their own agent platform, and they will make it easy for their own agent platform to access their own APIs, and they may do that through some governance or security.

When we talk to a CTO or CIO of a large enterprise now, the ship has already sailed. They cannot make one platform "the" platform for all their agents. They already have lots of different platforms, with agents popping up everywhere like weeds: agents in Salesforce, agents built on Workday, some over on AWS, some over on Azure, some from random startups that have come in, plus stuff built internally on different platforms.

So, there is no "platform to rule them all" in terms of what kind of agents you have or where they are running. You need an independent layer where you say: we must have some kind of control over this. We need to do that at the data layer, not where the agents are running, but how they are connecting to proprietary enterprise data.

That is all you actually need to govern. It is the data access, not the mere fact there is an agent running somewhere disconnected from anything. If it is not connected to anything, you do not have to worry about it. As soon as it starts getting connected to company data, that is where the need for governance kicks in, and then you can have a single point of governance there.

60,000 APIs and the Geological Layers of Software

LW: Could you outline an example of a customer that was really in a mess with AI integration into legacy systems, and how you fixed it?

SB: At the most extreme end, an enterprise with the most internal APIs, entirely bespoke, had over 60,000 internal APIs. Those had nearly a million endpoints, different functions and operations.

That is exceptional. Normally it is a few thousand, maybe 3,000 or 4,000 APIs, and maybe tens of thousands of API endpoints. Their challenge, in terms of agents, was to connect agents into that API landscape.

LW: How do they get to that point of 60,000 APIs?

SB: Over decades, normally.

That includes old mainframe stuff, going back to old COBOL systems, and then layer upon layer of transformation along the way. I think of it as "geological layers of software".

So, for example, some financial services companies will have legacy API estates still running on mainframes that cannot be touched. It is too complicated and there are too many trillions of dollars running through them to tamper with.

You have 1980s systems, then 1990s systems. In the 1990s it is CORBA and DCOM. In the 2000s you get SOAP, so web services appear for the first time but as SOAP based services, which are better but still a bit horrible.

Then you get REST web services in the 2010s, and some may have moved up to GraphQL type approaches more recently.

That is the reality of how those companies run and where all of the data lives, and it is normally high stakes data.

Meeting AI Where the Legacy Already Is

LW: So, what did you do?

SB: First, our position is that all that legacy is there for a reason. It is really hard to modernise this stuff, or they would already have done it over the last 20 years.

Realistically, AI needs to be met where it is, and actually AI can do that. You can interface AI into even really complex old legacy systems, so long as the documentation is good. If you can document how that old thing from the 1980s actually works, you can point something like Claude Code or OpenAI style agents at it, with the documentation, and they can figure out how to interface with it.

What differentiates us from previous companies, and what I would call a truly AI native approach to this integration problem, is that you forensically investigate all those geological layers and document them, then hand the documentation to AI to work with, rather than build lots of new software on top and create yet more technology layers.

Scoring APIs for AI Legibility

More specifically, when we go in, we read all of the APIs they currently have. Normally they have these in API management systems or API gateways, those are the systems they use to manage their APIs. There will be a list, a catalogue, all in one place.

We read that down and run it through a scoring system we developed and open sourced, which scores the APIs for AI legibility. Normally they score really poorly, because those APIs have been created to the minimum standard required for them to work, with the idea of some tireless humans at the other end who have to sit down and try to work with them. Those humans might have weeks to experiment and figure out how to make the API work, or they rely on institutional knowledge, being able to walk down the hall and find someone who was involved and ask them what happened in 1996 to lead to the current situation.

That is the existing standard: the APIs can be made to work, but it is not easy.

Then we put them through a process where we try to raise the standard of the documentation and the APIs. There is a standard called OpenAPI that has been around for 15 years, and companies generally use it to a greater or lesser extent. We actually have a lot of people involved in creating that standard working with us now.

The first step is to make their OpenAPI descriptions (the machine readable descriptions of their APIs, which the AI will read) great. We use AI to do that. That is the forensic, geological work.

Digital Twins: Moving Fast Without Touching Production

Once you have really good OpenAPI descriptions of the APIs, you can begin to do all the other stuff. For us that involves digital twins or sandboxes. We set up an emulation of every API that we read. So now you have the real thing and the digital twin of the thing.

That allows you to use something like Claude Code or other agents to connect to the simulation and have them develop even more code, but without tampering with production. That allows companies to move very quickly, begin to build new applications, automate work and have a test simulation where they can let the AI run and figure it out.

When it has figured it out well enough, and proven that it is solving a task in simulation by interfacing with various databases and APIs, some of those thousands of APIs around the company, you can take that use case as having proven itself and move it into production.

LW: So that reduces the risk. Are you always starting with the digital twin format?

SB: Yes, at least with big companies.

By creating the digital twin, it gives them a place where they can proceed right now with no security or compliance hurdles to overcome in order to experiment at scale. Then they pick the successful things and move those through security and compliance to get to production.

Why I Am Bearish on Vertical AI

LW: What's your long-term prognosis for vertical AI companies that perform sector specific tasks like the one you outline above?

SB: From the vantage point of where I am building, I would be bearish on vertical AI companies.

Companies like mine and other start ups are building our own systems using things like Claude Code and OpenClaw, and we have very little interest in buying a vertical tool.

I think AI is basically horizontal and general purpose. OpenClaw is an example of a horizontal, general purpose agent, capable of doing virtually anything you ask it to.

There are potentially benefits to having a fine tuned model on a very particular domain, but I think they are marginal. Those marginal benefits are probably outweighed by the convenience of having an agent that is perfect for your use case, built into your company, speaking the language you speak, and speaking to the systems you use.

It is sovereign to you. When you work with it, its data continues to belong to you, and every moment you spend working with it builds your business value, not your vendor's.

LW: "Universal agents will be the death of vertical AI" is a punchy line, but isn't it a bit dramatic?

SB: I do not think it is too dramatic. In reality, it just does not leave a lot of space for vertical agents to grow. If you consider that OpenClaw style agents are here now, Microsoft is building similar capabilities into Microsoft 365. Apple and Google basically announced similar concepts two years ago and did not ship them. Project Astra from Google was basically the same thing, the Siri demo in June 2024 was basically the same thing, but they did not ship. Now OpenClaw has blown that space open.

Are they going to respond? I would say they have to, or Meta will ship something similar in WhatsApp. Everyone is going to have a universal agent on their phone within a couple of years. When that happens, where do you need vertical AI? Where do you need separate software?

The Marginal Benefit of Specialist Models

LW: On the legal example, specialist models like Genie AI or Harvey are drawing on much more niche data. Do they not have an advantage?

SB: They do, but it is a marginal benefit.

And I think that benefit is reduced over time. It is hard to compete against the raw intelligence of the underlying model as it continues to improve and as its training set increases.

There is a marginal benefit to specialist training, but I think it is outweighed by the practical advantages of being able to set up something like the latest Opus class model in your environment, in a way that is perfect for you, that gets you 97% of the way there.

How hard will you work for the extra 3%, versus waiting a month for the next model?

This article originally appeared in Tech Monitor, interviewed by Lara Williams and published on 17 September 2026.