📘 Teemant User Guide – Introduction


Welcome to the Teemant User Guide.

This guide is designed to help you understand how to configure and operate a Teemant workspace, from high-level setup to day-to-day usage. It provides a structured overview of each section of the platform and explains what each feature is for, without going into low-level implementation details.


🎯 Purpose of this guide


The goal of this documentation is to:


  • give you a clear mental model of how Teemant works,
  • explain the role of each workspace component,
  • help administrators, managers, and builders navigate the platform confidently.


This is not a step-by-step tutorial. Instead, it focuses on concepts, responsibilities, and best practices, so the documentation remains easy to maintain and evolves smoothly with the product.

👥 Who this guide is for


This guide is intended for:


  • Workspace administrators managing configuration and access,
  • Managers supervising users, channels, and operations,
  • Bot builders designing agents, flows, and automations.


Depending on your role, some sections may be more relevant than others.


🧭 How to read this guide


The guide follows the structure of the Teemant workspace:


  • Each section corresponds to a menu entry in the platform.
  • You can read it linearly or jump directly to a specific topic using the table of contents below.
  • Screenshots and icons are used to help you quickly recognize features in the interface.



For advanced use cases (custom integrations, APIs, or complex workflows), additional documentation or support may be required.

🏠 Home (Dashboard)

The Home tab is the dashboard of the workspace.


It provides a high-level view of activity and usage, such as:


  • number of users,
  • number of active bots or agents,
  • conversion or completion indicators,
  • activity trends over time.


The Home dashboard is used for:


  • monitoring platform usage,
  • understanding adoption and activity levels,
  • getting a quick status overview without entering configuration screens.

It does not contain configuration or data management features.

🗃️ Entities

Entities represent the actual databases of external synchronized data inside Teemant.


They are typically used for:


  • reference data (e.g. stores, locations, organizational units),
  • business objects coming from external systems,
  • datasets shared between agents and processes.

Key characteristics:


  • Entities are structured datasets, not conversational elements.
  • They are often synced from or to external systems via imports or tasks.
  • Agents and guides can read from Entities to validate or enrich user inputs.


In short:


👉 Entities are where structured business data lives inside Teemant.

🛠️ Builder

The Builder is where process intelligence is designed.


It is used to:


  • build Guides (logic, questions, validations, flows),
  • assemble Agents based on those guides,
  • define how different elements work together.


Within the Builder, you define:


  • how an agent behaves,
  • what data it expects,
  • what documents it can handle (emails, files, JSON payloads, attachments),
  • how information is collected, validated, and prepared.


The Builder is the core design area of Teemant:


  • Guides define what to collect and how,
  • Agents combine guides with data, documents, and logic to execute real processes.

⚙️ Workspace

The Workspace section contains global and administrative settings.


It is used to manage:


  • general workspace configuration,
  • administrators and registered agent users,
  • communication channels (e.g. WhatsApp, email, other channels),
  • environment-level settings (development, test, production).

Workspace settings control who can access the platform, through which channels, and under which permissions.


No business logic is defined here — it is purely operational and administrative.

🔗 Transports

Transports define the technical means of data transfer between Teemant and external systems.


Examples include:


  • SFTP push or pull,
  • file-based exchanges,
  • email-based transfers.

A transport answers the question:


👉 “How does data physically move between systems?”


It does not define:


  • what data is exchanged,
  • when it is exchanged,
  • or how it is interpreted.


🔄 Tasks

Tasks are used to scan, import, or synchronize external data sources.


They typically:


  • monitor external databases or file locations,
  • trigger imports,
  • update Entities with new or changed data.


Tasks focus on data ingestion and synchronization, not user interaction.

🧠 AI Contexts

AI Contexts define the behavioral and semantic environment in which the AI operates.


They provide the AI with background information, intent, and communication rules, ensuring that interactions remain consistent, relevant, and aligned with business expectations.


AI Contexts are used by both:


  • conversational agents (chatbots),
  • and email automation processes.

🌐 Global Contexts

Global Contexts describe general, cross-cutting information that applies to the entire organization or workspace.


They typically include:


  • company or organization description,
  • general business rules or terminology,
  • overall tone and communication style,
  • common constraints or assumptions.


Global contexts act as a shared foundation that can be reused across multiple agents and processes, ensuring coherence at platform level.

🤖 Agent Contexts

Agent Contexts are specific to a given agent or use case.


They define:


  • what the agent is expected to do
    (e.g. collect incident declaration data),
  • who the users are
    (employees, customers, partners, internal teams),
  • how the agent should communicate
    (tone, level of formality, clarity requirements),
  • any role-specific or process-specific constraints.


Agent contexts allow the AI to adapt its behavior depending on the business process it supports.

🧩 Role of AI Contexts in Guides

When building AI Guides, the builder must select the appropriate Agent Context.


This selected context is then:


  • applied during each conversation, or
  • used during email processing workflows.


The context ensures that

:

  • the AI understands its role,
  • interactions remain aligned with the intended process,
  • responses are consistent across channels.


In short:


