What it measures

Agentic Foundation answers a practical question: if someone (human or agent) opens this repo cold, how much friction will they hit?

Each connected GitHub repo gets a 0–100 score built from nine dimensions: docs, tests, CI, structure, agent context files, and similar signals. Lower scores aren’t moral failures. They’re a prioritized to-do list.

The headline number is not “how good your code is.” It is Agentic readiness: can an agent find instructions, run tests, understand layout, and work within reasonable context limits? It is not live delivery.

Agentic readiness measures repo-agent maturity from scans; the engineering delivery score measures live delivery signals from connected integrations.

Reading the dashboard

The overview always shows N of M repos measured. The workspace % next to it is Agentic readiness. The section title stays Overall Agentic Foundation. That % includes unscanned repositories as 0%, so a low headline can mean coverage, not only weak scores.

Under the score, a line says how many repositories are blocked and which rule blocks the most of them. A repository is blocked when its latest successful scan still has a gap or partial criterion that is not fixed. If nothing is blocked, the line says No repository is blocked.

If the workspace has repos but none have been scanned yet, you see 0%, the line includes unscanned as 0%, and no band chip. If there are no repositories, the page shows No repositories analyzed yet.

Repos that have never been scanned show as muted (not a red 0%). If some rows are still pending, the table banner shows how many are not scanned yet. Use Show unscanned to filter that list, then run Scan on a row.

The Repositories comparison table starts with five columns: Repository, Overall, Open issues, Blocking rule, and Worst dimension. Blocking rule is the one open gap or partial criterion on that repository. It lands sorted so the lowest Overall score is first. Never-scanned rows sit after every scored repo and still show Not scanned, not 0%. The nine dimension scores stay hidden until you open Columns. Above the filters, Fix results lists merged fixes from the last 30 days, with the score before the merge, the score after the next scan, and whether that scan cleared the rule. If nothing merged, it says No fix has merged in the last 30 days. Readiness scores covers the picker, sort, and empty states.

After two completed workspace scans, the same overview shows one chart titled Overall Agentic Readiness over time. Readiness series defaults to Overall. You can switch it to a dimension without leaving the overview. The chart is not on a dimension-detail page. Readiness scores covers when it appears, Weekly/Monthly, and how the selector differs from the sidebar.

What’s in this phase

These screens work together. You can jump between them anytime after onboarding.

Prerequisites

Agentic Foundation needs a connected GitHub App installation. Only repositories you granted at install time appear in the list. If a repo is missing, check GitHub integration for org, access scope, and repository selection.

After onboarding, the platform queues an initial scan for every visible repo. You don’t have to click anything for the first pass. Use Analyze when you want a fresh run after pushing fixes.

Activity Log

The Activity Log (Agentic Foundation → Activity Log, /agentic-foundation/activity) highlights fix requests and merged fix PRs. It is the feed of human-initiated fix work from AI Resolution Hub Fix it, not a scan or score timeline.

Action filters are All actions, Fix requested, and PR merged. You can still search, narrow by repository or date, and export CSV of those same events.

Scan progress, scores, failures, and run history stay on the readiness dashboard and each repo’s detail view. If the log is empty, scans can still be running or complete; empty means no fix requests or merged fix PRs yet.

How a scan works

1. 1
   Find repos

   Anything your GitHub App can access shows up in the Agentic Foundation list. Repos added or removed in GitHub App settings usually sync within a few minutes.

   Example: Acme installs the app on acme-corp with access to payments-api, web-checkout, and handbook. All three appear on the dashboard after sync.

2. 2
   Queue a scan

   Select repos and click Analyze. The scan runs in the background; you can leave the page. If a scan is already running, the dashboard reuses that run instead of starting a duplicate.

   Example: The first scan for all three repos queues automatically after onboarding. Later, an engineer merges an AGENTS.md into payments-api and clicks Re-scan on that row only.

3. 3
   Read the breakdown

   Overall score plus per-dimension detail on each repo. Open a repo to see individual criteria marked Met, Partial, Gap, N/A, or Blocked.

   Example: payments-api scores 58 (Material gaps). Agentic Readiness is low (no AGENTS.md), Test Coverage is moderate (Jest present but no CI gate), and Delivery Readiness shows a Dockerfile plus GitHub Actions workflow.

4. 4
   AI Resolution Hub

   Cross-repo list of the highest-impact fixes. Tackle these when you want scores to move.

   Example: The hub surfaces “Add agent instructions” for payments-api and “CI does not run tests” for web-checkout ahead of minor gaps in handbook, because severity and dimension weight rank higher-impact items first.

