Amazon Bedrock Knowledge Bases: RAG Over Your Monorepo for Coding Agents

Your coding agent just spent 14 tool calls find/grep‑ing for createPaymentIntent across a turbo monorepo — then hallucinated an SDK that was deleted last quarter. Bedrock Knowledge Bases are the unfair advantage when the agent needs retrieval over your code and internal docs without stuffing the whole tree into context: sync from S3 (or connectors), retrieve chunks, and feed Converse / Agents with citations. This is not the same as the Day‑30 bootcamp multi-tenant KB lab — here we focus on monorepo RAG for production coding agents, chunking pitfalls, and wiring into tool loops. Pair with OpenSearch Serverless scratch memory for session-hot semantic notes and Prompt Management for the system voice — this post is the monorepo RAG layer.

⚡ TL;DR: Export curated code+docs to S3 on a webhook/CI schedule; create a Bedrock KB with a code-aware chunking strategy; call Retrieve (or RetrieveAndGenerate) before Converse tool loops. Prefer metadata filters by repo, package, language. Avoid naive fixed-size chunks that bisect functions. Related: Bootcamp Day 30 KB project, ApplyGuardrail, Step Functions graphs.

Where KB sits in a coding-agent architecture

1. Ingest — CI uploads docs/, selected *.md, API specs, and symbol summaries (not necessarily every .ts byte) to s3://code-rag/{repo}/{sha}/
2. KB sync — Bedrock crawls the bucket into the vector store (OpenSearch Serverless managed by KB, or your choice where supported)
3. Retrieve — agent tool search_codebase(query, filters) calls Retrieve
4. Generate — planner uses chunks as context in Converse; tools still apply patches in sandboxes (Fargate Spot, EFS workspaces)

KB does not replace sandboxes. It replaces blind grep when the question is “where do we implement X?” and “what is the canonical pattern?”

Syncing a monorepo without indexing trash

Index signal, not node_modules:

• ✅ README*, ADR*, docs/**, OpenAPI/AsyncAPI, proto, selected **/src/**/*.{ts,py,go} summaries
• ✅ Generated symbol cards (path, exported names, 40-line signature window) from tree-sitter in CI
• ❌ Lockfiles, build dirs, minified bundles, vendored trees, .env*
• ❌ Secrets — scan before upload; never rely on KB to “not retrieve” a leaked PAT (Secrets Manager rotation)

# ✅ CI sketch — publish RAG corpus for SHA
- name: Export code RAG corpus
  run: |
    python scripts/export_rag_corpus.py \
      --repo "$GITHUB_REPOSITORY" \
      --sha "$GITHUB_SHA" \
      --out /tmp/corpus \
      --include 'docs/**,**/src/**/*.ts,**/src/**/*.py' \
      --exclude '**/node_modules/**,**/*.min.js'
    aws s3 sync /tmp/corpus "s3://code-rag-prod/${GITHUB_REPOSITORY}/${GITHUB_SHA}/" \
      --delete
    aws bedrock-agent start-ingestion-job \
      --knowledge-base-id "$KB_ID" \
      --data-source-id "$DS_ID"

Trigger on default-branch pushes and on docs/** paths; avoid re-ingesting every feature-branch commit unless you filter by branch metadata.

Chunking pitfalls for source files

Blog-post chunkers destroy code:

• Fixed 500-token windows split mid-function, losing signatures
• Markdown header splitters ignore class / def boundaries
• Huge files become one useless mega-chunk or thousands of orphans

Prefer:

1. Structure-aware splits — per function/class with overlapping headers (file path + exports in every chunk metadata)
2. Dual corpus — coarse doc chunks + fine symbol cards
3. Metadata — repo, package, language, symbol, sha for filters

# ✅ Retrieve with metadata filters for a monorepo package
import boto3
br = boto3.client("bedrock-agent-runtime")

def search_codebase(query: str, package: str, repo: str):
    resp = br.retrieve(
        knowledgeBaseId=KB_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                "numberOfResults": 8,
                "filter": {
                    "andAll": [
                        {"equals": {"key": "repo", "value": repo}},
                        {"equals": {"key": "package", "value": package}},
                    ]
                },
            }
        },
    )
    return resp["retrievalResults"]

# ❌ RetrieveAndGenerate with no filters on a multi-tenant KB
# cross-tenant / cross-repo chunk leakage risk
br.retrieve_and_generate(
    input={"text": user_q},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {"knowledgeBaseId": SHARED_KB},
    },
)

For multi-tenant SaaS, follow isolation patterns from Day 30 — separate data sources or hard metadata filters enforced in your tool wrapper, not “the model will only ask for its repo.”

Wiring into Converse / Agents

Expose retrieval as an explicit tool (search_codebase) so the agent can interleave retrieve → read file in sandbox → patch. Alternatively, pre-retrieve in the planner for known intents (“explain payments package”) then Converse with citations.

// ✅ toolConfig entry — model decides when to search
const tools = [
  {
    toolSpec: {
      name: "search_codebase",
      description: "Semantic search over internal monorepo docs and symbol cards",
      inputSchema: {
        json: {
          type: "object",
          properties: {
            query: { type: "string" },
            package: { type: "string" },
          },
          required: ["query"],
        },
      },
    },
  },
];
// Use with Bedrock Converse toolConfig — see
// https://cheatcoders.net/bedrock-converse-toolconfig-idempotent-tool-results-under-retries/

Run ApplyGuardrail on retrieved text before it enters the model context — docs can contain outdated security anti-patterns you do not want echoed as instructions.

Freshness and eval

• Webhook/CI ingest > nightly-only for active monorepos
• Store sha in metadata; agent can prefer chunks matching the sandbox checkout SHA
• Eval: “wrong file vs wrong advice” taxonomy (bootcamp Day 29); log retrieve IDs in CloudWatch
• Budget Bedrock + AOSS costs with Budgets / anomaly detection

Production checklist

• [ ] S3 corpus excludes build artifacts and secrets; pre-upload secret scan
• [ ] Chunking is structure-aware for code; metadata includes repo/package/sha
• [ ] Tool wrapper enforces tenant/repo filters — not prompt-only
• [ ] Retrieve tool idempotent; results cited with path + sha
• [ ] Guardrails on retrieved content before Converse
• [ ] Ingestion jobs alarmed on failure; freshness SLO defined
• [ ] Session scratch (AOSS) separate from long-term KB
• [ ] Private model calls via PrivateLink (next post) when required

Citation UX for developers

When search_codebase returns hits, show the engineer (and the model) path + sha + short excerpt. Agents that paste unmarked chunks into patches cause “phantom code” reviews. Prefer tool results shaped like {path, sha, score, text} and require the apply tool to open the real file in the sandbox before editing.

FAQ

Q: Index every source file or summaries only?
A: Start with docs + symbol cards. Full-file indexing blows cost and retrieval noise; add hot packages selectively.

Q: KB vs OpenSearch Serverless scratch?
A: KB = durable org knowledge. Scratch = this chat’s notes and transient snippets. Different lifecycles — use both.

Q: Can Agents (Bedrock Agents) attach a KB directly?
A: Yes — still wrap with your tenant filters and audit logging; do not skip the tool-policy layer (Verified Permissions).

Bedrock Knowledge Bases give coding agents a searchable monorepo brain — if you sync deliberately, chunk for code, and filter like a multi-tenant system. Grep remains for exact edits; KB is for “where and how do we do X here?”