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: 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 in a review step, and take the whole ready batch live with a single Publish.

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.

Select as many endpoints as you want, then commit the batch to move into review. If a batch is larger than the server allows, it’s stopped before it commits and you’re told why in a sentence rather than left guessing.

Two things worth knowing about this step:

• Add more 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. Every card shows what the AI filled in for that capability:

• Description — what the capability does
• Usage guidance — how the agent should use it
• Proposed tier — read, act, or transact
• Blockers — anything that has to be resolved before that row can publish

Only a read tier proposal is pre-filled automatically. If the AI proposes act or transact, the tier pill is left unselected on purpose — someone has to tap it and confirm the tier by hand before that row’s tier_set requirement clears. This mirrors the same auto-confirm rule the backend enforces on its own: nothing above read goes live without a human decision.

Cards can also carry warnings that aren’t hard blockers but are worth reading before you publish — for example, a connection using full access with no key saved shows a banner, and a write-capable endpoint whose connection is limited to Read shows a warning line on that endpoint’s card.

Picking a shared specialist

Rather than assigning a specialist per capability, the review step has one specialist picker shared across the whole batch. Pick it once and it applies to every row in the batch when you publish — the publish run reads the specialist’s assignments a single time for the whole batch rather than once per row.

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 act/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 is one action for the whole review screen. It walks every row that has no outstanding blockers and takes it live, showing progress per row so you can see which capabilities have gone live, which are still working, and which hit a problem.

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.
• Rows only track the capabilities created in the current run, not every draft sitting on the connection, so re-opening the flow later doesn’t accidentally sweep up unrelated drafts.

When publish finishes, every row that succeeded is live with its AI-filled description, usage guidance, confirmed tier, and shared specialist already in place — no separate trip through the single-capability editor needed.