KyroChat Platform Logic
Understand how KyroChat keeps one shared bot core while letting each tenant define its own business knowledge, actions, and integrations.
Core principle
KyroChat is best understood as `shared bot core + tenant configuration + tenant integrations + channel/client adapters`. That separation keeps the reasoning engine reusable while letting every business define what its bot is allowed to know and do.
Server-Side Core
The shared bot core owns orchestration, retrieval, guardrails, memory, escalation, and server-side action execution.
Tenant Configuration
Each business defines its own instructions, knowledge, allowed actions, escalation rules, and business constraints.
Integrations
Integrations connect the bot to real systems like billing, ecommerce, CRM, support, and other tenant backends.
Channel Adapters
Website widget, WhatsApp, Slack, API, and future surfaces normalize transport and render output without becoming separate bot brains.
Client Surfaces
Rich client surfaces such as the website widget can add browser context, tools, and forms while still relying on the shared core.
Rules We Follow
These principles keep KyroChat consistent as channels, integrations, and tenant actions grow.
- Cross-channel business capabilities should be implemented as server-side actions.
- The widget and other channels should contribute context and UX, not business intelligence.
- Tenant behavior must come from explicit configuration instead of inference.
- The customer-facing playground should stay simple and test the bot, not expose transport internals.
Use this guide with the rest of the docs
Start here when you want the product model first, then go deeper into AI agents, API behavior, or specific integrations.
Users create, manage, and deploy bots
Sign up, upload documents, customize widgets, monitor analytics, and handle escalations.
Have questions? Our community is here to help. Learn more about our community
Active tenants
