How to save up to 80% in AI costs with a Context Lake

Part 1: The Problem

AI costs are rising, and the instinct is to blame the model. Teams switch from Opus to Sonnet, from Sonnet to Haiku, add caching, tighten prompts. Some of that helps at the margins. But it treats a symptom.

The real culprit is messy context.

Every time an agent answers a question about your engineering environment, it has to gather information from wherever that information lives. Service ownership is in GitHub. Incidents are in PagerDuty. Tickets are in Jira. So the agent calls GitHub, takes what it gets, calls PagerDuty, reconciles the naming mismatch between what GitHub calls the team and what PagerDuty calls the service, calls Jira, and reasons through the results.

That's for one fairly simple query. Now multiply it.

Gartner calls this context accumulation: the compounding effect of agents assembling a fresh context window at every step from enterprise data, tool schemas, system instructions, and conversation history. The agent reinvents the same connections every single time. The 1,000th time a query runs costs the same as the first.

Input context is the dominant cost in agent queries. And in a fragmented data environment, every query drags in more of it than it needs to. Engineers connect more MCP servers to give agents broader access, which increases the surface area of every query, which increases the token cost, which makes the problem worse.

The repetition problem

What makes this expensive at scale isn't the cost of one query. It's that the same queries run hundreds or thousands of times, and each run pays the full assembly cost from scratch.

This happens in two ways.

The first is humans. Engineers ask the same types of questions constantly. "Who's on call for this service?" "Does this team have any open incidents right now?" "What was deployed recently that might have caused this?" These aren't exotic queries. They're the daily operating questions of anyone running software in production. Across a 2000-person engineering org, some version of "who owns this?" gets asked dozens of times a day through Slack bots, internal tools, and AI assistants.

The second is workflows. Agentic workflows ask these questions without anyone noticing. A deployment workflow checks service ownership before routing approvals. An incident triage automation looks up on-call before paging. A security scanner queries team assignments before filing tickets. Each step in each workflow is a fresh context assembly. A deployment pipeline that runs 50 times a day and asks "who owns this service?" at each step is running that query 50 times a day, every day, forever.

Part 2: The Experiment

We wanted to know exactly how much a semantic layer can affect agent cost, so we ran a controlled experiment.

We pulled tens of thousand of agent queries from production, categorized them, and ran a representative sample of 1000 SDLC queries across four conditions and three models. We measured token usage on every query.

The four conditions

Claude + MCPs (baseline). The agent had direct access to GitHub, Jira, and PagerDuty via their respective MCP servers, the same setup most teams run today. The agent had to figure out which tool to call, in what order, and how to reconcile results that came back in different formats with different naming conventions.

Claude + MCPs with a skill file. Same tool access, but with a markdown skill file that describes what each tool is authoritative for and outlines a lookup strategy for each query type. The intent was to help the agent take more direct paths.

Context lake. The agent had access to Port's MCP server only: a unified software catalog where GitHub, Jira, and PagerDuty data are already pre-integrated. Services already have their PagerDuty service, GitHub repository, and Jira project linked as relations.

Context lake with a skill file. Same catalog access, plus a skill file optimized for the catalog's structure: a routing table that maps query type to the entity and field that answers it.

The results

In percentage terms vs. the baseline:

A few things stand out.

The savings hold across every model. Context lake + skill is ~80% cheaper than direct MCPs whether you're running Haiku, Sonnet, or Opus. The data layer improvement isn't model-specific.

Expensive models become viable for everyday queries. Opus at $1.761 per query is something you'd normally reserve for critical tasks. With a context lake, that same query costs $0.354. Still the most expensive option, but within reach for common use.

Adding a skill file to fragmented data made things worse. We expected routing guidance to help agents take more direct paths. Instead, agents followed the skill file like a checklist, executing every step in sequence rather than reasoning about what they actually needed. The skill file turned optional steps into mandatory ones.

On the context lake, the skill file worked differently. Because the data was already joined, there were no redundant calls to eliminate. The skill file's only job was to point the agent toward the right entry point: a much smaller, better-defined task.

Skill files work better when the underlying data is well-structured. But they often don't compensate for fragmentation. They amplify whatever structure is already there.

Part 3: How a Context Lake Works

A context lake is a unified semantic layer that connects your organizational data (services, teams, incidents, deployments, tickets) into a single structured model with explicit relationships. Agents query it instead of querying individual tools.

Two characteristics make it more efficient than a direct-to-MCP setup.

Pre-joined data

In a direct MCP setup, the agent connects entities itself. It uses partial results from tools that don't know about each other, resolves naming mismatches mid-flight, and reasons about how things relate on every query.

In a catalog, a service entity already knows its owning team, its repository, its PagerDuty service, its Jira project. Those aren't foreign keys the agent has to resolve. They're properties on the object. The agent reads one thing and gets the full picture.

