The Agent-Per-Domain Pattern: How D23 Structures Analytics Agents

Understanding the Agent-Per-Domain Pattern

When analytics teams grow beyond a single data warehouse and a handful of dashboards, they hit a critical inflection point. The monolithic analytics stack that worked for ten users breaks under the weight of a hundred. Queries slow. Governance becomes impossible. Different teams—finance, operations, sales—start building their own shadow analytics stacks because the central platform can’t respond fast enough to their specific needs.

The agent-per-domain pattern solves this by deploying separate, specialized analytics agents for each business domain while maintaining a shared layer of data access tools. Instead of one analytics agent trying to understand every table, every metric definition, and every team’s unique business logic, you deploy a finance agent that knows P&L deeply, an ops agent that understands inventory and fulfillment, and a sales agent that can instantly query pipeline and forecast data.

This architecture isn’t new—it mirrors patterns used in distributed systems, microservices, and multi-agent AI systems. But applying it to analytics infrastructure, especially when built on Apache Superset with AI-powered query generation and Model Context Protocol (MCP) integration, creates a fundamentally different experience for data teams. Instead of a single bottleneck, you get domain-specific intelligence that understands context, business rules, and team-specific metrics without sacrificing data governance or consistency.

At D23, we’ve structured our managed Superset platform to make this pattern native. This article walks through why the agent-per-domain approach works, how to implement it, and the concrete benefits you’ll see in query latency, time-to-insight, and team adoption.

The Problem with Monolithic Analytics Agents

Before diving into the solution, it’s worth understanding what breaks in a single-agent architecture as your organization scales.

A monolithic analytics agent operates like a generalist consultant who’s supposed to know everything about your business. When the finance team asks, “What’s our month-to-date revenue by region?” the agent has to parse that question, search through potentially hundreds of tables, apply business logic it may not fully understand, and generate SQL. When the ops team immediately follows with, “How many units are in transit?” the same agent context-switches, loses the finance domain knowledge, and has to re-establish its understanding of inventory tables.

The problems compound:

Context Explosion: A single agent’s context window fills with schema information, metric definitions, and business logic for every domain. As your data warehouse grows—finance tables, operational tables, customer data, product catalogs—the agent spends more tokens just understanding what exists and less on actually solving the user’s problem.

Latency Degradation: Each query requires the agent to reason about a larger problem space. Text-to-SQL generation becomes slower. The agent makes more mistakes and requires more correction cycles. What should be a 2-second query becomes a 15-second affair.

Metric Drift and Governance Failures: When one agent owns all metrics, conflicting definitions emerge. Finance defines “revenue” one way, sales defines it another. The agent can’t enforce consistency because it’s trying to satisfy everyone simultaneously. You end up with trust issues—teams stop using the AI agent and go back to asking analysts.

Poor User Experience: Users from different teams experience different quality. The agent works great for simple operational queries but fails on complex financial logic. Teams perceive the agent as unreliable, and adoption stalls.

These aren’t theoretical problems. They’re the reason most organizations deploying single-agent analytics systems hit a wall around 50-100 concurrent users. The architecture doesn’t scale horizontally because the agent itself becomes the bottleneck.

How the Agent-Per-Domain Pattern Fixes This

The agent-per-domain pattern addresses these issues by introducing domain specialization and isolation. Instead of one agent, you deploy multiple agents—one per major business domain—each with its own:

Specialized Context: The finance agent knows P&L tables, GL accounts, revenue recognition logic, and financial metric definitions. It doesn’t need to know anything about inventory or fulfillment. Its context is lean and focused.

Domain-Specific Prompting: Each agent receives a system prompt tailored to its domain. The finance agent’s prompt includes rules about revenue recognition, accrual accounting, and regulatory reporting. The ops agent’s prompt includes business rules about order fulfillment, inventory thresholds, and supply chain logic.

Isolated Query Reasoning: When a finance user asks a question, only the finance agent reasons about it. There’s no context pollution from other domains. The agent can be more aggressive with assumptions and shortcuts because it’s operating within a well-defined domain.

Shared Tool Layer: All agents access the same underlying data through a shared Model Context Protocol (MCP) server. This MCP server provides a consistent interface for querying tables, executing parameterized queries, and returning results. The shared layer ensures data governance, consistency, and security.

The pattern works because it separates concerns: domain logic lives in the agent prompts and routing; data access and governance live in the shared MCP layer; and Superset provides the visualization and dashboard infrastructure that ties everything together.