👉 AI Contexts define how the AI thinks and communicates, while Guides define what the AI does.

🧩 AI Guides

AI Guides define the instructions used by the AI during:


  • live conversations (chatbots),
  • and email processing (Email Automation).


A guide describes what information must be collected or processed, how the AI should behave, and how data is structured, but it does not define the transport or the integration logic.


  • AI Guides are executed by Agents and always operate within a defined AI Context.

Guide types


Teemant provides several types of AI Guides, each serving a specific purpose within a process.

📥 Data Collection Guides

Data Collection Guides are used to collect structured information based on a predefined data model.


Once a data model is defined (fields, formats, constraints), a guide can be built with AI assistance.


Each step of a Data Collection Guide typically defines:


  • a display name (human-readable),
  • a technical field name,
  • a field type (string, number, address, date, etc.),
  • bot instructions explaining how the AI should collect or validate the information,
  • optional user instructions when a specific action is required.


Bot instructions may include:



  • validations,
  • dependencies on previously collected values,
  • conditional behavior.
  • Data Collection Guides are used in both conversational flows and email automation.

✅ Checklist Guides

Checklist Guides are similar to Data Collection Guides but are designed for closed questions.


They typically define:


  • the displayed question,
  • available choices (Yes / No, or similar),
  • bot instructions,
  • optional user instructions,
  • whether a comment is required (true / false).


Checklist Guides are commonly used for:


  • compliance checks,
  • validation steps,
  • procedural confirmations.

🧮 Calculated Fields Guides

Calculated Fields Guides define fields that are computed automatically based on previously collected values.


They:


  • rely only on bot instructions,
  • never require user input,
  • are not displayed to users.


Calculated fields can be used at different stages of a process to:



  • aggregate values,
  • compute totals,
  • derive intermediate results.
  • These fields are internal to the process but can later be used for outputs or integrations.

Guide interface structure


Each AI Guide is organized into three main tabs:

📄 Details

The Details tab contains the general settings of the guide, such as:


  • display name,
  • guide type,
  • associated AI context,
  • linked agent,
  • description.


This tab defines what the guide is.

🛠️ Build

The Build tab is where the guide logic is defined.


It displays:



  • the list of fields or questions on the left,
  • the AI-assisted prompt and generated instructions on the right.
  • This tab defines how the guide behaves.

✉️ Response (Email Automation only)

The Response tab is used only for Email Automation.


It allows configuration of:



  • an email response template,
  • attached template files,
  • email signature.
  • This tab defines how the AI responds by email once processing is complete or additional information is required.

Summary

In short:


  • AI Contexts define how the AI thinks and communicates,
  • AI Guides define what the AI must collect, calculate, or validate,
  • Agents execute guides within a process,
  • Response templates apply only to email-based interactions.



If you want, next we can:


  • shorten this for a “quick overview” version,
  • or align wording exactly with menu labels for consistency across Help pages.

💬 Messages

Messages are predefined, non-AI messages that can be sent during a conversation.


They are hard-coded messages, meaning:


  • they are not generated by the AI,
  • they do not use AI reasoning or context,
  • they are not automatically translated.


Messages are typically used for fixed communication points in a process.


Purpose of Messages


Messages are designed to:


  • send confirmations (e.g. end-of-conversation confirmation),
  • display standardized information,
  • ensure exact wording where variability is not desired.


They provide a way to deliver controlled, deterministic messages alongside AI-driven interactions.


How Messages are used


Messages can be triggered:


  • at specific steps in a conversation,
  • at the end of a process,
  • as system notifications during an interaction.

They are commonly used together with:


  • AI Guides (which handle dynamic logic),
  • Agents (which orchestrate the flow).



Key characteristics


  • Messages are static.
  • They are language-specific and must be created separately per language if needed.
  • They ensure full control over wording, tone, and legal or compliance-sensitive text.


In short:


👉 Messages complement AI interactions by providing fixed, reliable communication blocks where variability is not acceptable.

⚡ Events

Events represent internal system occurrences generated during the execution of processes.


They are intended to capture significant moments in the lifecycle of a conversation, an agent execution, or a data processing flow. Events may be triggered automatically by the platform based on predefined conditions or system activity.


This section will later be used to describe how events are defined, recorded, and leveraged within Teemant to support monitoring, automation, or integration scenarios.



At this stage, Events should be considered as technical markers that reflect what happens inside the platform during process execution.

🔑 Identifiers

Identifiers are unique chronological reference numbers generated by Teemant to identify each processed interaction.


They are used to track:


  • conversations,
  • email processing flows,
  • and the resulting business records exchanged with external systems.

An identifier acts as the technical reference of a process instance from start to end.


Purpose of Identifiers


Identifiers are used to:


  • uniquely identify a conversation or email processing instance,
  • ensure traceability across the entire process lifecycle,
  • reference the same case in external information systems,
  • facilitate audits, monitoring, and troubleshooting.


They provide a stable reference key shared between Teemant, users, and external systems.


Identifier structure


An identifier is defined using a mask, which may include:


  • an incremental counter,
  • date or timestamp elements,
  • a fixed prefix identifying the process or environment.