The efficiency gain isn't just fewer API calls. It's that the agent never has to reason about how things connect, because that reasoning was done once at ingestion time and baked into the data model.

Data shortcuts

Mirror properties and aggregation properties let you pre-compute values that agents would otherwise derive on the fly.

A mirror property copies a value from a related entity onto the source entity at sync time. service.oncall isn't a relation the agent traverses. It's a field already populated by pulling pagerdutyService.oncall from the linked PagerDuty entity every time PagerDuty syncs.

An aggregation property pre-computes a calculation across related entities. service.open_incident_count isn't something the agent counts by querying each incident one by one. It's stored as a running total, updated whenever the incident list changes.

When an agent counts incidents or looks up on-call by querying each tool individually, it's spending tokens on work the catalog could have done once. Shortcuts move that work to ingestion time. Every subsequent query is cheaper.

A query, in detail

Here's how this plays out with a query that appeared frequently in our research :

"Does the service owned by team X have any open incidents?"

This looks simple but it isn't so straightforward. To answer it, the agent needs to know which services team X owns, then check each one for open incidents. In a fragmented environment, that's two separate traversals across tools that don't share a data model.

With direct MCPs, the agent has to:

1. Call GitHub MCP: look up team X's repositories via CODEOWNERS or team membership; returns a list of repo names (payment-service, auth-service, notifications-service)
2. For each repo, call PagerDuty MCP: search for the corresponding PagerDuty service. Repo names and PagerDuty service names don't match (payment-service in GitHub is payment-api-prod in PagerDuty), so the agent tries variations for each one
3. For each matched PagerDuty service, call PagerDuty MCP again: query for incidents with status triggered or acknowledged and count them

If team X owns three services, that's at minimum seven tool calls, with name resolution errors possible at step 2 for each service. The agent isn't answering the question yet. It's still figuring out what to ask.

With a context lake, the agent:

1. Queries the catalog for all service entities where owning_team = team X and open_incident_count > 0

That's a single filtered lookup. The owning_team relation was established when the GitHub integration matched each repository to a team. The open_incident_count field is an aggregation property pre-computed from linked PagerDuty incidents, updated continuously as incident statuses change. The catalog already did the join. The agent reads the result.

The skill file entry for this query pattern maps the natural language question to a single catalog filter: find all service entities where owning_team equals team X and open_incident_count is greater than zero.

The agent doesn't traverse the team-to-service relationship at query time. It doesn't resolve naming mismatches between GitHub and PagerDuty. It runs a filter against data that was already assembled at ingestion.

Part 4: Building Your Context Lake

Building a context lake isn't a separate project from setting up Port. It's what happens as you configure your catalog. These five steps take you from a fragmented MCP setup to a unified context layer.

Step 1: Define your data model

Start by deciding what entities matter to your organization and how they relate. The core set for most teams:

• Service: the central entity. Everything else relates to it.
• Team: owns services; has an on-call schedule
• Deployment: records of what shipped and when
• Incident: active and historical PagerDuty (or similar) events
• Repository: the GitHub repo backing a service

Port blueprints come in two types, and understanding the distinction shapes how you build.

Generic blueprints represent your organization's own abstractions: service, team, deployment. These exist independent of any specific tool. They're what agents query when they need to answer questions like "who owns this?" or "what's currently broken?" Port creates service and team during onboarding as a starting point. These are the spine of your catalog; everything else connects to them.

Integration blueprints represent tool-native entities. When you install the PagerDuty integration, Port creates a pagerdutyService and pagerdutyIncident blueprint. GitHub creates githubRepository and githubTeam. Jira creates jiraProject and jiraIssue. These blueprints are defined by the integration: their schema comes from the tool's API, and Port populates them on the integration's sync schedule.

The two types play different roles. Integration blueprints are your source material. Generic blueprints are your interface. An agent querying "does this service have open incidents?" doesn't need to know that incident data lives in PagerDuty; it reads service.open_incident_count, a property on a generic blueprint that was computed from pagerdutyIncident entities behind the scenes. Integration blueprints feed the generic ones; agents use the generic ones.

This is also why the relations step (Step 3) matters so much: it's where you wire integration blueprints to generic blueprints, turning tool-native data into a connected model agents can query in one shot.

Start with the entities that answer the queries your agents run most often. Extend later.

Step 2: Connect your tools

Port has plug-and-play integrations for GitHub, Jira, PagerDuty, and 100+ other tools. Installing an integration creates blueprints for that tool's entities, defines a default mapping from the tool's API responses to Port properties, and begins ingesting data on a continuous sync schedule.

For most teams, GitHub, PagerDuty, and Jira cover the bulk of agent queries. Install those three and you have the data foundation.

Step 3: Wire the relations

