From Planning to Building

In our last installment, we discussed project definition and the context and clarity it can provide. In this installment, we’re going to jump into the part that most techies hanker for—the designing and building. We’re not doing this because these are necessarily the most fun, but rather because early design choices and prototypes will anchor our requirements for data and context.

Design patterns and technologies are changing rapidly—many under the theme of Context Engineering. It’s hard to keep track. Rather than try to enumerate all the technologies and the roles Context Intelligence plays, we’ll focus on a subset of coarser approaches that can be refined to accommodate different situations. The goal of these approaches is to improve alignment with business requirements and provide the best relevant data to AI applications, enabling them to produce high-quality responses.

Many development teams rely on Context Engineering techniques—prompt optimization, retrieval strategies, agent configurations. These are valuable, but they operate within the scope of a single query. They can’t tell you which systems to trust, which data is current, or how organizational boundaries should shape AI behavior. They optimize what goes into a prompt at query time, but lack the broader organizational understanding that should inform these decisions.

However, by defining the business requirements first (as discussed in the previous blog), we establish what kinds of context are relevant to this project – and the scopes to consider for each. For example, if this is a sales forecasting advisor for North America, sales territory is a key part of the context we care about – and we want to restrict our system to sales territories in North America. We want to intelligently inject this knowledge into our AI Applications – hence, Context Intelligence.

In this blog, we’ll explore three fundamental patterns where Context Intelligence transforms AI development: Scoped-Resource Lists (ensuring you use the right data), Query Routing (directing queries to appropriate resources), and RAG Contextualization (making retrieval context-aware). These patterns aren’t mutually exclusive—most applications combine them—but each addresses a distinct challenge in building AI systems that align with business reality.

Pattern 1: Scoped-Resource Lists – Finding and Managing the Right Data

Scoped-Resource Lists ensure your AI application uses only appropriate, trustworthy data—not everything that’s technically accessible. In organizations with hundreds of databases, thousands of documents, and complex system landscapes, the challenge isn’t finding data; it’s finding the right data. Context Intelligence transforms this from a manual curation exercise into a systematic, maintainable approach.

Data Scopes and Data Lenses

Context Intelligence uses Data Lenses to define scope—temporal (last fiscal year), geospatial (European operations), or organizational (sales department data). Based on requirements from Project Definition, you either use an existing Data Lens or create one for your project. You then look through this lens to find assets that conform to the scope, because assets carry Data Scope classifications providing this context. A database table classified as “North America,” “Current Fiscal Year,” “Sales Operations” becomes visible through appropriate Data Lenses.

Data surveys—whether in Egeria, extensions to Egeria, or external tools—can analyze assets to assign Data Scope classifications automatically. As new sources come online or existing ones evolve, they’re appropriately classified or reclassified and discovered through relevant Data Lenses without manual intervention.

Honoring Policies

Scoped-Resource Lists aren’t just about relevance—they ensure compliance with policies around security, licensing, privacy, and governance. Context Intelligence connects policies to the data they govern. When you look through a Data Lens, you see not just what data exists within scope, but what policies apply. Customer forecast data requiring GDPR compliance appears differently for European versus North American applications—not through manual configuration, but because Context Intelligence applies relevant policies automatically.

This prevents developers from including data in training or RAG systems without realizing it violates licensing, privacy, or governance requirements. Policies flow from Context Intelligence into the scoped list, ensuring compliance by design.

Accommodating Evolution

Of course, Scoped-Resource Lists must evolve as business requirements and data change. When a system is archived, its Data Scope classification updates and Data Lenses requiring current operational data stop seeing it. When a merger adds new regional systems with proper classifications, relevant Data Lenses start including them. When policies change, the list respects updated constraints automatically.

This living approach means your AI application’s data access evolves with the business through the same Context Intelligence infrastructure that supports the broader organization.

Implementation Patterns

Egeria implements Scoped-Resource Lists through Digital Products. A Digital Product (like a Verified-Sales Scoped-Resource List) includes a list of resources that conform to a Data Lens, the details of the Data Lens definition, and, if available, Data Dictionary and Business Glossary. How much additional information to include is negotiated between teams.

Rather than querying Egeria at runtime for every data access decision, Egeria pushes or synchronizes the list to a local cache near the AI application. This provides lower runtime latency—the performance benefit of hardcoded lists with the maintainability of dynamic generation. It also provides resilience: if Egeria goes down, operations continue using the last certified version.

