---
title: "Full Platform Demo: Building Context for Your AI Agents"
url: "https://atlan.com/demos/full-platform-demo-building-context-for-your-ai-agents/"
description: "Most teams have data. What they're missing is the layer that makes AI trustworthy. The full 45-minute session, from enriching raw data assets to engineering a semantic model and watching an AI analyst answer business questions correctly."
duration: "PT44M15S"
video: "https://videos.ctfassets.net/nwa1c00rtgxb/2fKYOI1RgLpuLP4Yt6tB1C/3dda04b6361b4d88ea080bf448d5dc48/Full_Platform_Demo__Building_Context_for_Your_AI_Agents.mp4"
content_type: "video transcript"
---

# Full Platform Demo: Building Context for Your AI Agents

Transcript of the video at https://atlan.com/demos/full-platform-demo-building-context-for-your-ai-agents/

## 00:00 — Many agents, many versions of the truth

We've got a jam-packed agenda today. We're gonna be focused on all things context. So really thinking about how can you build out your enterprise context layer for AI and thinking about the agentic use cases that we can capture, whether that's talk to data, operational use cases, and really the power that context provides when it comes to building out these systems. So the first thing that we wanna talk about is really giving you some insights into what we hear from our customers on a day-to-day basis. Several folks come to us saying, "Hey, I know I'm gonna have dozens of platforms, hundreds of agents, whether that's Sierra, Writer, Google Agentspace, Snowflake Cortex, Genie with Databricks." But what's happening is that they're all speaking slightly different versions of the truth. Now, coming from the data world, this was always the case.

If you ask finance and sales, the revenue number, you get two different numbers. Now this is happening the same with these agentic systems, but at a much higher and compounding scale with AI. Now trust is easily lost, but hard to earn. And what we're finding is that when we think about performance of agents, it's all about a function of intelligence and context. Now intelligence, well, this is the model. This is GPT, this is Claude, this is an open source model. They're really interchangeable at the end of the day and becoming highly commoditized. You know, every week there's a new frontier model. It's giving you more and more capabilities. But what we're finding is that context, on the other hand, is where we're getting the much more increase in control in our performance and our productivity.

You can think about context, you know, in the scope of knowledge, skills, tools, you know, everything someone learns while on the job. And because of that, it's really becoming a massive influencer when it comes to the performance of your AI agents. Now, I think it's worth spending a few moments just kind of understanding how we break down context. Context is a loaded term. I just came from Snowflake Summit last week and every person that came to the booth had a different version of what they thought context was. Now, it's important to note that we view context not just as semantics. It's much more broad than that. So we think about it from this three buckets. You know, first, we've got knowledge.

You can think about this in terms of your entities, your data assets, your definitions, metrics, relationships. Then we think about expertise. Think procedure, playbooks, workflows. How do you actually action upon insights to get the right outcome from a business standpoint? And then lastly, norms. What's actually allowed? These are going to be your policies, your permissions, your guardrails. You know, if I'm in finance, there should be an expectation on what a metric means versus if I'm somebody in marketing. So all three of these together, knowledge, expertise, and norms, are how we view the actual underlying context layer that we're producing.

## 03:00 — The architecture: mining, foundation, activation

Now, this is very abstract. What we want to do is then break it down into how we're viewing the architecture. So on the left-hand side, the first thing that you want to do is think about your context mining. So this is very much aligned to getting information out of your systems of record, your systems of data, systems of knowledge, systems of work, and even runtime or operational systems. So in practice, this could be, say, this could be Snowflake and Power BI or Tableau could be documents from SharePoint or Confluence or runtime signals like dbt, Airflow, Spark that give me insights into the data pipeline, as well as even observability tools. All of these cohesively start to build out this context foundation that you're seeing in the middle of the screen.

Now, we see this breaks down into a couple different areas. First, being AI ready through a data knowledge graph. So we've got accelerators to help to get you up to speed on building out your context pipelines and your data elements. And then we're also going to build out semantics and ontology, so making sure we have that shared meaning, business logic, and relationships fully understood. Again, if I ask revenue, there should be an expectation on how we're calculating that. And then lastly, breaking these down into skills, we're seeing that the agent's architecture is kind of coalescing around skills for codifying workflows or business processes. We're going to talk a little bit about how we can enable that, but these three areas build out what we're calling is the context foundation.

