Coding agents: Tools, memory and repo context in practice

Coding agents combine runtime tools, memory layers, and repository context to turn large language models into practical coding assistants. Modern systems mix code execution, retrieval of project files, and short- and long-term memory so the model can write, test, and refine code against a real codebase.

Core components

Tooling: Agents expose runtime capabilities the model cannot do with text alone. Common tools include a code execution sandbox, unit test runner, linter and formatter, package manager, shell access for building or running scripts, and repository search. Agents call these tools as discrete actions: run tests, open file, apply patch, or execute code. Tool outputs are returned as text or structured results and fed back into the agent loop so the model can evaluate failures and iterate.

Memory: Agents use multiple memory horizons. Short-term memory is the immediate conversation state and the current plan, often kept entirely in the model context window. Mid-term memory is retrieval from an indexed store of recent edits, test failures, and developer notes. Long-term memory holds persistent user preferences, coding style conventions, and knowledge extracted from the repository across sessions. Implementations typically use embeddings and a vector database for retrieval augmented generation, with heuristics to select which chunks of memory to surface before each model call.

Repository context: Access to the codebase is essential. That includes a file index, a semantic search layer over code and comments, commit and blame metadata, and test suites. Agents chunk large files and rank relevant snippets via embedding similarity, then stitch results into prompts or feed the model a summary plus pointers. Some systems also provide build graphs or dependency manifests so the agent can reason about runtime behavior before making edits.

Controller and orchestration: A thin controller coordinates planning, tool selection, and memory retrieval. It turns a high-level user request into a plan of actions, invokes tools, captures outputs, updates memory, and repeats until the task completes. The controller enforces safety checks, rate limits, and rollback on failed patches.

Practical design choices and failure modes

Retrieval strategy shapes how much repo context fits into each step. Dense retrieval with short, frequent queries keeps prompts small and focused, at the cost of more model calls. Aggressive summarization reduces token use but increases risk of losing crucial details such as function signatures. Embedding granularity matters: chunking by function or logical block performs better than fixed-size slices for code.

Testing and verification are critical. Agents that run unit tests and evaluate coverage produce higher-quality changes but need reproducible, sandboxed environments. Security and dependency management are additional concerns, since executing repository code can leak secrets or run untrusted binaries. Permissioning, secret redaction, and reproducible containerized execution reduce risk.

Limitations include staleness of long-term memory, drift between the memory store and the live repo, and model hallucination when retrieval fails. Observability is often the easiest mitigation: logs of tool calls, diffs, test runs, and an auditable action history help developers review agent behavior.

Why it matters

Coding agents bring three practical capabilities together: they let models act on code, remember developer context across sessions, and ground decisions in the repository. That combination reduces repetitive tasks and speeds iteration for routine edits, code discovery, and debugging. The design choices around retrieval, tooling, and safety determine whether an agent is reliably helpful or creates more work for human reviewers.