An Application-Free Future? Speaking Directly to Data with illumex CEO Inna Tokarev Sela

Inna Tokarev Sela, CEO of illumex, welcome to The Cognitive Revolution.

Thank you for having me, Nathan. I’m happy to be here.

I’m looking forward to the conversation. Right off the bat, on your homepage, the call to action is, “Get your data speaking the way your employees do.” I think this is a really interesting space. It’s a subset of AI-assisted coding, heavily rooted in the paradigm of tool use, and it seems like you’re on the verge, as so many companies are, of transforming a job role.

I’m looking forward to unpacking it both from the technical underpinning standpoint and also in terms of how you think it’s going to—and perhaps already is—impact the way your customers conduct their businesses.

For starters, you started the company in 2021, right? That’s what I saw in my research.

Yes. The golden age of startups.

Was this a generative AI play from the start? At that time, we had seen glimpses of GPT-3, but I don’t know how many people realized how far it was going to go. What was your mindset at the time, and what was the original founding vision? How, if at all, has that transformed over the last few years?

That’s a good question. Imagine me going to deep-tech investors in 2021 and explaining automated context and reasoning for agentic AI. After 2 or 3 pitches, it was clear to me that I needed to refine that.

I presented illumex as we do today: We’re on a mission to enable an application-free future for knowledge workers, with a vision to augment people in their daily jobs with self-service access to data analytics from structured data sources.

To me, it was always fascinating—from my early days at SAP and then Siemens—to understand why, after such heavy investment in data and analytics practices, the majority of business decision-making is still based on guesswork. It’s not to blame anyone. We as humans have so many questions every day, and we didn’t really have a helper answering all our questions with data automatically.

Then, when 2017 arrived with semantic models, Hugging Face, and all of that, it became clear to me that the time was now. I’ve been in love with graphs since my first degrees. I won’t mention how long ago that was, but imagine that we were programming graphs in MATLAB, so it was a very long time ago.

To me, it was clear: The graphs are here. They provide context and relationships. Semantics provide content. Together, context, content, and automation give us this exquisite fabric that can connect data to people and workflows and finally enable self-service.

This idea of an application-free future is really interesting. It’s a very different take on the future of software compared with a lot of the other companies I’ve been exploring recently.

I’ve done 2 episodes with companies creating full-stack software-development AIs. Their vision is that you can get any application you want in record time. We’re going to have tons of applications: custom applications, personal applications, disposable applications.

Tell me more about the application-free vision. It’s the first time I’ve heard that phrase, and it’s a striking contrast to some of the other visions for the future of software that are circulating.

I don’t find it necessarily contradictory. What you described—different functions and different niche agentic full-stack implementations—can absolutely coexist with an application-free future.

Business users, especially those who are not tech-focused, don’t want to keep learning new technologies and tools. On the business side, they have a day job, and that day job is not looking into new software. Having multiple interfaces, multiple applications, context switching, and integrations between them is simply too much for businesspeople to tackle.

Right now, we already have a lot of embedded experiences. For example, if you have Sales Cloud and Salesforce, you might have integrated analytics, agentic capabilities, and plugins from customer-success applications inside Salesforce. So it doesn’t really contradict the application-free future. We can always integrate experiences into experiences.

Eventually, it will boil down to having a launcher interface. You ask a question or narrate your task, and then it happens. You don’t really care which application you need to invoke, which data is being used, or which workflow process facilitates the result. You don’t need to care about all that orchestration or remember the order of clicks required to get your answer or perform a task.

The application-free future is coming. It doesn’t contradict what you described; it means that the whole operation will happen in the background rather than being exposed as the interface to the end customer.

I’m totally with you that it’s not going to be one or the other. Both visions can probably coexist: applications conjured out of nothing on one side, and your application-free paradigm on the other.

I do think it’s an idea people should consider more. What would it look like if you could do everything while walking around? I’ve really wanted that with Advanced Voice Mode from OpenAI, but I haven’t quite gotten it yet for what seem like mundane reasons. It doesn’t have all the same features, and I can’t load as much context into it as I can with normal chat interactions.

I envision a future for myself where I’m untethered from my chair and out in the world more, but still able to interact with information and take actions within the digital world that aren’t accessible to me right now unless I’m locked in at a workstation. That seems like a fascinating and potentially liberating paradigm for people who feel, as I do, that they can’t do their usual work unless they’re at the desk.

Do you want to show us what this looks like?

Absolutely. You mentioned that it would be nice to invoke something from your phone. Can you see my Slack screen at the moment?

Yes.

There we go. You have Slack on your phone, and you can simply ask, “How many products do you have in stock right now?” Maybe you’ve just received a message about low stock.

We have 2 modes. “Let Omni decide” is autopilot. If you’re an analyst or a data person and want to dig deeper and choose for yourself, we have that option as well.

“Let Omni decide” matches your query with the semantic ontology that we create in the background. A more sophisticated way to describe that is that we capture business logic from your data sources—from your data lake, warehouse, database, business-intelligence tools, SAP, and so on—and match your prompt to those business-logic definitions.

We show you what you’re seeing, with varying levels of detail. You can see the semantic entity we used, go into illumex, and explore everything from the data to the actual SQL code and the resulting number.