And from there, you want to think about context almost as you would software. So in the same way that software development lifecycle is built to deploy production grade software applications, our context development lifecycle is built to produce production grade context for AI agents. So in the same way we want to think about build, test, review, approve, deploy, and learn, all of these are built into our platform and essentially for establishing the discipline around building out context for agents. Once we're happy with this notion of a context layer across the enterprise, it's all about activation, so here on the top right-hand side, we've got several methods of activation because we don't want to, you don't want to get pigeonholed into a single interface because that might become unusable in the future, so we want to be open and interoperable by nature. So a few of the interfaces that we're really focused on investing into are going to be MCP for natural language search, semantics, push and pull of context.

We also have APIs for more deterministic interactivity with your context. And even SQL can be run. So all of our context is replicated into a context lake.

## 06:00 — The compounding learning loop, and the three walls teams hit

So you can bring in an iceberg format, you can bring your own compute, and you can actually run SQL on top of your context at high performance. All of this then helps to build out what we call as a compounding learning loop. So once you deploy your agents into production, we want to establish a sense of traces and understanding of the model's reasoning. This serves a few purposes. Are we actually providing the right context at runtime? And secondly, how do we increase or improve the context over time? We want to avoid drift in underused or underutilized context across the enterprise. And then lastly, context governance and observability. We've got our background in governance and working on metadata. It's really a natural evolution as we're seeing this play out the same as you would within context.

You can almost think about these as building out your own data marks. You want to make sure they're governed, trusted, and usable. It's the same with their context layer. You want to make sure that the context you're providing to AI agents is trusted, usable, at a high quality, with the right versioning and approval workflows. The last piece before I jump into the actual demo is going to be thinking about the path to contextual intelligence, the path to building and deploying your AI agents. The first wall that we're seeing folks run into is what we're calling is context bootstrapping. It's really easy to build an agent on cursor or Claude in just a few minutes. It'll spin up, build a YAML file, build out what it thinks is the right context, and deploy.

Well, that's great, but when we want to build out a production-grade application, it takes much longer from what we're hearing from our customers. I've heard folks say that it's taking me several months to be able to build the right context for the right application, and that's really hard. That means that our time to value is slow, and our ability to deploy in a high velocity is a challenge. Now, we're seeing this is really the impact of maybe building out one to three agents, and then once you get past this initial hurdle, context lifecycle management and governance becomes a challenge. How do we present or prevent the overuse of certain contexts or govern what a metric or term actually is for the right repository? This becomes a challenge when we start thinking about middle scale, two to 30.

And then lastly, context, sprawl, and drift. Once you've gone live in production, how do you ensure that the context you're providing your agents is not giving you diminishing returns through sprawl and building out too much context for your agents? And then drift, are we not answering the right questions or having challenges in that sense? We're going to showcase how we actually handle traces or developing that feedback loop once we're actually in production. So let's go ahead and get into it, folks.

## 09:02 — Two analysts, one question: what context changes

We're going to spend the next, say, 20 or so minutes in the actual platform showcasing the context development lifecycle. If there's questions, please use our Q&A. We're happy to help facilitate that at the end. So jumping in, the first thing that I want to do is actually give you a side-by-side comparison of two agents and why enterprise context is important. So on the left-hand side, we've got an agent that was given just raw SQL access. So the use case that we're taking is a fictitious burger chain where you might have a franchise operator who owns multiple stores. And they're asking a very basic question, you know, why is my drive-thru time up this week? Now, why and how questions typically require additional nuance. It's not as easy as what questions, where it's inherent within a metric definition or calculation.

Why questions require, well, what time of year is it? Are there any marketing campaigns going on? Are there any issues with the stores? You know, maybe there's a sporting event in town and we're over capacity when it comes to serving out food. These are all the considerations to have when providing an answer. So when I actually fire off the question to two separate analysts, what we see on the left-hand side is almost that of an entry-level data analyst. Somebody who doesn't really know too much about the business, but what the first thing that they start doing is simply querying tables. And they go directly to the raw tables and query, query, query to try to understand what's going on.

Well, the good thing is it's at least telling me when it's making assumptions. And then finally, it's not hallucinating and telling me, well, actually, I can't even confidently tell you why. So at least we're not losing trust, but we're not gaining value. And that's an important distinction. On the right-hand side is drastically different. We've given access to context at the persona, glossary, skill, and semantic model level. So before ever going directly to the data, the analyst first understands, well, who's asking the question, how many stores do they own? How do we calculate drive-through time?

