---
title: "Inside Verizon's context architecture | Context Conference 2026"
url: "https://atlan.com/context-conference/verizon-context-architecture/"
description: "Architecture deep dive from Context Conference 2026 with Steven Huang. Watch the recording on demand."
keywords: "Context Conference, Context Conference 2026, session recording, context layer, Atlan"
---

**Inside Verizon's context architecture**: architecture deep dive from Context Conference 2026 (online, Oct 28, 2026), 20 min, in the [Context Conference recordings](https://atlan.com/context-conference/). On demand from Oct 29, 2026.

## About this session

Verizon's team are the earliest adopters of AI context platforms and the furthest along in building AI agents enterprise-wide. Walk through their architecture with the team that built it, from the first use case to the platform running today: what they built, bought, and standardized, and the decisions they'd redo.

## Chapters

- [0:00](https://atlan.com/context-conference/verizon-context-architecture/?t=0) One context platform instead of per-tool silos
- [2:33](https://atlan.com/context-conference/verizon-context-architecture/?t=153) Separate pipelines for documents and data assets
- [5:00](https://atlan.com/context-conference/verizon-context-architecture/?t=300) How SOP documents become agent playbooks
- [8:55](https://atlan.com/context-conference/verizon-context-architecture/?t=535) Agent playbooks still have no standard
- [10:51](https://atlan.com/context-conference/verizon-context-architecture/?t=651) Two context repositories, synced over PubSub
- [13:31](https://atlan.com/context-conference/verizon-context-architecture/?t=811) Ontologies first: don't boil the ocean
- [16:26](https://atlan.com/context-conference/verizon-context-architecture/?t=986) Why the platform never proxies data calls

## Speakers

- **Steven Huang**, The architect behind Verizon's Enterprise Context Platform, Verizon.

## Next steps

- [AI Context Platforms For Dummies](https://atlan.com/resources/ai-context-platforms-for-dummies/): A plain-English guide to why enterprise AI stalls without context, and what to know before you start.

## Up next

[The company brain for shared skills and ontologies](https://atlan.com/context-conference/company-brain/) / Deep dive.

## Transcript

[0:00] **Steven Huang:** My name is Steven Huang. I work for Verizon, and my topic today is about the architecture design of our context platform. So this is the vision. I want to start from here. So we intend to build an enterprise context platform in Verizon to connect to a variety of knowledge sources, either unstructured or structured sources, and then we curate them, enrich them, and deliver them to our agents. In Verizon today, we have classified our agents into three broad categories. Operational agents that handle business transactions and conduct, uh, proactive workflow orchestrations. And knowledge agents that answer the questions to our, uh, from our customers or employees. Um, and then the analytical agents that can generate instant business insights when a user can issue a query.

[1:18] So this is the vision, and you may ask: Why are we building this enterprise context platform? Here's the current situation. This is the problem statement. In Verizon today, we have many third-party agentic tools. Each of these tool actually has a agent studio and agent runtime. The agent studio manages the context. It actually connects to a variety of con- knowledge sources, then process them and locally and, and enable their runtime. If we allow this condition to continue, we're gonna have problems. Knowledge silos, no sharing, reuse of knowledge, no standards, and we're vendor locked in. If we decide to move away from any of one of these tools, we will lose lots of context objects we have curated for those projects residing in those tools.

[2:33] Now, how do we solve the problem? We're gonna build an enterprise context platform that will connect to the sources and then integrate with them, curate, enrich, reuse and share, and govern them, and we will deliver them to the agents. These context objects, as they're moving to the agent space, if it is a third-party agent environment, agents, the third-party system, then the agent studio will continue to refine the context window, implement tools, APIs, and test, simulate, deploy, and run those agents. And we also have homegrown agents as well. The enterprise context platform, we are gonna adopt context object store technology and knowledge graph store and technology, and we're gonna build context curation and delivery pipelines. As you can see from this picture here, to support operational and knowledge agents, we're gonna leverage the artifact and tool curation pipeline, which will go against the business documents, knowledge articles, along with the MCP tools and APIs.

[4:03] Now, to support analytical agents, we're gonna leverage the asset curation and delivery pipeline, which will focus on asset metadata, semantic models, reference data and query logs. The analytical agents is typically a third-party vendor solution. We do not encourage the homegrown analytical agents development, and we just simply build agents on top of this third-party tool, basically. So step three here, and we also want to migrate those context objects in those projects in the third-party tool and migrate them into the ECP so that we do not want to lose this context, and we want to reuse, reuse them across all kinds of agents. Okay, that's our solution. Now I wanna talk about the capability view. What are we building in our enterprise context platform?

[5:08] So on top, as I mentioned before, we have many third-party agentic applications, and we have also homegrown agents that sits on top of a variety of approved SDKs, agent SDKs and frameworks in Verizon. Now, they're all empowered by the core capability here. To support operational and knowledge agents in their context, the first thing we do is to curate the standard operating procedure document. This type of document typically contains business rules, processes, policies, guidelines. Then we take the content, then we feed into the authoring environment to create agent operating procedure playbook. In, in that playbook, we have instructions that will be referencing the tools and session variables. We also need to curate knowledge article and authoring them, enriching them.

[6:25] Along the way, we also need to curate the tools and APIs. Now, the knowledge graphs need to be converted to context markdown files so that we can enrich the context from our knowledge graph. On the right-hand side, to support the analytic agent, we need the four capabilities, and these are the key capabilities. We need to describe assets, both table and columns, and we need to create an index categorical value. Categorical value here refers to a set of, uh, distinct values from a selected database column. Then we need to obviously define SQL joins whenever possible in the semantic layer. Now, below we have five other common capabilities that supports all the agents. We need a context object store and technology.

[7:35] We need a RDF knowledge graph store and technology. And we also need to model ontology, taxonomy, and vocabulary terms. Then we curate the knowledge graph records and map them to the ontology elements. Last but not the least is how do we package the context for delivery? Now we have enabling capabilities underneath. Obviously, uh, we-- our SOP documents are stored in various web content management system, and we have knowledge articles everywhere, um, and we need to, you know, uh, source them. And we have MCP tool, API catalogs, and we also have business rules that are lying around everywhere, not just coming from the business document, but also can come from our, uh, rules engine, even our code.

[8:40] And in Verizon, we do have data marketplace and data catalogs, and these we'll consider as sources to feed into the core capability and of c-of course, the structured database. So that's our capability view, and next I wanna talk about the status of where we stand of implementing these capabilities. I use the color coding here for the borders of these capabilities boxes to indicate our current state. So the green boxes indicate that we have already established the tools, skills, systems, and practices. The yellow boxes is where we have been actively developing. The red boxes is where we have ongoing experiment with quite a few emerging specifications, and we expect them to evolve very fast, and we're ready to change.

[9:53] For the context delivery packaging, we're today adopting Google open knowledge format, OKF. For the converting the knowledge graph records to the context markdown file, we're looking at Vault linked data spec, along with other open source proposals. Now, I have to say that for the AOP playbook authoring today, in the industry, we don't have a standard yet. Every agentic tool, the third-party tool, they have their own agent studio, they have their own context authoring environment. We look forward to some common specification, a standard coming out from the industry soon. So that's where we stand today. Next, I wanna talk about the knowledge management here, right? The key components and then the context processing pipelines. Yeah. Uh, the context object repository tool, I use the purple color here to indicate that is where we manage the asset metadata, the tool and APIs metadata, and then we will also manage the business document artifact, the knowledge article artifact, product catalog, and obviously any other context objects that will be managed in that technology, in that tool.

[11:33] This tool also serve other functions in the context curation pipeline and context delivery pipeline. So the context object repository tool will be utilized to extract artifact Data asset and tool. And they, they will tag, store these artifacts there. Now for the delivery, this tool will be utilized to prepare OKFs bundle and deliver OKFs per business use case to the agent environment. If it is a third-party tool, we're gonna deliver the, them to the agent studio. If it is a homegrown agent, we're gonna deliver, uh, directly deliver them to the agent runtime. Now, the knowledge graph repository tool here, it manages ontology classes either for the business, business, uh, ontology terms or the domain ontology terms.

[12:42] Now, we'll also use the tool to build taxonomies and vocabulary terms. Then we'll use the tool to develop and manage the knowledge graph records for the artifact, for the asset, for the tool and other objects. Now, for the curation pipeline, that's the tool we use to generate the knowledge graph records, in this case it will be RDF triples, and then we map them to the ontology vocabulary and taxonomy terms. Now, we integrate the context object repository tool with a knowledge graph repository tool via the pub/sub service. So we use the event-driven, uh, integration architecture there. I wanna talk about ontology design and knowledge graph curation. So in the knowledge graph repository tool, we're gonna define the ECP, the Enterprise Context Platform, ontologies.

[13:49] And we start with artifact tool and asset ontologies. And then we're, we're gonna build, uh, business domain ontologies there. We're gonna utilize our document re-repository, our document corpus today, and also our database schema to create this business domain ontologies. Then we're gonna leverage the existing taxonomies we have in Verizon. There are four levels down there, I just gave you a sample here. And then the, and the, the, uh, domain vocabulary terms. Yeah. Again, these are just examples. Now, in the bottom left we have the context curation pipeline. As we're moving, curating the documents, we also want to generate the knowledge graph records. Once we create the artifact tool asset knowledge graph records, we're gonna map them to the upper ontology elements here, um, taxonomy and vocabularies.

[15:03] And each of the knowledge graph record here actually also l- has link to, to the physical asset that's stored in the context object repository tool. Our initial plan is to onboard sixteen thousand business documents and twenty-three thousand knowledge articles, along with, uh, many asset objects and objects. Uh, for... I wanna talk a little bit about the, the timing, right? For near term, our curation jobs, we want to focus on coarse-grained classes. These are the higher level classes. We want to start with artifact, tool, and asset. Artifact here refers to either business document or the knowledge article. For the longer term, we're gonna extend the curation jobs to fine-grain classes such as business rule, business policy, workflow, data product and measure.

[16:18] So we know this is a journey. We wanna f- start from small. We don't wanna boil the ocean here, so we do have a plan. Yeah, so this is actually my last, last slide here. I want to talk a little bit about the ECP. We position this against the agent lifecycle stages. Now, step one here, we have context developer building out the context from a variety of sources, and get the context ready and bundle them and get ready to serve. Step two, then we have agent developer and the development team that will be coming to the ECP to discover and retrieve the context bundle. Right? It could be business instructions, business rules and business policies, and then the database asset metadata or the existing tool metadata.

[17:19] They come to the ECP, treating ECP as a single one-stop shop, get all the context they need to fulfill their business use case when they develop that agent. Then they will go into the agent development, the, the testing and deployment phase, and then go into the runtime In runtime, which is step four here, in session, the agent is going to execute the tools based on the workflow, based on the business instructions, and then they're gonna access the databases and the applications. I want to call out that we're not gonna channel or proxy call-- the database calls or application calls through Enterprise Context Platform. The ECP only serves context and metadata only. I need to m-make that very clear.

[18:21] Then step five, in the post session, and obviously the agent will save its interaction history, all the other traces locally in the agent store. Now, this is the current state, and we want to be able to get the fine feedback, the agent feedback into the ECP. It could be traces, it could be other objects or the feedback coming from the agent back into the ECP, but that's our future plan. And that's all I have for today. Thank you, and back to you, Austin.

[19:03] **Austin Kronz:** Thank you, Steven. Uh, informative as always. Uh, I, I don't know if you were able to follow along in the chat, but there's plenty of questions for you in the, the Q&A and in the chat. So maybe, uh, as we continue on here, you'll have a chance to respond to those. But Steven, thank you again for walking through what, you know, you've put together for Verizon and how you're thinking about building this overall architecture to support agents. There's a really good question in there about what is at build time versus what happens at runtime. So I think probably a good, uh, side conversation to have. So thank you again, Steven.