When you click on the semantic entity from Slack, you can see the explanation, the lineage, the attributes, and the actual business ontology behind it. It’s a platform for control freaks. Most people will get the answer and take action based on it, but some people will want to see the business ontology, the relationships, and the definitions behind it. They can go deeper and see all the explanations and related information, including the definition of the data and the code that produced the result.

It’s fascinating that we can have different user experiences within the same workflow. I love my Ray-Bans because they have speakers, a camera, and everything else built in. It’s liberating not to have headphones in addition to that.

The same is true of having self-service data-copilot access. You’re in your environment—in Teams, Slack, or your regular tools—and suddenly you can have this friendly chat with an analytic experience.

I mentioned that automating jobs is actually about augmenting jobs. We all want to make smarter decisions, and this allows you to be factual about them.

Let’s dig into where this data comes from. I know a lot about SQL databases and how to query them, but I don’t know nearly as much about where enterprises store their data, what platforms they use, how they get those systems to talk to one another, or what challenges exist there.

How do you create that understanding in the first place? If I’m understanding the approach, you first scout out the data environment at a company and try to make sense of it. You arrive at an established, canonical understanding: This is what the data means, this is what it represents, and this is how it relates to other data.

Once that understanding is vetted and validated, runtime queries become safer because you’re not asking language models to make all of those determinations on their own every time. If I have that right, how do you actually do it, from getting access to a large company’s data environment to understanding it?

It’s fascinating to me as well. That’s why I started the company in the first place.

Naturally, you need a corpus of knowledge about each industry and each line of business. We need to understand terminology, processes, metrics, analyses, and dependencies across all the areas we cover—from IoT and manufacturing to insurance, pharmaceuticals, retail, and finance.

What we built is a domain of knowledge covering all of the above. We encapsulate this knowledge as a business ontology. Architecture-wise, it’s a knowledge graph of semantic embeddings, a combination of relational models and semantic models.

For customer onboarding, we take an interesting approach: We look only at metadata. We work with regulated and data-intensive companies that have hybrid data stacks. They may have on-premises Oracle, SAP, Microsoft SQL Server, Teradata, or other traditional systems, but they also have modern environments with Redshift, Snowflake, and Databricks. They may have business-intelligence tools such as Tableau or Power BI, along with dozens of other systems in each department. There is absolutely no single source of truth.

Our system brings our ontologies as a benchmark. This is what an industry benchmark for a single source of truth would look like for a specific customer. Then we rechain the ontology onto the customer’s data stack using only metadata. We look at schemas, query logs, and application APIs to automatically rechain the business ontologies.

The result is a custom ontology for the customer. This process usually takes a few days, depending on the size of the customer. We have customers with millions of tables spread across their data estate, so the timeframe varies.

This is automated context and reasoning. Compared with RAG, graph RAG, and other techniques, you don’t need to provide manual examples or labels during onboarding, and you don’t need to move your data. We don’t require you to move your data to a vector database, for example. We do it as a virtual layer.

This virtual layer is a knowledge graph of semantic embeddings that represents the semantic single source of truth across the customer’s entire data estate. We support both federated and centralized models. That means we can understand that an order ID in one table and system is actually a vendor ID in another system, and incorporate that knowledge into the platform.

A single source of truth is important, but it’s also important to bring humans into the loop. When we model data for business intelligence, we already create gaps between business users and data. We have a subjective understanding of the business that gets delegated to data professionals, who model the data for applications.

With generative AI, it’s even more complicated. With RAG and similar techniques, you trust your data scientist to correctly represent your business-logic corpus in a semantic model. Why would that happen? Why would business users understand all the examples required to feed into the system? They don’t. They aren’t running those processes; they’re in the background.

What’s good about illumex is that, when we generate semantic reasoning and context automatically, we also have user-friendly application workflows. Business users and other nontechnical users can verify and certify our definitions through our web interface or in their own environments, such as Slack and Teams.

That brings humans and AI into the same playground.

Do I understand correctly that you’ve essentially created the platonic form of an enterprise in different industries? You’ve drawn on extensive experience and brainstorming to identify all the aspects of, for example, an e-commerce business that you would expect to find in a customer’s data environment.

Then you have another model for a pharmaceutical company, which could be quite different in terms of the information it handles. You’ve done this work for different customer profiles, and when you onboard a new customer, you compare and contrast its environment, finding the idiosyncrasies that represent the ways it departs from the idealized data model you created in advance.

Is that the right way to understand the approach?

Exactly. Every customer is special, and they customize their systems. They have preferences, and sometimes they use personal names for tables and columns.

We have automated cleaning of definitions and automated labeling and semantic-entity resolution in the system. That comes from the canonical industry model, which picks up different clues from the customer’s metadata for the correct mapping.

You may have heard of a company called Palantir. This approach isn’t novel. They have business ontologies and a process that maps organizational data into those business ontologies. We simply do it automatically.

I would have guessed that you could only do that reliably quite recently. I’m sure you’ve had many versions of this process, but if you take me back to 2021 or 2022, I did a lot of fine-tuning of models in that era. I would have guessed that those models would have been pretty unreliable at reasoning through this kind of problem.

We’re now mostly past the debate over whether AI systems can reason, but back then it was a much more reasonable question. Are these systems still just stochastic parrots, or are they reasoning a little bit?

How did you get anything working, and was it automated at that time? I’m struggling to imagine how you could make this reliable enough to be valuable with anything other than models we’ve had since around Claude 3.5 Sonnet.