Pattern 2: Context-Driven Query Routing

Query routing addresses the reality that modern AI applications orchestrate multiple specialized resources. The challenge is determining which resource to use based not just on query text but on business context. Context Intelligence provides routing logic grounded in organizational understanding.

Multiple Models

Not all models excel at all tasks. You might use different foundation models—a general model for broad queries, a specialized legal model for regulatory questions—or even different model types like Small Language Models for quick lookup and Tabular Foundation Models for numerical analysis. Context Intelligence connects models to the business capabilities they serve. When a query relates to European regulatory compliance, it knows which model understands EU regulations. The routing is based on business context, not just keywords.

Multiple RAGs

RAG systems often partition data by scope dimensions—Sales documents in one partition, Finance in another, current guides separate from historical archives. These partitions improve retrieval quality and respect governance boundaries, but require routing queries appropriately. Context Intelligence provides the mapping: finance-related queries from finance users route to the Finance partition; European managers get EU-compliant documentation. The routing can be sophisticated, orchestrating retrieval from multiple partitions and combining results based on business context.

MCP Tool Selection and Parameterization

MCP tools expose system capabilities to agents, but which tool for which purpose? Egeria adds rich context to MCP tool definitions—business purpose, organizational units served, data accessed, governance requirements. It then provides lookup tables or APIs helping agents select the right tool based on context requirements. When a European sales manager asks for forecast data, Context Intelligence maps user context (EU sales organization, GDPR requirements) to the appropriate MCP tool with proper parameterization.

Implementation Patterns

Your AI application loads a local “Router Cache” delivered by Egeria, mapping business contexts to appropriate resources—models, RAG partitions, MCP tools. When a user asks about safety protocols, the application consults the cache to route directly to the correct partition. The cache includes not just destinations but parameters: model settings for query types, RAG thresholds for content types, MCP tool parameters for organizational contexts. Egeria maintains authoritative routing logic; the application consumes it as high-performance local lookups.

Pattern 3: RAG Contextualization

RAG Contextualization ensures retrieval understands and respects business context. The same query from different users in different organizational contexts may need to retrieve different content because different users may be asking different things—even with the same words.

The Challenge

Consider “lead management.” For sales teams: customer leads, prospects, pipeline. For manufacturing: the heavy metal, safety protocols, regulatory compliance. Traditional RAG systems retrieve based on semantic similarity alone, potentially mixing inappropriate content. Business context should influence retrieval: who’s asking, from which organizational unit, for what purpose, under which governance constraints.

Option A: Metadata Filtering

Most modern vector databases allow metadata fields alongside vectors. When indexing content, include metadata from Context Intelligence: organizational scope, business domain, timeframe, content authority. At query time, use Context Intelligence to build filters: where region == "EMEA" AND domain == "Sales" AND status == "Current". Semantic search happens within these boundaries. This approach is straightforward, performant, and works with existing embedding models. The tradeoff: embeddings themselves don’t understand context—you’re filtering after semantic matching.

Option B: Context-Aware Re-ranking

After initial semantic retrieval retrieves a broader set of candidates, the re-ranker scores each chunk against context requirements: user role, organizational scope, temporal relevance. Re-ranking can also leverage hierarchical relationships—scoring Germany higher than Europe when the user’s context is Germany-specific. Contextually appropriate content surfaces first, even if it wasn’t the top semantic match, and results are reordered before presentation to the user. This offers a middle ground—easier than context-augmented embeddings, more flexible than filtering alone. However, unlike filtering, re-ranking improves relevance but doesn’t enforce strict boundaries; inappropriate content might still appear lower in results.

Option C: Context-Augmented Embeddings

To make context affect actual vector positions, append Context Intelligence definitions before embedding: Text = [Original Content] + " [Context: Manufacturing, Domain: Safety, Lead=Heavy Metal]". When querying, similarly augment: Query = "lead management" + " [Context: Manufacturing]". The vector search finds manufacturing-contextualized content because embeddings encode that context. This improves retrieval quality for ambiguous terms but requires more complex indexing.

Choosing Your Approach

