Systems and application architecture
What you will learn in this module
How AI is changing the architecture of the analytics stack
The four layers of an AI-based analytics architecture
What an agent harness does and why enterprise analytics needs one
Archetecting AI analytics
The legacy data stack was built around a dashboard. Pipelines moved data out of source systems and into a warehouse. A modeling layer shaped that data. As search capabilities started to advance, semantic layers were added in to help define metrics — think keyword search capabilities in your browser. This improved self-service analytics, but it never quite lived up to its promise.
As we’ve discussed, today’s AI analytics and agents work differently. A general-purpose model can reason over a question the moment you ask it, wherever the data sits, as long as it has the context to interpret that data correctly. This is transforming which layers you need, collapsing the “modern data stack” as most teams know it.
The architectural shift in the analytics stack
Federated access: The system queries data where it already lives. Trino’s federated query model shows the pattern: one query planner, many connected sources. Warehouses and lakes remain sources the system queries, and in many cases a new question no longer needs a new pipeline, though some workloads still call for ingestion or preprocessing.
An enterprise context layer: Modeling, semantic, and governance work that used to be spread across the stack moves into one unified layer. Your analytics agents can access that context so they always know which metrics you trust, how each domain defines its business terms, and which anomalies to ignore.
An analytics harness around the model: A language model on its own is probabilistic. Ask it the same question twice and you may get two different queries. The harness is the software that ensures the context is correctly applied as it plans, controls, and checks the model’s work.
Overview of an AI-based analytics architecture
An AI-based analytics architecture has four layers. From the bottom up, they are enterprise data, the enterprise context layer, analytics harness, and insights delivery surface. Note: the model or large language model isn’t mentioned here, as this architecture treats the model as an interchangeable component you choose based on which model is best fit-for-task.
Enterprise data
Start where your data lives. Most enterprises hold analytics-relevant data across four families of sources:
Structured sources: Snowflake, BigQuery, Databricks, Teradata, MySQL, and Postgres. These sources have rows, columns, and a schema the system can read directly.
Semi-structured sources: APIs, MongoDB, DynamoDB, and ERP systems. Their data has a shape, but that shape is nested, sparse, or inconsistent from record to record.
Unstructured sources: PDFs, documents, and the files stored in Google Drive and Amazon S3. Their meaning sits in prose, so no column name tells you what a contract clause says.
Third-party applications: Salesforce, Google Analytics, Workday, Zendesk, and MCP servers. This data sits behind another vendor’s API and schema.
Enterprise context layer
Faced with that list of sources, the instinct is to move everything into one warehouse, standardize the schemas, and give AI access only once the data is clean. That project rarely finishes, and even more importantly, it leaves hardest questions open.
Clean data can tell an AI system what the values are and how the tables join, but it cannot explain what those values mean to your business, why a definition changed last quarter, or which team’s version of “revenue” applies to the question in front of it.
To close that gap, you need to govern the context around your data. The enterprise context layer provides a single governed source of business meaning. It holds metric and KPI definitions, business rules and procedures, data models and their descriptions, the ontology that relates business entities to each other, access and data policies, and the institutional knowledge that usually lives in one analyst’s head.
Much of that context already exists in places nobody has treated as an asset: query logs, dbt projects, BI models, data catalogs, documentation, decision traces, analyst workarounds, and call transcripts. Direct connections to those sources work better than manual uploads, because the context can update as the sources change. Most importantly, you should prioritize a context layer that can be connected, transferred, and universally understood by both humans and models. Look for OSI compliance and other emerging standards for portability.
You don’t want to fall into a context trap, where you structure your context for the system, rather than for its purpose. Doing so can cost you in the end. Especially when you consider that data leaders expect this layer to change quickly. In a recent survey of enterprise VP- and C-suite data leaders, 94% of surveyed data leaders plan to change how they store and manage enterprise context in the next 12 to 18 months.
Some agentic analytics platforms are more advanced, helping you build and maintain your context. For example, WisdomAI’s Context Builder bootstraps the Enterprise Context Layer from sources like these during onboarding, then attributes and versions each later update so you can trace how a definition changed.
Key takeaway
You no longer have to finish consolidating your data before AI can use it. Federation gives AI reach across your sources, and the context layer tells it what the data means.
What is an agent harness?
So far, you’re probably familiar with both of these terms and ideas. Here’s where the architecture is really diverging. To ensure your data is reliably accurate, you need purpose-built software capable of controlling the model, and optimizing its path for the task at hand. That software is the analytics harness. It supplies tools, selects the information the model sees, and checks the output.
General-purpose and specialized harnesses
Chat assistants such as ChatGPT and Claude are general-purpose harnesses. Because they are tuned for a broad range of knowledge work, they carry no specific guarantees for any one task. High-stakes work is getting its own specialized harnesses. Coding agents such as Claude Code and Cursor, for example, can read a codebase, run its tests, and check their changes before handing work back.
Analytics on enterprise data is high-stakes work, too. When you ask a KPI question, the answer has to respect who you are, which rows you are allowed to see, and how your company defines that KPI. When a colleague with the same access asks the same question five minutes later, they should get the same answer. In an analytics architecture, the enterprise data harness fills that role, and much more.
What the analytics harness does
The enterprise data harness works on two timelines.
Each time someone asks a question, the harness must:
Interpret and select context: Work out what the question means, then pull in only the context that applies to it. Loading everything into the model tends to degrade the answer.
Enforce guardrails and access: Apply row-level and column-level security as it builds the answer, so each user sees only the data they are allowed to see.
Plan and execute efficiently: Build the query plan against the source systems, optimizing the tokens and compute each answer consumes.
Verify and repair: Check the result before you see it, and correct errors it can detect, such as a failed query or a result that contradicts a known definition.
Continuously, in the background, it will:
Build context from sources: Pull definitions and rules from documentation, query logs, catalogs, and BI metadata.
Learn context from usage: Capture corrections and feedback from the people and agents using the system.
Govern and version: Route changes through expert review and keep a history of each definition.
Evaluate and score: Measure accuracy and consistency, running regression tests so a context change does not quietly break answers that used to be right.
This new layer is entirely dependent on your context, and vice versa. The harness should ground each answer in the context layer and route feedback to keep that layer accurate over time. The context layer works to provide the harness with the information the model needs to deliver an accurate answer, and the harness is designed to improve its consistency, cost, and speed.
Real-world application of this analytics architecture
Consider a regional sales director who asks, “What was net revenue retention for enterprise accounts last quarter?”
A general-purpose assistant with a warehouse connection, but none of your business definitions or analytics checks, writes a plausible query. It uses the first revenue table it finds and returns a number. If its connection runs on a broadly scoped service account, that number may also include accounts outside the director’s territories. Asked again the next day, it may choose a different table and return a different number, and nobody can tell which run was right.
With an analytics harness, the system reads the question against your company’s definitions of net revenue retention and of an enterprise account. Access policy limits the query to the director’s territories. The harness checks the result against a verified query for the same metric and returns the answer with its reasoning. As long as the data, definitions, and permissions have not changed, the director gets the same answer tomorrow.
Go deeper
Read Harness engineering for coding agent users (martinfowler.com) for a practitioner’s view of how teams design the guides and checks around an agent. The same thinking carries over to analytics.
Querying underlying data through multi-step analysis
Complex business questions rarely resolve in a single query. For these questions, the harness runs a loop. It reasons about your goal, picks a tool, calls that tool, checks the result, and repeats until it has enough to answer. Anthropic’s guide to building effective agents describes this loop in detail. In analytics, the tools available to the harness decide which questions it can answer.
A typical analytics harness can call these tools:
Text-to-SQL: The harness translates your natural-language question into an executable SQL query against a target database. If it maps a business term to the wrong table or column, it can write valid SQL that answers the wrong question, which is why the semantic rules in the context layer matter so much here.
Text-to-Python: For statistical work that SQL handles awkwardly, such as a cohort regression or a distribution fit, the harness generates Python code using libraries such as pandas.
Retrieval-augmented generation (RAG): RAG pulls passages from unstructured documents so the harness can combine them with structured results. For example, a procurement lead might ask which suppliers have price-escalation clauses and how much you spend with each. RAG finds the clauses, text-to-SQL returns the spend, and the harness joins the two into one answer, sparing the team a manual contract audit.
Data visualization: The harness renders a chart that suits the shape of the result, often through a declarative grammar such as Vega-Lite.
Verified queries: A context engineer reviews and approves these queries and joins, including joins that span different databases. When a question matches one, the harness reuses the approved logic stored in the context layer, which keeps results more deterministic from run to run.
Two architectural properties matter as much as the tool list:
Those are, open interfaces and native connections. MCP, the Model Context Protocol, standardizes how an agent connects to an external tool or data source, so the harness can reach a live Salesforce or Jira instance through the same interface it uses for everything else. Native connections let the harness query each source directly, without first copying the data into a central warehouse, so queries can run faster and cost less.
Insights delivery
Once the harness has an answer, it still has to reach a person. A complete architecture delivers answers wherever people make decisions, across three kinds of surface:
The analytics platform’s own interface: Users work directly in the platform’s chat, apps, dashboards, and agents.
Third-party agents: Claude, ChatGPT, and other MCP clients call the system in the background, and so do workplace tools such as Slack and Microsoft Teams. WisdomAI’s MCP server, for example, lets a connected client act as the signed-in user, so that user’s role, row-level security, and column-level security still apply.
Embedded and white-labeled experiences: A product team builds the analytics experience into its own application through React SDKs, iFrames, and GraphQL APIs.
Across those surfaces, you work with answers in these ways:
Interactive conversational BI: You ask a question, read the answer, and ask the next one. Most data discovery happens in the follow-up questions.
AI-generated apps or dashboards: You describe the interactive analytics app you want in plain language, and the system builds it and refreshes it as the connected data changes.
Autonomous analytics agents: You give an agent a KPI to watch or a type of anomaly to detect, and it notifies you in email, Slack, or Teams when something crosses your threshold. Because the agent holds your business context, it can start investigating why the number moved instead of only reporting that it did. Agents can be third-party or native to an agentic analytics platform. It can also be embedded inside of another app.
Regardless of the surface, each answer should be traceable: when the harness exposes its reasoning, sources, and assumptions, your governance team has something concrete to audit, and your business users have a reason to trust the number.
Key takeaways
An AI-based analytics architecture has four layers: enterprise data, the enterprise context layer, the analytics harness, and insights delivery.
Federation helps you reach data where it lives, and the context layer absorbs the modeling, semantic, and catalog work of the legacy stack.
The harness plans, guards, executes, and verifies the model’s work at query time, orchestrating feedback to help maintain the context layer.
The harness answers questions by calling tools such as text-to-SQL, RAG, and data visualization skills, and it reaches other systems through open interfaces such as MCP.