Adding Multiple Capabilities at Once

Turning a freshly connected account into a set of live capabilities used to mean a bulk-edit modal that only touched name and description — tier, usage guidance, and the specialist still had to be finished one capability at a time in the editor. The Add capabilities flow at /capabilities/add replaces that modal with a full-screen, two-step process — the rail reads Choose what it should do and Review and publish: pick as many endpoints as you want in a ranked choose step, then review every AI-filled setting for each one on its own card, and take the whole ready batch live with a single press of Publish N capabilities.

Opening the flow

The most common way into /capabilities/add is automatic: right after you save a freshly parsed connection and choose to generate capabilities from it, you land straight on this flow with that connection pre-selected. You can also navigate to it directly to add more capabilities to a connection that’s already set up.

If you reload the page — or come back later — with drafts already sitting on that connection, the flow skips the choose step entirely and puts you straight on review with those drafts already loaded. It only asks you to choose endpoints when there’s nothing already committed to work from.

Choose step: picking endpoints

The choose step shows a ranked list of the connection’s endpoints so the ones most likely worth turning into capabilities surface first. Endpoints that already have a capability are left out of this list — you’re picking from what’s still available, not re-adding what’s already covered.

The endpoints the ranking recommends arrive already ticked. Adjust the selection, then press the button that counts it — Prepare 1 capability, or Prepare 12 capabilities for a batch of twelve — to commit the batch and move into review. One batch holds at most 200; go over and the button is held with a sentence telling you to untick some and add the rest in a second round, rather than leaving you guessing.

Two things worth knowing about this step:

• Add more, on the finish screen, refreshes the ranking rather than reusing a stale list, so anything published or removed elsewhere shows up correctly if you go back to add another batch.
• If you use Back after committing, the endpoints that were already committed no longer appear in the choose selection — so Back can’t accidentally resubmit them and trip a duplicate.

Review step: one card per capability

Once a batch is committed, each endpoint becomes its own card on the review screen, under the heading What we prepared. Every card is editable and shows what the AI filled in for that capability:

• The capability name, over the endpoint’s method and path
• What it does — the description
• When should the Agent Stack use this? — the usage guidance
• How far it may go — one pill per tier, Public, Read, Act and Transact, with a sparkle on the one the AI proposes
• Blockers — anything that has to be resolved before that row can publish, plus a status chip: Preparing, Ready, Needs attention, Needs a hand, Publishing or Live

Only a Public proposal is pre-filled automatically. Anything above it — Read, Act or Transact — leaves the pills unselected on purpose, with the note We propose … — tap it to confirm how far this may go; someone has to tap it before that row’s tier_set requirement clears. This mirrors the same auto-confirm rule the backend enforces on its own: nothing above Public goes live without a human decision.

Cards can also carry warnings that aren’t hard blockers but are worth reading before you publish — a connection on Shared credentials with no key saved shows a banner over the whole batch (Anything published here fails on every customer call until the connection gets its key), and a card whose tier is set to Public on an endpoint that changes data (any method but GET) says so on that card.

Picking the specialists

Rather than assigning per capability, the review step has one Who can use them picker shared across the whole batch — Which specialists should be able to use these? — and it takes as many specialists as you like. Pick them once and they apply to every row when you publish; the publish run reads each specialist’s existing assignments a single time for the whole batch rather than once per row. A tenant with exactly one specialist gets it selected by default, and clearing the picker sticks.

The specialist pick — and the rest of the cards — freezes while a batch is actively publishing, so an edit mid-run can’t quietly miss the snapshot that publish is working from.

Resolving blockers

A card lists its blockers plainly, and a row can’t publish until they’re cleared. An unconfirmed Read, Act or Transact tier is the most common one, but a card can also carry other unresolved requirements from the same publish checklist used elsewhere in capability editing — the review step runs the same publish-gate check the single-capability editor does, so a row that’s ready here is ready anywhere.

If a name collides with an existing capability in the tenant — capability names are unique tenant-wide, not just per connection — you’ll see a clear sentence telling you a name needs to change, instead of the batch silently failing. Renaming to something that still collides gives the same clear answer rather than a generic error.

Publishing the batch

Publish N capabilities is one action for the whole review screen, and the count in the button is the number of rows with no outstanding blockers. It walks those rows and takes each live, showing progress per row so you can see which capabilities have gone live, which are still working, and which hit a problem. When the button is held, the reason is spelled out above the cards — no specialist chosen, rows still preparing, or nothing left that can go live.

A few behaviors to know once you hit Publish:

• If a row’s specialist assignment fails during publish, the capability is still marked live and stays on screen with its own error sentence — it doesn’t disappear or get treated as failed outright. You can act on that row without re-running the whole batch.
• If the commit itself fails because the queue is temporarily down, the flow keeps the stuck rows’ own selections and lets you retry rather than depending on a cache that was never refreshed.
• A row’s retry or remove spinner is scoped to that row only — retrying or removing one capability doesn’t lock up the rest of the batch.
• Once a batch is committed, the screen tracks only the rows this run created or picked up on entry — a draft a teammate adds on the same connection mid-run doesn’t get swept into your publish. (On entry, before anything is committed, the flow does adopt the AI-generated drafts already waiting on that connection: that is the resume behaviour above. Capabilities you built by hand are never adopted.)

When publish finishes with nothing failed and nothing left behind, the flow ends on its own screen — your Agent Stack can now do N new things — with Back to capabilities and Add more. Every row that succeeded is live with its AI-filled description, usage guidance, confirmed tier, and the batch’s specialists already in place — no separate trip through the single-capability editor needed.