How coding agents retrieve context

A coding agent looks unusually capable because it can answer questions about a repository it has never seen before. The model is only part of that ability. The Agent Harness gives it tools for finding and reading the right context.

Without those tools, the model sees only your prompt and whatever files the application inserted ahead of time.

The harness sits between the model and your files

An Agent Harness sends the model a set of tool definitions. A tool definition says what the tool does and what arguments it accepts. The model can request a call, but the harness decides whether the arguments are valid, executes the operation, and returns the result.

sequenceDiagram
    participant U as You
    participant M as Model
    participant H as Agent Harness
    participant R as Repository
    U->>M: Where is retry behavior implemented?
    M->>H: find src/**/*.py
    H->>R: Match paths
    R-->>H: Candidate files
    H-->>M: Paths
    M->>H: grep retry
    H->>R: Search candidates
    R-->>H: Matches with line numbers
    H-->>M: Matches
    M->>H: read src/acme_deploy/retry.py lines 1-80
    H-->>M: Bounded source text
    M-->>U: Answer with file locations

The model does not receive direct filesystem access. It asks through narrow tools. That separation lets the harness enforce roots, ignore rules, output limits, and read-only behavior.

Why the loop repeats

Retrieval is rarely one perfect search. A filename suggests a term. That term leads to an implementation. The implementation imports another function. A test explains the behavior better than the function name did.

The model can repeat find, grep, and read as it learns. That is what makes the retrieval agentic: the next retrieval method depends on the result of the previous one.

A fixed RAG pipeline makes those decisions in application code. An agent asks the model to choose. Both still need stable Sources, bounded reads, and evaluation.

Tools shape behavior

If you give the model one opaque tool called search, you cannot easily tell whether it searched paths, content, vectors, or records. Separate tools make the choices visible:

• find_sources(pattern) discovers paths;
• grep_sources(pattern) finds exact content;
• read_source(path, lines) retrieves a bounded section;
• later, semantic_search(query) handles paraphrases;
• structured_lookup(name, filters) retrieves exact records.

Tool descriptions matter because the model uses them to decide what to call. Tool validation matters because the model can still produce malformed or unsafe arguments.

This is RAG

No vector database appears in the loop above, but the mechanism is still retrieval-augmented generation. The model retrieves information outside its current context and uses it to produce an Answer.

That wider definition is useful because it keeps you focused on the information need. If the Query contains an exact symbol, grep may be the best retrieval method. If it asks for a plan limit, a structured lookup is better. If it paraphrases a concept, vectors may help.

You now have the mental model for the whole Course: discover, retrieve, inspect, and only then generate. Next, we will stop experimenting with individual commands and build one system in layers.

Build the retrieval pipeline