WHEN THE AGENTHAD TO ASKGITHUB

For weeks, I had been trying to get Control Tower over the finish line.

It was painful.

Not the glamorous sort of pain people usually associate with building something new. This was the grinding kind. Authentication boundaries. GitHub Apps. Installation tokens. Revocation semantics. Workflow orchestration. Cloud execution. Claims. Leases. Receipts. Fail-closed controls. One edge case exposing another edge case exposing another edge case.

There were moments when I wondered whether we had simply engineered ourselves into a corner.

Then something happened that made me reconsider what we were actually building.

The system got stuck on GitHub.

And instead of guessing, working around the problem, weakening the control, or declaring victory because a test happened to turn green, the process eventually reached a very different conclusion:

We don't know. GitHub knows. Ask GitHub.

That sounds almost trivial when written down.

It wasn't.

The problem was real

The issue involved GitHub App installation access tokens.

Our system could create an installation token, verify that it had the expected repository scope and six read-only permissions, use it, revoke it through GitHub's documented API, and receive the expected HTTP 204 response.

The problem was what happened next.

The supposedly revoked token continued to work.

Not forever. For seconds.

In our controlled reproduction, GitHub later confirmed that the same classic installation token continued authenticating after the successful revocation response, with the final successful request occurring about 3.1 seconds after revocation. An earlier reproduction showed successful use at least six seconds afterward.

We also tested GitHub's stateless token format.

That did not disappear instantaneously either. GitHub confirmed that both tested endpoints continued returning HTTP 200 for roughly 1.5 seconds after the 204 revocation response before transitioning together to 401.

For an ordinary application, perhaps that becomes a shrug.

Wait five seconds. Retry. Move on.

But that was precisely the kind of reasoning we were trying not to allow inside Control Tower.

If this infrastructure is supposed to govern autonomous execution, credentials, mutations, releases and eventually more consequential systems, then "it seems fine after five seconds" is not a contract.

So the system stopped.

And for a while, that drove me crazy.

Fail-closed feels terrible when you're the human waiting

One of the hardest lessons in building governed autonomous systems is that good controls are incredibly irritating when they are doing their jobs.

The machine says no.

The test refuses to pass.

The candidate won't advance.

Some invariant nobody remembers writing three weeks earlier suddenly becomes the most important object in the universe.

When you're trying to ship something, every instinct says:

Come on. We know what's happening. Just continue.

But in this case, we didn't know.

GitHub's public documentation said revocation invalidates an installation token so it can no longer be used. What we could not find was a documented eventual-consistency model, a maximum propagation time, endpoint-specific behavior, or different guarantees between token formats.

Those were not small details. They defined what our own credential lifecycle was allowed to assume.

So the system kept the release path parked.

Eventually the evidence became good enough that something interesting happened.

The next rational action was no longer another test.

It was escalation.

The next tool was a human organization

This is the part I keep thinking about.

The engineering system had exhausted the information available inside its immediate world.

The answer wasn't in the repository.

It wasn't in our tests.

It wasn't in the workflow logs.

It wasn't in Cloudflare.

It wasn't in the GitHub documentation we could find.

And it certainly wasn't something an LLM should simply invent.

The authority for the missing information lived somewhere else:

inside GitHub.

So the system helped assemble a support case.

Not a vague message saying, "Your tokens seem weird."

A real engineering escalation.

The submission documented the App and installation involved, API version, controlled workflow, reproduction procedure, pre- and post-revocation behavior, security controls, request sequencing and GitHub request IDs. It explicitly avoided including token values, JWTs, private keys, authorization headers or credential-derived fingerprints.

The final submission still crossed a human approval boundary. I submitted the case.

That distinction matters to me.

The agent didn't impersonate me.

It didn't invent authority it didn't possess.

It got the problem to the boundary where a human action was actually required, with the evidence needed to make that human action useful.

A GitHub Support ticket went out.

And then a human at GitHub investigated it.

GitHub answered

On August 11, 2026, GitHub Support came back.

The engineer correlated our request IDs and confirmed the central behavior we had reported.

Then came the part we actually needed.

GitHub explained that although the public documentation does not describe an eventual-consistency model, maximum propagation interval, endpoint-specific guarantee or separate post-revocation semantics for classic and stateless token formats, HTTP 204 remains the documented successful revocation response.

The client contract is straightforward:

Once the 204 is returned, clients should stop using that token and use a newly created token for later requests.

GitHub does not require clients to poll endpoints until they observe 401, and checking a handful of endpoints would not prove that every authentication path inside GitHub had converged anyway.

That answer changed our architecture.

Our earlier thinking had been trying to prove something stronger:

zero provider-valid credential coexistence.

But GitHub had just demonstrated why that wasn't an invariant we could actually control.

The provider's distributed authentication systems may require some amount of time to converge.

What we can control is our side.

Zero client-authorized coexistence. Zero intentional reuse of a revoked credential after successful revocation acknowledgement.

That is a much stronger engineering boundary because it governs something our system can actually guarantee.

And that new knowledge came from outside the system.

