Architecture overview

How a conversation moves through NeevAI: a control plane that holds configuration, a data plane that runs the chat, and MCP for every tool the agent can call.

This is the high-level shape of the platform, written for a technical reviewer doing due diligence. It describes what runs, not how to operate it.

Three parts

| Part | Role | |---|---| | Control plane | Tenants, agents, language model settings, connector and tool records, appearance, audit. The admin portal edits this. | | Data plane | Sessions, conversation history, streaming answers, and the tool-call loop. The chat talks to this. | | Tools over MCP | Every connector, featured or built for a client, is exposed to the agent as tools through the Model Context Protocol or an HTTP API. |

The data plane does not duplicate configuration. It loads the effective configuration for an agent from the control plane at the start of each session.

A conversation, step by step

1. The visitor's session is resolved: which agent, and any metadata the host page attached (page, campaign, variant).
2. The agent's configuration is loaded: model parameters, knowledge sources, and the connectors it may use.
3. A connection to the agent's tools is obtained. Tool definitions are cached per connection.
4. The conversation history is loaded and the new message is stored.
5. The model streams an answer. If it decides a tool is needed, the tool is called, the result is fed back, and the model continues until it has a final answer or hits a safety limit.
6. The answer streams to the visitor with a status line while tools run, and a sources footer when the answer came from knowledge.

Tool use is reactive: the model decides when a tool is needed during the conversation. There is no separate planner running ahead of it. Multi-tool calls can run in parallel, and the loop enforces a maximum depth and detects repeated calls.

Approvals

Any tool can be marked as requiring approval. When the model proposes such a tool, the chat shows an approval card instead of running it. The action executes only after the card is confirmed, and the confirmation is recorded with the conversation. Tools that need the visitor to be signed in show a login gate first.

Knowledge

Knowledge bases are built from crawled websites and uploaded documents. At answer time the agent retrieves relevant passages and cites them. Knowledge is read at retrieval time; tools are called live. The difference matters for anything that changes often, such as availability or order status, which should be a tool rather than a document.

Connectors and credentials

Featured connectors are maintained by NeevAI and connected with the provider's own sign-in, owned by NeevAI with no third-party broker. Client-added connectors accept any MCP server or HTTP API. Credentials are encrypted at rest, each tool can be switched on or off per client, and a connection test confirms a connector works before an agent uses it.

What is recorded

Every message, tool call, approval and action is stored with the conversation and shown in the admin portal. After a conversation ends, the platform extracts labels, intent, sentiment, a quality score, the questions asked and the questions left unanswered. Assistant output is capped in size to protect clients and storage.

What is not here yet

Voice, scheduled or unattended runs, self-serve onboarding, per-visitor sign-in to a client's identity provider, and enterprise single sign-on are on the roadmap. Security and compliance specifics are answered by the team on request rather than claimed here.