Setting Up Your First Capability

The Set up a capability wizard is a guided, five-step flow for one specific job: getting a brand-new tenant — nothing connected, nothing built — from zero to a live, working capability. Instead of leaving you to find your way through the Capabilities surface on your own the first time, the wizard takes over the screen and walks you through connecting a system, choosing what it should do, setting how much authority it has, deciding who it acts on, and publishing.

It is deliberately a one-time thing. Once your tenant has even a single connection or a single capability, the wizard steps aside and the regular Capabilities surface takes over.

When the wizard appears

The wizard only offers itself under one condition: your tenant has zero connections and zero capabilities. That’s not a cosmetic gate — on an empty tenant, nothing is mapped yet, there’s no sibling capability whose publish status a new write could disturb, and no subject binding already exists to conflict with. The moment either of those stops being true, the guided flow no longer makes sense, and it won’t be offered as your default path again.

If you start the wizard and then leave before finishing, you’re not locked out — an overflow menu item lets you resume it, but only for as long as the tenant is still empty. Once you (or a teammate) connect something or publish a capability outside the wizard, that resume option goes away along with the wizard itself.

The five steps

The wizard is a straight line — one Continue button per step, and it’s the only way forward. (The progress rail at the side shows you where you’ve been, but it moves backward only; it never saves anything on your behalf.) Each step’s Continue button is what actually commits that step’s answer, so don’t treat any other control on the screen as a save.

• 1. Connect a system — Pick or configure the system you want to give your AI access to, including any credentials or authentication mode it needs. Continue won’t advance until the connection can actually authenticate.
• 2. Choose an action — Pick the specific endpoint on that system you want to turn into a capability. This is also where the capability itself gets created behind the scenes.
• 3. Set the action tier — Decide how much authority this capability has — read-only, act, or transact — before it’s ever run against real data.
• 4. Define subject binding & ownership — Decide what the capability acts on (the subject) and who owns it going forward.
• 5. Publish — Review the checklist and make the capability live, assigned to a specialist.

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 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 Act and Transact skip the test run

If you set the action tier to Act or Transact at step 3, you won’t see an option to test-run the capability before publishing. This isn’t an oversight: running a capability at those tiers requires an active conversation context, and there isn’t one during setup. Rather than offer a “Test” button that would fail every single time, the wizard tells you directly why a test run isn’t available at this tier, and lets you proceed to publish knowing that.

Read-tier capabilities don’t carry this restriction, since read-only actions don’t need that same conversational context to run safely.

Publishing

By the time you reach step 5, publish is gated on your entire checklist — connection, action, tier, and subject binding all need to be in order, not just the publish step’s own requirements. That’s intentional: it stops you from arming a Publish button that the server would immediately reject.

Publishing also requires assigning 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 screen tells you why — with a way to go create one before coming back.
• If you have more than one, you choose which specialist takes ownership of the capability once it’s live.

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.