Architecture: Agents, MCP, and Superset

Let’s walk through a concrete architecture that shows how these pieces fit together.

At the foundation, you have your data warehouse—PostgreSQL, Snowflake, BigQuery, or another OLAP system. This is your single source of truth. All data flows here, and all queries ultimately execute against this system.

Above the warehouse sits the MCP server layer. This is the critical piece that enables domain agents to access data safely and consistently. The MCP server implements a set of standardized tools:

Table Introspection: Agents can query the schema—what tables exist, what columns they have, what types they are. This is scoped per domain. The finance agent’s introspection only returns finance-related tables. The ops agent only sees ops tables.

Query Execution: Agents can execute SQL queries, but only against tables they’re authorized to access. The MCP server enforces row-level security (RLS) and column-level permissions. If an agent tries to query a table outside its domain, the MCP server rejects it.

Metric Resolution: Agents can request pre-computed metrics or metric definitions. Instead of every agent reconstructing “revenue,” they call a metric resolution tool that returns the canonical definition, the SQL to compute it, and any necessary filters.

Result Caching: The MCP server caches frequently-accessed queries and results. This dramatically improves latency for repeated questions and reduces load on the warehouse.

Above the MCP layer sit the domain agents. Each agent is a language model (Claude, GPT-4, or another model) configured with:

System Prompt: Domain-specific instructions. The finance agent’s prompt includes rules about revenue recognition, P&L structure, and reporting standards. The ops agent’s prompt includes rules about inventory management and fulfillment logic.

Tool Definitions: The agent knows about the MCP tools available to it. It can call table introspection, execute queries, resolve metrics, and access cached results.

User Context: Information about the current user—their role, their team, their permissions. This flows through to the MCP server to enforce security.

Finally, D23’s managed Superset sits at the user-facing layer. Users interact with dashboards, ask questions in natural language, and drill into data. When a user asks a question, a router (which we’ll discuss in the next section) decides which agent should handle it, the agent generates SQL or calls MCP tools, and the results flow back to Superset for visualization.

This architecture is similar to patterns described in AI agent architecture frameworks, where perception (user input), reasoning (agent logic), and tool integration (MCP) are layered separately. The key difference is that our reasoning layer is split by domain, not monolithic.

Routing: How Requests Find the Right Agent

The routing layer is often overlooked but critical. When a user asks a question, how does the system know which agent should handle it?

There are several routing strategies, each with trade-offs:

Intent-Based Routing: A classifier model reads the user’s question and predicts which domain it belongs to. “What’s our month-to-date revenue?” → finance. “How many orders are pending fulfillment?” → ops. This is fast and simple but requires training data and can misclassify ambiguous questions.

Explicit Domain Selection: Users explicitly choose their domain before asking questions. “I’m in finance. What’s our month-to-date revenue?” This is 100% accurate but adds friction. Most teams reject this approach.

Hierarchical Routing: A meta-agent reads the question and decides which domain agent to invoke. This is more flexible—the meta-agent can handle questions that span domains by invoking multiple agents sequentially—but adds latency and complexity.

User-Based Routing: Route based on the user’s team or role. If the user is in the finance department, route to the finance agent. This is simple and works well in practice but breaks for cross-functional teams.

At D23, we use a hybrid approach: user-based routing as the default (it’s fast and accurate for 80% of cases), with a fallback to intent-based classification for ambiguous cases, and an option for explicit domain selection when users want to be sure. This keeps latency low while maintaining accuracy.

The routing decision happens in milliseconds, before the agent even starts reasoning about the query. This is crucial for maintaining the sub-second response times that users expect.

Domain Specialization in Practice

Let’s walk through three concrete examples of how domain specialization works in practice.

Finance Agent: Revenue and P&L

The finance agent owns all questions about revenue, profitability, and financial reporting. Its system prompt includes:

• Revenue recognition rules (when to recognize revenue, how to handle refunds, how to account for multi-year contracts)
• P&L structure (what goes into COGS, operating expenses, etc.)
• Metric definitions (gross margin, operating margin, net income, ROIC)
• Regulatory requirements (GAAP, IFRS, SOX compliance)

When a user asks, “What’s our gross margin by product line for Q3?” the finance agent:

1. Calls the metric resolution tool to get the canonical definition of gross margin
2. Understands that this requires revenue and COGS data
3. Generates SQL that applies the correct revenue recognition rules and COGS allocation
4. Executes the query through the MCP server
5. Returns the result to Superset for visualization