That’s a great question. There’s some truth to what you’re saying, but even with modern reasoning tools, you need to program them and improve their reasoning.

We don’t trust language models to reason on their own, even now, because they aren’t customized enough for what our customers require. We pick up reasoning from the industry benchmark—the canonical ontologies we’ve built over time—and we’re always enriching them. It’s an ongoing process.

We also pick up reasoning from existing relationships in the customer’s metadata. For example, if you have a procurement or purchasing process, we already understand the thresholds and the rule-based decisions implemented in the application APIs. We pick up that information from application APIs or from metadata.

It still sounds hard. Who is making the connection?

In your canonical model, let’s say we have an e-commerce business with variations on a product. I was looking at some Shopify data, and it has collections, products, and product variants. You can have styles and other cascades from high-level concepts to low-level details.

You go into the data environment of a particular e-commerce company, and it may be easy to say, “This looks like a product.” But there must be many lower-level concepts with idiosyncratic names, perhaps even names in different languages.

Suppose I have my own idiosyncratic e-commerce business. Instead of calling them product variations, I call them “VRX.” How do you become confident enough to know what my idiosyncratic concept is in relation to the canonical, idealized representation?

We don’t trust semantics, even when the semantics are self-explanatory. We still don’t trust them 100%. We analyze usage.

We don’t only build ontologies—semantic entities and their relationships—we also build taxonomies. A taxonomy is an understanding of the usage context.

For example, you might have a poorly named column with your first name embedded in it. We analyze different usages of that column and their context. It might be used for a transformation and assigned an alias in a dbt data pipeline. It might also be used by a business-intelligence report to calculate channel attribution.

We analyze formulas and logic and cross-validate them with the metrics already embedded in our platform. We understand the usage context, all its appearances, and the proximity of the usage contexts between different elements. Then we infer the mapping.

If a meaningful column and a nonmeaningful column participate in a formula, metric, or calculation, and we have another example of the same nonmeaningful column participating in a different calculation, while both calculations are mapped to the same semantic model, we can infer the meaning of the nonmeaningful column.

There’s a lot of context analysis. This is only available when you have a history of logs showing how people interact with systems and when you have application usage. If you have a blank page—you’ve just created your warehouse and it’s empty—we analyze hierarchies, the proximity of different semantic definitions, and the data pipelines feeding those calculations.

How much of that analysis is done with fully explicit code, and how much is done by asking a language model to figure it out? Obviously, you have a hybrid approach where language models tap into explicit code, call functions, and get results. You also mentioned embeddings, which is another area where I’m struggling to make the leap.

When I think of embeddings, I think of highly semantic grounding for those embeddings. With Rewatch, my company, we do video creation for mostly small businesses. We’ve had a challenge over time: We have a huge library of different forms of content, and we’ve done the canonical work of identifying a good way for a small business to present itself.

Instead of mapping a business’s presentation onto our form, we’re painting its identity, brand, and content onto that form. We’ve often asked how to determine the best video template for a given business. They’re not going to watch every template and choose one. We want to make an intelligent choice.

We explored using embeddings, but we found that our notation wasn’t well understood by standard embeddings. We got matches based on things we didn’t actually want the match to be based on. If we have sample data in a template, that can dominate the actual vibe we want to match on.

We want to match on pace and energy, but if we put placeholder text in the template, those elements seem to be the real matches. So we don’t have an embedding component in our system because of that notation-versus-semantic disconnect.

What’s the mix of different kinds of analysis that go into this process? Specifically, how have you made the embedding side work? I’ve tried and failed to make that work well personally.

Video is a very complicated space. Structured data is complicated as well, and documents are naturally easier because they have a lot of context and corpus. Structured data is almost bare of context unless you analyze metadata, usage, and everything else.

The short answer is that we leave absolutely no ground-truth embeddings from the input ontology in the output. There are no traces or leftovers from the basic input ontology in the output. If we don’t find a match between an input and the customer’s ontology, we remove it completely.

That means there may be a business concept or business metric that other companies use—for example, a workflow—but if this specific customer hasn’t connected us to a data source that supports that workflow, we simply cannot introduce a business concept or semantic that isn’t grounded in the customer’s data. That’s how we keep it clean.

We have dozens of semantic models and graph models for different tasks. Explicit semantic labeling is done by one model. SQL usage and queries are analyzed by different models. Semantic-entity resolution is handled by another model. We use a combination of different models and benchmark them on the performance of each specific task.

We haven’t found 1 open-source model that is good at everything. It’s usually a combination of many models, along with our own IP.

After semantic labeling, we understand usage. After usage, we understand relationships. We build those graphs and analyze subgraph matches. For example, we identify subclusters in your ontology and compare them with the canonical ontology. Some algorithms are graph neural networks, and some are more traditional algorithms for identifying subclusters.

It sounds tedious, but it’s automated. We benchmark everything against our golden datasets.

Based on customer requests, we built a benchmark for different types of databases, inspired by the academic Spider benchmark for text-to-SQL. We built an automated ontology for all of the databases and ran our comparison. We were 91% accurate.

Then we analyzed why it was 91% rather than 99%, and we discovered that, because Spider is open source, there was a lot of garbage. Some of the examples were not actually true. Spider has around 60 different corpora or domains in the same database, from baseball and cooking to flying, with very limited context and very limited examples of queries.

We were able to do it automatically, and the system can only improve because, in real life, we have a lot more context from usage.

What do you do if the customer has a workflow or data structure that isn’t represented in your starting canonical version? I imagine that must happen. Do you flag it and say, “We need to expand our model”?

It’s more about supported connectors. We have a list of supported connectors and formats. We need to understand the schema format and API signatures, such as OpenAPI or Swagger definitions, to support automated onboarding.

We can always do manual onboarding. If a JSON format is different, for example, that requires more engineering. It’s not really a data-science or agentic task. We have a list of supported connectors for automated onboarding because we already know their formats.

It’s not really about the logic formats; it’s more about the system formats.

I was wondering how often the manual onboarding is needed. If a customer has something you aren’t prepared for in an automated way, is that where the manual supplement comes in?

For ontology creation, everything is automated. The manual work is related to how a particular API is invoked or how metadata is exported. The metadata export might be scripted or API-based, but that’s engineering.

We have absolutely no manual task for ontology creation. I’m proud to say that we do have certification workflows for business users and domain experts to certify the ontology.

To trust the results of agentic workflows, you must be able to go deeper and understand the concepts behind them. Building application workflows that allow people either to review where an answer came from or to certify definitions in advance is crucial.

It’s also cost-saving. If you prebuild the context and reasoning, your prompt doesn’t have to go to a language model. It can go through a prebuilt filter, and only the result of that matching is sent as a runtime call. That can save up to 80% of your tokens.

You don’t need to retrain the system every time you make a runtime call. To invoke a new semantic model or generative model, you need to create context in a format that the model knows how to digest. That consumes a lot of money.

We created context in a format that is pluggable for any language-model runtime. In the agentic-workflow orchestration that everyone is discussing, it isn’t enough to have niche agentic applications. We’re heading toward agentic workflows and agentic orchestration.

You absolutely have to have shared context. If each of your models has a separate context, they will never be aligned. We automate this context and reasoning and have connectors to different runtimes, such as AWS Bedrock, NVIDIA NIMs, and other platforms.

That allows our customers to build workflows from different agentic models supplied by different providers while keeping them aligned over the same context.

How have you noticed that evolve over the last few years? In my experience with video creation—which is a less complicated problem but a multimodal one with its own complications—the trend has been pretty clear.

Initially, we had to fine-tune. We had to fine-tune 1 model per task, and we had many subtasks. We had to break the task down into many smaller subtasks. Especially in the early days, in 2021 and 2022, we couldn’t necessarily provide all the context we would have liked because the context limit might have been 2,000, 4,000, or 8,000 tokens.

You had to be very careful with context management. We’ve definitely seen a trend toward less need to break things down. The tasks are getting larger, there are fewer of them, and there are fewer models. We can put in more context.

In some cases, we don’t even have to fine-tune anymore because the base models are good enough. We used to fine-tune and ensemble models, but now we can often use a single model.

A good example is understanding the images a small business has in its image library. We used to caption the images and then try to determine, from often very generic captions, which images were relevant. We could only process 1 image at a time.

Now we can put a group of images into a vision-language model and ask which ones are right to use. More often than not, it gives us a very good answer.

You’re dealing with much larger environments, so I imagine your life hasn’t been simplified as much as ours has. How would you describe the evolution over the last couple of years, and, if you dare, how do you think it will continue?

It depends. We benchmark all the time. Whenever a new model comes out, we benchmark it.

Because we deal with a very proprietary corpus and specific domains of knowledge, we haven’t seen significant breakthroughs in the general understanding of business corpora from out-of-the-box models yet. The context and reasoning have improved for public-domain information, internal data, news, and so on, but concepts that don’t necessarily belong to the business world are easier for those models.

In many cases, it’s very hard to build specific business concepts and reasoning. The foundational-model providers optimize for the broadest denominator.

What we do see are breakthroughs on specific tasks. For example, we used to have many models for describing SQL queries. We decomposed queries and categorized them: This is a filter, this is a dimension, this is a measure, and so on. We used different models and ensembles for that.

Now we use a single semantic model trained on a specific corpus that we have, and it outperforms the ensemble. I think it’s a combination of our training data and our ability to benchmark constantly against the latest and greatest.

We still don’t see significant—or even small—breakthroughs in business understanding from general-purpose models.

I could imagine a couple of ways to architect this. One would be to fine-tune a model on each customer’s data set so that it’s maximally tailored to that customer.

Another would be to train 1 model that is excellent at handling all of this complexity, have it speak in the native language of your canonical, idealized data structure, and then map each customer’s world onto that structure.

I’m gathering that it’s the latter. The core model gets smarter, but the mapping is the part that the general models can’t do, and that’s where ontology creation is really important. Am I inferring the right things?

The foundational models are getting much better at understanding user intent. If you use a phrase such as “Just show me,” the model can infer that you’re asking for a count if the subject is numerical. There have been breakthroughs in understanding the question.

The topic of the question, however, is where foundational models struggle in a specific organizational context. So, yes, we’re closer to the second approach.

We have an ensemble of graph and semantic models trained on domain-specific corpora, and then we fine-tune them automatically on organizational metadata. Every organization gets its own custom semantic language model and graph system.

It’s customized automatically with all possible examples—an “Uber RAG,” in a sense. Every example and every possibility is fed into the fine-tuning process.

