Inside Articul8’s Domain-Specific Platform and Real-World ROl

Uh, good morning everyone. I am Par Letta head of product management at ate. Um, like, uh, what we were discussing so far, right?

I mean, enterprise AI is not about generic AI answers. The future is in unlocking that expert intelligence. Uh, so when you are making a decision on a high value enterprise use case, you do not want to rely on generic AI agents because the cost of such decisions is humongous and you don't want to rely there.

You want agents which understand the tone of your, uh, use case, the context, uh, the logic of the domain, and that's what you would want to use for making such decisions. And that's why we will articulate a domain specific gen AI platform that can deliver hyper-personalized outcomes while operating completely within the security perimeter of the enterprise. So with that, I would like to now walk you through the key product capabilities.

Uh, first and foremost is the autonomous data perception. The moment the data enters the platform, which is the metadata in most of the cases, uh, it could be like unstructured PDF data, or it could be tables, images, or CAD drawings. The platform is able to identify the semantic and logical connections across this structured and unstructured multi-model data.

It then uses this understanding to build this dynamic and continuously evolving knowledge graph. You can almost think of the knowledge graph as the living data foundation based on which all the other inferences going to happen. And this knowledge graph is evolving over time.

It's like the institutional memory, uh, where it just that it is machine readable queryable and uh, it's kept up to date with the latest information. So that's the first major capability of the platform. The second one is the agentic reasoning engine.

So there are hundreds of domain specific and task specific agents on the platform, which is, uh, like trained for specialized functions. But when you are this agent reasoning engine of the platform, when it gets a complex enterprise mission, it is able to understand it in its full context. Um, meaning starting from the objective of the mission, how does that domain work?

How is the logic of the domain, what is the constraints in that particular domain? And also the data sources. And then it breaks down this complex mission into submissions.

And it's almost like how a team of real experts would do. And once these submissions are identified, it uses its intelligence to find the most suitable domain specific or task specific agent, which can go and execute the submission. And all of this is happening autonomously.

Without any manual intervention or with any rule configurations, none of that is needed. So a complex mission, which used to take several days, multiple teams working together can now be executed in the matter of minutes accurately with traceability so that it's really beneficial to the enterprises. So that's kind of the real power of that intelligence of that platform, uh, which is making all of this possible.

So, question real quick, um, on the, the knowledge graph stuff, especially dealing with all the live data, um, are you having to do any fine tuning or any, any, um, updates on the model itself to require recompile and rebuild and deploy? Or is that handled live? No, uh uh, so basically the knowledge graph.

So we have our own domain specific models, which is under the hood. Okay? There are hundreds of, I mean, there are multiple models which are powering the platform, right?

So when the ingestion of the data or metadata is happening, these models have the context to understand the data and build all of these connections. So the model training does not happen at that point. It is more understanding the data breaking, finding all these semantic connections.

Building that knowledge graph is what happens live during the ingestion process. I, I guess the question may, if I may paraphrase, is that if a knowledge graph is changing substantively, how does that affect the domain mission agents and those sorts of things? How are they, uh, updated to understand the new knowledge?

Yeah, so each time a user interaction happens, right? I mean on the platform it goes back into the knowledge graph and the knowledge graphs gets updated. So for example, let's say that a mission was broken down into five submissions and the user can now interact and say, Hey, I didn't like this way.

You have broken down it into sub submissions. I would have added another step or another submission to it. Now, this goes back into the knowledge graph as, uh, the personalization aspect of like, hey, for this enterprise, when this complex mission was given, they wanted six steps instead of five steps that goes back into the knowledge grabs.

The next time somebody is trying to execute a similar kind of mission, it knows that, hey, I need to break it down into six steps instead of five steps. That, that's why the knowledge Graph. So knowledge graph becomes sort of a ancillary context.

Yes. So Keith Townsend from the advisor bench, how do you stop, uh, people bad actors from poisoning the knowledge graph? You mean within the enterprise?