Because the agent is specialized, it doesn’t make mistakes about revenue recognition. It doesn’t accidentally include unrecognized revenue. It applies the same rules consistently.

If a user asks a question that the finance agent can’t answer—“What’s the inventory turnover ratio?”—the agent recognizes it’s outside its domain and either rejects the question or routes it to the ops agent.

Operations Agent: Inventory and Fulfillment

The ops agent owns inventory, fulfillment, and supply chain questions. Its system prompt includes:

• Inventory management rules (how to value inventory, how to handle obsolescence, how to calculate turnover)
• Fulfillment logic (how orders flow through the system, what states they can be in, SLA definitions)
• Supply chain metrics (lead times, fill rates, stockouts)

When a user asks, “How many units are in transit and when will they arrive?” the ops agent:

1. Calls table introspection to understand the order and shipment tables
2. Generates SQL that filters for in-transit orders and joins with shipment tracking data
3. Applies business rules about what “in transit” means (shipped but not delivered)
4. Returns the result with estimated delivery dates

The ops agent is fast because it doesn’t need to reason about financial concepts. It can make aggressive assumptions about what the user wants. If a user asks about inventory, the agent assumes they want current inventory, not historical snapshots, unless they specify otherwise.

Sales Agent: Pipeline and Forecast

The sales agent owns pipeline, forecast, and customer acquisition metrics. Its system prompt includes:

• Sales stage definitions (what each stage means, how long deals typically stay in each stage)
• Forecast methodology (how to calculate pipeline forecast, how to apply historical conversion rates)
• Sales metrics (ACV, CAC, LTV, win rate, deal velocity)

When a user asks, “What’s our pipeline forecast for Q4?” the sales agent:

1. Calls the metric resolution tool for the canonical forecast formula
2. Generates SQL that applies historical conversion rates and stage probabilities
3. Filters for deals that could close in Q4
4. Returns the forecast with confidence intervals

Because the agent is specialized, it knows that a deal in “negotiation” stage is more likely to close than one in “discovery.” It applies the correct conversion rates. It doesn’t accidentally include deals that have already closed.

Shared MCP Tools: The Governance Layer

While agents are specialized, they all access data through the same MCP tool layer. This is where governance lives.

The MCP server implements several critical tools that all agents use:

Authenticated Query Execution: Every query is executed in the context of the current user. The MCP server enforces row-level security. If a user in the EMEA region asks about revenue, they only see EMEA revenue. If a user doesn’t have access to a table, the query is rejected.

Query Validation: Before executing a query, the MCP server validates it. Is it syntactically correct? Does it access only authorized tables? Does it execute in reasonable time? Queries that would take too long are rejected or rewritten.

Metric Consistency: The MCP server maintains a canonical definition of every metric. When an agent calls the metric resolution tool, it gets the authoritative definition, ensuring consistency across all agents.

Audit Logging: Every query is logged—who asked, what they asked, when, and what the result was. This is critical for compliance and debugging.

Caching and Performance: The MCP server caches results from frequently-run queries. This dramatically improves latency and reduces load on the warehouse.

This shared layer is what makes the agent-per-domain pattern work at scale. Agents can be specialized and autonomous, but they’re all constrained by the same governance, security, and consistency rules.

The architecture mirrors multi-agent patterns in event-driven systems, where a shared event stream or data layer coordinates multiple independent agents. In our case, the MCP server is the shared coordination layer.

Scaling to Multiple Domains

The beauty of the agent-per-domain pattern is that it scales linearly. Adding a new domain—marketing, customer success, product—doesn’t require redesigning the entire system. You simply:

1. Deploy a new agent with the appropriate system prompt and domain knowledge
2. Register it with the router
3. Add any new tables to the MCP server and define access controls

Each new agent operates independently. It doesn’t slow down existing agents. It doesn’t pollute their context.

In practice, we’ve seen organizations scale from 3 domains (finance, ops, sales) to 8-10 domains (adding marketing, customer success, product, HR, legal) without any degradation in performance. The key is maintaining discipline about domain boundaries. If a question spans multiple domains, the router invokes multiple agents sequentially or in parallel, depending on the implementation.

For example, a question like “What’s our customer acquisition cost by product line?” spans sales (customer acquisition) and product (product line). The router might:

1. Invoke the sales agent to get CAC data
2. Invoke the product agent to get product line definitions
3. Join the results

