How to Build a Coding Agent Knowledge Base in Cortex

Introduction

Coding agents need many kinds of context for many different jobs: current dependencies, operational guidance, breaking changes, incident history, security updates, and practical best practices. It is possible to rely on ad hoc knowledge bases like markdown files or notes, which work up to a point. But with the latest AI models, coding agents can now build and maintain durable, scalable knowledge bases that improve over time. Cortex gives them an API for gathering, organizing, and retrieving the information coding agents need to build powerful knowledge bases.

Step 1: Project setup

Make sure your coding agent has the access it needs to build and maintain this knowledge base, both in Cortex itself and in the external systems that supply source material.

Your coding agent can connect to Cortex in two ways. The fastest path is MCP (Model Context Protocol) — it gives your agent direct tool access to Cortex without writing any integration code. Alternatively, use the OpenAPI spec for the machine-readable contract and the API reference for endpoint-level usage details as you create and maintain the project, define the feed, and work with the resulting digests.

Before you add any sources, create the Cortex project that will hold the rest of this setup. A good project objective should be broad enough to guide everything in the project, but specific enough to define the operating decisions, workflows, or outcomes the system is meant to support over time.

Step 2: Set Up Sources for GitHub Repos

Start with the GitHub repositories that are closest to the product itself. In this example, those repositories expose the release feeds, pull requests, and proposal work that directly shape validator upgrades and operational decisions.

For a different product, this same pattern still applies. Begin with the repos where the product team ships releases, discusses implementation changes, or manages formal proposals. These are usually the highest-signal sources because they are where the product itself tells you what changed.

{
  "url": "https://github.com/anza-xyz/agave/releases.atom",
  "cron": "0 0 * * *"
}

{
  "url": "https://github.com/jito-foundation/jito-solana/releases.atom",
  "cron": "0 0 * * *"
}

{
  "request": {
    "url": "https://api.github.com/repos/anza-xyz/agave/pulls?state=all&sort=updated&direction=desc&per_page=50",
    "auth": {
      "mode": "bearer_credential",
      "credentialRef": "<stored-github-credential-ref>"
    },
    "headers": [
      {
        "name": "Accept",
        "value": "application/vnd.github+json"
      }
    ]
  },
  "extract": {
    "itemsPath": "$[*]",
    "urlPath": "$.html_url",
    "titlePath": "$.title",
    "textPath": "$.body",
    "publishedAtPath": "$.updated_at"
  },
  "cron": "0 0 * * *"
}

{
  "request": {
    "url": "https://api.github.com/repos/solana-foundation/solana-improvement-documents/pulls?state=all&sort=updated&direction=desc&per_page=50",
    "auth": {
      "mode": "bearer_credential",
      "credentialRef": "<stored-github-credential-ref>"
    },
    "headers": [
      {
        "name": "Accept",
        "value": "application/vnd.github+json"
      }
    ]
  },
  "extract": {
    "itemsPath": "$[*]",
    "urlPath": "$.html_url",
    "titlePath": "$.title",
    "textPath": "$.body",
    "publishedAtPath": "$.updated_at"
  },
  "cron": "0 0 * * *"
}

{
  "url": "https://github.com/firedancer-io/firedancer/releases.atom",
  "cron": "0 0 * * *"
}

Step 3: Set Up More Sources for More Context

Repo activity usually is not enough on its own. Add a smaller set of outside sources that help explain what those repo changes mean in practice, especially if your users need rollout guidance, operational context, expert discussion, incident history, or ecosystem reactions.

Each source stays compact by default. Expand the connector config only when you need to see the request, selector, or polling fields that actually wire the source into Cortex.

{
  "list_id": "<x-list-id-or-url>",
  "max_results": 100,
  "exclude_replies": false,
  "exclude_retweets": false,
  "cron": "0 0 * * *"
}

{
  "url": "https://doublezero.xyz/journal",
  "selectors": {
    "item": "a.block[href*=\"/journal/\"]",
    "link": ":self",
    "title": "h6"
  },
  "pageSelectors": {
    "title": "h2",
    "date": "div.inline-flex.items-center span.text-foreground"
  },
  "waitFor": "css:a.block[href*=\"/journal/\"]",
  "cron": "0 0 * * *"
}

{
  "url": "https://status.solana.com/history.atom",
  "cron": "0 0 * * *"
}

{
  "url": "https://forum.solana.com/latest.rss",
  "cron": "0 0 * * *"
}

{
  "url": "https://blog.syndica.io/rss/",
  "cron": "0 0 * * *"
}

{
  "url": "https://marinade.finance/blog/rss.xml",
  "cron": "0 0 * * *"
}

Step 4: Set Up a Feed

Once the source set is in place, create a feed that brings those sources together under one filtering objective. The feed is where Cortex turns a pile of source material into a consistent stream of relevant items for this project.

Step 5: Set Up a Digest

For now, keep this example scoped to a single briefing digest. The feed already gathers more signal than an operator wants to read raw, so the briefing is the place where Cortex turns that stream into an upgrade-focused working view.

Conclusion: Observe and Improve the System

After the first digest starts producing useful output, observe what is working and improve the setup based on what you learn. Outside Cortex, the operator still uses normal tooling to do the actual work. In this example, that environment is centered on VS Code with GitHub Copilot, connected to Cortex via MCP.

The operator reads the Cortex outputs, reviews what is useful or noisy, and then updates the source set, feed objective, or digest objective accordingly. Over time, the system becomes more tailored to the actual operating questions that matter.

The digests surface the high-level picture. When something looks relevant, the coding agent can dig deeper: query the feed for related items, fetch the original source content, or call the GitHub API directly for full PR diffs, commit history, or issue threads. Cortex handles the continuous monitoring so the agent starts from context instead of starting from scratch.

Information begins in the tracked sources: release feeds, repository pull requests, SIMD proposal work, operator discussion, and supporting infrastructure updates. Cortex collects those items into the Validator Operations Feed. The feed provides the common intelligence layer for the project.

From there, Cortex generates the Validator Upgrade Preflight Brief. That briefing gives the operator a synthesized view of the latest changes that matter for upgrading and operating the current validator stack.

The operator then uses those outputs in their working environment to decide what action to take. Cortex continuously reduces the manual overhead of staying current, while the operator keeps control over execution in their normal tooling.