Connected repos re-scan on roughly a 24-hour cadence. Manual re-scan anytime from the dashboard.

Repository eligibility

Not every granted GitHub repository is analyzed. The platform marks repos eligible or ineligible using workspace rules (archived or removed repos, workspace repo cap, size limits, and similar gates). Unsupported stack is a separate advisory: analysis may still run with limited coverage when GitHub languages do not map to a supported application stack.

When a repository leaves active Agentic Foundation scope, the list and repo detail use different labels so you know what to fix:

• Archived on GitHub: the repo is still granted to the GitHub App installation, but GitHub has archived it. Analyze and Fix stay disabled. Past scores and scan history stay readable. Un-archive the repo on GitHub, then wait for sync (or re-include it) before scanning again.
• Removed from GitHub (no longer part of the installation): the repo left the installation grant, or the app lost access. Actions stay disabled the same way. Restore access or grant selection on GitHub; un-archiving alone does not help.

On the readiness dashboard, GitHub connect list, and Workspace settings → Agentic Foundation scope card, a summary shows how many repos fall into each bucket (for example ineligible because archived on GitHub, removed from the installation, over the workspace repo limit, or unsupported stack with limited analysis). Click a filter chip to narrow the list instead of checking repos one by one. On the dashboard table, language, platform, ineligible, size-limit, and warning chips stay inside the Repository cell. They are not extra score columns.

Workspace admins can tighten eligibility caps under Settings → Data → Repository eligibility. Platform defaults still apply as the upper bound unless a platform admin raises them for your workspace.

Example: first week with three repos

This walkthrough shows how the four steps play out for a typical team. Names are fictional; the flow matches what you see in the app.

Repo	What it is	Day 1 (auto scan)	After fixes + re-scan
payments-api	Node/TypeScript API	54 Material gaps. Gaps: no AGENTS.md, thin README, tests not wired in CI.	71 Partial foundation after adding AGENTS.md, expanding README build commands, and a test job in .github/workflows/ci.yml.
web-checkout	React SPA	68 Partial foundation. Partial: .cursorignore missing; CI runs build but not tests.	76 Partial foundation after ignore file and a npm test CI step.
handbook	Internal docs (MkDocs)	82 Partial foundation. Many delivery rows show N/A (no Dockerfile expected).	Unchanged. Docs repos often score high on hygiene with legit N/A on runtime criteria.

Day 1: GitHub connects during onboarding. Initial scans queue for all three repos. The engineering lead opens AI Resolution Hub and picks the top two items affecting payments-api.

Day 3: A PR merges with AGENTS.md and CI test wiring. They click Re-scan on payments-api. About ten minutes later the score updates and those hub items drop off.

Day 7: Scheduled re-scan runs overnight. No manual action needed unless they pushed more changes.

What a scan inspects

Scans work from a read-only snapshot of the repository file tree at scan time. They do not run your app in production or read live secrets.

Signal category	What we look for	Concrete examples
Agent & contributor docs	Instructions a human or agent can follow on day one	README.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md
AI tool configuration	Rules, skills, and ignore scope for Cursor or Claude	.cursor/rules/, .cursor/skills/, .cursorignore, .claude/
Build & test entrypoints	Non-interactive commands in docs or CI	npm test, mvn verify, bundle exec fastlane test in README or workflow YAML
Quality & delivery	Lint, tests, containers, deploy config	eslint.config.js, vitest.config.ts, Dockerfile, .github/workflows/
Contracts & governance	APIs and change control	openapi.yaml, CODEOWNERS, branch-protection evidence via GitHub
Context efficiency	Files and docs sized for agent context windows	.cursorignore excluding node_modules/, layered docs under docs/

We do not keep a long-term copy of source code. The snapshot is discarded when scoring finishes. See GitHub integration for the full data-handling summary.

Common repo situations

The rubric adapts to repo type. A mobile app and a backend API are scored against different expectations.

Situation	Example repo	What to expect
Backend / API	payments-api, user-service	Full bars for CI, contracts, observability hooks where they belong in-repo.
Web SPA	web-checkout, admin-portal	Frontend-appropriate tests and delivery; no backend-only tooling required in-repo.
Mobile	acme-ios, acme-android	Xcode or Gradle signals instead of Docker; ignore files should exclude build/ and DerivedData/.
Monorepo	platform with apps/ and packages/	Scored on dominant layout at the root; secondary stacks noted but not double-counted.
Docs-only	handbook, architecture-notes	Delivery and runtime criteria often N/A; they do not count against you.
Infra elsewhere	checkout-service with Terraform in acme-infra	With split infrastructure on, delivery checks read the selected Terraform repo. An unreadable selection is left out of the percent.
Unfamiliar stack	Legacy COBOL mirror, niche DSL	Scan still runs; confidence may stay low when fewer recognizable signals are found.