Example structure:


  • prefix (e.g. DEMO),
  • incremental number,
  • year or timestamp.


This allows identifiers to be:


  • readable,
  • sortable,
  • and unique over time.


When Identifiers are generated


Identifiers are generated at the end of a process, just before:


  • email notifications are sent,
  • data is exported to external information systems,
  • final confirmation messages are delivered.


This ensures that:


  • all collected or computed data is finalized,
  • the identifier reflects a completed process,
  • the same identifier can be reused consistently across outputs, notifications, and integrations.


Role in process tracking


Once generated, the identifier can be:


  • included in emails or notifications,
  • embedded in exported files or payloads,
  • stored in external systems as a reference key.


In short:


👉 Identifiers make each interaction traceable, auditable, and linkable across systems.

🧰 Tools

Tools are external applications that can be triggered from within Teemant during a process.


They allow Teemant to extend its capabilities by delegating specific actions to specialized third-party applications, while keeping the overall process orchestrated by Teemant.


Purpose of Tools


Tools are used when a process requires an action that:


  • cannot be performed directly by the AI,
  • must be handled by a certified or specialized external system,
  • requires user interaction outside the conversational interface.


Typical use cases include:


  • capturing certified and encrypted photos,
  • collecting a digital signature on a smartphone,
  • executing regulated or compliance-sensitive actions.


How Tools are used in processes


A Tool can be:


  • triggered at a specific step during a conversation,
  • invoked as part of an email-driven process,
  • embedded into an agent workflow.


When triggered, the user is redirected or guided to the external application, and the result is then returned to Teemant to continue the process.


Integration and partners


All Tools require:


  • a technical integration with Teemant,
  • and are provided by Teemant-certified partners.


This ensures:


  • security and data integrity,
  • compliance with regulatory requirements,
  • reliable exchange of information between systems.


Multiple external applications can be integrated over time, depending on business needs and available partner solutions.


Summary


In short:



 👉 Tools allow Teemant to interact with external applications to perform specialized actions that go beyond conversational AI, while remaining fully integrated into the overall process flow.

👁️ Vision

Vision – Document & Image Intelligence


The Vision module manages document and image information extraction within Teemant.


A Vision is an independent AI agent, specialized in reading, analyzing, and interpreting documents or images in order to produce structured, usable data.

Vision goes beyond basic OCR: it combines visual extraction with AI-driven understanding and validation.


Vision as a Specialized AI Agent


Each Vision is configured as a dedicated AI agent with its own:


  • Purpose,
  • Document context,
  • Extraction model,
  • AI processing logic.


The Vision agent is responsible for:


  • Reading documents or images (PDFs, scans, photos),
  • Extracting raw information using OCR or image analysis,
  • Applying Teemant AI logic on top of the extracted data to interpret, normalize, and structure it.


This additional AI processing layer allows Vision to handle complex layouts, handwritten content, and ambiguous information.


Document Context


Every Vision is associated with a Document Context.


The Document Context defines:


  • The type of document being processed (e.g. accident report, certificate, invoice, handwritten form),
  • The semantic meaning of the document,
  • The expected structure and business logic.


This context guides the Vision agent so it knows:


  • What information to look for,
  • How to interpret extracted values,
  • How to apply domain-specific rules during processing.


Extraction, Processing, and Validation Flow


The Vision workflow always follows the same principle:


  1. Extract
    Raw text and visual information are extracted from the document or image using an OCR or vision engine.
  2. Process
    Teemant AI processes the extracted content field by field:
  • Maps data to structured fields,
  • Applies formatting and normalization,
  • Interprets ambiguous or partial values.
  1. Validate (optional)
    During a conversation, the Vision agent can interact with the user to:
  • Confirm extracted values,
  • Request missing information,
  • Correct or refine data.


This validation step is particularly useful for handwritten documents or low-quality scans.


Vision Providers


Teemant supports multiple Vision backends depending on the use case:


  • Microsoft Document Intelligence
    Typically used for complex, structured, or handwritten documents, with custom-trained models.


  • Mistral OCR
    Direct OCR via API, easier to integrate but generally less reliable for complex documents.


Additional Vision platforms can be integrated in the future.


Regardless of the provider, the Vision logic remains the same: extract → process with AI → optionally validate with the user.


Vision in End-to-End Processes


Vision agents are designed to be integrated into broader Teemant workflows, including:


  • Data collection guides,
  • Incident or claim declarations,
  • Email automation,
  • Structured exports to information systems.


By transforming unstructured documents into validated, structured data, Vision plays a key role in automating document-heavy processes within Teemant.

📤 Outputs

The Outputs module manages all outbound flows from Teemant. It defines how data, documents, and notifications produced by AI agents are delivered to external systems, applications, and users.


Outputs can include:


  • Email notifications with structured or unstructured content
  • File exports (JSON, media files, ZIP archives, generated documents)
  • SFTP transfers
  • APIs, webhooks, and other outbound connectors used to integrate Teemant with enterprise information systems


