Plan requirement
| Subscription | Any plan |
| Access | Admin |
Where AI agents are built and watched. Knowing which part answers which question saves a lot of clicking.
The parts
- The agent list, showing what exists and what is live.
- Replies and dialogues, what the agent says and the exchanges it can carry.
- Knowledge, which content it may answer from.
- Actions, what it can do in other systems.
- Channels, where it appears.
- Conversations, transcripts of what actually happened.
- Reporting, the numbers on top of those conversations.
The one to spend time in
Conversations. Everything else describes what you intended; transcripts show what customers got.
Reading ten of them teaches more about your AI agent than any dashboard, and it is the habit that separates a working deployment from one that quietly disappoints.
Testing sits next to building
You can try the agent as you configure it, without touching what customers see. Use it constantly: a change that reads sensibly often behaves differently in an actual exchange.
Changes are live once published
Edit a reply and publish, and the next customer gets it. There is no staging environment here, which is another reason to test in the workspace before publishing.
Knowledge is a scope, not a copy
Pointing an agent at your help centre does not duplicate the articles. It reads the live ones, so publishing an article makes it available and unpublishing removes it, without anything to sync.
Comments
0 comments
Article is closed for comments.