At the same time, we continually extend and improve our ontologies. We have cross-industry ontologies, because many concepts apply across industries. We share and project ontologies between different use cases, and we’re constantly enriching them.

It doesn’t end with a fine-tuned agentic model for a customer. The model is enriched all the time. If a new employee joins a supply-chain company and asks, “How many pieces do we have today?” we know that “pieces” could refer to deliveries, and we can map it to the appropriate semantics.

That’s a simple example, but there are many different forms of jargon used across industries. We no longer assume that a person speaking to us uses the jargon of a single specific industry. We have cross-company and cross-industry projections.

It’s fascinating to see context shared across users, domains, and companies and picked up automatically. You have your fine-tuned model, but it’s also being enriched all the time.

That’s fascinating. I’m always looking for patterns that I can come back to, and I think this is an interesting one: Create a platonic ideal of what an enterprise looks like, get really good at handling that, and then deal with departures from that ideal through fine-tuning, mapping, and the other techniques that are important.

It creates a kind of software-engineering separation of concerns. Do you organize your team that way? Is there a structure where some people work on the canonical ontologies and the core models, while others work on projections and adaptations for particular customers?

I would love that, but data scientists get bored. We have rotation.

Of course, if we need a quick evaluation of a new model and someone is an expert at building benchmarks quickly—something we need to publish tomorrow, for example—that person will be assigned to the task.

Naturally, we rotate tasks between team members because everyone needs to learn everything. To me, one of the biggest benefits of working for illumex is not only creating this new future and meeting happy customers, but also developing your skill set.

This industry changes all the time, and every employee has to keep up. In addition to health care, salary, equity, and everything else, part of the benefit is the ability to maintain your relevance in this fast-paced environment.

That’s why everyone is allowed to touch every aspect of our business.

What performance benchmarks should we have roughly in mind? Suppose I want to run a query across a database or a couple of different data sources.

I could paste my schema and the structure of another data source into ChatGPT, describe what I want in natural language, and ask it to handle the query without any prior knowledge. Or I could go to a data analyst in my company and give them the question. Or I could ask illumex through Slack.

How good are each of those approaches? People often assume, tacitly if not consciously, that the human is 100% reliable. My own experience running businesses tells me that’s definitely not true. I’ve become radically skeptical of data-analyst results and often ask, “Really? How did you arrive at that?”

We always benchmark against human analysts because of that bias.

If you’re asking illumex for a query, it will create queries on the data source and compare those queries with business-intelligence reports created by analysts. If we’re better than that, we’re good.

illumex is a perfect platform for control freaks because you can check everything. With human analysts, you can get annoyed by follow-up questions such as, “Why did you use this data?” or “How did you calculate that?” There’s a limit to how many questions you can ask a human analyst.

With illumex, you can interrogate the system endlessly. You can ask as many follow-up questions or reverse-engineering questions as you like.

For example, you might ask for a channel-attribution analysis. The system gives you a table, and then you can ask, “What did you calculate with this definition of channel?” It can answer, “This is what I found in the definition of your business metric.” Then you can ask why it used that definition, and it might tell you that the definition was associated with the data source used by 90% of the API calls.

It can interrogate the system in many ways. Usually, people will do that once or twice to understand how the logic works, and then they’ll feel confident making decisions based on the data.

The whole point is to build trust and awareness about how the cake is baked. I use the cake analogy deliberately, rather than the sausage analogy.

Governance is also a major issue. We haven’t touched governance during this conversation, but in generative AI and data analytics, governance isn’t a built-in component of RAG systems, ontology-based systems, or other approaches. Governance is a separate practice, often run in a governance, risk, and compliance department, with no connection to agentic workflows.

That’s a problem because governance is needed most in these systems. Bias, ethics, access rights, skewed data, and all of that should be taken into consideration.

illumex has a governance component built in. We audit conflicts, duplications, personally identifiable information, and other issues. You can export those audit reports, but you can also verify, certify, and govern the system yourself.

There’s another layer of governance at the interface level. When you interact with the system, your prompt is mapped to part of the business ontology. You cannot reprogram the system through the interface or the input, on purpose.

We don’t expect business users to reprogram business logic that has been accepted at the organizational level. The only way for the logic to change is when the metadata or the underlying systems change. You might add synthetic data, add an API, or delete a few tables.

That’s how changes arrive in the system. We flag them, alert you to them, and automatically generate new descriptions and definitions. The system is programmed by inputs from the underlying systems, not by arbitrary interface prompts.

That’s really interesting, and it does foreshadow changes to how companies are going to be run. Before we go into that, are there rough numbers or a mental reference I should have in mind?

If I paste my schema into ChatGPT, I might get a certain level of accuracy. If I go to a human, I might get another level. Do you benchmark the humans at every customer?

It depends on the requirements. It might be a generic test that we need to pass, or it might be a comparison with actual activity.

The goal isn’t to replace analysts. Analysts are irreplaceable. I wouldn’t imagine a public company producing an SEC report or board report through a data copilot without a human analyst approving and confirming it. There’s legal liability around that.

We need analysts. The issue is that analysts are always facing an endless pipeline of requests that they never get to.

We serve those underserved customers. We recently received an inquiry from a department that had been waiting 9 months for a business-intelligence dashboard. They wanted to know if they could get the service to their users another way because the company didn’t consider the dashboard a priority.