Each Output configuration allows you to define:


  • The transport mechanism (email server, SFTP, API endpoint, webhook, etc.)
  • The documents and data formats to be sent
  • The content and structure of notifications or exported payloads
  • Whether the default Teemant mail server or a dedicated transport is used


Outputs are typically triggered at the end of a process, once data collection, AI processing, validations, and identifier generation have been completed. They ensure that results are delivered in a reliable, traceable, and integration-ready manner.



This module represents the final delivery layer of Teemant, enabling seamless communication between AI-driven workflows and external systems.

📄 Documents

The Documents section centralizes all the content produced, sent, or handled by Teemant throughout a process. It covers emails, technical documents (such as JSON), and media files (photos, attachments, generated documents).


Documents are typically used by Outputs (email notifications, SFTP exports, APIs, webhooks, outbound connectors) and can include dynamic variables coming from conversations, AI processing, and business logic.


✉️ Emails


Emails are the most common type of document in Teemant.


They are used to:


  • notify end users,
  • confirm a declaration or action,
  • communicate with internal teams,
  • or transmit information to partners.


Each email document defines:


  • recipients (To / Cc / Bcc),
  • a dynamic subject (e.g. using {app.identifier} ),
  • a customizable content body,
  • and a templating engine.


Available templating engines


  • Freemarker
    A standard and powerful templating engine, well suited for complex emails with conditions, loops, and advanced HTML formatting.
  • Teemant Template Engine
    A simpler, in-house engine designed to quickly create clear and maintainable emails with straightforward variable insertion.


Variables (e.g. {app.accidentDate} , {user.email} …) are automatically resolved at send time, based on data collected and processed by Teemant.


🧾 JSON & technical contents


Documents are not limited to emails.


Teemant also manages JSON documents used for:


  • data injection into information systems,
  • structured exports,
  • integrations via APIs, webhooks, and outbound connectors.


These structured documents ensure reliable, consistent, and standard data exchanges with external systems.


📎 Media & files


The Media category groups all files handled during a process:


  • photos,
  • user-uploaded documents,
  • automatically generated files,
  • outputs from Vision (OCR, image analysis),
  • attachments sent by email or exported.


Media files can be:


  • stored,
  • analyzed,
  • exported through Outputs (email, SFTP, API, webhooks, etc.),
  • or linked to a conversation, an identifier, or a business process.


🎯 Summary


The Documents section is the foundation for all outgoing and technical content in Teemant.


It enables you to:


  • centralize emails and documents,
  • standardize formats,
  • dynamically inject AI-generated and conversational data,
  • and ensure seamless integration with external systems.


🧱 Object Models

Object Models define the structured data layer of Teemant. They are used to model reference data, operational data, and workspace-specific configuration objects that are shared across agents, processes, and integrations.


They serve two main purposes.


1️⃣ Reference & Business Data Models (Data Synchronization)


Object Models are used to build structured databases that represent reference or business data required by Teemant processes, for example:


  • Stores, agencies, subsidiaries
  • Vehicles, products, contracts, policies
  • Any external reference dataset used during conversations, document processing, or routing


These models can then be:


  • Synchronized with external information systems
  • Kept up to date using:
  • Transports → how data is exchanged (SFTP, APIs, connectors, etc.)
  • Tasks → when and how often synchronization runs (on demand, scheduled, incremental, etc.)


This allows Teemant to work with live, trusted enterprise data and ensures AI agents always rely on consistent and up-to-date information.


2️⃣ Workspace Configuration Objects (Dynamic Workspace Properties)


Object Models can also define custom workspace-level properties.


These are not reference datasets but configuration objects attached to a workspace, such as:


  • Special email recipients (e.g. RC email, escalation email, partner email)
  • Identifiers, codes, or business parameters specific to a workspace
  • Any custom property that should appear in Workspace Settings


Once defined:


  • These fields automatically become available in the Workspace configuration
  • They can be reused across:
  • Documents and notifications
  • Outputs
  • AI Guides
  • Automations and routing logic


This makes Object Models a powerful way to extend Teemant without custom code, simply by modeling new structured properties.


Supported Field Types


Object Models support a controlled set of field types to ensure consistency and interoperability, including:


  • string
  • integer
  • number
  • email
  • date
  • location
  • content


These types are designed to be fully compatible with AI processing, document templating, exports, and integrations.


Why Object Models Matter


Object Models are the foundation of Teemant’s data architecture:


  • They structure how data is stored, shared, and synchronized
  • They connect AI agents with enterprise systems
  • They allow workspaces to be customized in a clean, scalable way



In short, Object Models turn Teemant into a data-aware AI platform, not just a conversational one.

🧱 Workspace Settings

A Workspace represents a logical tenant in Teemant. It defines the functional, technical, and organizational boundaries within which agents, data, integrations, and users operate. In practice, a workspace usually maps to an environment (development, test, production) or to a specific business unit or customer.


Environment & Governance (Main)


The Main tab centralizes the core configuration of the workspace:


  • Name, Locale, and Time Zone


These settings define how content is localized (language, date formats) and how time-based logic (events, tasks, notifications) is evaluated.


  • Best Practice: Multiple Workspaces


