Your Coding Agent Has a Context Problem, Not a Model Problem

AI coding tools are getting very good at writing code. After using them on real projects, though, I have found that the model is only one part of the system.

The harder problem is context.

A coding agent needs to understand the current codebase, know the business and architectural decisions behind it, remember important discoveries from previous sessions, and do all of that without loading thousands of irrelevant tokens into every conversation.

I have been building a local agentic coding environment around that problem:

OpenCode → JetBrains Context + ContextHarbor → local or cloud LLMs

The principle is simple: give the agent a different source of context for each kind of question.

The agent harness

I use OpenCode as the coding-agent interface. The agent can inspect a repository, plan a change, implement it, run validation, and call external tools. I can also separate planning, implementation, and review responsibilities without putting the entire project into every agent's prompt.

The model remains replaceable. A smaller model can handle routine work, while a stronger reasoning model can take on architecture, difficult debugging, or review. The engineering workflow stays stable even when the model changes.

Current code comes from the repository

For implementation knowledge, I use JetBrains Context through its jbcontext tools. It provides semantic code search for questions such as:

• Where is this behavior implemented?
• Which files participate in this feature?
• What depends on this function?
• What could this change affect?

This avoids repeatedly asking an agent to read large sections of a repository. More importantly, it reinforces a useful rule:

The repository is the authority for how the system works today.

An agent should retrieve current implementation details from the code, not rely on stale documentation or memories from an earlier conversation.

Project knowledge needs a different home

Code rarely explains the full reason behind a decision. Requirements, meeting notes, business rules, architectural trade-offs, and stakeholder clarifications often live elsewhere.

That is the role of ContextHarbor, the private knowledge and memory layer I am building for project context. Coding agents access it through the Model Context Protocol and retrieve only the material relevant to the task.

Instead of placing a 30-page requirements document into a prompt, the agent can ask for the decisions and constraints connected to the feature it is changing.

ContextHarbor also stores project-specific memory: an architectural decision made during a discussion, a constraint discovered during implementation, or a clarification that future agents should not have to rediscover. The project owns that memory, rather than an individual chat session.

Each repository maps to its own ContextHarbor project. That isolation matters because context from one project should never silently influence another.

The practical workflow

A typical task follows this loop:

1. Retrieve: query ContextHarbor when requirements, architecture, or earlier decisions matter.
2. Understand: use jbcontext to locate the current implementation and its dependencies.
3. Plan: decide how the change should fit the existing system.
4. Build: implement the smallest coherent change.
5. Validate: run the project's tests, checks, and pre-commit gate.
6. Remember: preserve only durable decisions or discoveries for future sessions.

The context layers stay deliberately separate:

The coding model does not need to know everything. It needs to know where to find the right information.

Context quality matters more than context volume

The objective is not simply to make an agent write code faster. It is to give the agent enough organizational and implementation context to make good decisions without continuously feeding it enormous prompts.

That shifts the important question from “Which model writes the most code?” to “Which system gives the model the right context, tools, memory, and engineering guardrails?”

Better models will help. But for real software projects, better context architecture is what makes an agent reliable.

Continue the discussion

If you are designing an agentic engineering workflow or a private knowledge layer for your team, book a CTO consultation.

You can also explore ContextHarbor and its approach to durable, project-scoped context.