Building a business-intelligence dashboard can be very expensive. Providing a data copilot is something we can do much sooner. We’re serving underutilized data, underserved employees, and use cases that haven’t been addressed.

If I had to guess, I would say that a typical one-off data request I give to an analyst at a large company comes back completely accurate somewhere in the 90% to 95% range. How does that match your experience with accuracy in real, large, complicated businesses?

When you’re dealing with underutilized data, the accuracy can fall a little below 95%. When you have unused data and start asking questions, we might return “There is no answer” because the data is corrupted.

That could be because of missing values or duplicate data. You might have a single source of truth and then duplicated data with a different value distribution. Based on our assumptions, we should never use the duplicate data.

When we analyze underutilized data and determine that there’s no answer, we have 100% conviction that it was due to corrupted data. So, frame it however you like, but the accuracy is above 95%.

In my experience, when I get an answer that isn’t right, it’s often because someone made an assumption that seemed reasonable at first but turned out to be flawed. It’s tricky to determine whether I should have expected that person to question the assumption at the time.

It’s an important nuance that the systems themselves often have problems. You can’t just naively query a database and expect to get the right answer every time.

You’re often building on a flawed foundation.

Because we automatically learn from human interactions, we learn from everything that has already happened. Think of it as an Uber analyst who has the experience of all your analysts combined.

How do you manage that? At a large company, the volume of interactions is going to be too large to put into a single context window.

I was talking to a friend who’s working on a research product grounded not in internal company data but in broad open literature. They said that a major challenge is keeping the AI system progressing step by step. How do you ensure that the answer is getting better as you apply more inference, rather than cycling, drifting, or going off in random directions?

There’s probably a diamond-in-the-rough problem here. If you’re looking at query logs, you have an overwhelming amount of information. Somewhere in that haystack, there may be a few queries that reveal that somebody discovered a problem with the data and figured out how to fix it.

How do you identify those highly informative anomalies without missing them? My business is only around 30 people, and our database is tiny compared with an enterprise environment, but I can remember many instances like that. How do you handle the volume?

We don’t use the same context window, for starters. Because of that, we have our own architecture and our own models. It would be extremely expensive to do this with a third-party tool, so we optimize the system for our own needs and processing.

Logic changes over time, and we pick up those changes. We determine whether a change is an ad hoc change. For example, a new analyst might run an ad hoc query with faulty logic. We don’t need to change our model because of that.

We have building blocks and an iterative approach. We don’t only map the workflows; we also cross-validate whether the workflow embedding remains similar to the compound embedding.

Iteratively, we go down to the lowest level of semantic-entity definitions and relationships, and then build the model back up. We have both a top-down and a bottom-up comparison to ensure that the logic remains consistent over time.

If conflicting logic is introduced, we don’t immediately embed it into the model. We flag the semantic entity as conflicted and create a workflow for the data-zone owner or domain expert.

The system can say, “A completely new definition has been introduced by this analyst or this report. It isn’t just a deviation; it’s a serious conflict. Would you like us to incorporate it into the ranking system?”

We ask humans about that. We could automate it using thresholds—for example, adjusting when more than 20% of deviations point in the same direction—but in reality, companies prefer to understand deviations in logic before incorporating them into the model.

It sounds complicated because you need to understand all the nuances, but it’s easy to use because you aren’t building anything. You’re simply reviewing information.

The experience requires 90+% less effort than what companies have today. The context and reasoning are built automatically, and the changes go through review. You have explainability and can examine the system both top-down and bottom-up.

It may sound complicated, but the experience has 90% less friction than current processes.

You’ve mentioned several times that the system is entirely metadata-based and never looks at the actual contents of tables or other data stores. Was that a decision you had to make because people didn’t want to allow another company to see their data?

Would the system be easier if you had visibility into the actual contents of the tables? I assume it would be helpful.

It would be helpful, but to me it’s both a tool decision and a business-model decision.

For the companies we work with, it’s imperative to keep the data to themselves and, to some extent, separate the definitions and business logic from the data values. If you have the same provider holding all your business logic and all your data, that becomes a significant liability.

Reducing risk for customers is our biggest priority.

When I send a query in Slack to the illumex bot, the query gets sent to your system. Your system knows the metadata and then sends a tool call back to an application, such as the Slack integration, that lives on the customer’s infrastructure.

That application calls the data source and returns the result to the customer. You’re generating the tool calls but not directly interfacing with the database at runtime. Is that right?

Exactly. We send the query for execution, and the results are presented in the same interface from which the prompt originated. Again, that’s for security reasons.

That’s very clever. The idea that you can do this much with data without ever seeing any customer data must be a major advantage in the sales cycle.

I wouldn’t know otherwise. People ask me what it’s like to be a female founder, and I say that this is the only experience I have.

It was an early decision to base the solution on metadata. During our early discovery calls, we heard that customers would have no interest in a solution that touched enterprise data with generative AI.

We made the decision early, and now when we receive security questionnaires, we can say that everything is based on metadata. We don’t touch personally identifiable information or other sensitive data.

Of course, companies want to understand exactly what we do with metadata, where it goes, who our subprocessors are, where we host it, whether we can provide instance separation, and whether we can provide account separation.

That’s all justified. Enterprises need to feel comfortable with the implementation before they can trust the results of the system. If you don’t trust your vendor, you can’t trust the output of the system.

There are many reasons people are sensitive about customer data. They want to maintain customer trust, avoid lawsuits, and comply with regulations in different jurisdictions.

