Register the ALB agent so entitled customers get it - #518
Merged
Merged
Conversation
The load balancer capabilities this repo publishes — the knowledge document, five read-only ALB tools and ten triage guides — were registered from raw JSON in the infra repository, mounted into the assistant as a fixture file. This team's provider content sat where it neither reviewed nor versioned it, and adding a guide under docs/agent/skills/ meant a second change in a repository its author probably did not have open. The fixture also could not be scoped: it named no project, so every project reaching the staging assistant got these tools whether entitled or not. Registers instead what a provider owns: a ServiceAgent for the agent itself and a ServiceAgentConfiguration for the content it offers. The service catalog copies that content into each entitled project, as the object the assistant reads there (milo-os/service-catalog#110). Content is byte-identical to the fixture it replaces, and both objects validate closed-world against the catalog's CRDs. The MCP endpoint is still alb-mcp's in-cluster address, which is what staging dials. Production needs it pointed at the AI gateway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ecv
approved these changes
Sep 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This repo publishes load balancer capabilities to the Patch assistant — a knowledge document, five read-only ALB tools, and ten triage guides. Until now the thing that registered all of that lived as raw JSON in the infra repository, mounted into the assistant as a fixture file.
That put this team's provider content somewhere it was neither reviewed nor versioned, and split every change in two: add a guide under
docs/agent/skills/, then go edit a JSON blob in another repo to make anyone see it.The fixture also could not be scoped to a project. It named none, so every project reaching the staging assistant got these tools whether entitled to networking or not.
What this registers
ServiceAgentServiceAgentConfigurationThe service catalog copies that content into each entitled project, as the object the assistant reads there. This repo never writes into a customer's project — it says what it offers, and entitlement decides who gets it.
Content is byte-identical to the fixture it replaces, verified field by field, and both objects validate closed-world against the catalog's CRDs so a misspelled field would fail rather than being silently dropped. I also checked the ten guides registered here against the ten actually in
docs/agent/skills/— they match exactly, no drift.One improvement falls out of the shape: content changes now ship as a new configuration object rather than an edit, and the newest Published one wins. That keeps "which version did this customer actually see" answerable.
Depends on
milo-os/service-catalog#110, which adds these two kinds and the controller that copies them. Until that merges and deploys, these objects are inert — nothing reads them, and staging keeps serving from its fixture. Merging this changes no running deployment.
Sibling registrations: datum-cloud/compute#381 and the DNS equivalent in
dns-operator. All three have to land before the assistant can be switched off the fixture (datum-cloud/infra#6399), or whichever is missing silently disappears from every project.Unchanged caveat
The MCP endpoint is still
alb-mcp's in-cluster address, which is what staging dials today. Production needs it pointed at the AI gateway — going direct means the call is not billed, does not carry the customer's identity, and will be refused.🤖 Generated with Claude Code