It is strongly recommended to create separate workspaces for:

  • Development (experimentation and configuration),
  • Testing / UAT (validation and business approval),
  • Production (live operations, end users).
    This ensures isolation, safety, and controlled deployments.


  • Public Workspace


When a workspace is marked as Public, it becomes accessible to end users depending on the channel:

  • WhatsApp: any user with a Meta WhatsApp account,
  • Microsoft Teams / Google Chat: users authorized to install the Teemant app.
    This is especially useful for large-scale or open user scenarios.


  • Default Contact Emails
    Contact email addresses defined here act as global fallback recipients for notifications and outputs (emails, alerts, exports) when no more specific destination is configured.


Providers & AI Services


The Providers tab is where the workspace connects to its technological ecosystem:


  • API keys for LLMs, OCR engines, Vision / Document AI, and other AI services are configured here.
  • Customers can either:
  • bring their own API keys, or
  • rely on Teemant-provided keys, depending on the setup and agreement.
  • This configuration applies workspace-wide and is reused by agents, Vision, document processing, and automation features.


Workspace-Specific Business Settings (Object Models)


The third tab (for example “Auchan Gestionnaires” in the screenshots) illustrates how Object Models are used at the workspace level:


  • These objects define custom properties of the workspace itself, such as:
  • special recipient email addresses (e.g. RC Email, DAB Email),
  • business-specific configuration fields,
  • any domain-specific metadata required by workflows or outputs.


  • Once defined, these fields appear directly in the workspace settings and can be referenced by:
  • agents,
  • documents and templates,
  • outputs (emails, APIs, exports),
  • integrations.



In short, the workspace is not just a container: it is the central configuration layer that ties together environments, users, AI providers, business rules, and integrations, ensuring consistency and control across the entire Teemant platform.

👥 Workspace Members

Workspace Members are the administrators of a Workspace (tenant). They are responsible for configuring, managing, and governing how Teemant is used within a given environment.


Members are internal users (your teams, partners, or integrators), not end-users interacting with chatbots or emails.


Roles & Permissions


Each Workspace Member can have one or more of the following roles:


  • Administrator
  • Full access to the workspace configuration
  • Can manage settings, providers, users, channels, outputs, documents, etc.
  • Cannot build AI agents
  • Manager
  • Can manage users, channels, configurations, and operational settings
  • Cannot build AI agents
  • Bot Builder
  • Can only build and configure AI agents (AI Guides, contexts, flows)
  • No access to workspace-level administration


This separation of roles ensures clear governance, security, and controlled deployments.


Best Practices


  • Development Workspace
  • Grant all roles (Administrator, Manager, Bot Builder)
  • This is the only place where AI agents are designed and configured
  • Test & Production Workspaces
  • Grant Administrator and/or Manager roles only
  • No agent building is allowed
  • Agents are deployed here, not created
  • One Workspace per Client Application
  • Strongly recommended to keep configurations isolated
  • Improves security, maintainability, and deployment clarity


Why This Matters


This approach:


  • Prevents accidental changes in production
  • Enforces a clean build → test → deploy lifecycle
  • Makes audits, support, and troubleshooting much easier
  • Aligns with enterprise-grade IT and DevOps practices



Workspace Members define who can do what, while AI Agents define what the system does.

👥 Workspace Agent Users (End Users)

Agent Users are the end users who can access and interact with Teemant agents (chatbots, email automation, etc.) within a workspace.

They are not administrators and do not configure the platform. Their role is purely to use the agents through the enabled interaction channels.


🔐 Access Rules


Access to agents depends on the workspace visibility:


  • Private workspace (default)
    Only users explicitly defined as Agent Users can see and interact with the agents.


  • Public workspace
    All users who can access the channel can interact with the agents:
  • WhatsApp: any user authenticated on Meta WhatsApp
  • Microsoft Teams: users authorized to install/use the Teemant app
  • Google Chat: users authorized within the Google Workspace


Each Agent User can be:


  • Enabled or disabled
  • Associated with one or more channels
  • Configured with locale and contact details


📱 Channel-Specific Best Practices


Access control should follow the logic of each channel:


  • Microsoft Teams / Google Chat / Email
    Access management is usually handled upstream, by the customer’s IT or identity provider (Azure AD, Google Workspace, mail systems, etc.).


  • WhatsApp
    Since WhatsApp is generally open to the public, authentication must be handled inside the process, for example:
  • Employee or agent ID
  • Vehicle plate number
  • Policy or contract number
  • Document-based verification (ID, form, photo, etc.)


This authentication logic is typically implemented within the AI Guide and conversation flow, not at the channel level.


✅ Recommended Practices


  • Keep Agent Users strictly separated from Workspace Members (admins, managers, builders).
  • Use private workspaces for controlled deployments.
  • Delegate identity and access control to the customer systems whenever possible.
  • Design explicit authentication steps in conversational flows, especially for public channels like WhatsApp.



In short, Agent Users define who can talk to the AI, while Workspace Members define who can configure it.

🔌 Workspace Channels

