Vishwa Teja Vangari

Vishwa Teja Vangari · Naperville, Illinois, USA · Greater Chicago Area

I lead the teams that put AI agents into production, and I work on the layer of meaning underneath them.

Senior Director of Engineering at Egen. I lead the application, data and AI engineering teams for a large retail client, and the team behind the platform our teams use to build and run AI agents. On my own time I study ontology-grounded agents, to learn how to write a business down so that an agent can follow it, show its evidence, and refuse when it can't.

See the work Learning Read the writing
Now: building and shipping the next phase of the agent platform on retail & healthcare use cases, and writing a series on ontology-grounded agents. More on what I'm doing
Vishwa Teja Vangari

What I work on

Four things, and how they connect

An agent platform needs a model of the business to reason over. Both need an engineering organization that can ship them safely. All three get tested in operations, where a wrong answer becomes a missing item in a customer's order.

01, Runtime

Agent platforms

The loop that calls the model and routes its tool calls. Tool permissions, human approval before a tool call that acts, and evaluation suites before each release. An orchestrator that hands work to domain agents over A2A, each with its own MCP server.

See the work 02, Meaning

The layer of meaning

Ontology, knowledge graph, semantic layer and context layer. The business written down once, in a form an agent has to follow, and mapped to governed data.

Read the learning notes 03, Delivery

Agentic engineering

A spec-first SDLC on an engineering harness. Shared coding agents draft and validate, checks block, and engineers make the product and release calls.

See how it runs 04, Operations

The order lifecycle

Orders, inventory, picking, substitutions and delivery for a large retailer. This is where I learned what a platform has to survive.

See the fulfillment model

The stack I work across

The four layers I work across

The systems my teams and I have delivered in the last few years sit somewhere in this picture. An agent is only as useful as the knowledge layer under it, and that layer depends on governed data. I make decisions at every layer, and most of the hard problems I've seen show up where one layer hands off to the next.

Experiences Store app eCommerce Ops consoles Marketing Agents Orchestrator A2A Fulfillment Orders Inventory Delivery Catalog Knowledge Ontology Knowledge graph Semantic layer Context layer Eval suites Data, infra Databricks Fabric, OneLake Kafka PostgreSQL Cosmos DB AKS requests, results tools over MCP views, CDC, events
Requests move down through the layers and results move back up. On this platform, agents reach business data through an ontology that maps to governed views; that is the only path they are given. Release of a new agent version is gated on the evaluation suites.

Selected engineering work

Systems my teams and I have delivered, and the decision at the center of each

For each system: the problem, the decision I made that shaped the design, and what it took the team to run it in production.

Agent platform

Problem
Run business agents for fulfillment operations, product catalog work and marketing, with the controls an enterprise needs before it lets an agent act.
Decision
I led the architecture, starting with the layers under the agents before the agents themselves, and the platform team built them: an ontology of the business's entity types, a semantic layer holding the metric definitions, and a context layer that controls what an agent sees at each step. I design agent access around governed interfaces: the ontology maps to physical tables through MCP tool definitions and governed views, and the agents on this platform read through those rather than from the tables directly.
Runtime
The runtime is a loop that calls the model and routes its tool calls. Tool-permission rules bound what it can call. A call that only reads goes straight to the tool; a call that changes a record or sends a message waits for a person to approve it before the tool runs, and the model is told when it is denied. Separately, each new agent version passes the evaluation suites before release. The team and I compared Gemini, Claude, OpenAI and open-weight models on our own questions before settling on the models in use.
Microsoft Agent FrameworkAzure AI FoundryMCPA2AGeminiClaudeOpenAINeo4jElasticsearch
Runtime, for each task Human approval denied: the model is told approved a call that acts reads go straight Task Model call Tool router MCP tools permission scope results, until the model answers answer Output to the caller Deployment, for each agent version Agent change Eval suites Release then runs above
Two processes. At runtime, tool calls run inside a permission scope. A call that only reads goes straight to the tool; a call that changes a record or sends a message waits for a person to approve it before the tool runs. Results return to the model until it answers, and the answer goes to the caller. Separately, each new agent version passes the evaluation suites before it is released.

Agentic SDLC on an engineering harness

