> ## Documentation Index
> Fetch the complete documentation index at: https://bilanc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/user-management#restricting-access-to-specific-teams-locations-or-levels)).
## 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](/mcp-server#code-read-only-inspection-of-your-repositories) 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.
| Check | Stage |
| - | - |
| Working instructions | 1 |
| Submitting changes | 1 |
| Codebase overview | 1 |
| Interfaces and data | 1 |
| Check | Stage |
| - | - |
| Tool versions | 1 |
| Setup | 1 |
| Dependency installation | 1 |
| Build/code generation | 1 |
| Configuration | 1 |
| Development services | 1 |
| Local/CI agreement | 2 |
| 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 |
| 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](/mcp-server#repository-settings-github-configuration-outside-the-files). 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 [sam@bilanc.co](mailto:sam@bilanc.co) or visit the [Bilanc dashboard](https://app.bilanc.co).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.