Within The enterprise? So let's say that, uh, you know, we have two competing divisions. 'cause no, no company has competing division.

The, uh, and I am putting in a request that will, uh, basically either handicap or get bid results for, for my competing division leader in their organization. Yeah, I, I think that is one of the unique cases why our platform is so powerful is because of the auditability and traceability it provides. So let's say that there is a competing division who went and made an update.

It's clearly visible that hey, this person or this particular team made an update to the knowledge graph, which is what is making all of these changes. So you wouldn't want to go and put your safety out There. Can you for a sec?

Sounds like an HR problem. So now going on to the hyper personalized outcomes. Now when I want to define this, I would like to, uh, take this whole idea of there is no spoon.

So for multiple decades we have all been conditioned to think that applications are rigid, the workflows, the screens, these are all fixed and the user needs to adapt to it. But with this autonomous agents and domain specific intelligence, this whole aspect of traditional applications is almost declining. I mean, it's, it's, it doesn't become relevant anymore.

Now, in this new world, the tools would not, I mean the user does not need to go to the tools. It is the other way around where the intelligence is coming back to the user and the workflows will not be predefined, but it needs to self assemble around the mission that the user want to accomplish. Uh, so it's almost like the iPhone moment for enterprise software where intelligence is replacing interfaces and context is replacing the configuration.

Uh, so that's super important and that's where we focus ex uh, very extensively on hyper-personalized outcome. The platform can not just understand the enterprise mission, but it can also understand you as a user and what task you want to accomplish on the platform because each user within an enterprise might operate very differently. They might have very different needs, priorities, workflows.

There might be one user who want to do an analysis of all financial information. The other user might come there for detecting components in a single line diagram, or they might be coming there for doing some compliance analysis. The platform is able to adapt to that user need and provide them with an experience which is very personalized for them.

And it does that by dynamically adapting the reasoning depth, the interfaces, the tone and format of the output, the kind of recommended next actions. Everything gets personalized for that particular user. So it's almost like a context aware, user aware experience that is getting delivered and hyper-personalized outcomes.

You should not think of it as giving users with more number of apps. It is almost like giving them an intelligence layer that they can interact with that is adaptable and it is continuously learning. And in that context, uh, something which Renato would be demoing later is also the aspect about digital twin.

So you as a user can go into the platform and create your own digital twin. It's almost like a representation of how you think, how you make decisions, uh, how you prioritize and how you would like to consume information. The platform's intelligence learns from this digital twin, and so the output becomes more and more adaptive to how you would want to see it based on your expertise, your style, the output gets adaptive to that.

And so that's kind of one of the key capabilities of the platform. So going forward, like all of these capabilities, as we were saying, is powered by a portfolio of domain specific and task specific models. Um, so we have domain specific models that span a very, a variety of industries.

So we have models that span manufacturing, aerospace, supply chain, financial services, semiconductor or telco. And these might look very disparate, but there are, when a domain specific model is built, there are many task specific models under the hood, which is also powering the model. And these tasks, like for example, the example of aerodynamics, there might be a task within that which is common across these different industries.

And we could leverage that when we are building these domain specific models on top of it. In addition to that, we also have like task specific models that cut across domains. Um, like the time series analysis or the table understanding or chart understanding the text to sql.

All of these are like tasks which are very common across these uh, domains. And we do not go and train a domain specific model just for the sake of it. We actually do it for high value use cases where the general purpose models are not able to provide the accuracy or the precision that is needed.

So for example, uh, if you take the case of semiconductor industry, so we have a very log, uh, DSM that we have trained and this integrates the semantics and structure of chip design language into its reasoning layer. So the output that is provided by this particular VeriLock, DSM is two times better than, uh, what the state of the art models can provide, especially in the case of veri log specific tasks. So it's kind of, we find these tasks which are very complex, which are very specific to the domain, and that's where we go get the data and train that domain specific model.