Channels define how users interact with Teemant agents and where messages, emails, or conversations are received and sent.


Each channel represents a concrete integration with an external communication platform such as WhatsApp, Microsoft Teams, Google Chat, email systems, or live chat tools.


A workspace can have multiple channels enabled at the same time, allowing the same AI agents to operate consistently across different touchpoints.


💬 Chat Channels (Conversational)


📱 WhatsApp


WhatsApp channels connect Teemant to Meta WhatsApp Business accounts using a dedicated phone number.


How it works:


  • Any user authenticated on WhatsApp can contact the bot via the configured number.
  • The workspace visibility ( Public or Private ) determines whether additional access control is required.
  • In most real-life use cases, authentication is handled inside the AI flow, not by WhatsApp itself
    (e.g. employee ID, badge number, license plate, document ID, etc.).
  • WhatsApp is typically used for external users or large-scale audiences.


Best practice:

Use conversational authentication inside the agent logic when sensitive data is involved.


💼 Microsoft Teams


Microsoft Teams channels allow Teemant agents to operate inside a Microsoft tenant.


How it works:


  • Access is restricted to users authenticated in the configured Teams tenant.
  • The Teams Tenant ID defines the scope of authorized users.
  • Ideal for internal use cases (IT support, HR, operations, internal assistants).


Best practice:


Let Teams manage identity and access; avoid duplicating authentication logic inside the bot unless required.


💬 Google Chat


Google Chat channels connect Teemant to a Google Workspace domain.


How it works:


  • Only users authenticated within the configured Google domain can access the bot.
  • Access control is naturally handled by Google Workspace permissions.
  • Well suited for internal corporate assistants.


🧑‍💻 Live Chat (Chatwoot)


LiveChat channels connect Teemant to third-party chat platforms, such as Chatwoot.


How it works:


  • Teemant acts as an AI layer behind the live chat system.
  • The AI can automate first-level responses, data collection, and triage.
  • Human agents can take over conversations when needed.


Best practice:


Use LiveChat integrations for hybrid AI + human support workflows.


📧 Email Channels


📩 Google Mail


Google Mail channels allow Teemant to read, classify, and respond to emails from a target mailbox.


Key concepts:


  • OAuth credentials (Client ID, Secret, Refresh Token) are required.
  • Emails are processed by AI agents for classification, data extraction, and response drafting.
  • Consent management ensures compliance with user authorization.


📬 Microsoft Mail


Microsoft Mail channels integrate with Microsoft 365 mailboxes.


How it works:

  • Emails are ingested, analyzed, and routed to the appropriate AI agent.
  • Agents can extract structured data, update the information system, and generate replies.
  • Explicit user consent is required before activating AI processing.


Typical use cases:

  • Email automation
  • Incident declarations
  • Customer or partner requests
  • Back-office process automation


⚙️ Channel Configuration Principles


  • Each channel has:
  • A status (enabled / disabled)
  • A description for documentation and clarity
  • A draft mode to safely configure before going live


  • Channels can be added independently and activated progressively.
  • The same agent logic can be reused across multiple channels.


✅ Best Practices



  • Separate environments (Dev / Test / Prod) should have their own channels.
  • Prefer native platform authentication (Teams, Google Chat, Mail).
  • For open channels like WhatsApp, implement authentication inside the AI conversation.
  • Keep channel configuration minimal; complexity should live in AI Guides and Agent logic, not in the channel itself.


🔁 Workspace Transports

Transports define how data and documents are exported from Teemant to external systems.


They are the technical bridge between Teemant and your information systems, data lakes, ERPs, CRMs, or operational tools.

A transport is typically used by Tasks to determine when, how, and where data is sent.


📦 What Transports Are Used For


Transports allow you to:


  • Export structured data (JSON, metadata, object models)
  • Export documents (PDFs, images, ZIP archives)
  • Synchronize reference databases with external systems
  • Push data automatically or on a schedule


They are most commonly used for:


  • System integrations
  • Data synchronization
  • Reporting and archival
  • Operational automation


📁 File Transfer (SFTP / FTP) 📤


File Transfer transports are used to send files to external servers, typically enterprise backends.


Key characteristics:


  • Supports SFTP / FTP
  • Data can be exported as:
  • JSON
  • Documents
  • ZIP archives (recommended for batch exports)
  • Secure authentication via account & password
  • Configurable destination path


Typical use cases:

  • Export daily or hourly datasets to an ERP
  • Synchronize reference databases
  • Send structured data to legacy systems
  • Batch processing pipelines


Example:


Export all processed documents and metadata as a ZIP file to an SFTP server every night.


✉️ Email Transport


Email transports allow Teemant to send data or documents via email.


Key characteristics:

  • SMTP configuration (host, port, encryption)
  • Authentication via email account
  • Supports attachments
  • Can be used for notifications or data delivery


Typical use cases:

  • Send reports or exports to business users
  • Notify teams when data is updated
  • Lightweight integrations with no backend system


🌐 Webhooks 🔔


Webhooks enable real-time push notifications to external systems.