Problem
We wanted coding agents to do most of the drafting without lowering the bar for what ships.
Decision
Work starts from a written spec. Role-based agents for data engineering, backend, web, data science and DevOps draft the code and tests. A review agent checks each change against the plan and the repo's controls. Engineers make the product and release calls, and the release pipeline requires review, test and evaluation gates on each change. Data pipelines go through the same gates.
Result
The teams moved onto the harness for their day-to-day work. The same workflow ran the analysis of the existing services ahead of the Azure cloud digitization.
Written specsRole agentsReview agentEval gates
Spec Plan Role agents data, backend, web, data science, devops code and tests changes requested Review agent against the plan and repo controls Gates review, test, eval Release an engineer decides
Role agents draft the change, a review agent checks it, the gates decide whether it can ship, and an engineer makes the release call.

Data platform for analytics and agents

Problem
Dashboards and agents needed the same governed data, and the agents needed it within seconds. We wanted one platform for both.
Decision
Unity Catalog governs the ML and CDC pipelines on Databricks. Microsoft Fabric is the read side, and it has its own workspace, item and OneLake permissions; access is granted on each side, and nothing carries across that boundary on its own. Direct Lake semantic models scoped by business domain serve dashboards and agents. Two separate calls sat under that. For ingestion, Fabric Mirroring of PostgreSQL and Cosmos DB is the backbone, chosen over Lakeflow Connect, with a freshness target of under 20 seconds from a write in the source system to the row landing in OneLake. That is a target for data freshness in the lake, not a measured end-to-end answer time. An event stream is the real-time overlay. For query mode, Direct Lake over DirectQuery. I led the architecture; the data team evaluated the options and implemented the pipelines.
Also
I wrote the business glossary and data catalog for the last-mile delivery domain, and the cost model for DBUs and capacity units. The data science team built the substitution recommendation system out of the same work. It uses two-tower retrieval for candidates, a ranking stage, and a calibrated model of customer acceptance.
DatabricksUnity CatalogMicrosoft FabricOneLakeDirect LakeKafkaPostgreSQLCosmos DB
Microsoft Fabric its own permissions PostgreSQL Cosmos DB Kafka OneLake Event stream target: under 20 s into OneLake events Direct Lake semantic models by domain Analytics Agents real-time overlay Databricks Unity Catalog ML and CDC pipelines data crosses; access is granted again
Systems of record mirror into OneLake, an event stream carries the real-time overlay, and Direct Lake semantic models serve dashboards and agents. Two governance domains: Unity Catalog governs the Databricks side, and Fabric has its own workspace, item and OneLake permissions. Data crosses that boundary; permissions do not, so access is granted again on the Fabric side.

Order management and fulfillment

Problem
Pick online orders inside stores, with labor that varies by hour and shelves that empty during the day.
Decision
A dynamic fulfillment model. A store pulls orders forward for picking when it has spare labor, so picker productivity follows labor availability. A dedicated picking area turns online orders around quickly, and the forecasting system replenishes that area and the store floor separately.
Now
I lead the architecture for the Azure cloud digitization of these services, and the engineering teams are delivering it: containers on AKS behind Azure API Management, with the data on Azure Database for PostgreSQL. In parallel, the team is improving substitutions and customer notifications, and I lead the design for items sold by weight.
JavaKotlinSpring BootAKSAPI ManagementPostgreSQLKafka
Forecasting replenishes Online order Fulfillment model pulls work forward when labor is free Pick area own replenishment Store floor own replenishment Order quality substitutions Delivery or pickup
Orders are pulled forward when labor is free, picked in a dedicated area or on the floor, and pass through order quality before delivery. The pick area and the floor are replenished separately.

Personal learning

Ontology-grounded agents, on my own time

Outside of work I study the layer under enterprise agents: what an ontology, a semantic layer and a context layer each add, and where retrieval on its own falls short. I try the ideas on synthetic data and write about what I learn.

what this agent may see what the words mean how the number is computed runs it with the caller's access and where it came from Question Context layer Ontology Semantic layer Data platform Answer, sources Says it can't answer a word is unclear, or nothing defines it
How I picture the path of one question. Each layer adds one thing, and the data platform the company already has does the work of running the query.

Scope. This is personal learning. I do it on my own time, with synthetic data, to learn and experiment. It is not work for any company or client, and the views are my own.

Read the learning notesThe engineering harness

Point of view