Or it might invoke a meta-agent that orchestrates multiple domain agents. The exact strategy depends on your latency requirements and complexity tolerance.

Implementation Considerations

Moving from theory to practice, here are the critical implementation details.

Choosing Your Model and Framework

You’ll need a language model capable of tool use and reasoning. Claude 3.5 Sonnet, GPT-4, and other recent models all work well. You’ll also need a framework for building agents. Popular choices include LangChain, LlamaIndex, and Anthropic’s Python SDK.

At D23, we use Claude with the Python SDK because it offers the best balance of performance, cost, and ease of integration with our Superset infrastructure.

Defining Domain Boundaries

This is harder than it sounds. Finance and accounting have some overlap. Sales and marketing have significant overlap. You need to be explicit about where boundaries are. A good test: can you write a single system prompt that clearly defines the domain? If the prompt becomes too long or contradictory, you’ve crossed a boundary.

We recommend starting with 3-4 domains and only splitting further if you have evidence that a single agent is becoming a bottleneck.

Building the MCP Server

The MCP server is the critical infrastructure piece. It needs to be:

Fast: Query validation and execution should be sub-100ms. Use connection pooling and caching.

Secure: Enforce authentication, authorization, and audit logging. Use parameterized queries to prevent injection attacks.

Reliable: Handle failures gracefully. If the warehouse is down, return a clear error. Don’t let one slow query block others.

Observable: Log everything. You need to understand what queries are running, how long they take, and whether they’re succeeding.

The MCP specification is well-documented, and several open-source implementations exist. Building on top of an existing framework is usually faster than building from scratch.

System Prompts and Domain Knowledge

The quality of your agents depends entirely on the quality of your system prompts. A well-written prompt should:

• Clearly define the domain and what questions the agent owns
• Include business rules and metric definitions
• Provide examples of good queries and bad queries
• Include instructions for handling ambiguous cases
• Define fallback behavior when the agent encounters something outside its domain

We recommend starting with a 500-1000 word prompt per agent and expanding as you encounter edge cases. Keep a log of questions the agent mishandles, and update the prompt to address them.

Testing and Validation

Before deploying agents to production, you need a robust testing framework. This includes:

Unit Tests: For each agent, define 20-30 test questions with known correct answers. Verify that the agent generates correct SQL and returns correct results.

Integration Tests: Test the full flow—user question → router → agent → MCP server → Superset.

Performance Tests: Measure latency for common queries. Ensure that adding agents doesn’t degrade performance.

Governance Tests: Verify that security is enforced. A user without access to a table shouldn’t be able to query it, even indirectly.

Automating these tests is critical. As you iterate on prompts and add new agents, you need confidence that you haven’t broken anything.

Real-World Example: A Mid-Market SaaS Company

Let’s walk through a concrete example of how a mid-market SaaS company implemented the agent-per-domain pattern.

The company had 150 employees, $10M ARR, and was using Looker for analytics. They were hitting Looker’s limits—dashboards were slow, the semantic layer was becoming unmaintainable, and the cost was climbing. They decided to migrate to D23’s managed Superset with agent-per-domain architecture.

Initial State: A single Looker instance with 50 dashboards and 200 saved queries. Dashboards took 10-30 seconds to load. The finance team had its own shadow BI system (Excel and Tableau) because Looker’s revenue metrics were slow.

Migration: They deployed three agents—finance, operations, and product—each with a specialized system prompt. They built an MCP server that enforced security and cached common queries. They migrated their 50 dashboards to Superset and connected them to the agents.

Results:

• Dashboard load time dropped from 20 seconds to 2 seconds
• Time to answer ad-hoc questions dropped from 1-2 hours (asking an analyst) to 30 seconds (asking an agent)
• The finance team’s shadow BI system became obsolete. They switched to using the agents
• Adoption increased from 30% of employees to 70% within 3 months
• Cost dropped by 40% compared to Looker

The key success factor was domain specialization. By giving each agent deep knowledge of its domain, they made it fast and accurate. Users trusted the agents because they didn’t make mistakes.

Comparing to Other Multi-Agent Patterns

The agent-per-domain pattern is one of several approaches to multi-agent systems. It’s worth understanding the alternatives and when each makes sense.

Subagent Pattern: A master agent spawns subagents to handle specific tasks. This works well for sequential workflows (step 1, then step 2, then step 3) but adds latency because tasks must be serialized.

Skill-Based Pattern: Agents are organized by capability (SQL generation, visualization, caching) rather than domain. This works well for complex technical systems but is confusing for business users.

