The agent reads the code and proposes proved fixes

Problem

RFC 0077 records the fix a person wrote. The owner wants more in the long run: an agent that looks into the code when an incident starts, finds the change that caused it, and proposes the repair, and that later proposes improvements of its own (a dependency with a known vulnerability, a test that fails one run in ten, a handler that got slower).

Agents that write code are common. What they lack is the proof: a proposed change arrives with a confident description and no measurement, and a person has to find out whether it works. This platform is built on the opposite rule (RFC 0045): a change counts when it is measured. RFC 0047 runs that loop for our own platform, RFC 0040.14 defines the verdict a pull request carries, and RFC 0074.5 lets a person approve a repair from the phone. This RFC is how the GitHub agent joins that loop on a customer's code.

Proposal

Three levels, chosen per repository

A GitHub App's permissions are the same for every installation, and adding one asks every installation to accept it again. So levels 2 and 3 are a second App, InOrbit Engineer, which a customer installs only on the repositories it wants investigated or fixed. InOrbit Agent keeps the narrow permissions customers already accepted. The console shows, per repository, which level is granted, and the agent never acts above it.

Investigating an incident

When an incident opens on monitors tied to a repository at level 2, the agent writes an investigation on the incident. It reads, in this order:

1. what the monitors measured: when the failures began, which checks, which error classes (RFC 0037);
2. what changed shortly before: pull requests merged and rolls recorded (RFC 0041, RFC 0077), with their diffs;
3. the code on the failing path, found from the monitor's target and the repository's routes;
4. earlier incidents and postmortems on the same monitors (RFC 0058).

The investigation lists hypotheses, each with the measurement and the change it rests on ("p95 rose a quarter of an hour after #312 changed how connections share the router"), ranked by how much of the measurement each explains. It is labelled as written by an AI agent (AI Act Art. 50) and never edits the postmortem; a person copies what is right.

Proposing a fix

At level 3, for the hypothesis a person picks (from the console or the phone), the agent:

1. writes the change on a branch named after the incident, with Fixes: INC-xxxxxx and the claims it makes in machine-checkable form (RFC 0047);
2. runs the repository's own tests and the platform's bench before and after in the sandbox (RFC 0010) or on the customer's agent (RFC 0029), never on shared hosts and never with production credentials;
3. opens a draft pull request only if its own claims held, with the change verdict of RFC 0040.14 on it: pass, fail, regressed or incomplete, and the evidence behind each.

The agent never merges, never pushes to a protected branch and never marks its draft ready for review by itself. A person reviews and merges, through GitHub or, for a repair, by approving on the phone (RFC 0074.5). From the merge on, RFC 0077 records it: merged, live, and whether the monitors say the fix held.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

Improvements of its own

After incidents, the same path proposes changes nobody asked for, each only with a measurable claim: a dependency with a published vulnerability (the EU Cyber Resilience Act asks for exactly this), a test whose failure rate the CI history shows, an endpoint whose latency a monitor shows rising. A proposal without a claim the bench can check is not opened.

Models and code

Code is customer data. The agent uses the platform's self-hosted models by default; a customer can allow a third-party model per repository, and only a provider under a data processing agreement can be chosen. Code is read into the sandbox for the length of the task and not kept; the investigation stores references (file, line, commit), not copies.

Security and compliance

• Least privilege by level and by repository. Level 1 is the default; levels 2 and 3 are a separate App on chosen repositories, and the agent checks the granted level on every action.
• Nothing merges without a person. Branch protection is respected; the agent opens drafts only.
• Isolation. Proposed changes run only in the sandbox or on the customer's agent, with no production secrets and no network beyond what the tests need.
• Customer data. No code to a third-party model without the customer's choice and a DPA; no code in logs, traces or error messages; references, not copies.
• AI disclosure. Investigations, proposals and comments say they were written by an AI agent.
• Audit. Every read of a repository and every branch push is logged with the installation, the repository and the incident.

Plan

1. This RFC.
2. RFC 0077 first: reporting, live and proved.
3. The InOrbit Engineer App and the console's levels per repository.
4. Investigations at level 2, on our own repositories first (the platform is the first customer, as in RFC 0047).
5. Proposals at level 3 with the sandbox run and the change verdict, on our own repositories, measured against planted regressions before any customer sees one.
6. Improvements of its own: vulnerable dependencies first.

Alternatives considered

• One App with every permission. One install, and every customer asked to give code write to an agent that, for most of them, only reports. Rejected.
• Let the agent merge when the verdict passes. Faster, and a failure mode no customer should accept from an agent: the verdict measures what it was told to measure. A person merges, at the moment or ahead of time through a standing approval for a named class of change (RFC 0101).
• A third-party coding agent behind the App. Faster to build, but its proposals would arrive without the platform's measurements, and code would leave the platform. The loop and the evidence are the product (RFC 0045).

Decision

Open. The owner asked on 2026-10-06 that the GitHub agent should, in the long run, investigate the code and propose updates.

Publication

Public.

Status log

• 2026-10-06: Opened at the owner's request, as the long-run part of RFC 0077.
• 2026-10-07: Checked: nothing built (#476 is the text). Open.
• 2026-10-09: What happens to a proposal after it is opened (gate, approval, merge, roll, resolved) is RFC 0101.