What do I do if I need to diagnose an issue or check seasonality or perform what-if analysis? Everything that it takes to do the job is loaded up front using our context. And finally, the agent then goes and queries the data mart, which contains the right answer. So a few things that we're seeing is that by providing this structured context up front, we're gaining a much more accurate answer. We're also reducing tokens, token use, and having higher token efficiency because we're not having to go query, query, query. Models are very good at reasoning and very happy to run tool calls.

## 12:03 — Context mining: connectors, skills, and knowledge folders

But when we provide it the right context up front, those additional tool calls do not have to happen because we're giving it the right guardrails or the right map to get to the outcome or the answer. So this is a bit of the how and how we enable agents and AI systems through our context. What we then want to talk through is about how do we get there? Well, the first thing that we want to think about is really around context mining. When we think about that architecture diagram I showed earlier, the first thing that we do is start thinking about gaining context from your system of records, systems of data, systems of knowledge, and so forth. So we've got over 100 connectors already built in to platforms like Snowflake, Databricks, BigQuery, Tableau, Power BI, Airflow, Spark, data quality tools, you name it. All of these provide really rich detail on how to interpret the business.

Secondly, we've also introduced the notion of uploading skills. We're seeing skills becoming a widely adopted paradigm for codifying business process or workflows. So if you've got skills already defined, perfect. We can go ahead and upload those into our platform to be centrally cataloged with all the other data elements. Otherwise, I'll showcase in just a few how we can actually help to generate skills. And then secondly, for folks that haven't seen Atlan in a while, we're also introducing this notion of knowledge folders and unstructured data. I'll show what that looks like in a bit and how we translate that to ontologies and metrics. But what I will highlight is that we don't want to be a catalog for all of your unstructured data. What we do want to do is become an ingestion point for your usable business processes, standard operating procedures, and so forth.

In the same way that you've got bronze, silver, and gold data, you probably also have bronze, silver, and gold unstructured data sets. SharePoint and Google Drive, well, that's just your data lake for unstructured data sets. But you probably have business certified policies and SOPs. Those are the ones that you want to upload into our platform to gain insights out of. Now, what does this build? This effectively is going to build out your data graph. So because we're going to have insights into your data transformations, your data pipelines, we're going to be able to showcase how data is being moved throughout the business and also being leveraged.

So here is a perspective, a data pipeline within Snowflake. The way in which we do this is through query mining. So I can actually expand this on the right-hand sidebar. What we're going to do is look at all the transformations that are being executed, whether that's through dbt, pushdown, stored procedures, you name it, we'll have access to it. We're going to parse these for your table-to-table as well as column-level lineage. Now, this is massively important to understand, again, how is the business truly architected when it comes to your data? This isn't just siloed to, say, your data platforms within your analytics warehouse or data lake, but also downstream to the BI level.

## 15:13 — Reverse-engineering the documentation that was never written

So here I can see we've got a data source within Tableau, but this could be Power BI, Sigma, or so on, or so forth. Any other platform is going to be supported. We connect into those platforms using their metadata APIs, and we've got custom connectors to extract the right context. I'll give you a little bit of hints of why this is important. What we're seeing is that your metrics are inherently defined within the BI. Think about your semantics. So what we want to do is use this as a starting point to reverse engineer some definitions, and we've got some accelerators on how to do that. So directly connecting into these platforms only gets you so far. Now, what might be missing?

That could be, say, descriptions on the table, descriptions on the actual columns, readmes, how to use the data sets. These are inherently lost or lacking documentation. Now, in the old world, data catalogs were used and set up to solve this problem, but the human in-the-loop element prevented value from being reached. So our focus over the last year has been all about how do we automate the context generation across our data pipelines. A lot of the documentation is already operationally there. It's about reverse engineering and reciting what actually that documentation is. So we've introduced the notion of context agents across our customer base.