Handoff Pattern: Agents pass requests between each other. If the finance agent encounters a sales question, it hands off to the sales agent. This works well for sequential workflows but adds complexity.

Router Pattern: A central router directs requests to the appropriate agent. This is similar to agent-per-domain but doesn’t require agents to be domain-specific. It’s more flexible but less optimized.

For analytics, agent-per-domain is the best fit because:

• Analytics questions are usually self-contained within a domain
• Domain knowledge is critical for correctness
• Latency matters—users expect sub-second responses
• Specialization improves trust and adoption

As discussed in Databricks’ agent system design patterns, the agent-per-domain approach is a variant of the multi-agent pattern optimized for distinct, non-overlapping domains.

Challenges and How to Address Them

The agent-per-domain pattern isn’t without challenges. Here’s how to address the most common ones.

Cross-Domain Questions: “What’s our customer acquisition cost by product line?” spans sales and product. Solution: Use a meta-agent that coordinates multiple domain agents, or define clear rules about which agent owns cross-domain questions.

Metric Conflicts: Finance and sales might define “revenue” differently (gross vs. net). Solution: Use the MCP metric resolution tool to enforce canonical definitions. Make the differences explicit in the prompts.

Agent Hallucination: An agent might make up a table or column that doesn’t exist. Solution: Use the MCP table introspection tool to ground agents in reality. Validate all SQL before execution.

Latency: Multiple agents add latency. Solution: Use caching aggressively. Pre-compute common metrics. Route to single agents whenever possible.

Prompt Maintenance: As your business changes, prompts become outdated. Solution: Treat prompts like code. Version them. Review them quarterly. Log questions the agent mishandles and update the prompt.

These challenges are manageable with discipline and good engineering practices.

Building on D23’s Infrastructure

At D23, we’ve built the agent-per-domain pattern into our managed Superset platform. This means:

Pre-Built Agent Framework: We provide templates for domain agents, system prompts, and routing logic. You don’t start from scratch.

Managed MCP Server: We host and maintain the MCP server. You don’t need to build or operate it. It scales automatically and includes audit logging and security out of the box.

Superset Integration: Your agents integrate directly with Superset. Users ask questions in Superset, and results appear in dashboards. No separate interfaces or custom UIs needed.

Data Consulting: Our team has implemented agent-per-domain systems at dozens of companies. We can help you define domain boundaries, write system prompts, and optimize performance.

If you’re evaluating managed Apache Superset as an alternative to Looker, Tableau, or Power BI, the agent-per-domain pattern is one of the most powerful reasons to choose D23. It gives you the speed and accuracy of a specialized analytics team without the cost.

Getting Started

If you want to implement agent-per-domain analytics at your organization, here’s a roadmap:

Month 1: Define your domains. Talk to stakeholders in finance, ops, sales, and other teams. Understand their analytics needs. Identify 3-4 core domains.

Month 2: Build the MCP server. Implement table introspection, query execution, metric resolution, and caching. Test thoroughly.

Month 3: Deploy your first agent. Start with finance or ops—whichever domain has the most clear-cut requirements. Write a detailed system prompt. Test with real users.

Month 4: Deploy additional agents. Migrate dashboards from your legacy BI tool. Train users.

Month 5+: Iterate. Monitor agent performance. Update prompts based on user feedback. Add new agents as needed.

This timeline assumes you’re building on D23’s managed Superset. If you’re building from scratch, add 2-3 months for infrastructure.

Conclusion

The agent-per-domain pattern is a powerful approach to scaling analytics in organizations that have outgrown monolithic BI platforms. By specializing agents to specific business domains and coordinating them through a shared MCP tool layer, you get the speed, accuracy, and user adoption that comes from deep domain knowledge, combined with the consistency and governance that comes from centralized data access.

This architecture isn’t just theoretical. It’s battle-tested at dozens of companies, from startups to enterprises. It’s the pattern that D23 uses to deliver managed Apache Superset that’s faster, cheaper, and more reliable than Looker, Tableau, and Power BI.

If you’re building analytics infrastructure at scale, the agent-per-domain pattern is worth serious consideration. It’s the future of how organizations will do analytics.

Ready to explore how agent-per-domain architecture can transform your analytics? Learn more about D23’s managed Superset platform and how we can help you implement this pattern at your organization. Our data consulting services are designed to help teams like yours build production-grade analytics without the platform overhead.