Five positions I hold on enterprise agents

I hold these until production proves one of them wrong. The learning notes and the harness page work them through with examples.

01

Enterprises don't lack engines. They lack the business written down.

The data platforms I work with now ship a semantic layer or an ontology feature, and each one arrives empty. Someone who owns the meaning still has to write down each entity, rule and definition, and keep them current as the business changes. The model can draft that; it can't decide it. In the programs I've seen, the deciding is the step most often skipped.

02

Similarity is not knowledge.

A brand name and the ingredient inside it don't look alike as text. They are linked because someone declared the link, and a drug terminology keeps ingredient, strength, dose form and brand as separate things for that reason. If that declaration isn't in the system, a larger model won't reliably find it, and the miss will look like a confident answer.

03

Context is a projection, and it carries permissions.

A longer prompt isn't a context layer. The context layer computes what this agent, acting for this person, at this step, is allowed to see. It can be tested and audited like any other access decision.

04

A refusal is a correct answer, and an answer has to be checkable.

An agent that can't ground an answer should say so and give the reason. I count a wrong refusal as a defect and a missing refusal as a worse one. When it does answer, the definition it used and the data behind it come with the answer, or nobody should act on it.

05

The harness outlasts the model.

Models change every few months. Tool scope, permissions, evaluation suites and gates stay. I choose models by running them on my own questions, and I design for swapping them.

How I build

Four rules I keep coming back to

None of these are original. Each one came from a production incident, a migration, or a design review.

Spec

Work starts from a written spec.

This applies to people and to agents. The spec names the behavior, the data it touches and how we will know it works. A change without one waits, however fast the draft would be.

Data

Reference data in the graph, transactions in the systems of record.

A knowledge graph holds products, categories, relationships and rules. Orders stay where they are written, and the ontology maps between the two.

Shape

Capabilities as services, experiences as apps, integrations as adapters.

This shape lets one store platform serve more than one brand, and it lets the in-store app work offline.

Review

A human signs off on what reaches a customer.

Generated product content goes live only after a person reviews it. Customer notifications are batched and throttled across the order lifecycle.

Writing

Articles and notes

New writing is published here first, then on LinkedIn and Medium. The hands-on Kafka series from 2019 is still on Medium. Subscribe by RSS or follow on LinkedIn.

Series

Beyond Similarity

A series on ontology-grounded agents. Retrieval finds text that resembles a question. An enterprise needs the records that satisfy it, with evidence.

  1. Part 1Why AI agents need clear business definitionsSep 30, 2026
  2. Part 2Why AI audit agents need more than search resultsOct 1, 2026
  3. Part 3How much semantic modeling do your AI agents need?Oct 4, 2026
Article

Why AI agents need clear business definitions

A grocery substitution explains ontology, knowledge graphs, semantic and context layers, and how business and technology teams keep their definitions trustworthy.

11 min
All writingEditor at Egen Engineering & Beyond on Medium

Speaking

Talks I can give

Each talk is built from systems I've run or experiments I've measured. I can give them at 25 or 45 minutes, to engineers or to a leadership audience. Abstracts and a speaker bio are on the about page.

Agent platforms
Agents in production: the loop, the permissions and the gates
What an enterprise needs in place before it lets an agent act, and the order to build it in.
Meaning
Similarity is not knowledge
One audit question, two architectures, and what an ontology finds that retrieval misses. Measured on synthetic data.
Agentic engineering
The engineering harness: shared agents, blocking checks, and what engineers do now
How a spec-first workflow with shared coding agents runs day to day, and what changes for hiring, review and KPIs.
Data platforms
One data platform for dashboards and agents
Serving analytics and agents from one governed copy, with a freshness target measured in seconds.
Operations
Retail order fulfillment
Picking online orders inside stores: labor-aware picking, dedicated pick areas, and substitutions customers accept.

Open source

Kafka tooling on GitHub

This is the companion code for the Kafka series, plus a few tools I needed and couldn't find. It all lives under github.com/vishwavangari.

SecureKafka

Configuration and walkthrough for hardening a Kafka cluster with SCRAM authentication, ACL authorization and SSL. Companion to the security article.

Shell, config kafka-oauth2

OAUTHBEARER callback handlers that validate tokens against Okta, for brokers, producers and consumers.

Java burrow