And what we're seeing is by running a few cohorts, we're getting into the scale of millions of documentation updates in just a few short weeks, whereas in the prior year, we were just a few hundred thousand updates to our metadata. So massive acceleration when it comes to bootstrapping your context. Now, a way in which that works is that you define a collection of data assets. You don't necessarily need to boil the ocean here. Typically speaking, if you've got a gold layer that's already curated and ready for analytics and insights, it's probably a good starting point. But if you wanted to deploy this holistically, that's fully up to you and available. Now, to show you an example, let's say that I want to focus on my worldwide assets within my data platform, Snowflake and Tableau.

Now, once you're in a collection, you can then deploy the agent on a few different areas. Descriptions, readmes, and SQL intelligence. Descriptions allow you to define the scope. And then the way it works is that we want to look at existing context. Think schema and column names. Upstream lineage, looking at the actual pipeline. Perhaps you're aliasing. You're already adding in descriptions. Query history. How is the business actually asking questions of the data?

## 18:13 — Descriptions, intelligence, and the automated FAQ

And glossary terms, have we actually established any underlying metrics, definitions, or terms that have been associated? We're taking all of these areas and reverse engineering into usable context. So to showcase what this actually looks like in practice, if I was to jump back into that same table, I'm now going to see that we've got descriptions that have been updated via AI, as well as what we're calling is intelligence. Now, intelligence is actually really important. Simplistically, I call this an automated FAQ, frequently asked questions. So what we're doing is looking at the actual query that a user's running, whether that's a select statement or so on, and we're translating that into a natural language question. Because all a structured query is doing is trying to understand a business term, a metric, or gain an insight.

So for the human coming to this table, I now know the questions that my colleagues are asking. For an agent coming to this table, I now have a sense of the metrics that are being derived from this data set. But also, these become your simulations or your evaluation sets when it comes to building out your context in the future. So again, thinking about acceleration in all fronts. We also want to gain insights, such as joins, you know, how can I connect data sets, filters, how do I actually produce an insight, and relationships. You know, maybe there's foreign keys that are associated with these tables. All of this becomes usable information for both human and agents alike.

Now, this is the, I'd say, the business lens, right? Or, I'm sorry, the data lens to these data pipelines. We also want to augment this with your systems of knowledge. So I hinted at this a little bit earlier. But we're going to have these items called knowledge folders, where you can simply upload your usable unstructured documents. You know, whether those are PDFs, PPT, CSV, and so forth. So we want to gain a usable context from your underlying unstructured assets. Now, you can govern these as you would with anything else. You can establish owners, purposes, or descriptions of these folders.

And then the actual PDF itself is going to have access. So we'll be able to see things like the underlying document, and even lineage, out to skills. We'll talk a little bit about skills generation in the future. But the important piece is that we don't want to just load an entire unstructured document into the context window for an agent. That's not usable, right? You're going to have far too many tokens used, and the agent might run into additional drift or hallucinations, because it's just too much information. That's not readily usable.

## 21:18 — From PDF to ontology: building the business graph

But what we want to do is take that PDF and translate that into usable business terms, ontologies, and maps on the right-hand side. So an example of this is that embedded within this particular PDF is this notion of subscription and refund. Now, if I simply click on the subscription term, it's going to bring me to our ontology, our business graph. So subscription is a standalone asset where you can have an AI-generated summary, any usable custom metadata properties that we want to add in, as well as the map, the association, the graph related. So for example, this subscription entity, I was going to zoom in a little bit, has four properties, last charge status, double charge flag, and so forth.

It also has three metrics, failed charge count, lifetime charge count, and subscription monthly recurring revenue. So it's important that we establish this knowledge graph, this business graph, to understand concepts, entities, and relationships. Once we get into agents, we're going to condense this down into something that's usable, like a skill or bounded context. But having this holistic view of the relationships within the business gives us a sense into how workflows and business processes are accomplished and their relationships to metrics. A final piece related to context bootstrapping that I'll cover off is going back to our context agents.

You're going to be able to deploy these from a high level. So you'll get a sense of how are we from an AI-ready context layer, by seeing the number of descriptions by agents, by humans, and how we want to translate this, or we want to load the by agent side of the house. You're going to be able to deploy these across descriptions, readmes, SQL intelligence, and get a full holistic view on the reporting sense. So the idea or the mental model to keep here is that it's not the human in the loop for all context generation. That's just not sustainable, not scalable.

It's the human on the loop. So you want to deploy the agent, trust that the AI is producing the right context, and allow you to scale out and focus on your objectives and outcomes. We're going to talk a little bit about those outcomes in just a few moments. Now, taking a step back, going back to my architecture, we've talked a lot about context mining and building out the context foundations. Now, the next important piece is going to be the context development lifecycle for building out your agents.

