The agent works in the pilot. Then the second customer arrives.

The workflow is familiar. The operating environment is different. Purchase orders live in another system. Approval thresholds vary by business unit. A status called “complete” means goods received at one customer and invoice reconciled at another.

Engineering starts collecting exceptions. Product starts expanding the onboarding checklist. The deployment team translates another company’s operating model into prompts, mappings, and custom logic.

That work belongs in the architecture.

A context graph gives teams a way to represent reusable product knowledge alongside customer-specific rules, relationships, and decisions. The objective is concrete: deploy the same product without rebuilding its understanding of the business at every account.

Customer differences need an explicit representation

Consider a procurement agent assessing whether an invoice is ready for payment.

The product understands invoices, purchase orders, receipts, discrepancies, and approval workflows. Those concepts apply across customers.

The payment decision depends on local context.

In an illustrative deployment, one customer allows a small delivery discrepancy and requires finance approval above $25,000. Another requires complete receipt before payment. A third applies different rules to different subsidiaries.

The agent needs to connect the invoice to the applicable policy, the relevant business unit, and the authorized approver. Retrieving a policy document addresses only part of that requirement. The deployment also needs to establish which policy governs this transaction.

This is where the distinction between product knowledge and customer context becomes operational.

Product knowledge describes the workflow. Customer context determines how that workflow applies.

A context graph makes those relationships usable

For enterprise agents, a useful context graph connects business entities with the rules, people, and decisions that govern them.

An invoice connects to a supplier, a purchase order, and a receipt. Its business unit connects to an approval policy. That policy connects to an owner and an effective date. A documented exception connects to the circumstances under which it was approved.

Those relationships give the agent a structured path through the business.

They also give reviewers something concrete to inspect. A recommendation should expose the records and rules that supported it. A missing approval relationship should remain visible. An unresolved policy conflict should trigger escalation.

The graph’s value comes from those operating properties. Storing business nouns in a graph database is insufficient.

Anthropic’s guidance on context engineering emphasizes selecting relevant information for the task and designing clear tool interfaces. The same discipline applies here: the graph should supply the context required for a particular decision. Dumping the entire business into the context window adds noise. anthropic.com

Structure the knowledge. Retrieve the relevant slice.

Reuse the product model. Resolve the customer environment.

A repeatable deployment architecture needs a clear boundary between the product model and each customer’s configuration.

The product model contains shared concepts, supported workflows, and standard relationships. Customer configuration supplies system mappings, local definitions, policies, and ownership.

For the procurement example, the shared model defines what an approval threshold means. Customer configuration identifies the applicable threshold and approver. The retrieval path resolves both in the scope of the current customer.

That boundary should be explicit and testable.

If a local policy overrides a product default, precedence must be defined. If a required mapping is absent, the system must expose the gap. If two customer policies conflict, the model should not select whichever passage sounds more plausible.

These are configuration and governance problems. Treat them that way.

For CTOs, this creates a maintainable separation between product releases and customer configuration. For CPOs, it creates a clearer account of what the product supports, what requires configuration, and what remains outside scope.

Customer differences become managed inputs.

Shared product knowledge requires customer isolation

Reusing a product model does not authorize sharing customer context.

A supplier exception approved at one customer must stay within that customer’s boundary. The same applies to contracts, approval relationships, and corrections learned during use.

Tenant isolation must cover the entire path through retrieval, memory, caching, and tool execution. It must follow the request after authentication.

AWS’s SaaS architecture guidance treats tenant isolation as an explicit architectural concern across both dedicated and pooled resources. Shared infrastructure requires controls that prevent one tenant from accessing another tenant’s resources. docs.aws.amazon.com

Apply that requirement to agent context.

Test the same request under different customer identities. Verify that customer-specific rules stay scoped correctly. Test missing identity and conflicting context. Enforce authorization in the systems executing the operation.

A context graph informs the decision. Access controls enforce the boundary.

Measure whether the deployment work is becoming reusable

Time to launch is useful. It does not explain what engineering built during onboarding.

Track the expert hours required to establish customer context. Record how many mappings reuse existing product concepts. Measure how many exceptions require custom code. Track the maintenance effort after a product or customer policy changes.

These measures expose whether deployment work is becoming a reusable asset.

A customer that launches quickly but requires persistent engineering intervention still carries a substantial operating cost. A reusable context model should reduce repeated discovery and make customer differences easier to review.

The architecture must improve the next deployment.

How Genloop applies this model

Genloop organizes data, processes, decisions, and people in a Living Context Graph. Its deployment approach captures product context once, then maps each customer’s systems, policies, and approvers onto it.

Its published onboarding workflow describes approximately two weeks to capture product context and approximately three days to activate each customer. Those figures describe Genloop’s stated workflow, rather than a universal deployment benchmark. genloop.ai

The product context can serve agents through MCP or APIs. Each customer’s context remains isolated, with deployment options that include the customer’s cloud, on-premises infrastructure, and air-gapped environments. genloop.ai

The architectural objective is the important part: preserve reusable product understanding while representing each customer’s operating reality.

Build the product’s understanding once. Make customer differences explicit. Maintain both.

That is how context becomes infrastructure.

FAQ

What is a context graph for AI agents?

A context graph connects business data with the rules, ownership, and decision history needed for a task. It gives an agent a structured way to identify applicable context and gives reviewers a way to inspect the basis of its response.

How does a context graph work with RAG?

RAG supplies retrieved information to a model. A context graph adds explicit relationships that help determine what information applies. A deployment can use graph relationships to select context and document retrieval to supply supporting policy text.

Does every customer need a separate product model?

The shared product model can be reused. Customer-specific mappings, policies, permissions, and exceptions must remain scoped to that customer. The architecture needs clear precedence rules for combining the two.

Does the graph authorize an agent to act?

Authorization belongs in the execution path. The graph can identify an approver or applicable policy, but the tool and underlying application must enforce access and action permissions.

How should a team begin?

Choose one workflow with repeated customer-specific configuration. Model its shared concepts, map two customers’ differences, and test both against the same scenarios. Measure the expert effort required for the second deployment.