Hi, Carl Fugate. I'm curious if you have or if you're planning to, uh, build any domain specific models around healthcare in the, in the near future? No, at least we do not have it in the current plan.

I mean, when we say that we do not have it, we mean when you say healthcare is a very broad domain, there are some processes within the healthcare industry, let's say there are many manufacturing processes which could benefit from some of our supply chain models that we have. But at least at this point, we do not want to get into the core of healthcare Big enough. I'm Arun Sub and I'm the founder and CEO of Articulate.

Um, while that is exactly accurate, the reason why we go into any of these domains is because we actually have expertise in all of them. And we strongly believe that you need to have domain experts before you can go build models. It's not just computer science people building these models.

It's very important. And the reason why parva, they is saying we currently don't have any plans to get into healthcare from a clinician standpoint, from healthcare, from a a clinical research standpoint, is we don't have any in-house expertise in the domain Might be able to help you a little bit. Perfect.

And however, the example she used was very relevant because if you look at manufacturing process, industry process in say, oil and gas process in chemical industries are remarkably similar to process in pharmaceuticals. So us going and talking to a Merck or Pfizer about their manufacturing processes, absolutely. And for that, a model that understands pharmaceuticals in addition to manufacturing is required.

However, us going into drug discovery is not a domain that we know and we are, I mean, one of the traits of the company is we are humble gangsters, humility has to come from the pers perspective of what we don't know and acknowledge that of course if we have partners who, uh, come in with that particular expertise, we'll certainly walk into it. For example, cybersecurity was one such use case where it was a partner who came in, they're a cybersecurity expert. We actually knew systems understanding we could mix that together.

I'd love to more love to love, I would love to know more about what, you know, bringing experts to bear to train these models is good. But you also need to have some amount of data sets behind powering behind this. Where are you sourcing the data for these pieces?

Perfect. So we, um, so we didn't touch upon partnerships. So one of the main, uh, efforts we do is we go after and build partnerships across multiple domains.

For example, with, uh, energy, it is EPRI, electric Power Research Institute. They are the institute that owns everything about energy production and transmission. Not just the data, but also the know-how.

Right. The partnership we have with them is public. Such partnerships also exist in mechanical engineering, in aerospace.

I can't publicly name them quite yet, but that's really where we are sourcing the data sets from. Right? And we also are sourcing the experts would attest whether these models are doing the right things or not.

And I assume these partners would wanna be paid as their data is used in inference. So that's, uh, uh, the beauty of this particular engagement because it is a win-win situation. 'cause they're not technology providers, they're data and knowledge providers.

We are the technology partner who's bringing them a brand new revenue source that they don't have access to quite yet. And, and we strongly believe in by the community, for the community. So that's something that we do quite well.

And the examples I used were from industries that we all came from, we grew up in that industry. We have a, a natural connection to it. That's really how we are going into it.

Healthcare, uh, very important field, however, extremely fragmented. Right. Especially here.

And, uh, extracting value outta that is very, very hard. Mm-hmm. I didn't wanna steal, uh, r the standard, but I had to No, that's perfect.

That's exactly what I wanted to understand was like that relationship. So just to Clarify, so like a telco model there, there's some sort of telco partner that you worked with in order to get there. Yes.

You had some expertise. Yes. They provided the data.

You created the miles and the systems associated with, and now this becomes a profit stream for that telco. Absolutely. In addition to whatever else they were doing, like selling telephones or whatever.

Absolutely. This in the, so it becomes not only a profit stream, it becomes a, uh, a vehicle to monetize their information that they never had before. And it's not a one time thing, it's a repeating thing.

Yeah. Right. If you want to think about us as, um, an exchange that takes your information and magnifies value for you, not just for us, that's really what we would like to, And those models, would you say they basically apply globally or are they region Specific?

