What you can do

Each group below starts with what it lets you get done. The table underneath it is reference material: the names of the tools your assistant will call. You never type a tool name yourself. You describe what you want to happen, and the assistant picks the tools. For prompts written the way you would actually type them, see Example prompts.

Scope is the permission you have to tick when you connect for the tool to work at all. In shorthand: DISCOVER is List environments & AI Agents, READ is Read configuration & conversations, WRITE_STAGING is Edit the staging version, WRITE_PROD is Publish to production, ANALYTICS is Read usage analytics, CHAT is Test conversations. Whether an edit lands on the draft or on what customers see is covered in Permissions and versions.

This page is a map of what is possible, not a set of instructions you have to pass on. The server tells your assistant how each of these works — the order steps have to happen in, what has to be trained or switched on, which formats Zowie expects. You say what you want; working out the sequence is its job.

Getting oriented

Start here when you are not sure what you are looking at. Ask what you have access to and you get a straight answer: which Zowie environments you can reach, which AI agents live in each one, which languages and regions they serve, and whether the one you care about is live. This is also where the assistant reads Zowie's own background material, so that it does not have to guess how Zowie works before it touches anything.

Persona and guidances

This is how the agent sounds and what it must or must not do in specific situations. The persona covers how it sounds, and a guidance is one rule it has to follow.

You can change the tone for one channel without touching the others, so email can be formal while chat stays friendly. You can add a rule in plain language, such as when a customer mentions a chargeback, never promise an outcome and offer to hand over to a human. Rules can be limited to particular regions or channels, so a policy that only applies to your German market stays there. All of it lands on the STAGING draft for you to review before it reaches customers.

Intents

An intent is what Zowie thinks the customer is trying to do, and it decides which path the conversation takes. So this is where you fix misrouting: the customer asked to change a delivery address and the agent started a returns flow instead. You can see every intent and what it routes to, read the phrases it was trained on, and add the wordings your customers really use, including typos, the local slang for your market and the people who just paste an order number and nothing else.

Nothing here reaches customers until you decide it should. Putting an intent into service is a decision of its own, so you can rework routing and add phrasings knowing that nothing moves underneath you in the meantime.

Processes and system workflows

Processes are the step-by-step flows your agent runs: ask for the order number, look the order up in your shipping system, take a different route depending on the answer, hand over to a human if it fails. Here you can read a flow end to end and ask why it dead-ends, then change the part that is wrong. For example, if your shipping system does not answer in time and the customer is left looking at a raw error, you can change that step so they get a calm "we're checking with the warehouse" instead, followed by a handover.

You can also decide which flow owns each fixed moment in a conversation: the greeting, the "I can't help with that", the "get me a human".

A process is made of individual steps, called blocks, and a change can be as small as one of them. So a fix to a single step stays a fix to a single step — easy to read back, easy to undo — rather than a rewrite of the whole flow.

You do not have to brief it first. Zowie ships the assistant its own material on how processes are put together — what each type of step does, the ways a flow can end up looping, what is available inside a code step — and the server tells it to read that before it builds anything.

Data types and global variables

This is what the agent asks customers for and how strictly it checks the answer. If refunds keep failing because people type their IBAN with spaces, or paste an order number in the wrong format, this is where you tighten the checks and improve the wording the agent uses to ask. Global variables are values that several processes share, so you define something once instead of in five places.

Knowledge policies

This is the knowledge your agent answers from. Your assistant can read it but not change it. Use it to check what the agent is actually allowed to say before you blame it for a bad answer: search for a topic, read the exact wording, and see whether the article ever made it across from your knowledge base. It is often the fastest way to settle "did the agent make that up, or is it in our knowledge base?". Editing knowledge still happens in the Zowie UI.

Interactions and troubleshooting

This is the group most people use first. An interaction is one conversation with a customer, and it has an id you can copy out of the supervisor. Hand that id to the assistant, ask why something happened, and you get the answer end to end: the full transcript, every decision the agent made along the way, which process step it was in, which of your systems it called and what came back. If you want to go all the way down, you can also see the exact instructions the AI model was given at the moment it went wrong.

You can also work the other way round and start from a pattern rather than a single case: yesterday's chats that got a thumbs-down and ended in a handover, everything filed under a particular contact reason, every conversation where a process hit an error. Then let the assistant read the worst ones and tell you whether the cause was a misrouted intent, a broken connection to another system, or a bad answer.

Your own test conversations and real customer conversations both land here, so you can look into what your tests did the same way you look into what a customer experienced.

Contact reasons

Contact reasons are the categories every finished conversation gets filed under, and they decide what your reporting can even see. Your assistant can review the whole set, spot categories that overlap or are too vague to be useful, check which definitions were in force when a particular conversation was classified, and rework the set for you.

Reworking it is the one edit in this whole page with no draft to review. There is no staging copy of contact reasons, so a change takes effect on the live AI agent at once, and it applies to how conversations are classified from now on — conversations already filed keep the category they have. It is also the one edit that needs Publish to production at consent time and an AI agent set to Write to live. Ask to see the proposed set before it is written.

Analytics

This is the reporting layer, and it is an addition to the group above rather than a replacement for it. Analysing conversations — reading them, finding the pattern, working out the cause — needs nothing from this section. What this adds is your Zowie data as a set of tables the assistant can query directly, so you can ask for automation rate month over month, CSAT by contact reason, handover rate by channel, or which topic grew fastest since the last release, and get a figure across everything rather than a read of a sample. You describe the question in your own words and the assistant writes the query.

Two things to know. It only works if Zowie has switched analytics on for your account — see Permissions and versions. And the data is loaded once a day, up to the previous midnight UTC, so today is never in it. For anything happening right now, the interaction tools above are the ones that answer.

Test chat

Talk to your agent the way a customer would, without leaving the conversation you are already having. You can play a difficult customer, such as the one whose parcel is marked delivered but never arrived, or the one who pushes back twice and then demands a refund, and watch what the agent does with your new rule or process before anyone real meets it.

This is a real conversation with the real agent, not a simulation. It runs the tools you configured, it calls your systems, and it uses up real AI model capacity. Treat it as a rehearsal. It uses the STAGING draft unless you say otherwise, and every test conversation can be inspected afterwards with the troubleshooting tools described above.

Test conversations show up alongside real ones, marked as started from MCP.

Feedback

You can report a bug, a gap or something confusing from inside the conversation where you hit it. See Connect.