But as I hear you describe everything you can do with metadata, I wonder whether people should be more concerned about it. Metadata is the scaffolding of the business. If I wanted to compete with one of these companies, it sounds like access to its metadata might be even more valuable than access to the underlying raw data.

I would take the question in a different direction. Processes are generally less differentiating than business metrics. Companies differentiate themselves through results, and most public companies already report their leading metrics, business structures, and related information.

I would say that much of the differentiation is in the data. Foundational models are going to become faster, cheaper, and more agile. Companies will build many automations around them, and those automations will be as personalized and effective as the underlying data.

The real value for companies is the richness of the data they accumulate over time. If companies don’t accumulate data about everything they can, they’re missing opportunities. That data might become the next revenue engine.

Five years ago, people said that every company was going to be a digital company or a digital-product company. I think this is the next stage. Companies will have many data products and services that they can sell to customers and partners, perhaps even as data agents.

But to do that, they need differentiated data.

It sounds like you see a maturation of data management, querying, and analysis analogous to earlier waves of computing.

At one point, an e-commerce company might have said, “We’re the best at running servers for this e-commerce business. That’s why we’re going to win: Our site loads faster and people have a better experience.”

Now everyone’s site can load. That isn’t the primary differentiator anymore. It sounds like you’re saying that, before too long, everyone will be able to extract value from their data. The question will be how much value there is to extract, rather than whether you can extract it.

It will also depend on how integrated you are. We’re going to have industry clouds and cross-company services. How well you recognize the value of data and integrate it into different systems will matter.

We started with the application-free future. For that future to happen, several things need to be in place.

First, we need the shared context we discussed in depth. Data, agents, and workflows need to be able to operate around the same shared context. For orchestration, you need common data formats so that you can share data between companies and industries.

Semantic mapping, a semantic layer, or a shared context could facilitate that. You also need to integrate your software into other companies’ offerings.

Customers could invoke a cross-company workflow and pay for what they use through a consumption-based model. They wouldn’t care which systems answered the question because the whole process would be encapsulated.

No actual data values would need to be shared. Everything could remain secure, while business and semantic alignment would prevent another “lost in translation” experience.

It sounds very forward-looking, but we already have the beginnings of it. We have semantic models that came from nowhere, and suddenly they’re expected to understand your business logic. Now we have mechanisms to provide those models with business logic through RAG, illumex, vector databases, and other approaches.

We’re at the beginning of this transition, but it isn’t far-fetched.

Who are your users today? You have data analysts, executives, and business leaders who want to ask questions. I’ve often found myself asking data questions after hours, when the person who could answer them wasn’t working.

It may be early for this, but I also expect AI users before too long. Google has discussed virtual coworkers, and OpenAI has discussed specialist agents. I can easily imagine an AI chatting with illumex in Slack in the not-too-distant future.

illumex is definitely a playground for machines, humans, data, and applications. It’s a playground where everyone can collaborate.

Our users are changing rapidly. Six months ago, most of our users were technical people: data-management teams, governance teams, analysts, and similar groups. They used self-service access for domains they weren’t experts in.

For example, an analyst might be asked to create a report on a database they know nothing about. They could use illumex to get started.

In the last 6 months, all of our inbound requests have been about self-service for business users. The industry has matured rapidly, and self-service for business users is no longer as intimidating as it used to be, especially because we provide built-in governance and cost management.

I expect agentic workflows to become users as well, sooner than we expect.

How do you price the product with that in mind? The per-seat model has been popular, with the idea that you grow as the customer’s team grows. But if an AI agent working on behalf of a senior leader is doing a large amount of querying, a per-seat model may not work well.

Do you have thoughts on how enterprise SaaS products in general should adapt their pricing to this new reality?

Our investors are venture investors, so they like predictability. I also like predictability. When I pay the bills at the end of the month, I don’t like surprises.

The biggest factor slowing enterprise adoption last year was the surprise factor around costs and return on investment—the cost of AI success.

At illumex, we have sealed tiers based on the size of the company and the number of data sources. If you connect 1 data source, you’re in the starter package. If you connect 3 to 5 data sources, you’re in the midsize package. Then we have an enterprise-level, all-you-can-eat package.

The pricing is sealed. There are no surprises regarding context, seats, or consumption. No one likes surprises, and they can significantly slow adoption.

We aren’t being careless about our costs. We encapsulate interactions with agentic systems inside the company itself. Because the context is prebuilt, most interactions use the same context rather than sending it repeatedly, rechaining it, or fine-tuning everything again.

Our pricing is much more cost-effective than using off-the-shelf APIs and traditional RAG approaches. We benchmark against the latest and greatest, not the lowest denominator.

If you extrapolate this, the models are improving all the time. You’re saving money relative to the baseline cost, but the baseline cost is also declining.

In software development, it’s hard to tell what’s happening right now, but we may be entering a period when entry-level software developers are starting to struggle. There are fewer job postings, and people with computer-science degrees are saying they were promised good jobs that aren’t materializing.

Senior people aren’t immediately threatened, both because the technology isn’t good enough yet and because companies aren’t ready to rely on it entirely from a trust perspective. It sounds like that’s true for data as well.

Would you advise a college student to go into a data-analytics role today? I have a hard time saying yes. By the time that person finishes college, the field may not exist in the same way it has in the past.