## 24:19 — Context Engineering Studio: building a context repository

The way in which we've done that is if I jump back into the Atlan platform, we've got Context Engineering Studio, where you can think about this as almost a context engineering workbench. How do we think about the use case or the outcome that we're after and gain the right context that's fit for purpose? So a use case could be maybe customer support, customer 360, financial analysis, marketing analysis, revenue, so forth. Each of those requires its own bounded notion of what context is and how the enterprise interprets or produces functions on top. Now, to give you a quick glimpse into what that looks like, I'm going to kick off a context repository build and showcase our workflow in action.

So you simply give the point of view of what you want. So in this case, I said, build me a context repository for our McContext burger chain. I want the agent to explain why operational metrics like drive-through time, order throughput, store performance shift, week-to-week. So you give it an area to focus on. Now, because we have a context layer in the back end, inclusive of your data, business graph, metrics definitions, and so forth, we're going to search across those data elements. Tableau, Snowflake, Databricks, Power BI, you name it. We're also going to load in what we consider gold layer assets.

We want to exclude the noise. Perhaps you've got a raw landing zone, bronze, silver, gold. We don't want to just take everything that could meet the criteria. We want to take the most usable data sets for this outcome. We're also looking to other data assets. Maybe you've got some information in SAP, upstream, and Postgres, or Oracle, or Salesforce. Each of these are rich repositories for context. Now, because we're using an LLM on the back, we're consistently reasoning over the results that are being returned and allowing you to look at the assets, view, refine, and continue. So this refinement is the human on the loop. Again, I'm not having to comb hand by hand and try to find the relevant assets.

I'm being provided what we believe are the right data elements in context for this particular purpose and allowing me to have the last call or the last certification. It's going to continue to look across data products as well as existing context repositories because the last thing we need is to have additional sprawl. Now, what we're seeing is that time to value for AI agents is being massively compressed. So if you're somebody who's building out Snowflake, Cortex, Databricks Genie, or your own talk-to-data architecture, you'll probably find that it's taking a long time to actually provide the right context for the right outcome. Think about it in terms of providing a map to a non-deterministic system.

## 27:32 — Inside a repository: semantic models and skills

We should have an expected outcome, but the map to get there can vary in a variety of different manners, but it's important for us to still get to that trusted outcome. Now, once it's happy with the notion of the context required for this, it's going to build out on the right-hand repository of usable context. Now, this takes a few moments and would require some follow-ups, so I'm actually going to jump into an existing repository to showcase what that looks like. So this builds out your file structure, your contents, embedded into a repository. Repository, think about in the lens of a data product, if you're familiar with that methodology, or a use case, a purpose of context. At a high level, it's going to build out your semantic models.

So it's going to take that information that we've mined from your data platform, such as name of the table, database schema, synonyms, descriptions, dimensions, filters, and so forth. Everything that we've been able to mine from that platform is translated into a semantic model. And we'll extract several of those that are going to be relevant to the outcome. Again, thinking back to the notion of knowledge, expertise, and norms, this would be your knowledge. Expertise then becomes your skills. How do you handle situations such as daily sales trends, drive-through timing, and so forth? You want to embed interpretation in how a user would gain insights.

So for those that aren't aware of what skills are, we're seeing that Anthropic pioneered this, and that it's being largely used in the AI agent architecture and ecosystem as a way to pre-compile your context, to tell the agent exactly how to do something. They give your workflows, your business processes, your standard operating procedures. So those unstructured documents that I showed you a little bit earlier, we're going to translate those into a usable skill that's condensing not everything, but just what the agent needs to do. This could be inclusive of SQL, seasonality dimensions, and so forth. Now, multiple skills can be embedded because an agent might have multiple purposes in terms of workflows that it needs to execute upon.

So this allows the model, the harness, to reason over what are the most usable skills, and then the skill actually dictates or provides the map for how the agent needs to act. Now, because we want to embed this in terms of a lifecycle, context CDLC, you can have your repository summary. So again, think about your purpose, linked assets, semantic definitions, model, and skills at a high level, as well as who owns this and is it verified for use. We're also going to have versioning that's applied.