All of these models are global, right? So what models that are not there on the list are models that we have, for example, for Japan that understand Japanese. Uh, Korean is another example where one of our customers, we built a model, we deployed it, it's an energy model for, uh, a refinery in Korea.

And we had two groups. One in Seoul, there's a business group and there's a group, uh, that was in the refinery that was talking to us on the phone. And we were in Seoul.

And everybody was happy with the answers. The answers were accurate. The people who were in the room, the business people were very happy, but I could sense that the folks on the phone were not as happy as the people in the room asked What, what gives the response is your answers are accurate, but they're rude.

I'm like, I would have no d no means of knowing that. And so that actually triggered us to go hire linguists. So we actually work with linguists in multiple areas and not just say the answers are accurate, but they're also culturally aligned.

Right. And, uh, in many cultures, how you say something is just as important as what you're saying. Right?

And uh, like those kinds of things we do quite a bit. I I have heard that the, um, the translation, um, models and services out there have been getting better at picking up dialect over the past year. Mm-hmm.

Is, is that the Case? It depends on the language. Okay.

Uh, but they've gotten really, really good. Yeah. Um, I can tell you from what I can tell you about Indian languages, they gotten really good.

They still can't, they can distinguish dialects between different kinds of languages. They can't distinguish dialects in the same language, for example, in the same language across different states. Mm-hmm.

They speak differently, not quite, but dialects across different language is very, very good. Yeah. Yeah.

And, uh, in addition to that, like on that context of across geographies, right? I mean there might be some, uh, context which is very specific to a country, some regulations to get that. What we do is that we take a global model and then train it for that particular region to make it very specific to pick up some of those regulations which are very specific to that, um, region.

Uh, And I was just, I was just thinking for instance, like guide is the consulting to, um, BC Hydro, which is the a you know, they do the generation transmission distribution in, in British Columbia. And I'm just wondering whether there's any, you know, opportunity to be able to differentiate between what they do as opposed to what like American companies might do in that Particular Yeah, definitely. And that new answers gets picked up when we do, like, there is a general purpose.

I mean, when I say general purpose, a general model which is applicable across geographies, and then you do the next level of training for a particular geography itself, uh, to pick up some of those nuances. Thank you. So, uh, like all of these, like whatever I showed so far is just a tip of the iceberg.

There is a lot more models which are there on the platform. Uh, and what we have done is that, um, like we have taken two of our, uh, domain specific agents and put it out there on the AWS marketplace for enterprises globally to use. Uh, and that's again, like just two, we will, we are planning to do more of such domain specific agents to be made publicly available so enterprises can go try it out without even coming and using the complete platform itself.

Um, so these two agents, the first one is the LLM IQ agent. And one of the challenges that enterprises really struggle with, with all these models coming out is that they do not know which model to use for which use case. And most of them do that in a very manual fashion where they write prompts, they run tests, they build these scripts, and they have to get the engineering teams involved.

And it takes weeks for them to do that. And that's where the L-L-M-I-Q agent comes in because it can do all of this for the enterprises, uh, compare models like across open source and closed source and provide all of this in a real time. Um, so it, it can evaluate in almost like 25 plus live, uh, scenarios and give the enterprises like inline evaluation of, okay, for this particular use case, this is the best model that you could use.

And one of the top use cases for this agent is that you can use it for prompt routing. So if you know that, hey, this is the use case, it can route it to the best, uh, model, and that can save a lot of cost and accuracy. Improvements can also be driven through that.

And the second agent is the network topology agent. And what this agent does is that it actually takes raw log, uh, network logs and topology diagrams and converts that into the digital network of the Overall. Just to be clear, these are free.

No. AWS marketplace, It's not free. I mean, you, it's very minimally priced, so you have to price per API call.

Um, but it's like, why not, not, not 6 cents per API call Make white recommendation. I think your table model needs to be up there as, as one of the next ones to go up there. 'cause if you're gonna, you know, a wedge sort of solution, every enterprise and consultancy in the world has a gazillion spreadsheets.

