Finding your way around Kav Studio
A tour of the Studio's modules, and the one distinction that matters everywhere in it: a draft you're still shaping versus what residents actually see.
The Studio is organized around the things a city actually configures, not around a menu somebody thought looked tidy. Each module is a distinct concern:
- Catalogue — the capabilities the assistant can call, and the modules and versions they belong to.
- Connectors — the instances that actually reach your systems (a base URL, a credential, a mode).
- Channels — the website widget, Telegram, WhatsApp and the rest, and their branding and reply-window rules.
- Knowledge — the sources your assistant reads, and the approval queue that governs what it's allowed to say.
- Rules — decision tables for eligibility, discounts and routing.
- Flows — the conversation menus, forms and handoffs, as a diagram or a real editable grid.
- City — branding, model credentials, languages and the effective-config view for one municipality.
- Staff & Desk — who on your team can do what, and how conversations queue to them.
The one idea that repeats everywhere: draft versus published
Almost everything you edit in the Studio — a flow, a rule set, a capability's semantics — exists as a draft until you deliberately publish it. Saving a draft is unconditional: it can be half-finished, inconsistent, even wrong, and the Studio will still let you save it, because a draft is where thinking happens.
Publishing is different. It's blocked until a set of gates clears — validation errors, failing tests, a decision with no default outcome, an unrun preview — and every one of those reasons is shown next to the publish button before you click it, not after. Once something is published, it's frozen: you can't edit a published flow graph in place, because a resident might be halfway through it right now. Any further change opens a new draft, which becomes the next version when it's published in turn.
This matters for timing: a change you make in the Studio does not reach a resident until you publish it. If something "isn't working" after an edit, the first thing to check is whether it's still sitting in draft.
Where to start
- If your organization already has capabilities and connectors set up, start in Flows or Rules — that's usually where day-to-day changes happen.
- If you're setting up something new end to end — a brand-new system Kav should answer from — start with Connectors, then Catalogue. The first-capability guide walks through exactly that.
- Whatever you're editing, look for the environment badge in the corner of the screen. Draft and published state, and even dev versus production, are shown explicitly — nothing here is a guess.
Every write in the Studio reports its outcome as a real confirmation, not just "request sent." If a save or a publish seems to hang, check for that confirmation before retrying — retrying a write that already landed is exactly what idempotency keys exist to make safe, but it's still worth knowing which happened.