LIVOI processes messages, documents, and other content to provide knowledge, answer requests, and run connected functions. The application, its storage systems, and the services configured for each purpose work together.
Storage and processing follow different data paths. A file may be stored in the LIVOI environment and also sent to a connected service for an AI function. Which content follows that path depends on the function, file format, and configuration.
LIVOI connects your data and applications to configured AI services. This simplified diagram shows the main data paths with example providers and channels.
Prepare content, search knowledge and execute tools.
Storage
Files, chats, text sections and vectors (embeddings).
Self-hosted option
LIVOI in your infrastructure. You choose the location.
Models & services
Model-agnostic
For example OpenAI, Azure or Anthropic. Models and providers depend on configuration.
Embedding model Content → vectors returned to LIVOI
Response model Request & context → answer
Integrations & MCP
Connected systems, MCP servers and custom tools for your APIs.
GDPRcompliant
EU AI ActAI governance
AES-256Encryption
GermanyDevelopment & hosting
Arrows show requests and responses. Logos represent examples. AI service and integration locations depend on the chosen connection, including in self-hosted deployments.
Model-agnostic: LIVOI is not tied to a single AI provider. Response and embedding models can be configured separately. Supported models, the chosen endpoint and its processing location determine the available setup. LIVOI’s deployment model and the choice of AI service are independent.
Public API: Your applications can access LIVOI through the LIVOI API. Authentication and permissions determine which data and functions are available. The public API provides access to LIVOI; custom tools and MCP connect LIVOI to other systems.
Choose a flow and deployment model. Select a component to see its inputs, outputs, storage and processing location. For managed hosting, the green LIVOI area indicates the server location in Germany; for self-hosting, it represents your own infrastructure. Connected services have locations determined by their configuration.
Application and storage: German data center. Connected services have their own processing locations.
Application and storage: German data center. Connected services have their own processing locations.
Application and storage: German data center. Connected services have their own processing locations.
The LIVOI environment includes the application, background processing, file storage, database, and technical caches. AI services and integrations are accessed through configured interfaces. A service may run outside the LIVOI environment, so its processing location must be considered separately.
The location details below describe our environment operated in Germany. For self-hosting, your chosen locations and operating settings apply instead.
The following LIVOI data is stored in our environment in the German data center.
Data type
Use and storage in LIVOI
Original files and attachments
Stored in the configured file storage. Associated records include the filename, type, and resource association.
Messages and conversation histories
Stored with their text, attachments, and other conversation elements. Parts made available to the model may be used as context.
Processed knowledge
Text sections, source references, and metadata are stored in the database for later searches.
Embeddings
Numerical vectors are stored in the search index with their content associations and embedding profile.
Agent and access configuration
Defines tasks, models, available functions, and access rights, among other things.
Technical processing data
Job statuses, events, and caches support background tasks and interface updates. Their lifetimes depend on their purpose and configuration.
A chunk is a section of content, such as a text excerpt. An embedding is a numerical representation used to find similar content. Text sections and embeddings are separate parts of the search index: vectors do not replace stored text or source files.
When a file is added as a knowledge source, LIVOI processes it in the background. The process depends on the file format and configured embedding model.
Ingest the file: store it in file storage and associate it with a knowledge source.
Prepare content: for text-based processing, extract content and split it into sections. Supported multimodal processing may instead use PDF pages or the file itself as input.
Create embeddings: send the prepared inputs to the configured embedding service, which returns the corresponding numerical vectors.
Store the search data: LIVOI stores the embeddings, associated text or content descriptions, and source references, including page references where applicable.
Splitting content into sections does not automatically anonymize it. A section may still contain names, business information, or other confidential details.
For each request, LIVOI assembles the context intended for the agent. This may include the current message, agent instructions, permitted conversation content, attachments, and results from called functions.
If the agent uses knowledge search, additional steps follow:
Prepare the search query: send it to the configured embedding service to convert it into a vector for semantic search.
Find knowledge: LIVOI searches the knowledge available in the current access context. Vector search and text search may work together.
Provide results: return matching text sections and source information. Depending on processing, document access or selected PDF pages may also be provided. An additional configured AI evaluation may rerank the results first.
Generate the answer: the response model processes the request and supplied context. LIVOI returns the result through the channel in use and stores the associated conversation entries.
This combination of retrieval and answer generation is called retrieval-augmented generation (RAG). The embedding model and response model perform different tasks. Their data paths and processing locations must be considered independently.
Depending on the intended processing, chat attachments may be made directly accessible to the model, for example through temporary file links. Document search may pass selected PDF pages as file content. For supported audio input, a transcription service may convert the recording to text before the agent processes it.
An original document or media file does not necessarily remain within the LIVOI environment just because it is stored there.
A tool is a function an agent can call while processing a request. The model receives the available tool descriptions and input schemas. It can generate a call with specific arguments; the execution path depends on the tool type.
Tool type
Where does it run?
What data is exchanged?
LIVOI tools
In the LIVOI application, potentially with further service calls. Examples include knowledge search, calendar functions, and internal agent functions.
Call arguments are processed; internal data or results from connected services may be returned to the model.
Custom tools
LIVOI makes an HTTP request to the configured API.
Arguments validated against the input schema are sent as path parameters, query parameters, or request content. The API response returns as a tool result.
MCP clients
The client runs in LIVOI and connects the agent to a configured MCP server, which executes the tools it provides.
Tool definitions flow from the server to LIVOI and the model. Calls send the tool name and arguments to the server, which returns results.
Model-side tools
At the AI service, for example a web search provided by that service.
Inputs and results are processed within that service and, where applicable, its connected sources.
A custom tool’s configuration specifies the API, HTTP method, and expected inputs. LIVOI validates the model’s arguments against this schema and constructs the request. Stored credentials and additional headers are used to connect to the target system.
The parameters and content assembled for the call are transmitted. This is not automatically the entire chat history, but individual arguments may contain information from the message or previous context. The API response may also contain business or personal data and is provided as a tool result for further processing.
MCP (Model Context Protocol) connects the agent to tools provided by a server. The MCP client in LIVOI and the MCP server are separate components. The server may itself access other systems, such as a knowledge source or a business application.
The data path is: model call → LIVOI → MCP client → MCP server → target system, if applicable. Results travel back and may inform the model’s answer. The MCP client runs within the LIVOI environment in the German data center. The MCP server and its target systems use their configured locations, which may be outside Germany.
LIVOI attaches enabled MCP clients to the relevant agent. The connection may use configured headers or linked personal authorization. Available actions also depend on permissions at the server and target system. Depending on configuration, instructions supplied by the MCP server may be included in the agent context alongside tool descriptions and schemas.
A tool result may form the basis of the final answer or another tool call. A single request can therefore trigger several rounds between the model, LIVOI, and connected systems.
Calls and results may also be stored in conversation history. Which parts are later shown to the model or in the interface is separate from what was transmitted during the original call. Hiding something in the interface does not mean no data was processed.
A connected communication channel carries messages and, where applicable, attachments between LIVOI and that channel. An integration may also retrieve information and perform actions through tools or independent workflows. The scope and destination of transmission depend on the enabled function, its configuration, and the specific call.
With our managed hosting, LIVOI’s central storage and operation are in a German data center. For self-hosting, you choose these locations. Running a function may additionally send content to a configured service. This overview identifies the recipients:
Destination
What data is sent?
Location
LIVOI file storage
Original files and attachments.
German data center.
LIVOI database and search index
Conversation histories, processed text, metadata, embeddings, and agent and access configuration.
German data center.
Embedding service
Search text, text sections, or, depending on the model, PDF pages and supported media. Generated vectors return to LIVOI.
Processing region of the configured service.
Response model and other AI services
Messages, agent instructions, permitted conversation content, tool definitions and results, search results, and, where applicable, attachments or audio for transcription.
Processing region of the relevant AI service.
Custom tool API
Parameters and content assembled for the specific call, plus the authentication configured for the connection.
Location of the connected API or target system.
MCP server and its target systems
Tool name, call arguments, and connection authentication data. The server returns tool definitions and results and may access further systems.
Location of the configured MCP server and any downstream systems. The client itself runs in LIVOI in Germany.
Communication channel
Messages, responses, and attachments exchanged through that channel.
Processing locations of the channel provider.
Processing by connected services is not automatically limited to Germany. The configured service endpoints, processing regions, and agreed operating terms determine this. This also applies to model-side tools and their data sources.
Generated answers, search vectors, and tool results return to LIVOI for further processing. A result returning to LIVOI does not mean that the receiving service no longer holds any data; its storage and retention follow that service’s terms. Separate operating and retention rules apply to backups and operational logs.
Choosing a different embedding service changes only that processing step. Response models, media processing, custom tools, and MCP integrations may still have their own data paths.
LIVOI associates data with a tenant and its resources. User context, roles, permissions, and sharing rules determine access to those resources. Access control is separate from where data is stored or processed.
Files and their derived search content are linked. Removing a knowledge source removes its associated search sections; a shared storage object may remain as long as it is referenced elsewhere. Conversation histories, backups, and content already sent to other services each have their own lifecycle.
Four details are therefore essential when evaluating a specific environment: the storage systems in use, the configured AI services, the enabled integrations, and the applicable retention rules.