Yeah. So you mean every enterprise has a structured data problem. So whole thing like that, Just, sorry, I'm making sure I understand.

This was built with articulate mm-hmm. Yes. And you're giving two examples of what the platform can do in practical use cases.

So the actual agents themselves are using the underlying platform platform Yes. Platform of AWS to call, uh, cloud, uh, clock, Gemini and GPT and their example, their No, I mean, at least both of these agents, they run on our platform. It is available as agents on AWS marketplace.

You can go and subscribe to it. So Instead of me needing to spin up the, uh, the resources like my own bedrock and my own VPC, et cetera, you're, I'm just another tenant on your platform. Yes, yes.

Okay. Got, Yeah. So this, uh, particular network topology agent, it actually understands the devices in the network, the connections, the links, and then it is able to also find any changes or, uh, like detect anomaly.

So it actually makes the overall troubleshooting process very easy for the network engineers. So instead of manually analyzing all of these different sources, they can go and ask this agent, Hey, what changed, uh, when I made this particular switch upgrade, which devices got impacted? And this agent is able to provide that response back to you.

So that's how it can actually impact the real life scenario. So these were like two agents, which is out there for any public to go and access. But we have been in production with this overall agent of agent architecture for almost more than two years now.

And I just wanted to highlight two example, uh, of like enterprises where we are actually making mission critical decisions. The first one is, uh, one of the largest semiconductor manufacturers. And within their company, the mission that they wanted us to handle was to make the overall root cause analysis a much faster process.

And the challenge that they were facing is that their data was distributed across different systems in different formats and even their experts. It took a lot of time for them to comprehend all of these logs, network sig, the signal, uh, like faulty signals and the process parameters. They have to process all of this, find the root cause, then come up with recommendations.

So this took several days for them to do that. And how the platform was able to help them is that once it got in, it was able to take all of the siloed enterprise, uh, data, bring it together into a schema aware knowledge graph. And then the specialist agents, which are the domain specific agents, they were able to do a diagnostic reasoning across these logs and signals and process parameters and able to identify the root causes and provide recommendations based on that.

Uh, and that actually made this whole process much faster, which means that like, which used to take days now takes hours for these experts to, uh, process and do actions over it. So that is one of these applications. And the second one is the, uh, example of a large mechanical engineering company.

And for them it was, uh, kind of a different use case where they had a lot of CAD drawings as well as electrical schematics. And their aspect was that they needed to identify the components in these, uh, different CAD drawings. And they wanted to find missing components.

They wanted to detect anomalies. And all of this was a very manual, slow process and was limited by the human throughput. And that's what they, they wanted us to go in and help them to make it faster, but not compromising on the accuracy aspect.

So we have our own vision intelligence agent, which was able to do this. It was able to identify the components, find the missing components, all of this with 93% plus detection accuracy, and also give, uh, like once it detects an anomaly, it also gives recommendations on what the next steps are. And that actually helped make the con uh, validation more context aware and faster inspection cycle.

And the other key benefit both of these use cases got was that it was all very auditable and traceable. So if, if every decision that an agent makes, they can go back, audit it, see why it was made, what was the logic behind it, and if they want to correct it, it is very easy to correct it. Versus a human decision might not be that easy to audit and trace.

So that was the other benefit that was provided by this and all of these things that we discussed. Right? I mean, it is also, um, it actually brings us back to thinking that the whole concept which used to exist was like, Hey, do I need to build or buy, uh, some software to do some things?

That notion itself is actually going away today with all of these autonomous agents and the domain specific intelligence, it becomes, the question becomes more about should I build slow versus build fast? If you want to build fast, you need to use all of these agents, but otherwise you could do the traditional way of building, which is making it slower for you. So that's the whole notion here, or the transform may shift that we are seeing in the industry.