## 30:34 — Versioning, simulations, and evals

So as we're making iterations to the repository, we'll be able to push back updates and then dictate whether something is active in a draft status or even archived. So the lifecycle is important here because it's not just a one-time build, but an ongoing iteration. And in some cases, we'll need to decommission our context because there's a better way to define that. And that's okay, but what we want to do is give a sense of how that lifecycle can be handled within our platform. Once you've got your context built out at the repository level, simulations and evals are your next step. So think about questions. You know, what's a question that we ask of an agent and what's the SQL that it might generate? So for something like a talk to data analyst where we're trying to query Snowflake or Databricks, you might already have an expectation on what that question in SQL might be.

If I was to look back, again, this is that usage and intelligence that we're mining. This is the acceleration that we can provide for building out your evals. Now, what we want to do is showcase what is the expectation versus the generated. I mean, this is a very simple unit test or reconciliation. It's no different than if you were developing software. We don't care necessarily if the expected versus the generated SQL is exactly the same from a syntactic standpoint. What we do care is that the query result is the same. So this allows you a sense of expectations and actuals and giving those guardrails to the agent. Now, this isn't in the world of manually annotating queries, but providing the right context.

So let's say that the expectation versus the actual is providing differing results 70% of the time. This likely means that we're not providing the right context. Maybe there's something inherently wrong in the semantics or the metrics definition that we're providing or the description of a particular field or column. So what we want to establish is this feedback loop to take an inaccurate response and feed that back in to the actual contents of the repository. So we're always taking a context level mindset. It's never about hard coding or fixing queries in place, but how do we provide the right map to the agent?

Now, once you're happy with your simulations, let's go ahead and deploy. Now, we view context as your IP. What this means is that it's important that you decouple your context production from the data platform or from the compute or from where you're actually running your model. The reason that's important is because you need your context to be open and interoperable. You might have workloads that are more performant on Snowflake, whereas you might be having some operational workloads within Claude managed agents.

## 33:34 — Deploying context: MCP, and one-button ports

And that's okay. But what you don't want is that each of these agents are pulling from differing context. You want to pull from a centralized context layer. So our belief is that you centralize the context production and then you deploy or you port this context into your runtime. So we enable this through Atlan MCP. So any model provider, OpenAI, Claude, Gemini, you can run this within Cursor, VS Code, Copilot, and so forth. Anything that has a hook into MCP is compatible with our platform. Then we also have one button, Deploy, into Claude, Databricks, and Snowflake to make your lives easy.

Now let's say that we're building a Snowflake, a Cortex analyst or Cortex agent. What this will do is actually translate that repository into a semantic view that then Cortex can call upon. So again, this is allowing us to be agnostic of the platform, but push or port out to whichever platform or end user interface that you all want to define. That's the port piece, portability. The last piece, if we go back to our architecture, is this compounding learning loop. In the same way that software deployment or applications, you're never one and done, there's always ongoing requirements, updates, and deployment changes. It's the same for context.

So we want to bake in observability into this platform as well. So observability in the scope of traces. So we're seeing that the ecosystem is coalescing around open telemetry is one way to export traces. Many other platforms, Cortex, managed agents, and others also enable the ability to export an endpoint for traces. This effectively gives us a sense of how is the model reasoning over the request in the context, and what's a proposed edit that we can make. So this reduces the scope of sprawl and drift, because now we're consistently taking back actual production runtime use and relaying this back into context refinement. So when we think about that lifecycle, it's post the deploy is going to be learned, and this is how we can enable that.

And we're actually seeing that observability in traces is probably becoming the most important data to gain access to when it comes to agentic use cases, because this will give us a sense of how do we continuously refine, improve, and maintain that level of accuracy. So in summary, we walked across our entire platform, how we're thinking about AI agents, but most importantly, the context piece of the puzzle. We started off with context mining.

## 36:38 — Recap, and the first questions: how the feedback loop works

How do we gain insights from your underlying systems of record, systems of data, knowledge? Using that to build out our foundations of context, which is inclusive of data graphs, business graphs, semantics, ontologies, as well as skills. And then taking that centralized context and building a development lifecycle on top of that. How do we build the right context for the right outcome? And deploy that to any platform of our choice. Once we're in production, then the compounding learning loop comes into play. It's not about static deployment, but continuous improvement and iteration. And using something like traces and observability to build out recommendations is how we want to go ahead and accomplish that. So that was the demo for today.