Our professions are going to be reinvented several times during our lifetimes. We all need to keep upskilling.

Driving changed from pulling carts, to managing horses, to operating a steering wheel. Data and analytics professions will go through a similar transformation.

We’re going to have fewer content creators and more content moderators. That shift is critical because it isn’t feasible to have everything done with human resources.

Consider how much companies spend on data analytics today. They’re using perhaps 10% of what could be done in the data domain. We can upgrade data and analytics professionals so they can resolve conflicts, talk to business users about expected experiences, moderate the system, and customize the experience by giving software instructions.

Software, including agentic software, isn’t yet very good at understanding requirements. The same prompt in a system like Illumex can produce different answers depending on the context.

We still need humans because humans understand analogies, metaphors, and customer intentions. They can also understand the technical details. If the system says that the data is insufficient for a model to perform, an experienced person can recognize that a crucial column was removed and understand why the alert appeared.

I’m not saying that the moderator role will still exist 50 years from now. It will become something else. But I do see a shift from content creation to content moderation at scale.

That does require expertise. New graduates should become proficient in something deep enough to enable them to become moderators quickly.

It’s a brave new world, and it’s coming at us extremely fast.

Maybe I can ask 1 more question. What academic research or other work would you point people toward if they want to go deeper into this field?

I’ve had a couple of ideas, and I’ll put my own recommendations in the show notes, but I’d be interested to hear which academics, papers, or open-source projects you think people should study.

If someone wanted to upskill and become a good candidate to work at your company, what should they study in the broader world?

That’s a great question. We’ve always had academia as a never-ending source of news and inspiration, especially in agentic AI.

What I see now is that some of the biggest inspirations are coming from the largest industry players and, in some cases, from unexpected sources. I advise people to follow the biggest players in the industry and observe the direction of their development and what they’re saying, including in business keynotes.

They say a lot. You just need to read between the lines.

For me, the biggest inspiration is coming from industry rather than academia. I do read academic research on ontology, different approaches to combining context and content, and related topics.

I don’t see a major breakthrough yet, but there’s a growing understanding that a purely semantic approach won’t be enough for a multimodal experience. If you want a multimodal agentic AI system, you need combinations of content, context, timelines, and what you call “vibe.”

You need to incorporate factors that are currently treated too flatly. Academic research is shifting in the direction of multimodal context, but it isn’t there yet.

I recently saw interesting research published at a NIST conference about an ontology-based RAG system for supply chains. The researchers took industry-specific data and an industry-specific ontology and showed that the RAG system performed better and more cheaply.

That’s great, but we should extrapolate further. Do you need to manually create an ontology for every use case? That isn’t scalable. Academic research is advancing, but not at the pace I would expect.

That broadly aligns with my sense of things. People often ask me where they should go to get up to speed on AI and whether they should take a course.

Honestly, for general-purpose knowledge about what’s happening with generative AI, a lot of the best education is coming from online practitioners. They aren’t necessarily professors, but they’re moving quickly, trying to keep up with the frontier, and shipping things that are roughly current.

In many ways, less-credentialed but more-current resources can be better for people today. I read a lot of academic work as well, but there’s a big difference between academic publications—such as what appears on arXiv every day—and what universities actually offer in their curricula. The curriculum is far behind in many cases.

This has been great. I appreciate you taking me through all of this. There are several new concepts and perhaps even paradigms that I’ll be thinking about going forward.

You’ve definitely achieved my main goal of learning something new and interesting with every episode. I’m coming away with several good takeaways from this one. Is there anything else you want to share with the audience before we wrap up?

I think it was a very enlightening conversation. I’m sure the audience won’t use the word “ontology” for the next 2 days after hearing it so many times.

My advice is simply to be brave. I have a 9-year-old child, and I wonder whether he’ll attend university or learn to teach himself through some new kind of Discord. I’m eager to explore it.

Put your hands on the latest and greatest technology and experience it yourself. I’ve studied at 5 different institutions, and it’s funny to talk about inspiration and all of that, but now we can find inspiration in many different places.

Life is short, everything is moving quickly, and academic degrees may reinvent themselves.

I have 3 children. My oldest is almost 6, so I’m not quite as far along as you are.

Are there any AI education or tutoring products that you’ve found particularly valuable?

It’s a tricky question. When my son was a baby, I bought all kinds of neural-network books for babies and toddlers, but they didn’t really stick.

Throwing a ball and explaining gravity was much more educational than reading books about it. I introduced him to ChatGPT relatively early.

That may not sound educational because I explained how he could use it to do his homework, but it’s more important to me to teach him critical thinking, how to check sources, and how to combine different types of technology to achieve a task.

There’s another approach where parents give children a pencil and notebook and no access to electronics in order to teach them to think. I’m at the other extreme. I want to give my child as much technology as is age-appropriate and teach him to be critical about it.

He should think about what could go wrong and look for faults. This is just my approach.

He was very happy when he first got to use ChatGPT and ask questions. Then he said, “The homework is trivial now, so I’ll do it myself.”

I said, “Great. You don’t need it right now, or at least not to the same extent.” The important thing is that the tools are available and the judgment remains his.

That’s fascinating. I think I lean more in your direction, but we’re just starting to figure this out.

This has been amazing. Thank you again for taking all the time, Inna Tokarev Sela, CEO of Illumex. Thank you for being part of The Cognitive Revolution.