Countly is a privacy-first analytics platform, and Cee was designed with careful consideration for data security. Cee runs inside your Countly instance as the AI Assistants plugin and uses the Mastra SDK for agent orchestration. It is a multi-agent assistant: there is a docs / general-knowledge agent, plus optional product agents such as Drill, Cohorts, Funnels, Journeys, and Drill Insights. Because the deployment can be configured in several ways, the exact data-sharing behavior depends on which agents you enable and whether you route model calls through the Countly Gateway or your own provider.
How Cee Processes Data
Cee interacts with Countly through Countly backend APIs and plugin state. When you type a request in the dashboard, the prompt is sent to the AI Assistants backend, where Countly validates the user, determines the active app/page context, routes the request to the relevant agent, and streams the answer back to the UI.
- Limited Data Access: Cee and its sub-agents do not have access to your raw user data or individual event records. The builder agents operate only with metadata and current form state – event names, property names, segmentation fields, available user properties, and allowed values needed to construct a valid query. For instance, the Drill Agent might know that an event “Purchase” exists and has a property “Price”, but it does not fetch actual purchase records or user details. All analysis results still come from Countly servers processing the data – the AI just helps set up the query. The one exception is Drill Insights (drill-analyzer-agent), which receives a processed Drill query result returned by the Drill plugin (an already-produced, aggregated result set, not raw event storage) and summarizes trends, anomalies, and business implications.
- Configurable model provider: The natural-language understanding and generation behind Cee are powered by a configurable large language model. Depending on your setup the model may be served through the Countly Gateway or through your own provider, and may be backed by OpenAI, Google Gemini, or another compatible provider. Mastra provides a general-purpose agent SDK abstraction, so the same Countly agents can be connected to the Countly Gateway, a provider-compatible endpoint, or a self-hosted model inference endpoint.
- The docs-agent is a special case: it depends on the Countly RAG MCP documentation service and therefore always uses the Countly Gateway by default, regardless of how the other product agents are configured. The gateway is activated automatically during license registration/provisioning so documentation search works out of the box. The docs path is served through Countly MCP for docs and uses the Gemini-backed Countly RAG API.
For the non-doc agents, the deployment can be configured in two ways:
- Gateway enabled: all non-doc agent model calls are routed through the Countly Gateway, hosted as a Cloudflare service, and then on to the configured upstream model provider.
- Gateway disabled: you can use your own provider credentials – including a self-hosted inference endpoint – as long as it is compatible with the configured model/provider interface.
Data Transfer and Subprocessors
External services may be involved, depending on configuration.
- Docs-agent: requests go to the Countly Gateway and the Countly RAG MCP/docs service. This means the user’s documentation question, the conversational context needed to answer it, and retrieved documentation context are processed outside the customer’s Countly instance.
- Non-doc agents with Countly Gateway enabled: prompts and agent context are routed through the Cloudflare-hosted Countly Gateway and then to the configured upstream model provider. Depending on the selected model, subprocessors may include Cloudflare, Countly Gateway services, Google Gemini, OpenAI, or another configured model provider.
- Non-doc agents with Countly Gateway disabled: data is sent to the customer-configured provider instead. If that provider is a self-hosted model running in the customer’s own infrastructure, non-doc agent inference can remain within the customer-controlled environment.
All communications with external model services are encrypted in transit. Countly does not include personal data such as usernames, emails, or user IDs in the prompts – only the high-level metadata and form context needed for the AI to understand the request.
What data is shared, by agent
The type of data shared depends mainly on which agents are enabled:
- Docs-agent: documentation questions and docs / RAG context.
- Cohort, Funnel, Drill, and Journey builder agents: primarily metadata and configuration context – event names, property names, segmentation fields, current form state, and allowed values needed to build valid parameters.
- Drill Insights (drill-analyzer-agent): a processed Drill query result returned by the Drill plugin, not raw event storage. It analyzes the already-produced result set and summarizes trends, anomalies, and business implications.
Regions and data residency
Regions depend on the selected path. The Countly Gateway is hosted as a Cloudflare service, so gateway processing follows Countly’s Cloudflare/gateway deployment. Upstream model processing depends on the selected provider. For self-hosted inference, region and residency are controlled by the customer’s own deployment.
Deployment Model and Self-Hosting
Cee is not fully self-hosted in its complete form if the docs-agent is included, because the docs-agent depends on Countly’s RAG MCP/docs service. For the other agents, a self-hosted model can be used by turning off the Countly Gateway for those agents and configuring the customer’s own provider credentials or self-hosted inference endpoint. In that setup, non-doc agent inference can be kept within the customer’s infrastructure.
- Full Cee including the docs-agent: requires the external Countly RAG MCP / gateway dependency.
- Product agents excluding docs: can be configured to use either the Countly Gateway or customer-controlled / self-hosted inference.
Data Protection and Compliance
Cee does not train models itself. Whether data is used for model training depends on the configured processing path and the applicable provider/subprocessor commitments:
- With the Countly Gateway enabled, data is routed through the gateway and onward to the configured model provider under Countly’s gateway/provider setup.
- With the Gateway disabled for non-doc agents, the customer is responsible for the selected provider’s privacy, retention, and training configuration. (For OpenAI specifically, refer to OpenAI’s Privacy Policy.)
- With a self-hosted model, those controls can remain entirely within the customer’s environment.
Protection from unintended access or reuse is handled mainly through:
- Countly user authentication and thread ownership checks.
- Server-side gateway / API key configuration.
- Agent-level scoping – agents only receive the context needed for their function.
- Settings-level agent enablement.
- Builder agents operating on metadata / form context rather than raw event rows.
- Drill Insights using processed Drill output rather than directly reading raw event data.
There is no single “zero data sharing” switch that keeps every Cee capability active. Strict zero external sharing requires disabling the external agent paths or using a self-hosted inference setup for the non-doc agents. The docs-agent remains externally dependent on the Countly RAG MCP service.
You Remain in Control (No Autonomous Actions)
Cee cannot perform any action in your Countly instance without your involvement. It cannot press buttons, delete data, send messages to your users, or change settings on its own. Its role is strictly assistive – it helps you navigate and configure features through conversation. Any final actions (saving a cohort, creating a funnel, running a query) either happen through you clicking the normal UI buttons or as a direct result of you approving the AI’s suggestion. You remain in full control of your Countly workspace.
Activation and Control
Cee provides operational controls through the AI Assistants settings page. Go to Management > Settings > AI Assistants, where administrators can:
- Enable or disable Countly Gateway usage for the non-doc agents.
- Configure the gateway URL and gateway API key.
- Select the model.
- Enable or disable individual product agents, including the Cohorts Agent, Drill Agent, Funnels Agent, and Journeys Agent.
The data-sharing model is therefore controlled by configuration choices rather than by explicit “no data / metadata only / aggregated only” access levels. In practice:
- If an agent is disabled, Cee will not route user requests to that capability. (Being privacy-first, you can switch off any data-related agent if you prefer not to send its event metadata to the AI service.)
- If the Gateway is enabled, enabled non-doc agents route model calls through the Countly Gateway.
- If the Gateway is disabled, enabled non-doc agents can use customer-provided credentials or self-hosted inference.
- Most product agents use metadata and current form state; Drill Insights is the agent with access to processed Drill result data returned by the Drill plugin.
- The main documentation agent depends on the Countly RAG MCP service and the Countly Gateway, so it operates externally even when other agents are configured for self-hosting.
Frequently Asked Questions
Where is data processed when Cee communicates with AI providers? (region)
When using the Countly AI Gateway, AI requests are currently processed within the European Union (EU). If you choose to use your own AI provider or a self-hosted inference endpoint, data processing follows the region and configuration of that provider or your own infrastructure. The documentation agent always uses the Countly AI Gateway together with Countly’s RAG MCP service.
Is customer data used to train AI models?
No, when using the Countly AI Gateway.
Data processed through the Countly AI Gateway is not used to train AI models. If you use your own AI provider instead of the Countly AI Gateway, model training and data retention depend on that provider’s policies and configuration. We recommend reviewing your provider’s documentation and configuring it according to your organization’s requirements.
Can I use my own OpenAI API key instead of Countly’s AI Gateway?
Yes. You can disable the Countly AI Gateway for the product agents under Management > Settings > AI Assistants and configure your own OpenAI API key, another supported AI provider, or a self-hosted inference endpoint.
The documentation agent is the exception. It relies on Countly’s RAG MCP service and always uses the Countly AI Gateway.
What data is sent when using Countly AI Gateway versus a customer-managed OpenAI key?
The same types of metadata are sent in both cases. What changes is where the requests are sent.
Depending on which agents are enabled, Cee may send metadata such as event names, property names, current form state, processed Drill Insights results, or documentation questions and related context.
When using the Countly AI Gateway, requests are routed through the Countly Gateway before reaching the configured AI provider. When using your own API key, the same metadata is sent directly to your configured provider.
Is Cee fully functional in self-hosted deployments?
Partially. The product agents (such as Cohorts, Funnels, Journeys, Drill, and Drill Insights) can run with self-hosted inference by disabling the Countly AI Gateway and configuring your own AI provider or self-hosted inference endpoint.
The documentation agent requires Countly’s hosted RAG MCP service and therefore cannot currently operate as a fully self-hosted component.