A fork of LinkedIn's Burrow consumer-lag monitor that adds SCRAM-SHA-256 and SHA-512, published as a Docker image with a compose setup and dashboard.

Go graphite-kafka-connect

A Kafka Connect sink connector that writes topic data to Graphite for time-series dashboards.

Scala

Experience

15 years in, 10 of them at Egen

I joined Egen as a developer in 2016 and moved through staff and principal engineer roles into the leadership job I hold now. Before Egen I worked on clinical data in healthcare and on dealer systems for an automotive manufacturer. The longer version is on the about page.

  1. Egen Naperville, Illinois
    Feb 2016 to now
    1. Apr 2024 to now

      Senior Director of Engineering

      Application, data and AI engineering teams for a large retail client, and the team behind the platform our teams use to build and run AI agents. Member of the leadership team.

      • Architecture for the agent platform, the governed data platform and the order and fulfillment services, with the engineering teams that deliver them.
      • The hiring loop for software, AI and data engineering roles, the delivery KPIs, and the technical workshops and bootcamps for the teams.
      • The AI, data and applications parts of Egen's strategy with the leadership team; the roadmap and business reviews with the client.
      Microsoft Agent FrameworkAzure AI FoundryMCPA2ADatabricksMicrosoft FabricAKS
    2. Mar 2021 to Apr 2024 3 yr 1 mo

      Principal Software Engineer

      Solution architecture and design reviews across projects: service boundaries, data stores, deployment topology and each service's availability target.

      • APIs over data-science models, writing their results to Informix, SQL Server, Cosmos DB, Cassandra, PostgreSQL and Elasticsearch.
      • Azure and AWS infrastructure for Kafka, PostgreSQL and Cosmos DB with CI/CD pipelines; mentored engineers on their microservice designs.
      JavaKotlinPythonSpring BootNode.jsAzureAWS
    3. Sep 2018 to Mar 2021 2 yr 6 mo

      Staff Software Engineer

      Streaming and data pipelines, and the tooling around them. The Kafka articles and the GitHub repositories come from this period.

      • Kafka streaming into Redshift, Elasticsearch, RDS, PostgreSQL and Solr; schema changes with Flyway; a rules engine on Kafka Streams that raised alerts on thresholds.
      • Airflow pipelines with PySpark and Akka; SQS, SNS and Lambda for the event-driven pieces; single sign-on with JWT and Ping Identity; Jenkins deployments onto Kubernetes and Mesos.
      KafkaAirflowPySparkAkkaKubernetesPostgreSQL
    4. Feb 2016 to Sep 2018 2 yr 7 mo

      Software Developer

      Services and front ends for healthcare clients, and the clinical data pipelines behind them.

      • REST services in Spring Boot with Spring Data and in Scala with Scalatra; Angular and React front ends in TypeScript.
      • Data Factory pipelines into Azure SQL Managed Instance; clinical data into the OMOP common data model; Power BI tabular models; HDFS with Cloudera.
      Spring BootScalaAngularReactAzure Data FactoryOMOP
  2. University of New Orleans New Orleans, Louisiana
    Aug 2014 to Dec 2015 1 yr 5 mo

    1. Graduate Assistant

      Web and iPad applications for research projects, alongside the master's degree.

      • REST services, AngularJS and Telerik UI with Protractor tests; email and SMS through Clickatell and Amazon SNS; Google Charts and Maps over SQL Server and MySQL.
  3. Tech Mahindra Hyderabad, India, for Nissan Automobile, Europe
    Aug 2011 to Jul 2014 2 yr 11 mo

    1. Software Engineer

      Dealer communication and sales systems for Nissan Europe. My first lesson in how enterprise software is released and supported.

      • SanGen, a communication channel between Nissan's investigation engineers and dealers: JSF, EJB, JPA and Hibernate over Oracle, Spring Web Services.
      • The Nissan Feedback Information Tool and the sales and marketing projects (EURO5, ENOCS, a payment system) in Struts and Spring over Oracle and DB2; JBPM workflows and Frevvo forms; WebSphere, WebLogic, JBoss and Resin; releases through Jenkins.
      Java EEJSFEJBHibernateOracleWebSphere
LinkedInlinkedin.com/in/vishwatejavangari
GitHubgithub.com/vishwavangari
Mediummedium.com/@vishwateja.vangari