Integrations create entities, and Port's presets establish some relations out of the box: PagerDuty incidents are linked to their service automatically, for example. But the relations that describe your organization's structure won't be there by default. These are the ones worth investing in.

The key relations to establish:

• Service → Owning Team: use GitHub CODEOWNERS or a naming convention to match repositories to team entities
• Service → PagerDuty Service: match by service name or a label you put on PagerDuty services pointing to the Port identifier
• Incident → Service: Port's PagerDuty integration does this automatically using a search rule that matches the incident's service ID to the pagerdutyServiceId property on your service entities
• Service → Jira Project: match by project key or a custom field

Once these relations exist, the catalog knows that payment-service is the same thing as payment-api-prod in PagerDuty and the PAY project in Jira. The agent doesn't have to figure that out anymore.

Step 4: Add data shortcuts

With relations in place, you can pre-compute values that agents would otherwise derive on the fly.

Mirror properties pull values from related entities and store them directly on the source entity. To surface on-call information at the service level, add a mirror property named oncall to your service blueprint and point it at the oncall field on the linked PagerDuty service entity. Port keeps that field populated on every sync, so service.oncall is always current. The agent reads a property, not a relation chain.

Aggregation properties pre-compute counts and calculations across related entities. To give every service a live incident count, add an aggregation property named open_incident_count that targets linked PagerDuty incident entities, filters to those with a status of triggered or acknowledged, and stores the result as a count on the service. Port recomputes this whenever the incident list changes. The agent reads a number, not a list it has to count itself.

Start with the properties that show up in your most common queries. A small number of well-chosen shortcuts covers the majority of agent token spend.

Step 5: Write the skill file

The agent doesn't need to know how to find information; the catalog handles that. It just needs to know where the answer lives. That's the main purpose of the skill file within the context lake.

A routing table for the most common query patterns might map on-call lookups to service.oncall, open incident checks to service.open_incident_count, ownership questions to service.owning_team, recent deployments to the service's deployments relation sorted by date, and open ticket counts to service.open_ticket_count.

The skill file's job is to eliminate the agent's first decision ("where do I look?"), not walk it through a procedure. If your skill file has conditional logic or multi-step lookup strategies, the data probably isn't joined enough yet.

Part 5: The Organizational Side

Platform engineering owns the data layer

A context lake needs an owner. The natural fit is platform engineering. They control the integrations, define the data model, and maintain the shared infrastructure everything else depends on. That's what they already do; the catalog is an extension of that responsibility.

What's changed with AI is the scope of who consumes the data. Before agents, developers used the IDP directly: they clicked through self-service actions, looked up service owners, checked deployment status. Now agents consume it independently, on behalf of developers across the org. Platform engineering's job is to make that shared layer reliable enough that both humans and agents trust it as their first source of truth.

The model that works: platform engineering owns the core data model (the blueprints, relations, and integration mappings) and keeps it accurate. Teams build on top of it: dashboards, automations, agents that use the catalog as their data source. The platform team sets the foundation; they're not the bottleneck for everything built on it.

Building a source of truth that earns trust

The goal isn't to convince teams to use the catalog. It's to make the catalog accurate and complete enough that using it is the obvious path. When engineers and agents get reliable answers from one place, that's where they go.

This is more achievable than it sounds, because the same AI capability that makes the context lake valuable also makes it easier to build and maintain. Agents can help map integrations, fill in missing relations, and surface gaps in the data model. Building a well-connected catalog doesn't require the same manual effort it once did. The work that used to take weeks of careful data modeling can now be done iteratively, with AI doing much of the assembly.

The result is a virtuous cycle: a better-connected catalog produces more reliable agent answers, which builds trust, which means more queries flow through the catalog rather than directly to individual tools.

Replacing MCP sprawl with a shared layer

Without a catalog, every team solves context independently. One team builds an agent that calls GitHub and PagerDuty directly. Another team builds a different agent that does the same thing differently. A third connects a new MCP server that partially overlaps with both. The result is a proliferation of fragmented context pipelines, each maintained separately, each with its own naming conventions and failure modes.

A context lake replaces that sprawl with a single, shared layer. Agents across the org query the same catalog, built on the same data model, with the same relations. Platform engineering configures it once; everyone benefits. The alternative isn't just expensive in tokens — it's expensive in the engineering time spent maintaining parallel pipelines that all answer the same questions.

Conclusion

Agent cost is a data problem. Fragmented context makes every query more expensive than it needs to be, and that cost compounds with every workflow and every model upgrade. A context lake addresses it at the source: by pre-integrating data, establishing relations, and pre-computing common values, it reduces what agents have to figure out at query time.

The experiment showed up to 80% cost reduction across every model tested. The steps in Part 4 show how to get there. The organizational foundation in Part 5 shows who needs to own it.

The savings are real, they're immediate, and they grow as the catalog grows.

*To learn more about Port's context lake, visit https://www.port.io/platform/context-lake