What we wanted to do is just give you a sense of how we're accomplishing some of these use cases that we're seeing as agents and AI analysts are coming front and center for how folks are leveraging context within their environments. I'll go ahead and take a pause here. I'm going to quickly check to see if there's any questions in the chat. Okay. I see a question. How does the feedback loop work? Does it get the input from, say, Databricks? Yeah. So the idea is that we want to build in almost connections or integrations into whichever platform you execute your agent on top of. If you're building out sort of platform agnostic architecture, think LangGraph, other agent builders, typically speaking, you can enable open telemetry or you could provide a dedicated observability tool.

That's one way in which we're seeing customers do this. For all in data platforms like Databricks and Snowflake, we're seeing them starting to expose traces and observability. And what we want to do is write an integration into those platforms to ingest that metadata, that context into ours. And the idea is that we have in-house harness for agents that actually parse out all of these traces in a structured fashion and proposed edits. So a long way of saying, yes, our goal is to provide or extract traces from all platforms, dependent on how they're exposing those. I see another question.

How long does it take to build the context once you give it access to all these systems and how much human in the loop we need initially to build the context layer? Yeah. So we're seeing that folks are getting up and running in the span of days, if not weeks. So it's really the limiting factor is almost how quickly can you provide access to your platforms, provision a service account, and allow us to run our agents. So we've got customers that are able to, say, give us access to their Snowflake, Tableau, Power BI environments very quickly.

## 39:46 — Q&A: time to build, and where the context layer runs

And the first thing that we want to do is extract all of the information around your data assets. So again, that business, that data graph, data pipelines, usage and popularity, and so forth. That's all done on initial run. Once you have that in, as I was mentioning with our context agents, you then reverse engineer business usable insights, business context from those. Those are already built out as our own in-house harness for our context agent. So what you have to do is just deploy this selectively. So the actual generation of the context is very low lift from you all. The reason being is because once you get to the context generation piece within the repository, you're going to allow for simulations to handle any fallout.

So this is where you can actually ensure that the context you're providing is fit for purpose when it comes to building out your agents. I see a question. Where does the context layer sit in Customer Cloud or Atlan? Yeah, yeah, great question. So everything that you're seeing here on screen is basically a service through our SaaS product. So we're fully managed SaaS. We deploy a platform into GCP, Azure, AWS in the region of your choice. So everything is available as a platform. So you'll have full access.

If I was to look back at our architecture real quick, you'll have full access into retrieval via API, SQL, MCP. Et cetera. Now, if you wanted to then export those files from the repository into your runtime or into a GitHub, you absolutely can. So you can still house the individual context within your sort of your runtime environment, your harness. But the Atlan platform itself is going to be fully managed SaaS. How do you measure the accuracy of the context built by the agent? Yeah, that's a great question. So this goes back into our simulations. So simulations and observability.

Simulations allow you to build those guardrails into what the expectation is. So, for example, this was the franchise analyst, but let's say we're building out a sales analyst or financial analyst into a repository. You'd want to have questions and simulations that are relevant to that use case. Now, a way in which we're seeing folks do this is by reverse engineering what they might already have built, say, in Power BI as a semantic layer or even Tableau or dbt or others. So you probably already have these gold layer SQL statements predefined. If not, we will be mining those directly from the SQL you execute in your data platform.

## 42:46 — Q&A: measuring accuracy, and closing

So we can accelerate the creation of these simulations. But at the end of the day, simulations, evals, and traces are how you certify that you're providing the right bounded context for the agent. And if these are failing, we'll have recommendations for context improvement. You can actually have natural language conversation as well to produce the right level of context. Okay. I think that was all the questions that I can see here. The last thing that I'll have on screen is just going to be our QR code. So for folks that do want an additional deep dive demo, we're more than happy to showcase how our context layer can help with your specific use case by a follow-up demo.

We can talk again about how we're viewing the world when it comes to context. Again, thinking about knowledge, expertise, and norms. And how we can execute on a single use case for you all, get you up and running in production, and showcase that we can build a repeatable discipline to build out not just a single use case, but many for trusted, verified context. Well, I hope you all had learned a little bit about how we're viewing the world of context and how Atlan can help enable better, more trusted agents within your enterprise. Thanks for joining today.