Ask your systems in plain language. Check every answer.
Enterprise knowledge rarely lives in one place. It is distributed across documents, databases, ERP and CRM applications, ticketing platforms, collaboration tools and internal services.
LEAF works with your IT and business teams to create a natural-language interface across those systems, grounding answers in the information users are allowed to access and keeping the supporting sources visible.
Why this matters
Your company already has the answers. Finding them is the hard part.
Policies live in document repositories. Customer context lives in CRM. Operational information lives in databases. Project decisions sit in collaboration tools and tickets. Technical knowledge is spread across manuals, code repositories and internal services.
Traditional search often treats these sources separately. A conversational layer can provide one entry point, but only if retrieval, permissions, provenance and system boundaries are designed together.
The goal is not to create another copy of enterprise knowledge. It is to make the systems that already contain it easier to interrogate.
One question, many systems
The answer may come from more than one place.
A useful enterprise assistant needs to know where to search, when to retrieve information, when to query structured data and when a controlled tool call is more appropriate.
Documents
Contracts, manuals, policies, reports, emails and other unstructured information can be indexed and retrieved with page- or passage-level provenance.
Databases
Structured records can be reached through controlled queries or a semantic layer rather than treating relational data as if it were another document.
Enterprise applications
ERP, CRM, ticketing and collaboration platforms can expose relevant information through their supported APIs and access models.
Search systems
Keyword and semantic retrieval can be combined with metadata filtering and reranking to find the evidence most relevant to the user's question.
Internal APIs & tools
Defined tools can expose specific business capabilities through explicit schemas, scopes and failure handling.
Language models
Models interpret the question and the retrieved context, but they do not replace the systems that remain the source of truth.
From question to evidence
Retrieve. Check access. Answer. Cite.
Understand
Interpret what the user is actually asking
The assistant identifies the intent, relevant systems and whether the request requires retrieval, structured data or a defined tool.
Authorize
Access depends on who is asking
Identity and permissions determine which sources, records and tools the request is allowed to reach.
Retrieve or call
Use the right path for the information
Documents may go through retrieval. Structured information may use validated queries. Business capabilities may be reached through explicit tools or APIs.
- Retrieve
- Query
- Call
Generate
Build the answer from available evidence
The model works with the information returned by the authorized sources instead of relying only on knowledge acquired during training.
Cite
Keep the evidence attached
Supporting documents, records or system responses remain visible so the user can inspect where the answer came from.
Not all data is a document
Different sources need different access patterns.
A PDF and an ERP transaction should not automatically be handled the same way.
Unstructured
The information lives inside content.
- Extract
- Chunk
- Index
- Retrieve
Examples
- Contracts
- Manuals
- Policies
- Reports
- Emails
- Tickets
- Presentations
- Scanned documents
Approach
Extraction, chunking, metadata, search, reranking and passage-level retrieval are appropriate where the relevant information lives inside content.
Structured
Values, relationships and aggregations must stay correct.
- Validated query
- Semantic layer
- Controlled API
Examples
- Orders
- Customers
- Inventory
- Measurements
- Transactions
- Projects
- Assets
- Service records
Approach
Validated queries, semantic layers or controlled APIs are often safer when values, relationships and aggregations need to remain structurally correct.
The architecture chooses the access pattern based on the source instead of forcing every enterprise system into the same retrieval-augmented generation (RAG) pipeline. Not everything should be embedded and chunked.
Identity before intelligence
The same question can have a different answer for a different user.
Enterprise knowledge cannot be separated from enterprise access control. A useful assistant needs to know both what information exists and what the authenticated user is allowed to see or do.
Same question
in scope out of scope
Existing identity
Architectures can integrate with the organization's identity provider so requests originate from an authenticated user rather than an anonymous super-user.
Permission-aware retrieval
Source permissions and access metadata are designed into retrieval so results can be filtered according to the user's authorized scope.
Scoped tools
Tool and API access follows least privilege. Write operations can require explicit confirmation or human approval where the consequences justify it, and tool calls can be logged for review.
Reading and acting are different
Accessing information does not automatically grant permission to change it.
Retrieving a policy, reading a customer record and updating an ERP order are three different operations with different risk profiles.
When a conversational interface exposes tools, each tool should have an explicit purpose, schema and permission scope. Consequential actions can require confirmation or human review.
This is where Talk with Your Systems meets AI Automation: the interface can discover and prepare an action, while workflow execution remains governed by the controls appropriate to the process.
Explore AI AutomationRead
Retrieve a policy
Document permissions
Read
Read a customer record
Record-level scope
Write
Update an ERP order
Confirmation or human approval
Evidence first
An enterprise answer should be inspectable.
A fluent answer is not enough. Users need to understand which document, record or system response supports it.
The architectures we design keep provenance attached to the result so people can open the underlying source, review the context and decide whether the answer is sufficiently supported.
When the available evidence is insufficient, the desired behavior is not confident improvisation. It is to say that the answer cannot be supported with the information currently available.
Answer
Source 01Policy.pdf · p. 14
Evidence
Source 02CRM · Account record
Evidence
Source 03Service desk · INC-xxxx
Evidence
Insufficient evidence
The available sources do not support an answer to this question.
Retrieval is an engineering problem
Search quality determines what the model gets to reason about.
A strong language model cannot use information that retrieval failed to find. Enterprise search therefore needs to be evaluated as its own system.
- Source
- Parse
- Metadata
- Search
- Rerank
- Evidence
Ingestion
Extract text, structure and metadata from each source without losing the context needed later.
Search
Combine semantic and lexical retrieval where appropriate instead of assuming one search strategy works for every corpus.
Metadata
Preserve source, ownership, document type, dates and other fields useful for filtering and traceability.
Reranking
Reorder candidate evidence around the actual question before it is passed downstream.
Evaluation
Test retrieval using real reference questions and expected supporting evidence.
Models are a component, not the architecture
Choose the model around the task and the constraints.
The conversational layer should not be designed around a single model provider by default. Model choice depends on language, task quality, latency, context requirements, deployment constraints, data policy and evaluation results.
Commercial APIs and privately hosted open-weight models can both fit the architecture. The right choice is made per engagement and can change as models evolve.
Technology landscape
Designed around the systems you already run.
Systems that expose an API, a database or files can be assessed for connection. These are common examples across the layers of the architecture.
Examples, not a fixed mandatory stack. Technologies are selected according to the systems, data and requirements of each engagement.
Product names are listed for reference only and do not imply a partnership with or endorsement by their vendors.
ERP & CRM
- SAP
- Oracle
- Microsoft Dynamics 365
- Salesforce
- HubSpot
- Odoo
Documents & collaboration
- Microsoft 365
- SharePoint
- OneDrive
- Teams
- Google Workspace
- Confluence
- Notion
- Slack
IT & project systems
- ServiceNow
- Jira
- Zendesk
- GitHub
- GitLab
Databases & data platforms
- PostgreSQL
- MySQL
- Microsoft SQL Server
- Oracle Database
- MongoDB
- Snowflake
- Databricks
- BigQuery
Search & vector stores
- Elasticsearch
- OpenSearch
- pgvector
- Qdrant
- Weaviate
- Milvus
Models
- OpenAI GPT
- Anthropic Claude
- Google Gemini
- Mistral
- Llama
- Qwen
- other suitable open-weight models
Frameworks & interfaces
- LangChain
- LlamaIndex
- Model Context Protocol (MCP)
- REST
- GraphQL
- SQL
- webhooks
Identity
- Microsoft Entra ID
- Active Directory / LDAP
- Okta
- Google Identity
- SAML
- OpenID Connect
Files
- Office documents
- Email archives
- Scanned documents / OCR
- CSV
- Spreadsheets
- Images
Deployment follows the data
Cloud, private cloud or on-premises.
The retrieval layer, model serving and orchestration do not have to run in the same place for every organization.
Cloud
Appropriate where external AI and managed infrastructure fit the organization's data and operational requirements.
Private cloud
Dedicated infrastructure and controlled networking when stronger isolation or deployment control is required.
On-premises
Models, indexes and orchestration can run inside infrastructure controlled by the organization when data cannot leave its perimeter.
Model choice, hardware, security controls and performance trade-offs are assessed per project.
Explore Confidential AIValidation
A demo answer is not production evidence.
An enterprise assistant should be evaluated against the questions, sources and access rules of the environment where it will operate.
Evaluated against
- Reference questions
- Expected evidence
- Access rules
Answer correctness
Does the answer correctly reflect the available enterprise evidence?
Citation accuracy
Do the cited sources actually support the statements they are attached to?
Retrieval quality
Did the system find the information needed to answer the question in the first place?
Refusal behavior
Does the assistant avoid inventing an answer when the available evidence is insufficient?
Permission enforcement
Does access remain consistent with the identity, role and source-system permissions of the user?
Tool correctness
When tools are enabled, are the right operations called with valid parameters and within the user's authorized scope?
Where it fits
When people need answers across systems, not another search box.
Internal knowledge
Find policies, procedures, manuals and institutional knowledge across repositories while keeping the supporting source visible.
Customer & account context
Bring together authorized information from CRM, tickets, documents and other systems when people need a consolidated view.
Operations & support
Search manuals, incidents, asset information and service history before preparing a response or recommended next step.
Engineering & technical knowledge
Navigate specifications, project documentation, issue trackers, repositories and technical records through one query interface.
Document-intensive work
Find evidence across contracts, reports, correspondence and structured records without requiring users to know which repository contains the answer.
Management & analysis
Ask questions that may require combining information from more than one authorized enterprise source before producing a traceable synthesis.
Illustrative patterns, not descriptions of specific client deployments.
The LEAF method
Scout. Connect. Unlock.
Advisory leads the assessment and the architecture, Labs adds the engineering for the pilot and the integration, and Academy prepares the people who will use and maintain the result.
01/ Scout
Start with the questions people actually need answered
Together with business and IT teams, map the systems, data sources, access model and reference questions. Identify what should be retrieved, queried or connected and where a language model adds value.
02/ Connect
Build a bounded pilot on real sources
Co-design the architecture and connect a limited set of real enterprise sources. Evaluate it using a reference question set created with domain experts, including answer correctness, retrieval quality, citation accuracy and refusal behavior.
03/ Unlock
Embed it into the way people work
Integrate identity, monitoring, logging and the target user experience, then prepare the teams who will use and operate it to understand both its capabilities and its limits.
Connected capabilities
The conversational layer is only one part of the architecture.
AI Automation
When the system needs to move beyond finding information and execute a governed business workflow.
Explore AI AutomationConfidential AI
When models, indexes and orchestration need to run inside infrastructure or boundaries the organization controls.
Explore Confidential AILEAF Academy
When users and maintainers need the skills to adopt, evaluate and operate the resulting system effectively.
Explore LEAF AcademyWhat it does not solve on its own
Better access does not make weak information reliable.
The objective is not to make a model appear knowledgeable. It is to design an interface whose answers can be evaluated against the enterprise systems that actually hold the information.
- Answers are only as reliable as the sources available to the system.
- Outdated, contradictory or incomplete enterprise data can produce incomplete or misleading answers.
- Retrieval and citations reduce risk; they do not eliminate language-model errors.
- A citation does not automatically prove that the generated interpretation is correct.
- Permission-aware architecture does not replace the organization's identity and access governance.
- Not every question requires a language model.
- Not every system should be connected.
- Not every requested action should be automated.
- Structured data may require deterministic queries rather than free-form generation.
- Production quality has to be measured using the organization's real questions, sources and workflows.
Start with one system and one real question set.
Tell us where your teams currently search for information, which systems contain it and what questions are difficult to answer today. We can assess whether a natural-language interface is the right approach and what an evidence-backed pilot should connect first.