Organizations commonly use metadata filtering for strict governance enforcement, often adding re-ranking to improve relevance within those boundaries. Filtering provides hard boundaries while re-ranking optimizes results within those constraints. Context-augmented embeddings are emerging for specialized collections where semantic disambiguation is critical.

How These Patterns Work Together

In practice, these three patterns combine to create business-context-aware AI applications. Development begins with understanding from Project Definition: which business problems we’re solving, which stakeholders have which needs, which systems are in scope, what success looks like.

Context Intelligence translates business requirements into technical decisions. “European managers need forecasts” becomes: RAG must include GDPR-compliant data (Scoped-Resource Lists), queries route to EU-specific RAG partitions and MCP tools (Query Routing), and retrieval is contextualized for European regulatory environment (RAG Contextualization).

As developers work, they continuously query Context Intelligence: “Which system is authoritative for UK sales data?” “What governance requirements apply?” Answers are grounded in organizational metadata, not assumptions. The application itself leverages Context Intelligence at runtime—agents query which systems to use for specific user roles and regions, RAG systems retrieve based on user context, the AI adapts behavior based on current organizational structure.

Sales Forecasting: Development in Action

Let’s see how all three patterns work together in our sales forecasting example.

Scoped-Resource Lists – Context Intelligence defined a Data Lens for “Current Sales Forecasting” with scopes: temporal (last 3 years), organizational (sales departments), regional (NA, EU, UK post-merger), status (operational only). This identified four in-scope systems and excluded System C (archival), pre-merger systems, and product development forecasts.

Query Routing – The system routes based on user context. European managers’ queries route to EU-specific RAG partitions and the “get_eu_sales_forecast” MCP tool. Finance users get cross-regional aggregation routing to a tabular model. Regional managers get detailed data for their region through appropriately parameterized MCP tools.

RAG Contextualization – Sales forecasting documents were indexed with context metadata: region, product line, forecast horizon, regulatory context. When a UK manager queries about quarterly forecasts, retrieval filters to UK-specific content under current regulations. The same query from an EU manager retrieves different content—same semantic topic, different regulatory context.

The result: AI that understands organizational context, not just technical context. Developers made decisions grounded in business reality. The application adapts to organizational structure and governance—not through hardcoded rules, but through Context Intelligence.

What This Means for Data and Instrumentation

Development reveals what data is actually needed. Scoped-Resource Lists show which systems the AI must access. Query routing exposes which RAG partitions and MCP tools are critical. Contextualization reveals which metadata dimensions matter most. But knowing what data you need isn’t the same as having it prepared and ready for use.

This directly informs what comes next: Data Preparation. The Scoped-Resource Lists identify source systems, but someone needs to extract, transform, and provision that data. RAG indices need to be populated with chunked, embedded content. MCP tools need configured access to systems. The metadata required for filtering and re-ranking needs to flow from Context Intelligence into your vector databases. Development decisions create concrete data preparation requirements.

Development also creates instrumentation requirements: track which MCP tools are used, which RAG partitions provide useful answers, whether routing aligns with business intent, whether contextualization improves relevance. Context Intelligence helps design instrumentation connecting technical metrics to business outcomes—not just “retrieval latency” but “are European managers getting EU-compliant content?”

As development progresses, Context Intelligence evolves. New MCP tools are cataloged with their purposes. RAG content sources are documented and linked to business capabilities. Routing rules are captured as governance policies. This context serves not just the current project but future ones, building institutional knowledge.

Looking Ahead

With development strategies established through Scoped-Resource Lists, routing, and contextualization, the team knows what data they need and how they’ll use it. But knowing requirements isn’t the same as having data ready for consumption. How do you actually get data from source systems into RAG indices? How do you provision data for MCP tool access? How do you maintain synchronization as sources change? How do you ensure the metadata required for contextualization flows through preparation pipelines?

This is where Data Preparation becomes critical. In our next blog, we’ll explore how to translate Scoped-Resource Lists into actual data provisioning, feed RAG systems with appropriately chunked and embedded content, enable MCP tools with access to live systems, and maintain data quality throughout preparation pipelines. We’ll see how Context Intelligence tracks data flow from source to consumption, documents transformations, and maintains the connection between business context and prepared data.

Data Preparation bridges the gap between knowing what you need (from Project Definition and Development) and observing what’s working (through Instrumentation). It’s where strategy becomes operational reality.