Compute owns its assistant registration - #369
Merged
Merged
Conversation
…Binding Compute's capability document — the knowledge, tool allow-list, and seven skills it contributes to an entitled project's Patch assistant — lived as raw JSON in the infra repository, mounted into the assistant as a fixture file. Compute's provider content sat where compute's team neither reviewed nor versioned it, and adding a skill under docs/agent/skills/ meant a second change in a repository its author probably did not have open. It now ships here as a CapabilityBinding (capabilities.assistant.miloapis.com/v1alpha1), the CRD the assistant landed in milo-os/assistant#87, beside the docs and runbooks it names. The object is cluster-scoped and belongs in a project control plane, not in Milo root and not in the workload cluster where compute's manager runs: a Milo project is a virtual control plane, so the plane is the tenancy boundary and one apply entitles one project. metadata.name is the agent name the service catalog's projection controller uses, so when that controller starts materializing bindings it converges on this object instead of creating a second one that would collide tool-for-tool. The MCP endpoint is compute-mcp's ClusterIP, which is what staging dials today. Production needs an MCPRoute fronting compute-mcp and this rewritten to it: the assistant refuses to dial a host outside CAPABILITY_MCP_ENDPOINT_HOSTS and reports Composed=False, and a direct endpoint would bypass the gateway-side copy of the allow-list, go unmetered, and receive no caller identity. The comment on the field says so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The comments were doing a design document's job: control-plane partitioning, tenancy boundaries, and the history of how the object got its name. That buries the part a reader needs. Plain language now, and only where a wrong value actually breaks something — the endpoint that must change before production, the service name that billing uses, the allow-list that silently hides a tool. The reasoning lives in the commit history and docs/agent/README.md instead. No content change: the rendered object is identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ecv
approved these changes
Sep 25, 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.
Compute publishes knowledge, a reviewed tool allow-list, and seven triage skills to the Patch assistant. Until now the document that registers all of that lived as raw JSON in the infra repository, mounted into the assistant as a fixture file.
That put compute's provider content somewhere compute's team neither reviewed nor versioned, and split every change in two: add a skill under
docs/agent/skills/, then go edit a JSON blob in another repo to make anyone see it.This moves the registration here, as a
CapabilityBinding— the CRD the assistant landed in milo-os/assistant#87 — inconfig/components/assistant-capability/, beside the docs and runbooks it names. Adding a skill is now one change in one repo.What it declares
The same content staging serves today, unchanged: the
llms-full.txtknowledge document, three resource-model concepts, the sevencompute_*tools (all read-only — compute publishes no mutating tool), and all seven skills.Before this can go to production
An MCPRoute fronting
compute-mcp. The endpoint here is compute-mcp's ClusterIP, which is what staging dials today and works because staging sets no endpoint allow-list. Production sets one, and the assistant refuses to dial a host outside it — reportingComposed=Falseon the binding rather than failing a chat. A direct endpoint would also bypass the gateway-side copy of the tool allow-list, go unmetered, and receive no caller identity. No such route exists yet; the comment on the field says so.Something to apply it per project. The object is cluster-scoped and belongs in a project control plane — a Milo project is a virtual control plane, so the plane is the tenancy boundary and one apply entitles one project. At scale that is the service catalog's projection controller's job.
metadata.nameis the agent name that controller uses, so when it starts materializing bindings it converges on this object instead of creating a second one that would collide tool-for-tool.Nothing in compute's overlays references this component yet, so merging changes no running deployment — same as
config/components/service-catalog/, which infra references.🤖 Generated with Claude Code