AI agents are becoming central to engineering workflows - and token costs are scaling with them. Switching to a cheaper model helps at the margins, but the real cost driver is something most teams overlook: how context is structured before the agent ever sees it. Port's research team ran 12,000 queries across multiple conditions and models to understand why context structure matters more than model choice, and how platform engineers can dramatically reduce costs through disciplined LLM context optimization.
Main insights
- Messy, unstructured context forces agents to burn tokens reconciling conflicting data across multiple tools, making input tokens the dominant cost driver
- A well-designed context lake with pre-joined properties and mirrored data can reduce token usage by 58-80% compared to raw MCP connections
- Adding skill files to unstructured context actually increases costs - skills only deliver savings when paired with a structured context lake
- The key is analyzing your organization's repetitive queries and building a context layer optimized for those common patterns
Matar Peles, Field CTO at Port, and Aron Taylor, Program Manager and researcher, recently shared findings from an extensive study into AI agent token consumption. Matar works closely with platform engineering teams helping them build AI-native organizations, while Aron conducts research on how Port's platform can best serve customer needs in the rapidly evolving AI landscape.
You can watch the full discussion here if you missed it.
The hidden cost driver: Input token explosion
The research started with a structural observation. Cursor's analysis shows that the ratio of input to output tokens has been climbing steadily over time. Models are reading far more data than they're writing, which means input consumption has become the biggest variable in AI costs.
"If you think about input, you ask a question in a certain AI tool," Matar explained. "And then you see that over time the more models are becoming smarter, they have more data that they collect which leads to higher consumption of tokens."
This creates a compounding problem. When you connect an agent to 10 or 20 MCP (Model Context Protocol) servers - a common setup in tools like Claude or Cursor - the agent must hop between fragmented data sources, comparing results and reconciling conflicting information. Each hop burns tokens. The more fragmented your context, the more expensive every query becomes.
Port's team analyzed approximately 35,000 queries from thousands of organizations. Grouping these by topic revealed a clear pattern: certain questions repeat constantly, both from humans and from agents running in automated workflows.
What makes queries expensive
The research identified two distinct query categories. Repetitive, high-frequency queries - like "who owns this service?" or "who is currently on call?" - run dozens or hundreds of times per day, especially in automated agent workflows. One-off queries - like "build me a graph" or "create an artifact" - happen occasionally and don't justify optimization effort.
"We're not going to focus on those," Aron noted about the one-off queries. "We're focusing on the really popular ones."
The cost difference is significant. When an agent answers "who is on call for the payment service?" by querying multiple MCPs, it must:
- Fetch all services from one source
- Fetch all PagerDuty services from another
- Find the on-call person for each PagerDuty service
- Cross-reference to match the payment service to its PagerDuty entity
- Return the final answer
Each step consumes tokens. Multiply this across hundreds of daily queries, and costs spiral quickly.
Building a context lake that works
Port's solution centers on a context lake - a structured, graph-based representation of organizational context that reduces query hops through strategic data modeling. The key mechanism is using mirror properties and aggregations to pre-join frequently accessed relationships.
Instead of forcing an agent to traverse from service to PagerDuty service to on-call person, the context lake includes a mirrored "on call" property directly on the service entity. The agent looks up the service once and immediately retrieves the on-call information - no multi-hop traversal required.
This approach requires discipline. You must analyze your organization's actual query patterns and model your context lake around them. A generic context lake won't deliver these results. For maximum impact, your context lake must also provide:
- Reconciliation: A single source of truth when different tools report conflicting data
- Real-time updates: Stale data renders even efficient queries useless
- Easy querying: Well-designed APIs and MCP interfaces that agents can use without friction
- Rich metadata: Detailed properties and relationships that give agents the context they need
The experiment: Four conditions, three models, 12,000 runs
To validate their hypothesis, Port's research team designed a controlled experiment with four conditions:
- Claude plus MCPs: The baseline - an agent connected to multiple MCP servers with no additional structure
- Claude plus MCPs plus skill file: The same setup with a skill file attempting to guide the agent
- Context lake: Port's structured context layer accessed via API
- Context lake plus skill file: The structured context with additional guidance
They ran 1,000 common SDLC queries across all four conditions, then repeated the entire experiment across three models: Haiku, Sonnet, and Opus. This produced 12,000 total query runs with consistent, comparable data.
The results were striking. For Opus, the most expensive model tested, the baseline condition cost an average of $1.76 per query. The context lake plus skill file condition cost just $0.35 per query - an 80% reduction. Even without a skill file, the context lake alone delivered 58% savings across all models.
The skill file surprise
One of the most unexpected findings challenged a common assumption in AI engineering. Adding a skill file to the baseline condition - Claude plus MCPs - actually increased costs rather than reducing them.
"The skill file tried to tell the agent where to look," Aron explained, "but what ended up happening is the agent kind of went step by step by step in that skill file and ended up adding cost rather than reducing cost."
Without structured context, the skill file became a liability. The agent followed instructions methodically, making more tool calls and burning more tokens in the process. Only when paired with a well-designed context lake did skill files deliver value - helping agents navigate the optimized structure even more efficiently.
This has direct implications for platform teams: skill files are not a silver bullet. If your underlying context is messy and fragmented, adding more guidance won't solve the fundamental problem. It may make it worse.
Practical steps for platform engineers
Context discipline directly translates to cost control. Treat context management as a first-class concern, not an afterthought.
Start by instrumenting your current setup. Track which queries your agents and users run most frequently. Look for patterns - the questions that repeat daily or hourly across different teams and workflows. Port's platform includes audit logs for every query, making this analysis straightforward.
Model your context lake around those patterns. If "who owns this service?" is a top-10 query, ensure ownership is a direct property on your service entities - not something that requires traversing multiple relationships. If "what's the status of this deployment?" runs constantly, mirror deployment status onto the relevant service or environment entities.
Keep context current. The context lake must ingest data in real time from authoritative sources. Stale data undermines even the most efficient query structure.
Provide clean interfaces. Whether through API, CLI, or MCP, make it easy for agents to query your context lake. Port's MCP server acts as a gateway, allowing agents to access structured context through a familiar interface while benefiting from the optimized data model underneath.
If you enjoyed this, find here more great insights and events from our Platform Engineering Community.
For more comprehensive guidance, check out the Platform Engineering Certified Architect Course and learn best practices from industry experts.
Key takeaways
- Analyze before optimizing: Don't build a generic context lake. Study your organization's actual query patterns and optimize for the repetitive, high-frequency questions that drive the most token consumption. This is where LLM context optimization delivers the highest return.
- Structure beats guidance: A well-designed context lake with pre-joined relationships delivers 58% cost savings on its own. Skill files only help when the underlying context is already structured - otherwise they can increase costs.
- Input tokens are the real cost driver: As models evolve, they read more data relative to what they write. Reducing the amount of context an agent must process for common queries has a direct, measurable impact on costs - regardless of which model you use.
- Context discipline scales with agents: The more agents you deploy, the more critical structured context becomes. What seems manageable with one or two agents becomes chaotic and expensive at scale without a shared, optimized context layer.