So, you know, customer onboarding, I'm a a telco, you had a telco solution out there. Yes. Uh, and I want to start to use your solution.

Um, I just go to your website and I sign up and I give you a billion ballot dollars and you go start working for me. Or, or is it an API call based costing or I, I, you know, pricing is part of this, but the onboarding is also the issue. 'cause obviously my telco is gonna be different than perhaps a half a dozen telcos that you've used in the past or done in the past.

And so there's some specific domain vertical act information that's important as well as obviously the vertical general common information. Let, let me, uh, help here. So, um, the way to consume the product, the ideal way to consume the product for, for example, a large telco is really an enterprise software subscription because that is designed to make sure your total cost of ownership over the long period of time is as low as possible.

However, the same large organizations have moved to a place today where instead of consuming large enterprise software kinds of engagements, they want to consume something that is quick, do the tests as they go in and go consume. So we, at the other end of the spectrum, you can also consume just agents for which the consumption cost is like milli pennies. Right.

However, it depends on what kind of agent you're talking about. Yeah. Right.

If you're running a full digital twin, that could be a few hundred dollars to actually run per call. But it's not the the significant enterprise software cost that comes with it without compromising security auditability, any of those things. Right.

I I think this whole area opens up a whole new, um, model of utilizing software development for a company. Yes. Um, because we, we've always had this notion that, you know, to build an application, we, we have to focus an entire team on it, go through the whole thing.

And even if it's a small amount of work, um, that's needed in a later time, we still have to live with it. Yes. And if you, this is a notion of if, if you have a quick throwaway product that you can spin up for two bucks but never have to worry about ever again, is it better than going and buying the enterprise tool or whatever that has all the features you don't care about.

And so it really flexes that build versus buy discussion right now on what you should do inside an enterprise. And, And it's also using diff So for example, the enterprise platform has all the capabilities, but you're not going to use all of them on day one. So you start using whatever you want to use.

And as long as that bite sized effort that you're using is monetizable on both sides and you have a return on investment, you should be able to do that. The Knowledge graph Yes. Prospect, which is, uh, data ingestion and that sort of stuff that's, uh, yet another API call kind of thing.

Yeah, absolutely. So what's interesting, this isn't necessarily a technology discussion, which is really, really cool. This is, uh, this is a discussion that you're having with other business leaders who are trying to achieve specific outcomes and ai it just happens to be the method to achieve the outcome.

We had this conversation yesterday with another presenter, but what I'm interested to know is where's the gap or how do you feel the gap between, I don't, it doesn't sound like it is the entry point for your conversations. No, no. So how do you feel that that gap between the business conversation that your lead team has had and your experts have had with the technology conversation has to have?

Because these are enterprise license agreements are not something that business leaders are gonna be a, what? I don't know. I don't understand how to buy this.

In, in interestingly, every single one of our enterprise customers, the decision maker is the business leader, right? So that's number one. You rightly identify that.

But also today's world is that the technology team has not been sitting idle. They've already done 60, 70, 80% of the work. And very rarely we have to explain the bottlenecks they're gonna hit, they've already hit the bottlenecks so they exactly know what gap we are actually filling.

It's no longer a question of are you coming in to replace me? It's about question of, okay, I need to go faster. And this is really an acceleration question.

Right. And the starting point, if it's an IT conversation, that really is not a, uh, a fast parts to converse. This gets back to what I'm seeing that we discussed offline more was, you know, these are the types of tools we're gonna see coming in as, you know, expert led opinions on these are the tools that I want to use, these are the tools that I need to use.

And so they will drive those in. That's right. And it's not gonna just be it.

That's what's interesting here is you're gonna see your HR department come into it like, yeah, we need to load this thing we built and did. It does perfect. Yes.

Or whatever. And you're gonna have them come in with very pinpointed solutions. Yes.

Yes. Thank you so much for your time. Thank you.

Thanks a lot. Thank you. Thanks.

Thanks. Thank you.