Graph Engineering in Production: Query Patterns and Performance
Graph Engineering in Production: Query Patterns and Performance
This is the second post in our Graph Engineering series. We covered the architectures behind MAGMA and GAM in the first post. Now we get into the practical details of making graph queries fast enough for real-time agent use, and a newer development - trainable graph memory.
Four Query Patterns for Agent Memory
The MAGMA paper identifies four traversal patterns, each corresponding to a common agent need:
Path queries find the shortest connection between two entities. The agent starts from one entity and traverses edges until it reaches the target. Used when the agent needs to understand how two pieces of information relate - for example, how a user is connected to a support ticket or how a change in one system affects another.
Neighborhood queries find all entities within K hops of a starting point. Used for broad context gathering - what happened around this event, who was involved, what tools were used. The agent needs surrounding context to understand a situation fully.
Pattern matching finds subgraphs matching a known structure. Used when the agent recognizes a situation similar to past experience. If the graph contains a subgraph matching "customer reports issue -> agent escalates -> engineering fixes -> customer confirms," the agent can predict the likely successful resolution path.
Causal queries trace cause and effect chains through the causal graph. Used for root cause analysis. The agent starts from an observed effect and walks backward through causal edges to find the originating cause.
Performance Optimization
Graph queries can be slow if the graph is large and queries are unconstrained. Three optimization strategies make them fast enough for real-time agent use:
Index-guided traversal: maintain indexes on commonly queried relationship types and entity types. The traversal starts from the index rather than scanning the full graph. For example, an index on "user_id" relationship type means the agent can directly find all edges connected to a specific user without scanning the entire entity graph.
Query budgeting: limit the number of hops and the branching factor. A neighborhood query limited to 3 hops with a max of 10 edges per node keeps query times under 100ms even for graphs with millions of edges. The budget is configurable per query type - path queries might need more depth, while neighborhood queries need more breadth.
Caching: frequently used query results are cached with a configurable TTL. The cache is invalidated when the consolidation process updates the relevant subgraph. Common queries like "find all active users" or "get recent tickets for customer X" hit the cache most of the time.
Trainable Graph Memory
A 2025 paper, "From Experience to Strategy," proposed a different approach to graph memory that adds a learning loop. Instead of a static graph populated by a consolidation process, the graph weights are optimized via reinforcement learning based on reward feedback from downstream tasks.
The system extracts agent trajectories into a structured decision graph. Each node represents a decision state, each edge represents a transition. Groups of related edges form meta-cognitive strategies - high-level principles like "when the user asks for data, first verify permissions" or "when the agent is unsure, present options before acting."
The key innovation: these strategies are not fixed. The system estimates the utility of each meta-cognition by comparing outcomes with and without its guidance. Strategies that consistently improve outcomes have their weights reinforced. Strategies that do not are gradually discarded.
The trained graph is integrated into the agent training loop through meta-cognitive prompting - the top-K strategies for a given situation are automatically injected into the agent context as strategic priors.
The results showed improved reasoning accuracy at inference time, faster convergence during RL training, and generalization across diverse tasks.
Integration with Agent Memory
The graph is not a separate system - it is part of the memory architecture. When the consolidation process runs, it extracts not just facts but also relationships. Facts go to semantic memory. Relationships go to the graph. They are two views of the same knowledge.
The agent retrieves from both simultaneously: semantic memory for facts about entities, graph for relationships between entities. Together they provide a richer understanding than either alone.
The Graph-Guided Multi-Factor Retrieval strategy from GAM paper illustrates the pattern: retrieval starts from high-level semantic themes in the topic associative network, then drills down to precise episodic details in the event progression graph using integrated temporal, confidence, and role-based signals.
Read the full Context Engineering series: orioverse.com/blog/what-is-context-engineering