Context – Bridging the AI Agent’s Blind Spot

Context – Bridging the AI Agent’s Blind Spot

In the last post, I introduced how to leverage Kiro’s Steering feature to automatically record task completion history and use it as persistent context for subsequent work. This time, we’ll dive into a more technical approach to feeding context to the AI agent, focusing on securing code quality and stability.

For those interested in enterprise-scale context management, I’ve also written about building an AWS-based RAG pipeline that can handle institutional knowledge at scale.

AI agents generally tend to do only what they are asked. If you request a modification to a specific function in the source code, the agent typically changes just that part. The problem arises when the modified function is referenced in multiple other locations. While agents sometimes figure out related code to adjust, they often fail to consider the full side effects.

Ultimately, unless the developer provides a perfect prompt that accounts for the entire code flow and includes all relevant parts, it’s difficult to produce high-quality code in large projects. This issue grows exponentially with the project’s size.

Limitations of Existing Context Provisioning Methods

To address this, several services have emerged that turn the entire code repository into a Knowledge Base, delivered to the agent via RAG (Retrieval-Augmented Generation) or an MCP (Model Context Protocol) Server.

• Claude Context: This is an open-source VSCode plugin for Anthropic’s Claude code agent. It embeds code chunks and stores them in a vector database. When a query is made, it uses semantic search to find relevant code, inserting it into Claude’s prompt context. This allows it to handle large codebases (millions of lines) by delivering only the necessary information.
• Codebuddy: An AI coding helper for JetBrains IDEs and VSCode. Like Cursor, it scans and stores the entire codebase in a vector database, enabling the agent to answer questions about the repository.

However, these approaches commonly require cloud access or external Database. This poses a constraint for organizations with restrictive software usage policies or those in isolated network environments (e.g., air-gapped systems). Furthermore, calling LLMs is not cheap, as costs accrue based on usage.

These issues could be solved with a local knowledge base that can be easily built and used as open-source. This is the motivation behind the local context knowledge base I’ve developed, which I introduce here.

Local Context Bank – Converting the Local Codebase into a Knowledge Graph

One of the key methodologies in context engineering is ‘retrieving relevant knowledge from a vector store.’ GraphLoom is being developed with the goal of implementing this method, optimized for the local environment.

The core objectives GraphLoom aims to achieve are:

• Independent Operation: No need to call external APIs or remote MCPs, allowing usage in isolated environments.
• Multi-Source Context: Ability to provide semantic context from various documents, including code, specs, design decisions, and implementation summaries.
• Modular Context: Support for adding context from independent code packages (e.g., back-end, front-end, microservices).

Local Context Bank combines two core technologies to provide semantic search, impact analysis, and specification-code synchronization for a local codebase.

Design

1. Modeling the Codebase as a Graph: Understanding Relationships for Impact Analysis

Local Context Bank stores the source code as a graph of relationships between functions, classes, and modules. When a part is modified, it traverses this graph to find all related nodes, notifying the agent of potential impacts.

This approach is crucial for inferring side effects. For example, if you change function A, graph traversal identifies other functions that call it, related data structures, etc., prompting the agent to review and modify them together.

It constructs a Code Knowledge Graph (CKG) by using Abstract Syntax Tree (AST) parsing (via tools like Tree-sitter) and LSP (Language Server Protocol) to extract dependency relations (function calls, variable references, import relationships). This CKG makes it easy for the agent to quickly grasp the scope of potential changes.

2. Contextual Retrieval via Vector DB: Semantic Search for Intent

In addition to the graph structure, Local Context Bank embeds the project’s code and documentation and stores them in a local vector database. When the agent needs information, it can query naturally, and the system retrieves the semantically relevant parts using semantic search.

For instance, if the agent asks, “Find the configuration related to this function,” the vector DB finds code snippets or specs with high similarity and provides them as context. This RAG-based approach helps overcome the context window limitations of the LLM by retrieving only the relevant code from large repositories. Since it avoids reading all files for every request, it also offers cost-saving benefits in a local environment.

Demo: GraphLoom Workflow

I named this software gloom. Here are the steps for indexing the Local Context Bank project locally to show how the Agent utilizes the MCP.

1. Initialization: Set up the GraphLoom environment and local vector DB.

1. Workspace Creation: Specify the project directory for analysis.

1. Indexing & Graph Build: Parse code and documents to build the knowledge graph and vector DB.

1. Impact: You can query related nodes for a specific code change through CLI.

1. MCP integration: The Agent queries the context using natural language.

1. Results: Agents can utilize the provided output as context.

Expanding the Potential of Coding Agents

I built and used this software myself, and it reduced the time it took to provide context to coding agents. Software developers using coding agents will need context management capabilities when conducting software engineering. If you can’t use a commercially available service, you can implement something similar like this to improve the agent’s efficiency.

The ultimate goal of (Local) Context Bank is to reduce the time developers spend manually managing context and encourage agents to generate high-quality code that considers side effects.