This is not the AI-agent story most people are telling

Most conversations about AI agents still seem to orbit a relatively familiar pattern.

Give the model a goal.

Give it tools.

Let it write some code.

Let it run tests.

Maybe let it open a pull request.

Perhaps let several agents work in parallel.

Those capabilities are useful. We're using them constantly.

But this incident exposed something that feels substantially more important.

The agent encountered a boundary it could not legitimately cross through reasoning alone.

It had several possible responses.

It could hallucinate.

It could assume.

It could weaken the requirement.

It could keep experimenting indefinitely.

It could bother the human with a generic "I'm blocked" message.

Instead, the system progressively assembled enough evidence to determine:

The missing authority is external.

This is the institution that owns it.

This is the evidence that institution will need in order to answer us.

That is a different species of behavior.

The human became part of the mesh

I have spent a lot of time thinking about distributed AI systems as combinations of models, software, APIs, repositories, execution environments, databases and deterministic controls.

This experience widened that picture.

Because for a brief period, a GitHub support engineer effectively became another authority node in the workflow.

Not because GitHub participates in our architecture.

They don't.

But the system understood that a question had crossed an institutional boundary.

The answer existed in another organization.

So the architecture routed the unresolved problem there.

Human
  ↓
AI
  ↓
Tools

became

Human authority
  ├─ Deterministic software
  ├─ AI reasoning
  ├─ GitHub / source authority
  ├─ Cloudflare / runtime
  ├─ Evidence stores
  ├─ External APIs
  └─ Other human institutions

The AI isn't necessarily at the center of that system.

That may be the deeper lesson.

It is a participant in a governed network of authorities.

Autonomy may depend on knowing when not to be autonomous

There is an irony here.

People often describe increasingly capable AI systems as systems that need humans less often.

I think that framing misses something.

A mature autonomous system may actually become better at using humans.

Not by constantly asking for permission.

Not by dumping every ambiguous decision back onto somebody's desk.

Quite the opposite.

Routine work should disappear into deterministic machinery.

Well-defined decisions should execute without ceremony.

Known patterns should become code.

AI reasoning should be reserved for unresolved ambiguity.

And human attention should become increasingly scarce and increasingly valuable.

When a human is finally brought into the loop, the system should know exactly why.

That is what happened here.

The AI did not need a human to read logs.

It did not need a human to formulate the reproduction.

It did not need a human to remember which request IDs mattered.

It did not need a human to speculate about the provider's behavior.

It needed a human because the answer belonged to another human institution and crossing that external boundary required legitimate human authority.

That is a far more interesting definition of human-in-the-loop than putting an approval button after every automated step.

The architecture asked for help

This is the sentence I don't want to lose:

The architecture asked for help.

Not because it was helpless.

Because it knew where its authority ended.

That distinction matters.

The system knew a lot.

It knew how to reproduce the defect.

It knew how to isolate credentials.

It knew how to preserve evidence.

It knew how to constrain mutations.

It knew how to recognize that the available documentation did not resolve the contradiction.

And eventually it knew something even more important:

It knew what it did not know.

Then it found somebody who did.

That, to me, is an astonishing property for an autonomous engineering system.

The agony was part of the proof

I'm not going to rewrite history and pretend this was elegant.

Getting Control Tower toward convergence has been brutal.

There were too many stops.

Too many repairs.

Too much infrastructure.

Too many moments when the system's insistence on evidence felt pathological.

But now I can see another side of that discipline.

If we had been willing to wave away the original inconsistency, GitHub would never have seen the case.

If we had allowed the LLM to rationalize the behavior, we would never have learned the actual client contract.

If we had treated successful tests as truth instead of evidence, we could easily have encoded a false assumption into the credential lifecycle.

Instead, the controls forced the uncertainty into the open.

The uncertainty produced an escalation.

The escalation reached the authority that actually owned the answer.

The external answer changed the model.

And now the architecture can continue with a stronger invariant than the one it started with.

That is not failure.

That is learning.

A different picture of AI

I think we are approaching a world where the most capable AI systems will not simply be those that can reason the longest or operate the largest number of tools.

The remarkable systems may be the ones that understand authority.

They will know when something can be calculated.

When something can be deterministically executed.

When a model should reason.

When evidence is insufficient.

When a human judgment is required.

When another system owns the answer.

And occasionally, when another human organization needs to be brought into the loop.

That means the future of autonomous systems may not look like AI replacing everyone around it.

It may look more like AI learning how the world actually works.

A world full of machines, policies, APIs, organizations, jurisdictions, specialists, operators and humans who each possess different kinds of authority.

The intelligence is not merely in solving the problem.

It is in routing the problem to the right authority when you cannot solve it yourself.

After all the agony of the past few weeks, that may be one of the most important things Control Tower has taught me.

We built a system that hit the edge of its knowledge.

It didn't make something up.

It didn't quietly lower the standard.

It gathered the evidence.

It stopped.

It asked for help.

And somebody at GitHub answered.

That feels like a small glimpse of what genuinely governed autonomy might look like.