feat(agent): let the assistant create workloads - #290
Merged
Merged
Conversation
Add discovery, render, validate, and token-bound plan/apply tools to compute-mcp, a workload-create skill, and a shared workloadspec package used by both the assistant and datumctl compute deploy. Prefix every published tool with compute_. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
compute_locations_list now reads compute's own ServiceAvailability records and the Locations they name, never LocationBindings. A control plane that does not serve those kinds fails loudly instead of answering with an empty list. Adds ServiceAvailability as a manager location source without changing the default. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Main moved placement from city codes to locations (#264), added runtime classes (#259), published a shared instance-type catalog, and grew `datumctl compute deploy` a URL-publishing path (#289). The assistant's workload-creation surface was rebuilt on top of those rather than beside them. Semantic resolutions: - Placements are locations. `workloadspec.Placement` drops `CityCodes` for `Locations []string` plus `LocationSelector`, exactly one of which must be set; render emits `spec.placements[].locations` or the selector and refuses an empty or malformed one, the way admission does. The render tool's schema, its notes, the diff summary, the workload-create skill, llms-full.txt and the README all say "location" and point the model at `compute_locations_list` for the names, with `locationSelector` named as the way to place in every location of a city or region. - Location resolution keeps main's structure. `SourceServiceAvailability` is gone; `locations.ListAvailableLocations` is built on main's `AvailableLocations` and errors with `ErrAvailabilityNotServed` when the control plane serves no availability, so `compute_locations_list` still fails loud rather than reporting a project with nowhere to run. The manager's placement reads, which treat an unserved kind as no gate at all, are unchanged. The tool now reports `placeable` and `ready` alongside the name, city code and topology. - Instance types read `pkg/instancetype`. `validation.SupportedInstanceTypes` and the duplicated sizing table in the agent are deleted, along with TODO(#137): the catalog is the single source now. - Runtime classes: `workloadspec.Input` gains an optional `RuntimeClass`, passed through verbatim with no default, so the server picks its own. - `internal/cmd/compute/deploy/deploy.go` is main's version wholesale, for `--location`, `--location-selector`, `--city` and `--http-port`. The CLI no longer renders through workloadspec, so the parity test that pinned the two together is deleted rather than left stale. - Docs take main's triage-skill changes with this branch's `compute_` renames on top, and workload-create now says that a public HTTPS URL is published separately — today only by `datumctl compute deploy --http-port` — so `ports` makes a port reachable on the instance's address, not on a managed URL. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…tion The assistant now gives every project turn generic tools for locations, quota, listing resources, and a token-bound validate/plan/apply path that acts as the caller. Compute no longer re-implements them: its MCP server keeps only what is compute-specific, rendering a Workload manifest the admission webhook accepts and the instance type catalog, alongside the existing diagnosis tools. This drops the compute locations, networks, quota, validate, plan and apply tools, the plan token key, the extra scheme registrations, the workload diff, the shared quota view (the CLI keeps its own), and the availability-only location listing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The workload-create skill gathers inputs with locations_list (service compute), quota_get, resources_list and compute_instance_types_list, renders with compute_workload_render, and plans a missing Network in the same resources_plan call before resources_apply. The knowledge document, README and quota-triage point at the base tools in place of the removed compute ones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mattdjenkinson
approved these changes
Sep 14, 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
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.
What a customer gets
Until now the assistant could only explain why a workload was broken. This PR lets it help create one, without the customer needing a shell or knowing the Workload API.
A customer can ask the assistant "deploy my image to Dallas" and it will check where compute is offered to their project and how much quota is left, draft a valid Workload manifest, show exactly what will be created, and only apply it after an explicit yes. Every step runs as the customer.
How it fits together
The assistant now ships generic tools in every project conversation for listing locations and quota, reading resources, and a plan-then-apply change path with a confirmation token (milo-os/assistant#74, milo-os/assistant#75, milo-os/assistant#76). Compute builds on those rather than duplicating them, and only adds what is specific to compute:
The knowledge document and triage skills point at the assistant's generic location, quota and change tools where they used to rely on compute-specific ones.
Breaking change
Every compute assistant tool is now prefixed
compute_so tools from several services can be composed without name collisions. The compute capability document in datum-cloud/infra must be updated to register the prefixed names and the workload-create skill before this is deployed, otherwise the assistant loses access to compute's tools.Follow-ups
🤖 Generated with Claude Code