Skip to content

feat(agent): let the assistant create workloads - #290

Merged
scotwells merged 7 commits into
mainfrom
feat/assistant-workload-creation
Sep 14, 2026
Merged

scotwells merged 7 commits into
mainfrom
feat/assistant-workload-creation

Conversation

@scotwells

@scotwells scotwells commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

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:

  • Render a workload. Turns a handful of inputs (image, locations, replicas, ports, environment, config and secret mounts, public IPv4, virtual machine, runtime class) into a complete manifest the platform accepts, and says in plain words which choices cannot be changed after create. It writes nothing.
  • List instance types. The sizes a workload may ask for, so the assistant never invents one.
  • A creation skill. Walks the assistant through prerequisites, the container-versus-VM choice, the common rejections in customer language, and the sequence: gather inputs, render, plan (including a network if the project lacks one), show the diff, get confirmation, apply, then check the rollout.

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

  • Update the compute capability document in datum-cloud/infra as described above.
  • Have the CLI's deploy command render through the same manifest builder so the CLI and the assistant produce identical workloads.

🤖 Generated with Claude Code

scotwells and others added 2 commits September 9, 2026 20:02
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>
scotwells and others added 5 commits September 10, 2026 09:32
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>
@scotwells
scotwells merged commit e01a9f0 into main Sep 14, 2026
10 checks passed
@scotwells
scotwells deleted the feat/assistant-workload-creation branch September 14, 2026 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants