Agent Readiness

How well are your active repositories set up for AI coding agents to work in?

Agent Readiness (sidebar: AI Tools → Agent Readiness) assesses each of your active GitHub repositories against a fixed rubric of repository foundations: can an agent understand the codebase, set up its environment, check its own work, and get independent review before anything ships? Each assessment reads the repository’s files and its GitHub settings and returns a verdict per check — pass, fail, unknown or not applicable — with cited evidence and, for a fail, the smallest sufficient fix.

Assessments are an AI-assisted static review of repository files and provider settings. Repository setup, tests and application workflows are not executed — a pass means the evidence is there, not that an agent has been observed succeeding.

Who can use it

Agent Readiness requires organisation-wide access, because repository and security evidence spans teams. Owners always have it. Managers have it unless your organisation has enabled Team Restrictions, which scopes managers to the people they were given access to (see User Management).

Which repositories appear

The page lists every repository where Bilanc has recorded a commit in the last 60 days. To assess a repository, two things must be true:

• Your organisation has a GitHub connection with access to it (Agent Readiness reads branch protections and other settings through that connection, so GitHub-only for now). Otherwise the request fails with Connect GitHub with access to … before assessing it.
• Its code sync into Bilanc’s read-only sandbox has completed successfully — the same sync the MCP server’s code tools read from. Otherwise you’ll see Wait for …‘s code sync to succeed before assessing it.

Running assessments

Click Assess repositories, search for and tick the repositories you want (the picker shows 25 per page), and confirm. You can leave the page; requests are processed in the background and the results appear after the next hourly analytics refresh. A repository that already has a pending request is not queued twice.

Each organisation has a budget of 25 assessments. The picker shows how many you have used and caps your selection at the remainder; once the budget is used up, the page says so and no more can be queued. A reassessment counts against the same budget.

From a repository’s own page you can Reassess repository after changes land. While the new assessment is queued or running, the previous results stay visible, and the page tells you when newer code has been synced than the revision that was assessed.

What is assessed

Every assessment evaluates the same 27 checks, grouped into four dimensions:

Dimension	Question it answers
Context	Understand the system and the right change
Environment	Set up the tools, dependencies and configuration
Verifiability	Judge correctness and diagnose failures
Safeguards	Protect changes and independently review them

Each check is either a Stage 1 foundation or a Stage 2 check that builds on it.

Context

Check	Stage
Working instructions	1
Submitting changes	1
Codebase overview	1
Interfaces and data	1

Environment

Check	Stage
Tool versions	1
Setup	1
Dependency installation	1
Build/code generation	1
Configuration	1
Development services	1
Local/CI agreement	2

Verifiability

Check	Stage
Useful tests	1
Error checks	1
Type checks	1
Formatting	1
Merge checks	1
Interface tests	1
Useful errors	1
Operational errors	2
Safe reruns	2

Safeguards

Check	Stage
Branch protection rules	1
Independent approval rules	1
Review ownership	1
Secret blocking	1
Credentials and logs	1
Security checks	2
Independent AI review	2

Results

Every check gets one of four results:

Result	Meaning
Pass	The evidence supports the check.
Fail	The foundation is missing. The finding includes the smallest sufficient fix.
Unknown	The assessment could not find enough evidence either way — for example a GitHub setting it couldn’t read. The finding says what evidence is missing. Unknown is distinct from a confirmed gap and does not count as a failure.
Not applicable	The check doesn’t apply to this repository (for example, no type checks for a language without them).

Each finding carries a one- or two-sentence explanation and citations — the file or settings source, line, and quote the verdict rests on — so you can verify it yourself. Open a repository to inspect the full checklist and its evidence.

Readiness progression

Checks roll up into a stage per repository:

Stage	Meaning
Foundations incomplete	At least one Stage 1 check is failing or unknown. If nothing has actually failed, the page shows Progression unverified — more evidence is needed, not more fixes.
Ready for agent work	Every Stage 1 check passes or is not applicable.
Agentic feedback loop	Every Stage 1 and Stage 2 check passes or is not applicable.

A repository only advances to a stage when every applicable check in that stage and the earlier ones passes, and at least one check of that stage actually passed (a stage made up entirely of not-applicable checks can’t promote a repository on its own). The overview page shows the highest confirmed stage for each repository and a pass / applicable breakdown per dimension; a later unknown leaves the last confirmed stage visible rather than counting as a failure.

Reading GitHub settings from your assistant

The same GitHub settings Agent Readiness inspects — branch protections, effective merge rules, reviewer access, workflow review permissions, environment metadata and deployment protections — are available to Owners and organisation-wide Managers as the readiness_get_repository_settings tool on the Bilanc MCP server. It works independently of assessments, so you can ask your assistant about a repository’s protections without spending an assessment.

Need help?

Reach out to us at [e-mail] or visit the Bilanc dashboard.