Key characteristics:


  • HTTP(S) endpoints
  • Event-driven delivery
  • Payloads sent in JSON
  • Secure authentication (headers, tokens)


Typical use cases:


  • Trigger workflows in external platforms
  • Notify downstream systems instantly
  • Integrate with automation tools (Zapier, Make, custom APIs)


Example:


When a document is processed, immediately notify an external system with its metadata.


🔌 REST APIs 🧩


REST API transports allow external systems to pull or receive data programmatically.


Key characteristics:


  • Standard REST endpoints
  • Secure authentication (API keys, OAuth, tokens)
  • Supports structured data exchange
  • Designed for scalable integrations


Typical use cases:


  • Real-time system-to-system integration
  • External applications querying Teemant data
  • Advanced orchestration and automation


🧠 How Transports Work with Object Models & Tasks


Transports are not used alone:


  • Object Models define what data exists
  • Transports define how and where data is sent
  • Tasks define when and how often data is synchronized

Together, they form a complete data synchronization pipeline.


✅ Best Practices


✔ Use SFTP + ZIP for large or batch data exports
✔ Use Webhooks for real-time integrations
✔ Use REST APIs for advanced or interactive systems
✔ Separate transports per environment (Dev / Test / Prod)
✔ Always test transports before publishing them to production


🧭 Summary


Transports are the backbone of Teemant integrations.


They ensure that data produced inside Teemant flows reliably, securely, and automatically into your enterprise ecosystem.


They are designed to be:


  • Flexible
  • Scalable
  • Enterprise-ready


⏱️ Workspace Tasks

Workspace Tasks are used to configure automated or on-demand operations that run at the workspace level. They are typically used to import or export data, synchronize reference data, or execute recurring technical processes linked to the information system.


🔁 What is a Task?


A task represents a repeatable action executed by Teemant, usually based on:


  • a data scope (Entity, Object Model, documents, etc.)
  • a Transport (SFTP, Email, API, Webhook, …)
  • a schedule or trigger


Example shown in the screenshot:

  • Import Magasin
  • Entity: Magasin
  • Transport: SFTP Import
  • Scheduler: ENABLED


This means Teemant will periodically import shop (store) data from an external system using SFTP.


🧩 Typical Use Cases


Tasks are commonly used for:


  • 📥 Data imports
  • Reference data (shops, products, users, contracts, etc.)
  • Configuration or master data coming from external systems
  • 📤 Data exports
  • Structured outputs (JSON, ZIP, documents)
  • Sending AI-collected or processed data back to the SI
  • 🔄 Synchronization jobs
  • Keep Teemant object models aligned with external databases
  • Periodic refresh of shared data
  • ⚙️ Other scheduled operations
  • Batch processing
  • Cleanup, consolidation, or future automated jobs


The system is designed to be extensible, so additional types of recurring or triggered tasks can be added over time.


🧠 How Tasks Work with Transports


Tasks do not move data by themselves — they rely on Transports:


  • A Transport defines how data is exchanged (SFTP, Email, API, Webhook, etc.)
  • A Task defines when and what is exchanged


This separation allows:


  • Reusing the same transport across multiple tasks
  • Changing schedules without touching connectivity settings


▶️ Manual vs Scheduled Execution


  • Tasks can be:


  • Scheduled (regular execution, depending on configuration)
  • Manually triggered (using the Run action)


This is especially useful for:


  • Testing imports/exports
  • One-off synchronizations
  • Production troubleshooting


 Best Practices


  • 🔧 Configure tasks mainly in development workspaces
  • 🧪 Validate behavior in test workspaces
  • 🚀 Keep production tasks limited, stable, and monitored
  • 📦 Use one workspace per client application to isolate tasks and data flows


🧠 Teemant Agents Builder — Overview

The Teemant Agents Builder is the core design environment of the platform.
It is where AI agents are created, structured, orchestrated, and published.


A Teemant Agent is not just a chatbot.


👉 It is a business-grade AI process, capable of guiding users, applying business logic, interacting with systems, and producing structured outputs.


🧩 Agent Types: Processes vs Navigators


⚙️ Processes (Business Processes)


Processes are complete, autonomous agents designed to:


  • Collect structured information
  • Guide users step by step
  • Apply business rules and calculations
  • Generate outputs (JSON, documents, exports, emails, etc.)


Typical use cases


  • Incident or claim declaration
  • Damage reporting
  • Liability or responsibility declaration


Processes represent end-to-end business flows.


🧭 Navigators (Others)


Navigators are orchestration agents.


They do not finalize a business process but are used to:


  • Qualify the user’s situation
  • Authenticate or identify users
  • Route users to the correct sub-process
  • Split flows based on conditions or choices


Typical use cases


  • Insurance policy verification
  • Choosing the type of incident
  • Routing between “with third party / without third party” scenarios


💡 In a full application, Navigators act as building blocks that connect and organize multiple processes.


🧱 Main Tab — Agent Configuration


The Main tab defines the identity and behavior of an agent.


📛 Identification


  • Name: technical identifier (unique, stable)
  • Display Name: human-readable name shown in channels and UI


✅ Best practice:


Use strict naming conventions including scope, version, and purpose.


🌍 AI Contexts


  • Global Context
    Defines the general environment:
  • company or organization
  • vocabulary and terminology
  • global rules
  • overall tone


  • Agent Context
    Defines the specific mission of the agent:
  • what the agent must achieve
  • who the users are
  • communication tone
  • data to collect


👉 These contexts directly drive the AI’s behavior during conversations and email processing.


🚀 Launch Mode


  • FLOW_ONLY
    The agent is used only inside another process
    → not directly visible to end users


  • DIRECT
    The agent can be accessed directly from a channel
    → visible as an entry point for users


💡 This setting determines whether the agent is:


  • an internal component
  • or a user-facing entry point


🧬 Flow Tab — Process Orchestration


The Flow tab provides a visual representation of the agent’s logic.


Each block represents:

  • another agent
  • a navigator
  • a calculation step
  • an identifier
  • a message end
  • an export or email action


🔗 Flow Logic


  • Sequential steps
  • Conditional branches
  • Complex decision trees


👉 This is where business intelligence and orchestration are truly implemented.


📡 Publishing and Availability

📤 Publish / Unpublish


  • Publish: activates the agent
  • Unpublish: instantly disables it


Once published, the agent becomes accessible:


  • through the configured Channels
  • according to its Launch Mode
  • respecting workspace access rules


📦 Export / Import ( .tee files)


Agents can be:

  • exported as .tee files
  • imported into other workspaces


This enables:

  • templates and reuse
  • version control
  • cross-project standardization
  • faster deployments


💡 .tee files are a core asset of the Teemant ecosystem.


🧠 Best Practices

🏷️ Strict Naming Conventions


Always include:


  • functional scope
  • version
  • agent role


This is critical for:


  • maintenance
  • scalability
  • readability of complex flows


🧩 Modular Architecture


  • Keep agents small and specialized
  • Reuse Navigators
  • Centralize shared logic


👉 The simpler each agent is, the more robust the overall system becomes.


🧩 Summary


The Teemant Agents Builder allows you to:


  • design complex AI-powered business processes
  • orchestrate intelligent user journeys
  • connect AI to enterprise systems
  • deploy across multiple channels
  • industrialize and replicate AI use cases



👉 It is a business process design platform powered by AI, not just a chatbot builder.

📞 Teemant Agent Calls (Reusable Processes)

🔍 Overview


Teemant Agent Calls are callable processes designed to be reused across one or multiple agents.
They represent standalone process blocks that can be invoked from different flows instead of being duplicated.

Think of them as shared business logic that can be called whenever needed.


🧩 Why Agent Calls Matter


Agent Calls are particularly useful when:


  • 🔁 The same process must be executed multiple times
  • 🧠 The logic is complex and should live in one single place
  • 🧱 You want clean, maintainable agent architectures
  • 🔄 Multiple agents or flows rely on the same business rule


Typical examples:


  • Authentication or identification steps
  • Insurance policy verification
  • Damage qualification logic
  • Eligibility checks
  • Circumstancing (amicable vs responsibility, etc.)


🏗️ How Agent Calls Work


An Agent Call is:


  • A process, not a full conversational agent
  • Not directly exposed to users
  • Triggered from another agent or flow
  • Executed with the current context


📌 It behaves like a function call inside a larger conversational workflow.


🧠 Execution Model


  1. A main agent reaches a point where shared logic is required
  2. It calls an Agent Call
  3. The Agent Call:
  4. Uses the current context
  5. Executes its internal process
  6. Control is returned to the calling agent


➡️ No user disruption, no duplicated logic.


🧭 Typical Use Cases


Use caseWhy use an Agent Call🔐 AuthenticationSame verification used in many flows🧾 Policy lookupShared across multiple claim types🚗 CircumstancingAmicable vs third-party logic📄 Document validationReusable validation rules🔁 Multi-step checksCentralized decision logic


🧱 Architecture Best Practice


✅ One Agent Call = One Responsibility


  • Keep Agent Calls focused
  • Avoid mixing UI navigation and core logic
  • Name them very explicitly

📌 Example naming convention:


  • FLOT6x-AMIABLE-CALL
  • FLOT6x-CIRCUMSTANCE-CALL
  • FLOT1.0-POLICY-IDENTIFIER


Clear naming is critical when flows become large.


🔄 Relationship with Teemant Agents


ComponentRole🤖 Teemant AgentUser-facing or orchestrating agent🧭 NavigatorGuides users to sub-processes📞 Agent CallReusable callable process


➡️ Navigators decide where to go
➡️ Agent Calls execute shared logic


🚀 Deployment & Availability


  • Agent Calls are:
  • 📦 Published like regular agents
  • 🔌 Available to any agent in the workspace
  • Once published, they can be reused immediately
  • Updates automatically apply everywhere they are used



🧠 Key Takeaways


  • 📞 Agent Calls = Reusable process blocks
  • 🔁 Avoid duplication, improve consistency
  • 🧩 Essential for complex, large-scale agent systems
  • 🏗️ A cornerstone of clean Teemant architectures