Setting Up Your First Capability

The Set up a capability wizard is a guided flow that takes over the screen and walks you from a system nobody has connected yet to a live, working capability assigned to a specialist: connect a system, choose what it should do, say how far it may go, watch it run, publish.

It is the permanent create path, not one-time onboarding — it is the only surface that presents connection, tier, binding and publish as one sequence.

When the wizard appears

Guided setup runs on any tenant, empty or not. It is offered from the ⋯ menu (More capability actions) in the Capabilities card header, as Guided setup. What used to be an empty-tenant gate now guards the risky write instead of the door: step 1 has no picker for an existing connection — it only ever creates one — so the flow is safe on a busy tenant, and it refuses the connection-scoped answers (the customer field and the ownership rule) on a connection any other capability is already using.

The tenant-is-empty question still exists, but it only decides what the empty Capabilities list leads with: on a tenant with no connections and no capabilities the empty state offers Set up your first capability, with Set it up myself underneath.

If you start the wizard and leave before finishing, you’re not locked out. The same overflow item reads Carry on setting one up while a half-finished run exists, and re-entering the wizard shows a banner naming what you were building with Carry on and Start again. The pointer lives in the browser tab’s session storage, so it survives a reload but not a new browser session — and Start again keeps the connection and leaves the earlier draft capability alone rather than deleting it.

The five steps

The rail shows five steps, plus one indented sub-step that appears only above the Public tier. Continue is the only way forward: the rail moves backward only, because each step’s answer is written on the way forward and a rail row that advanced would skip the save.

• 1. Connect a system — Point the wizard at the system’s documentation, or at an address where it can find a machine-readable description, and give it the key. Continue opens once a connection exists, a sign-in method is chosen, and — on Shared credentials — a key is saved or typed. It does not test that the credential works.
• 2. Choose what it should do — Pick the specific endpoint you want to turn into a capability, from a ranked list. This is also where the capability itself gets created behind the scenes.
• 3. How far it may go — Choose the action tier — Public, Read, Act or Transact — before it’s ever run against real data.
• 3b. Who it is for — Only above Public: name the field that carries the customer, and the ownership rule. It renders indented under step 3, and both answers are stored on the connection, so they are read-only when anything else already uses it.
• 4. Watch it work — Run it once against real data and read the response. Above Public the step becomes What happens when a customer asks and shows the shape read-only instead.
• 5. Publish — Review the checklist, choose the specialist, and press Publish capability.

Continue commits step 1’s credential and step 2’s endpoint. It does not commit steps 3 and 3b: the tier is written the moment you pick it, and the customer-field and ownership cards commit from inside themselves — so those answers are already saved before you press anything.

A couple of things worth knowing as you move through it:

• Re-picking an action replaces, not adds. If you go back to step 2 and choose a different endpoint, the draft from your first choice is discarded before the new one is committed — you’ll always end the flow with exactly one capability, not a spare draft left behind. The one exception is a run whose capability already went live: the wizard will not delete a published capability, and tells you to finish that one in the editor instead.
• The action tier you set at step 3 is what gets published. The system doesn’t quietly re-derive or auto-correct it later — what you chose is what ships.

Why some screens wait on you (and show skeletons)

Step 2 kicks off an asynchronous background job the moment you choose an action — it doesn’t come back with a finished answer immediately. The capability is created in a pending enrichment state while the system works out usage guidance and a proposed tier in the background.

That means steps 3 and 4 exist partly to give that background job somewhere to finish while you keep moving — you’re not stuck watching a spinner. But if enrichment hasn’t finished by the time you reach the later screens, you’ll see:

• Skeleton placeholders shaped like the eventual result, rather than a blank or broken-looking screen.
• A short poll checking the capability’s status every couple of seconds until enrichment completes.
• A disabled Publish button. Publishing while enrichment is still running will fail — the server checklist includes a usage-guidance item that nothing on screen can satisfy until the background job finishes. Rather than let you press a button that’s guaranteed to fail, the wizard holds it disabled and tells you why.

If enrichment fails outright rather than just running long, you’ll see a retry option instead of an indefinite wait — but only once the underlying job has actually reached a failed state; a job still in progress can’t be retried out from under itself.

Why only Public gets a test run

Step 4 offers a Run button on exactly one tier: Public. Set Read, Act or Transact at step 3 and there is no run to press — above Public the platform refuses a call outside a conversation in which the customer has proved who they are, and there is no such conversation during setup. Rather than offer a button that would fail every single time, the step retitles itself What happens when a customer asks, lists the values the capability will take from the conversation, and says the capability proves itself the first time a verified customer asks.

(A tier nobody has chosen yet behaves the same way, and says so: Say how far this may go first — until then we cannot run it here.)

On Public, the run goes against the real system, and the step says so — Run it once against real data … Nothing is published yet. You can publish without trying it.

Publishing

By the time you reach step 5, Publish capability is gated on your entire checklist — the name, the connection and endpoint, the tier, the customer field, the ownership rule, the customer sign-in path, and the guidance the background job writes — not just the publish step’s own row. That’s intentional: it stops you from arming a button that the server would immediately reject. A blocked row names what is missing, and choosing it jumps back to the step that owns it.

Publishing also assigns the new capability to a specialist:

• If your tenant has exactly one specialist, it’s selected for you automatically.
• If you have none yet, Publish stays disabled and the card says so, with a link to Agent Stacks to go create one — this setup waits for you in this tab.
• If you have more than one, you pick which specialist should be able to use it.

Some endpoints also need to know which customer they are acting for. When an endpoint is bound to a customer field, Publish stays disabled until the connection can identify the customer through verified sign-in. You don’t fill that bound field during the tool call; the platform fills it from the signed-in customer’s verified identity when the capability runs.

Once published, the capability is live immediately — there’s no separate activation step, and no additional auto-publish behavior runs after the fact. What you set at step 3 for the action tier is exactly what goes live.

Publish and the hand-over to the specialist are one press, but not one transaction. If the capability publishes and the assignment then fails, the wizard says so — This is published — it just isn’t given to a specialist yet — and pressing Publish capability again finishes the hand-over rather than publishing twice.