N/A is not a penalty. Criteria marked N/A are excluded from that dimension’s score. A docs repo without a Dockerfile is expected, not a gap.

Timing, cadence & limits

Topic	Typical behavior
First scan	Queued automatically after GitHub connect and onboarding.
Scheduled re-scan	About every 24 hours per connected repo.
Manual re-scan	Anytime via Analyze or Re-scan on a repo row.
Scan duration	Usually 5–15 minutes for typical repos; large monorepos can take longer. Progress shows on the dashboard.
Concurrent runs	One active scan per repo at a time; duplicate requests attach to the in-flight run.
Score freshness	Scores reflect the last completed scan. Pushed fixes won’t move numbers until the next successful run.

If a scan fails (GitHub unreachable, tarball error, timeout), the previous score stays visible and the repo shows a failed status. Retry with Analyze once the underlying issue is resolved.

When Agentic Foundation scans are paused

If the workspace Agent Execution Provider hits a provider quota (for example Cursor monthly usage limit, or Claude credits / rate limits), scans are paused across affected repos. The platform shows a warning banner at the top of the app for that workspace. Per-repo “Scan failed” notifications are secondary.

You can dismiss the expanded warning with ×. While the provider issue still exists, a compact persistent strip remains so the paused state is not lost.

What to do:

1. Open Settings → Integrations → Agent Execution Provider.
2. Raise limits or wait for the provider reset, switch provider (BYOK: Cursor User API Key or Claude API key, or ThinkAI Managed Cursor), or update the selected provider’s execution account or key.
3. Re-run Analyze after the condition clears. The banner disappears once scans can proceed again.

Provider options during onboarding are covered in Integrations setup. For the named BYOK tier and what still leaves your environment, see Bring Your Own Keys (BYOK). Automated Fix it jobs use the same execution provider (AI Resolution Hub).

Criterion outcomes (quick reference)

Status	Meaning	Example
Met	Signal present and satisfies the bar.	AGENTS.md with concrete npm test and npm run build lines.
Partial	Something there but incomplete.	README mentions tests but no exact command to copy.
Gap	Expected signal missing. Feeds AI Resolution Hub.	No CI workflow file in a service repo.
N/A	Doesn’t apply to this repo. Excluded from scoring.	No Dockerfile expected for handbook.
Blocked	Couldn’t verify at scan time. Usually counts as not met until evidence is available.	A GitHub API call failed while reading branch protection on payments-api.

Confidence on a dimension reflects how much evidence we found, not statistical test coverage. A repo with zero test files produces low confidence on Test Coverage before you even interpret the score.

When split infrastructure is on and a selected platform repo cannot be read, the checks for that role are left out of the dimension percent. They are not scored as a gap. See Linked platform repositories.

For how overall and dimension scores combine, see Readiness scores.

Score bands

Band	Range	Rough read
Strong foundation	85–100	Agents and new hires should settle in quickly.
Partial foundation	60–84	Solid; a few targeted fixes left.
Material gaps	40–59	Meaningful gaps; start with the Resolution Hub.
Not ready	0–39	Structural issues; don’t ignore the top items.

Bands are guides, not gates. A repo at 72 (Partial foundation) with a critical Gap in Agentic Readiness may still be painful for agents until that one item is fixed. These bands are for Agentic readiness only. They are not the engineering delivery score.

What scores don’t measure

Agentic Foundation is deliberately bounded. It does not:

• Judge code correctness, security vulnerabilities, or performance in production
• Replace human code review or compliance audits
• Measure team productivity (that’s under Insights)
• Score recent CI health (pass/fail, flake, duration). That is SDLC Insights, after you enable GitHub Actions. Setup rows only ask whether CI is configured.
• Guarantee an AI agent succeeds on every task. It measures repo affordances, not model quality.
• Penalize you for choosing a stack we don’t have deep heuristics for. Those repos may show lower confidence instead.

Use scores to prioritize documentation, structure, and automation improvements that make both humans and agents more effective.

Next

• Readiness scores
• The 9 dimensions
• AI Resolution Hub
• Activity Log
• FAQ