Agentic Context Radar

The Agentic Context Radar is the observability and acceleration layer of CodeRadius for organizations operating at scale. It is designed for engineering leaders managing large repository fleets who need to understand how AI tooling context is distributed across the organization — not just within a single team or repository.

In practical terms, the Radar answers questions like:

• "How many of our 300 repositories are running AI agents completely blind?"
• "Which teams have built brilliant, reusable AI capabilities that the rest of the organization has no idea exist?"
• "Where are two teams independently solving the exact same problem with the exact same AI rules?"
• "Which critical monoliths have zero AI context governance, despite having hundreds of commits per month?"

The Context Engineering Problem at Scale

When an organization adopts AI coding tools — Cursor, Windsurf, Cline, GitHub Copilot, Claude, Gemini — each team configures their tools independently. Within weeks, a pattern emerges:

• Team A builds a sophisticated .cursorrules file that encodes architectural patterns, security constraints, and API naming conventions. It dramatically improves the quality of their AI-generated code.
• Team B, across the hallway (or the continent), spends the same two weeks building an almost identical file from scratch. They will never discover Team A's work, because there is no system for surfacing it.
• Teams C through Z have no rules at all. Their AI agents operate without organizational context, producing code that is technically valid but architecturally inconsistent.

This is context debt at the organizational level. The Agentic Context Radar makes it visible and actionable.

How It Works

Data Collection: The Agentic Config Plugin

The Radar's data layer is built on the Agentic Config Plugin, which runs as part of the standard CodeRadius ingestion pipeline. This plugin scans every repository in the organization for AI configuration files matching patterns from 28+ supported tools:

.cursorrules                   → Cursor global rules
.cursor/rules/*.mdc            → Cursor scoped rules (file-level)
.cursor/mcp.json               → Cursor MCP server configuration
.windsurfrules                 → Windsurf global rules
.github/copilot-instructions.md → GitHub Copilot instructions
CLAUDE.md                      → Claude global instructions
GEMINI.md                      → Gemini global instructions
.agents/skills/*/SKILL.md      → Generic portable skills (e.g., CodeRadius)
.agents/workflows/*.md         → Generic agent workflows
langgraph.json                 → LangGraph multi-agent configuration
config/agents.yaml             → CrewAI agent definitions

For every file matched, the plugin extracts:

Each extracted configuration becomes an AgenticConfig node in the graph, linked to the owning service and — transitively — to the team and repository.

The Graph Traversal

The Radar executes a set of Cypher queries against the Memgraph graph. All traversals follow the pattern:

(Repository)<-[:STORED_IN]-(Service)-[:HAS_AGENTIC_CONFIG]->(AgenticConfig)
(Team)-[:OWNS]->(Service)

This architecture means the Radar respects your organization's existing ownership model. If a repository has no team ownership defined in the graph, the radar attributes its configurations to the repository's GitHub organization as a fallback.

Pulse-Aware Filtering

Not all repositories are equally relevant. A repository with zero commits in the last two years should not count against a team's "coverage" metric or skew the maturity distribution.

The Radar uses liveness data to classify repositories:

Understanding Agentic Maturity Levels

Every repository is assigned an Agentic Maturity Level from L0 to L4, computed automatically based on the presence and sophistication of its AI configurations:

L0 — Dark

No AI configuration files detected. The repository is operating entirely without AI tooling context. Agents working in this repository have no organizational guidelines, no architectural constraints, and no domain-specific knowledge injected.

Risk: Maximal. Any AI-generated code is unconstrained and will drift from organizational standards.

L1 — Aware

At least one AI configuration file exists, but it is either empty or minimal (fewer than 200 characters). The team is aware of AI tooling and has made a first attempt at configuration, but has not yet invested in meaningful context.

Risk: High. Minimal context provides minimal protection from hallucinations and architectural drift.

L2 — Configured

Meaningful, non-empty rule files exist (≥200 characters). The team has structured instructions for how AI agents should behave in this repository — coding conventions, architectural patterns, prohibited patterns.

Risk: Moderate. The most common entry point for serious AI tooling adoption.

L3 — Skilled

The repository contains custom Skills or Workflows — portable, executable capabilities that AI agents can invoke. A "skill" is a structured SKILL.md file that teaches the agent how to perform a specific, repeatable task in that codebase (e.g., how to create a Jira ticket from a branch name, how to run the migration pattern used by this service).

Risk: Low. The team has made a significant investment in AI-assisted automation for their specific domain.

L4 — Orchestrated

The repository either:

• Uses multi-agent subagent configurations (e.g., .roomodes, .clinemodes, config/agents.yaml), or
• Combines an MCP server + scoped rules + at least one workflow — a fully integrated agentic pipeline.

This is the highest maturity level. The team is not just using AI to assist individual developers; they have constructed a reusable agentic system.

Risk: Minimal. The entire agentic lifecycle is governed and observable.

The Dashboard: A Guided Tour

Generating the Report

# Generate the unified architecture dashboard
cr ui

# Generate with a timestamped filename
cr ui --out ./reports/health-$(date +%Y-%m-%d).html

The command connects to your Memgraph instance, executes the Radar queries, and generates a self-contained HTML dashboard that can be shared with stakeholders who do not have CLI access.

Executive Metrics Bar

The top of the dashboard presents four key performance indicators:

Active Repositories

The total number of repositories that pass the liveness filter (i.e., not dormant and not unknown). This is your operational baseline — the number of codebases where AI tooling decisions have a real impact.

Silo Index

A percentage indicating the degree of agentic configuration fragmentation across the organization.

A high Silo Index means teams are building specialized, non-overlapping AI configurations in isolation. Their capabilities are not being discovered or reused. This is a direct measure of how much value is being destroyed by organizational silos.

A low Silo Index means configurations are being shared and reused across repositories and teams — a sign of effective capability distribution.

Avg Maturity

The mean Agentic Maturity Level (L0–L4) across all active repositories. This is your organization's center of gravity. A fleet-wide average of L0.8 means most repositories are either operating blind or with token-gesture configurations.

Context Gaps

The number of duplicate agentic configurations detected across active repositories. This is not "bad" per se — intra-team sharing of the same configuration is a positive sign of internal standardization. The critical signal is cross-team duplication: two distinct teams building the same capability without knowing about each other.

Agentic Maturity Distribution

The histogram shows the distribution of all active repositories across the five maturity levels. This visualization answers a deceptively simple question: "Where is the bulk of the organization?"

In most organizations encountering this dashboard for the first time, the distribution is heavily left-skewed — the majority of the fleet is at L0 or L1. This is not a failure; it is a baseline. The value is in making the invisible visible.

The histogram subtitle shows the precise counts: how many repositories are active vs. how many were excluded for being dormant. This makes the metric auditable and free from optimistic distortions.

The Capabilities Catalog

The Catalog tab is, for many Principal Engineers, the most immediately valuable view. It is a deduplicated registry of every unique AI capability — Skill, Workflow, Scoped Rule — discovered across the entire repository fleet.

Unlike a simple list, the Catalog is:

• Deduplicated by (name, type): the same skill appearing in 12 repositories is shown as a single entry with a usageCount of 12, not 12 separate rows.
• Cross-referenced to teams and repositories: for each cataloged capability, you can see which repositories are using it and which teams own them.
• Searchable: filter by name, type, description, team, or repository.
• Sortable by usage: the most-adopted capabilities surface naturally.

How to Use the Catalog for Knowledge Discovery

The canonical workflow:

1. Sort the Catalog by Usage: Low (ascending).
2. Look for high-quality skills with a usageCount of 1 — these are unique capabilities built by a single team that no one else has discovered.
3. Identify the owning team and repo. Review the skill's description and content.
4. If the capability is generalizable, extract it into a shared organizational standard and distribute it via CI injection.

This is the Discovery Loop — transforming siloed innovation into organizational leverage.

The Insights Tab

The Insights tab contains two analytical visualizations:

Capability Coverage Bar Chart

A horizontal bar chart showing the distribution of AI topics across configurations fleet-wide. Topics are extracted automatically by keyword scanning the content of every configuration file (using patterns for security, testing, architecture, ci-cd, database, api, typescript, and 10 more).

The bar chart immediately reveals organizational blind spots. If security appears in only 3% of configurations while typescript appears in 60%, it signals that teams are using AI agents for code style — but have not thought about using them to enforce security constraints.

The chart covers all repositories in the graph, not just active ones, because topic coverage is a knowledge audit — even dormant repositories may contain valuable reference configurations.

Agentic Risk Quadrant (Scatter Plot)

The Risk Quadrant plots every repository along two axes:

• X-axis: Repository liveness (commit velocity, on a log scale)
• Y-axis: Agentic Maturity Level (L0–L4)

The log scale on the X-axis is deliberate. Large codebases with hundreds of monthly commits would otherwise compress all smaller repositories into an unreadable cluster near the origin. The logarithmic transformation spreads the fleet evenly, making it possible to read the relative positioning of a 10-commit-per-month microservice alongside a 1000-commit-per-month monolith.

The quadrant naturally creates four strategic zones:

Team Overview

The Team Overview is a matrix of every team in the graph, providing a side-by-side comparison of agentic adoption metrics:

All columns are sortable. The most valuable sort for a Principal managing an organizational rollout is Coverage % ascending — it surfaces the teams furthest from baseline adoption.

Reading Coverage %

Coverage % is deliberately simple: it counts repos at L1 or above (any AI config file present). This is the binary "has the team started?" question.

It is intentionally not a measure of quality. A team with 48/50 repos at Coverage 96% but all at L1 (empty files) should not be confused with a team at 30% Coverage with every configured repo at L3. Use Coverage alongside Avg Maturity for a complete picture.

Maturity Matrix

The Maturity Matrix is a repository-level table providing the most granular view in the Radar. Every repository is listed with:

• Its team ownership
• Its individual maturity level and label
• Its liveness level and commit count
• The count of each configuration type (rules, skills, workflows, subagents)
• The AI tools detected in the repository
• A direct link to the repository URL (where available)

This is the view for drilling down after identifying a team or area of concern in the Team Overview. Sort by Maturity: Low within a specific team to build a precise remediation backlog.

Context Gaps

The Context Gaps tab surfaces duplicate configurations — configurations that share the same normalized content fingerprint across multiple repositories. These are cases where the same AI context is being maintained in multiple places without awareness.

Cross-Team Duplicates 🔴

The highest-priority signal. Two or more distinct teams have written configurations with the same semantic content, independently. This is wasted effort and a missed opportunity for organizational alignment.

Action: Contact the technical leads of both teams. Review both configurations for nuanced differences. If they are functionally equivalent, select the best version, elevate it to an organizational standard, and distribute via CI.

Intra-Team Patterns 🟡

The same team has replicated a configuration across multiple of their own repositories. This is often intentional — the team has developed a standard and is applying it consistently within their domain.

Action: Less urgent. Verify that the intra-team copies are intentional. If the pattern is strong, it may be a candidate for cross-team elevation.

MCP Servers

The MCP Servers tab provides a census of all Model Context Protocol server configurations detected across the fleet. For each discovered MCP server, it shows:

• The server name (as defined in the mcpServers object of the MCP config file)
• The list of repositories where it appears
• The teams that own those repositories

This view answers: "Which MCP integrations are in use?" and "Which teams have already connected to service X via MCP?"

Principal Engineer Playbooks

Playbook 1: The Discovery Loop

Goal: Find an isolated team's high-value AI capability and distribute it across the organization.

1. Open the Capabilities Catalog tab.
2. Filter by Type: skill and sort by Usage ascending.
3. Identify a skill with usageCount: 1 and a description that suggests broad applicability (e.g., "Generates a Jira ticket from a git branch name", "Validates outbound API calls against the organization's API naming conventions").
4. Navigate to the owning repository and review the skill's full content.
5. Generalize the skill into a portable format (refactor any repository-specific hardcoding).
6. Publish the generalized skill to a shared platform repository.
7. Distribute via CI injection (see the Impact Evaluation guide) or Backstage template.
8. Track adoption over the next 30 days by re-running the Radar and observing the skill's usageCount climbing.

Playbook 2: Closing Cross-Team Context Gaps

Goal: Identify two teams solving the same problem independently and merge their efforts.

1. Open the Context Gaps tab.
2. Look for ⚠️ Cross-team duplicate entries at the top of the list (sorted by priority automatically).
3. For each cross-team duplicate, note the two (or more) owning teams.
4. Retrieve the actual files from each team's repository.
5. Produce a diff. In most cases, the files are 95%+ identical.
6. Schedule a 30-minute working session with both technical leads to produce a canonical merged version.
7. Replace the individual team copies with the merged canonical version.
8. Either centralize the file in a shared repository, or distribute identical copies via CI validation that enforces the canonical hash.

Playbook 3: Rescuing the Wild West

Goal: Bring a high-velocity, L0-maturity monolith into baseline AI governance.

1. Open the Agentic Risk Quadrant.
2. Identify a repository in the upper-left zone (high liveness, L0).
3. From the Team Overview, find the owning team.
4. Baseline the situation: how many developers are actively committing? What AI tools are they using individually? What coding guidelines exist in offline documentation?
5. Propose a minimal L1 → L2 transition rather than a comprehensive overhaul. The goal is to reduce unconstrained AI output, not to immediately achieve L4.
6. A minimal L2 package typically includes:
   • A .cursorrules or CLAUDE.md with 10–20 architectural constraints specific to the service
   • A scoped rule for any high-risk areas (e.g., database migrations, API versioning)
   • A reference to the organization's standard security rule (if you have created one via Playbook 1)
7. Validate the transition in the Radar within two weeks.

Playbook 4: Building the Golden Path

Goal: Define and distribute organizational baseline AI configurations that every team should have.

1. Use the Capability Coverage bar chart in the Insights tab to identify which topics are least covered fleet-wide.
2. If security coverage is at 4%, your organization has no AI security guardrails. This is urgent.
3. Produce a canonical security-constraints.mdc (or equivalent for the organization's primary AI tool) that encodes the critical security constraints every team must have.
4. Integrate this file into a Backstage template so that every new service gets it by default.
5. Distribute it to existing repositories via a scripted CI propagation job.
6. Re-run the Radar and observe the Coverage chart shift.

Frequently Asked Questions

Q: The Radar only shows 2 repositories. I expected 300.

The Radar is reading from your local Memgraph instance. If you see only a few repositories, you are likely reading from a development graph, not the production enterprise graph. Ensure your MEMGRAPH_URI environment variable points to the correct endpoint before running cr ui.

Q: The "Context Gaps" tab is empty despite having many duplicates.

The Context Gaps tab only shows configurations that have a contentFingerprint match — i.e., whose content is semantically identical after normalization (stripping whitespace, comments, and frontmatter). If your duplicate configurations differ even slightly in substantive content, they will not appear here. They may still surface in the Semantic Duplicates section (if embeddings are configured).

Q: A critical infrastructure repository is being excluded from the Radar metrics.

This is likely because it is classified as dormant — zero commits in the last 12 months. The Radar excludes dormant repositories from aggregated metrics. If this is genuinely a critical-but-stable component, it indicates even more urgency around ensuring it has proper AI configuration before it next sees modification activity.

Q: How do I generate the Radar against the production graph automatically?

Schedule cr ui --out health-$(date +%Y-%m-%d).html as a weekly cron job (or GitHub Actions workflow) using the credentials for your production Memgraph instance. Archive the output to an S3 bucket or internal portal for stakeholder access.