Lexis Solutions has achieved the Select partner tier in the Claude Partner Network Services Track. What the milestone means and how we deliver production systems with Claude, powered by Anthropic.

Lexis Solutions Select partner in the Claude Partner Network Services Track

Lexis Solutions achieves Select partner tier in the Claude Partner Network Services Track

RAG-development-list

1728405892185

Bilyal Mestanov

dynamically-generated-documents-laravel

Nikola

Milush-photo

AI Companies Europe

open-ai-chroma-db-OPT

insurtech-pricerobot

Emil Kirilov

Deyan Denchev - new2

Viktor

building-web-scraping-at-scale-updated

Anthropic Two Bulgarian Partners

barton-malow-blog-post

CTO & Co-Founder

Nikola Popov

PHP / LARAVEL / DATABASES / SASS

Milush Karadimov

Software Developer

Deyan Denchev

CEO & Co-Founder

Web Developer

Viktor Enchev 

Full Stack Developer

**RAG development companies to consider for an AI knowledge system include Lexis Solutions, Scalefocus, and Accedia.** Each publishes retrieval-augmented generation capabilities. The right partner depends on your information sources, access rules, integration needs, and how you will measure useful answers.

An internal knowledge assistant needs to find the right evidence before it can answer well. It also needs to distinguish current information from obsolete versions, respect permissions, and recognise when the available sources cannot answer a question.

This guide introduces three companies with Bulgarian engineering operations and explains how to compare their proposed approach to your knowledge system.

_Published by Lexis Solutions, which appears first in this shortlist. Company information and technical sources were reviewed on 11 October 2026. Listing order is an editorial choice, not an independently measured ranking. Suggested project fit reflects our interpretation of the linked service descriptions._

### What does a RAG development company do?

**RAG stands for retrieval-augmented generation.** A RAG application retrieves relevant information from selected sources and supplies it to a language model as context for generating an answer. [Microsoft's RAG overview](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview) describes this pattern and its role in connecting generative AI to business content.

For a business knowledge system, the delivery work can include:

- Connecting approved document repositories, knowledge bases, or other sources.
- Extracting content and preserving useful structure and metadata.
- Building search and ranking so relevant evidence reaches the model.
- Applying access rules to retrieved information.
- Producing answers with traceable supporting sources.
- Evaluating performance and maintaining the system as information changes.

Common use cases include support knowledge assistants, internal policy search, product documentation, and onboarding guidance. Start with a defined audience and a set of questions people regularly need answered.

### Four RAG development companies to consider

We selected companies that explicitly describe RAG or retrieval-augmented generation in their own service materials. The list combines AI application development with broader software, data, and enterprise engineering capabilities. It is a starting shortlist rather than an exhaustive directory.

#### 1. Lexis Solutions

**Consider for: custom AI knowledge systems that need data integration and a usable product interface.**

Lexis Solutions is [based in Sofia, Bulgaria](https://www.lexis.solutions/about). Our [AI development services](https://www.lexis.solutions/services/ai-solutions) explicitly include RAG knowledge systems, semantic search, AI-powered internal tools, and intelligent data pipelines. We also build the application interfaces and agentic workflows around those capabilities.

That combination is relevant when the knowledge assistant needs to become part of an existing product or an internal process. The scope includes how information reaches the system and how employees use and check its answers.

**What to ask us:** assess your source documents and representative questions, propose an initial retrieval approach, and define the evidence needed to approve a release. Discuss permissions, source updates, evaluation, and handoff alongside the interface.

#### 2. Scalefocus

**Consider for: enterprise knowledge systems where governance and deployment requirements shape the architecture.**

Scalefocus documents [delivery operations in Bulgaria](https://www.scalefocus.com/company/who-we-are). Its [AI agent offering](https://www.scalefocus.com/capabilities/ai/ai-agents-with-governance-built-in) describes retrieval-augmented generation over proprietary data, source attribution, and visibility into agent operations. Deployment can use existing infrastructure or its AION platform.

**What to ask the team:** demonstrate how sources, permissions, and operational records are managed. Clarify which capabilities use your existing infrastructure and which introduce platform dependencies or additional operating costs.

#### 3. Accedia

**Consider for: RAG applications that also need data engineering, cloud integration, and AI operations.**

Accedia describes itself as an AI and custom software company [headquartered in Sofia](https://accedia.com/). Its [AI services](https://accedia.com/services/software-development-services/artificial-intelligence) explicitly include custom RAG systems, generative AI, validation, production deployment, and ongoing AI operations.

**What to ask the team:** show how retrieval and answer quality are evaluated separately, identify the specialists assigned to your project, and explain who maintains the data pipeline and monitors changes after launch.

### How to choose a RAG development partner

Give every shortlisted company the same sample documents, representative questions, and access requirements. The discussion should establish how the proposed system will work on your information, including cases where it should ask for clarification or decline to answer.

#### 1. Check how the team prepares your source material

Source preparation affects what the system can retrieve. Ask how the team handles scanned pages, tables, headings, duplicate files, and documents with conflicting versions.

When documents are split into smaller passages, important context can be lost. A passage mentioning a deadline may be misleading if the section specifying the relevant product or country is separated from it. [Anthropic's contextual retrieval article](https://www.anthropic.com/engineering/contextual-retrieval) discusses this problem and ways of preserving context around retrieved passages.

Ask the team to show the extracted content from a difficult document. Verify that its structure, identifiers, and source location are usable before evaluating the generated answer.

#### 2. Ask why the proposed retrieval strategy fits your questions

Semantic search helps find passages with related meaning. Keyword search can help with exact names, codes, and identifiers. Hybrid search combines these approaches, while reranking reassesses the relevance of initial results.

Microsoft's [RAG information-retrieval guide](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-information-retrieval) explains retrieval choices and how to evaluate search results. A partner should test those choices against your questions rather than assume one strategy will fit every source.

For example, an employee asking about “replacement parts for pump model P-204” needs the correct model's documentation. Similar descriptions of another pump may be irrelevant. Ask to inspect the retrieved passages and their ranking, as well as the final answer.

#### 3. Make permissions part of the retrieval design

Specify which users may access each source and how those permissions reach the knowledge system. Access controls need to apply before restricted content is supplied to the model.

Microsoft's [Azure AI Search security guidance](https://learn.microsoft.com/en-us/azure/search/search-security-best-practices) describes capturing permission metadata during indexing and enforcing document-level access at query time. Other architectures need an equivalent, tested approach appropriate to their stack.

Have the partner demonstrate the same question under two user roles. A user without permission should not receive the restricted document, its contents in an answer, or a cached response generated for someone with broader access.

Also test permission changes. Ask what happens when an employee changes departments or a document's access is revoked.

#### 4. Evaluate retrieval, answers, and citations separately

A system can find the right passage and still summarise it incorrectly. It can also produce a plausible answer using the wrong document. Evaluation needs to distinguish these failures.

Microsoft's [RAG evaluation guidance](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators) separates retrieval assessment from answer groundedness, relevance, and completeness. Apply those distinctions to your use case:

- **Retrieval:** did the system find the evidence needed for the question?
- **Groundedness:** are the answer's claims supported by that evidence?
- **Relevance:** does the answer address the user's request?
- **Completeness:** does it include the necessary information and qualifications?

Check citations directly. A working link is useful only if the cited passage supports the associated claim. Ask the partner to retain source identifiers and locations so reviewers can verify that relationship.

Agree on representative test questions before tuning begins. Include cases with no answer in the approved sources, ambiguous wording, outdated versions, and restricted information. Keep separate cases for final assessment, and use human review to check automated scoring.

#### 5. Plan source updates, removals, and conflicting information

Name who owns each source and define how quickly updates should become available. Ask how the system identifies superseded documents and how it handles disagreements between sources.

A useful acceptance exercise is to change a source document and repeat the affected questions. Then withdraw a document and check the index, retrieved passages, answers, citations, and caches that might still expose its content. The system should follow your agreed update and removal policy.

For conflicts, the application may need to favour a designated source, show the disagreement, or escalate to an owner. Decide that behaviour with the business team rather than leaving the choice implicit.

#### 6. Review security, operations, and ownership

Retrieved content can contain instructions intended to influence the model. [OWASP's prompt injection guidance](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) explains why RAG does not fully mitigate this risk and recommends controls such as separating untrusted content, restricting privileges, and adversarial testing.

For a knowledge assistant, define how content is handled and which tools it can use. If later versions add actions, assess their permissions and approval requirements as a separate scope.

The delivery proposal should also identify hosting, monitoring, support, and change responsibilities. Agree which assets your team receives: source code, ingestion configuration, evaluation datasets, prompts, infrastructure configuration, and operating documentation.

Ask how those assets can be used if you change model providers, search platforms, or delivery partners. Understand what rebuilding an index or changing an embedding model would involve.

### What should a RAG proof of concept demonstrate?

A useful proof of concept tests assumptions that affect the production decision. Choose a bounded question set and a representative mix of permitted documents, including difficult examples.

Consider a hypothetical support knowledge system containing product manuals, approved troubleshooting notes, and current service policies. A buyer could request these demonstrations:

1. **An exact-reference question:** retrieve the correct manual for a specific product code.
2. **A differently worded question:** find relevant guidance when the employee uses everyday language.
3. **A multi-source question:** combine relevant facts while preserving their individual citations.
4. **A missing-answer question:** explain that the approved sources are insufficient and offer an appropriate next step.
5. **A restricted-access question:** enforce different permissions for different users.
6. **An update test:** reflect an amended policy and stop relying on the withdrawn version within the agreed interval.

This is an illustrative evaluation plan, not a claimed customer project. Define expected evidence and outcomes with the business owner. Record unresolved gaps and the work needed for production.

### What affects the cost of RAG development?

Document volume is one input. Complexity also comes from parsing difficult files, connecting repositories, preserving permissions, supporting multiple languages, testing answer quality, and keeping sources current.

Ask suppliers to separate the build into discovery, ingestion, retrieval, application integration, evaluation, and deployment. Identify exclusions such as source cleanup or obtaining access to systems.

For ongoing operation, budget for search infrastructure, model usage, source processing, monitoring, and support. Compare latency and cost at an acceptable quality level on the same workload. A lower cost per answer is less useful if employees need substantial time to verify or correct it.

A proposal should explain what changes the estimate and who pays for work after handoff. Avoid comparing headline fees for systems with different source, permission, and maintenance requirements.

### Questions to include in your supplier brief

Send shortlisted companies a brief that answers:

- Who will use the knowledge system, and which decisions will it support?
- Which sources are authoritative, and who maintains them?
- What document formats, languages, and source systems are involved?
- Which information is restricted, and how are users identified?
- What questions should the first release answer, clarify, or escalate?
- What counts as a correct answer and a valid supporting citation?
- How quickly must updates and removals take effect?
- Where will users access the application, and what support is required?

Ask each supplier to respond with an architecture explanation, a scoped validation plan, acceptance criteria, delivery responsibilities, and an operating-cost estimate. This gives you a comparable basis for selecting a partner.

### Choose a partner around the evidence your users need

At Lexis Solutions, we build RAG knowledge systems and the data pipelines, interfaces, and workflows around them. Bring us a representative source set, the questions your team needs answered, and your access requirements.

We can assess the integration work, define an initial scope, and agree on how to evaluate retrieval, answers, and source maintenance. [Explore our AI development services](https://www.lexis.solutions/services/ai-solutions) to discuss your knowledge system.


Compare RAG development companies and assess retrieval quality, permissions, citations and maintenance when choosing an AI knowledge system partner.

RAG Development Companies: How to Choose a Partner for Your AI Knowledge System

**Lexis Solutions and Accedia were the only two Bulgarian companies identified in our review of Anthropic's public Claude Partner Network directory on 8 October 2026.** Both companies' public profiles display the **Select** partner tier.

Our October 8 review covered 313 public company profiles. For businesses looking for an Anthropic implementation partner in Bulgaria, that gives a focused starting point: two locally based firms whose partner standing can be checked directly in the programme's directory.

This guide explains what the listing means, what each company publicly offers, and what to ask when choosing a team to build with Claude.

*Published by Lexis Solutions, one of the companies featured here. The two-company count refers to our 8 October 2026 directory review; the individual profiles and their Select badges were checked again on 9 October 2026. The directory can change as profiles are added or updated.*

### Which Bulgarian companies are listed in the Claude Partner Network?

The two firms identified in our review were:

- **[Lexis Solutions](https://partnerhub.claude.com/directory/partner/lexis-solutions-partner)** — based in Sofia, Bulgaria; listed at Select; focused on Claude implementation, custom data infrastructure, and full-stack AI products.
- **[Accedia](https://partnerhub.claude.com/directory/partner/accedia-partner)** — headquartered in Sofia, Bulgaria; listed at Select; offering AI, software engineering, data, and technology consulting.

We identified Bulgarian companies using the location information in their public profiles and company websites. Regional service coverage is a separate attribute: serving customers in a region does not establish where a company is based.

The count describes publicly listed Bulgarian firms at the time of our review. Readers can check the latest listings in the [Claude Partner Network directory](https://partnerhub.claude.com/directory/).

### What is Anthropic's Claude Partner Network?

The Claude Partner Network is Anthropic's programme for companies that help customers adopt and implement Claude. The Services Track recognises a firm's delivery practice, including its certified practitioners and customer work.

Services partners can help with AI strategy, architecture, integration, implementation, and adoption. Anthropic presents these firms through its public services partner directory, where buyers can inspect company profiles and partner tiers. See the [official Claude Partner Network overview](https://claude.com/partners).

The programme distinguishes services partners from cloud platform partners. This article focuses on Bulgarian **services partners** that businesses can engage for Claude consulting and implementation.

### Lexis Solutions: a Select partner for Claude implementation and AI products

**Lexis Solutions has achieved the Select partner tier in the Claude Partner Network Services Track.** You can verify that standing in our [official partner profile](https://partnerhub.claude.com/directory/partner/lexis-solutions-partner).

We are a software company based in Sofia, Bulgaria, working with product teams and enterprises across Europe and North America. Our Claude practice combines three areas:

- **Claude implementation:** integrating Claude into products and internal systems, building agentic workflows, and establishing evaluation and operational controls.
- **Custom data infrastructure:** connecting databases, APIs, document sources, and data pipelines so the AI system has useful context.
- **Full-stack product engineering:** building the web and mobile interfaces through which people use the system.

These capabilities are described in our directory profile. Our [Select partner announcement](https://www.lexis.solutions/blog/lexis-claude-partner-network) explains the milestone and our approach to production Claude delivery.

#### A certified engineering team

As of October 2026, **90% of our engineers hold the Claude Certified Architect – Foundations certification**, according to our internal certification records.

That percentage describes our engineering team. When discussing a project, we can identify the practitioners who would work on it and explain how their experience relates to the proposed architecture, integrations, and deployment.

#### Public engineering work you can examine

Our work with Barton Malow's Data & Automation Engineering team provides an example of the engineering around an enterprise AI assistant. We helped build Moneypenny, a multi-model platform with a governed tool layer for warehouse queries, metadata retrieval, reporting, and deterministic calculations.

The platform enforces data access through individual warehouse identities and makes its capabilities available through a web application, Microsoft Teams, a REST API, and a Model Context Protocol endpoint. This multi-model implementation demonstrates how we approach integration and governance across AI systems. The [Barton Malow case study](https://www.lexis.solutions/case-studies/barton-malow-ai-assistant) describes the architecture.

**What to discuss with Lexis:** the workflow you want to improve, the data and tools Claude must use, the interface your team needs, and the tests that will establish whether the system works reliably.

### Accedia: a Select partner with a broader AI and software practice

Accedia is an AI and custom software development company headquartered in Sofia, Bulgaria. Its [official Claude Partner Network profile](https://partnerhub.claude.com/directory/partner/accedia-partner) displays Select and describes the company as a member of the network.

Accedia's public materials cover software engineering, data analytics, cloud engineering, and technology consulting. Its [company website](https://accedia.com/) describes its Bulgarian delivery team and work with customers in the US, UK, and Europe.

Its AI services include generative AI applications using Anthropic and other model providers, retrieval-augmented generation, agentic workflows, AI strategy, and ongoing AI operations. The company describes a delivery process spanning use-case definition, data preparation, development, evaluation, and deployment. See its [AI development services](https://accedia.com/services/software-development-services/artificial-intelligence).

**What to discuss with Accedia:** the Claude-specific experience of the assigned team, examples that match your proposed workflow, and how implementation and support fit within your wider software programme.

### How to choose a Claude implementation partner in Bulgaria

Both firms have a public Select listing. The next step is to compare the team and delivery plan for your actual use case.

**Ask who will build the system.** Identify the architects and engineers assigned to the project, their current certifications, and their experience with similar integrations. This connects a company-level credential to the people doing the work.

**Start with a defined workflow.** Name the users, approved data sources, actions Claude may take, and decisions requiring human approval. A clear first scope makes proposals easier to compare.

**Request an evaluation plan.** Agree on representative tasks, expected outcomes, and difficult cases before development begins. Include incorrect or missing data, tool failures, and requests that exceed a user's permissions.

**Review deployment and data handling.** Ask where the application will run, how it reaches your systems, which data is sent to the model, and how logs and credentials are managed. Document the controls your organisation requires.

**Define ownership after launch.** Agree who owns source code, infrastructure configuration, evaluation datasets, monitoring, and support. A useful handover should let your team understand and operate what has been delivered.

### How to verify a Bulgarian Claude partner

To check a firm's current standing:

1. Open the [official partner directory](https://partnerhub.claude.com/directory/).
2. Search for the company's name and open its profile.
3. Read the displayed partner tier and check the linked company website.
4. Confirm the company's location separately from its regional service coverage.
5. Ask the firm for the relevant delivery team and customer references.

For this guide, the direct profiles are [Lexis Solutions](https://partnerhub.claude.com/directory/partner/lexis-solutions-partner) and [Accedia](https://partnerhub.claude.com/directory/partner/accedia-partner).

### Discuss your Claude project with Lexis Solutions

If you are looking for a Bulgarian team to implement Claude, bring us one workflow you want to improve and the systems it touches. We can assess the integration work, propose an initial scope, and agree on how to measure the result.

**[Talk to Lexis Solutions about your Claude implementation](https://www.lexis.solutions/contact-us).**


Compare Lexis Solutions and Accedia, two Bulgarian companies listed in the Claude Partner Network in October 2026, and their implementation services.

Claude Partner Network in Bulgaria: Two Listed Companies

**AI agent development companies to consider in Europe include Lexis Solutions, Dreamix, Scalefocus, ML6, Theodo, codecentric, and Capgemini.** The right choice depends on whether you need a focused workflow, an agent inside an existing product, or a wider enterprise programme.

The useful comparison starts with what each team can build, integrate, and operate. An agent that searches documents has different requirements from one that updates a CRM, executes warehouse queries, or prepares payments for approval. Your shortlist should reflect those differences.

This guide compares seven implementation partners, the work their public materials describe, and the questions to ask before commissioning a custom AI agent.

*Published by Lexis Solutions, which is included in this guide. Company information was reviewed on 7 October 2026. Suggested project fit is our editorial assessment of the linked sources; listing order does not indicate an independently measured ranking.*

### What does an AI agent development company do?

An AI agent development company builds software that uses an AI model to select and execute steps towards a goal, within defined permissions. That usually means connecting the model to tools: search, databases, business APIs, or other applications.

The distinction matters when scoping a project. A workflow can follow a predefined sequence with an AI model handling selected steps. An agent gives the model more control over which steps to take. Both can be useful; the architecture should match the task. [Anthropic's guide to building effective agents](https://www.anthropic.com/engineering/building-effective-agents) explains this distinction and recommends starting with the simplest workable approach.

For buyers, the development work typically covers:

- **Discovery:** choose a workflow and define what successful completion means.
- **Data and integration:** connect approved sources, tools, and business systems.
- **Control:** define permissions, approval points, and escalation rules.
- **Evaluation:** test complete tasks against expected outcomes and difficult cases.
- **Deployment and operations:** monitor reliability, usage, cost, and changes after launch.

A useful proposal explains each of these in the context of your process.

### A quick comparison of AI agent development companies in Europe

Use these starting points to build a shortlist. The profiles below explain the evidence behind each suggested fit.

- **[Lexis Solutions](https://www.lexis.solutions/):** custom agents, governed data assistants, and AI features that need a working product interface.
- **[Dreamix](https://dreamix.eu/services/agentic-ai-development-services/):** custom agents and coordinated workflows integrated into existing business systems.
- **[Scalefocus](https://www.scalefocus.com/capabilities/ai/ai-agents-with-governance-built-in):** enterprise agents with an emphasis on governance, observability, and deployment within your infrastructure.
- **[ML6](https://www.ml6.eu/en/superintelligence/agentic-ai):** applied AI initiatives across product innovation, marketing, recruitment, and customer service.
- **[Theodo](https://www.theodo.com/en-uk/expertise/artificial-intelligence):** AI applications where software engineering, user adoption, and product delivery belong together.
- **[codecentric](https://www.codecentric.de/en/services/artificial-intelligence):** agent projects alongside enterprise software engineering and internal capability building.
- **[Capgemini](https://www.capgemini.com/gb-en/solutions/agentic-ai-for-enterprise-by-capgemini/):** enterprise programmes spanning custom agents, existing platforms, and governance.

### Seven AI agent development partners to consider

We selected companies with public descriptions of agent development or agent delivery offerings, alongside information about integration, deployment, or operations. The scope includes European delivery teams and firms explicitly offering agent implementation to European buyers. It includes three companies with Bulgarian roots, alongside partners serving other European markets. The list combines focused engineering teams and larger consultancies because project scope changes which delivery model makes sense.

#### 1. Lexis Solutions

**Suggested fit: custom AI agents and data assistants that need integration, permissions, and a usable interface.**

Lexis Solutions is a software company based in Sofia, Bulgaria, working with clients across Europe and North America. Our work combines agentic workflows, intelligent data pipelines, and web and mobile interfaces. That combination is useful when the agent is one part of a product your team needs to use every day. See our [company background](https://www.lexis.solutions/about) and [AI and product capabilities](https://www.lexis.solutions/).

A concrete example is our work with Barton Malow's Data & Automation Engineering team on Moneypenny, a governed enterprise AI assistant. Its tool layer connects business questions to warehouse-backed SQL, metadata retrieval, deterministic calculations, and reporting. Access is enforced through individual warehouse identities. The capabilities are available through a web application, Microsoft Teams, a REST API, and a Model Context Protocol (MCP) endpoint. The [published Barton Malow case study](https://www.lexis.solutions/case-studies/barton-malow-ai-assistant) describes the architecture and delivery.

Lexis also holds the Select partner tier in the Claude Partner Network Services Track, as described in our [partner announcement](https://www.lexis.solutions/blog/lexis-claude-partner-network).

**What to discuss:** which systems the agent must reach, how access should work, how users will interact with it, and which outcomes will demonstrate that it is ready for production.

#### 2. Dreamix

**Suggested fit: custom agents that need to work within established business systems.**

Dreamix is a software engineering company based in Sofia, Bulgaria. Its agentic AI offering covers use-case discovery, custom agent development, multi-agent orchestration, and workflow automation. The company describes building the pipelines, APIs, and integrations that connect agents to existing tools, followed by testing and monitoring. It also offers a proof-of-concept phase to assess feasibility before a larger deployment. See its [Bulgarian location](https://dreamix.eu/contact-us/) and [agentic AI development service](https://dreamix.eu/services/agentic-ai-development-services/).

**What to discuss:** which existing systems the agent must use, how the proof of concept will be evaluated, and what engineering remains before a production release.

#### 3. Scalefocus

**Suggested fit: enterprise agent deployments where governance and infrastructure control are central requirements.**

Scalefocus is a Bulgarian-founded software engineering company with delivery operations across several countries. Its published AI agent offering covers process automation, retrieval-based assistants, document intelligence, and multi-agent orchestration. Deployment can use a client's existing infrastructure or the company's AION platform. Its materials emphasise visibility into agent actions, model usage, costs, and auditability. See its [company history](https://www.scalefocus.com/company/who-we-are) and [AI agent capabilities](https://www.scalefocus.com/capabilities/ai/ai-agents-with-governance-built-in).

**What to discuss:** which controls are provided by your existing stack, which depend on AION, and how your team will monitor or disable an agent after deployment.

#### 4. ML6

**Suggested fit: businesses pursuing applied AI across innovation and customer-facing operations.**

ML6 lists European offices in Belgium, the Netherlands, and Germany. Its agentic AI offering includes marketing, product innovation, recruitment, and customer service. These provide concrete areas to explore when your brief extends beyond document search into a business process. See its [European locations](https://www.ml6.eu/en/contact) and [agentic AI offering](https://www.ml6.eu/en/superintelligence/agentic-ai).

**What to discuss:** which parts of the proposed solution already exist, which require custom engineering, and how the agent will be evaluated on your own data and operating rules.

#### 5. Theodo

**Suggested fit: AI applications where product adoption and software delivery are central to success.**

Theodo's Data & AI practice describes teams spanning data science, machine learning, MLOps, generative AI, and software engineering. Its services cover scoping, evaluation, deployment, and monitoring, alongside an offering focused on getting agents adopted in daily work. Published examples include a generative AI assistant integrated into a hotel group's internal content management system. These are described on its [Data & AI practice page](https://www.theodo.com/en-uk/expertise/artificial-intelligence).

**What to discuss:** how users will participate in discovery, what successful adoption looks like, and how the agent fits into the product roadmap.

#### 6. codecentric

**Suggested fit: enterprises combining agent implementation with software architecture and team enablement.**

codecentric's AI offering combines engineering support, AI application development, and cloud or on-premise operations. Its public references include customised agents at Tchibo and an agentic insurance claims proof of concept developed with Provinzial and andsafe. Those examples have different maturity levels, which is useful context when evaluating relevant experience. See its [AI services and project references](https://www.codecentric.de/en/services/artificial-intelligence).

**What to discuss:** who owns the architecture, which responsibilities your internal engineers retain, and what knowledge and operating procedures will be transferred.

#### 7. Capgemini

**Suggested fit: large enterprises coordinating agents across existing platforms and a broader transformation programme.**

Capgemini's enterprise agentic AI offering describes three routes: ready-made agents, custom agents for particular processes, and agents embedded in existing platforms. Its RAISE capabilities include governance, monitoring, and orchestration. This breadth makes it relevant to buyers whose agent project sits within a larger application and data estate. See its [Agentic AI for Enterprise offering](https://www.capgemini.com/gb-en/solutions/agentic-ai-for-enterprise-by-capgemini/).

**What to discuss:** the specific delivery team, platform dependencies, and which decisions and assets will remain under your organisation's control.

### How to choose an AI agent development partner

Start with one task that has a clear owner, approved inputs, and an outcome you can check. Then use the same questions with every shortlisted company.

**Ask for a relevant implemented workflow.** A document-search assistant demonstrates different skills from an agent that changes records or coordinates several systems. Request an architecture walkthrough covering the tools, permissions, failure cases, and deployment status.

**Agree on a task-level evaluation.** Measure whether the process completed correctly, how often people had to intervene, and what each successful completion cost. Include missing data, ambiguous requests, unavailable tools, and attempts to exceed permissions.

**Make authorisation concrete.** Ask which identity the agent uses, which actions it can take, and which actions require human approval. Have the team demonstrate how an unauthorised operation is blocked and logged.

**Map the data path.** Your review should cover source systems, model providers, retrieval stores, logs, and subprocessors. Specify your requirements for processing locations, retention, and deletion in the scope and contract.

**Assess the actual use case's regulatory requirements.** The European Commission describes the [EU AI Act as a risk-based framework](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai). Requirements depend on the use and the relevant role in delivering it. Ask the partner to support your legal and security teams with an assessment of the proposed system, including appropriate documentation and oversight.

**Define ownership and operations.** Agree who receives source code, infrastructure configuration, evaluation datasets, and runbooks. Name the owner of monitoring, incident handling, model changes, and support after launch.

### What production experience looks like in practice

Our enterprise data assistant work illustrates why these questions matter.

A question about open projects for one operating entity returned 370 through direct natural-language query generation. The correct result was 21,314. The query executed successfully, but its table choice and missing entity join meant it answered the wrong question.

The architecture we built retrieves certified table metadata and required joins before composing SQL. Calculations use deterministic tools, and the warehouse enforces each user's access. These decisions address specific failure modes that a polished demonstration can conceal.

In an internal evaluation of 21 business questions, our pipeline produced better answers on 13, the native engine on one, and seven were comparable. The evaluation used LLM judging with human spot-checks. That is evidence about this implementation and question set; broader conclusions require broader testing. The [full engineering article](https://www.lexis.solutions/blog/when-your-ai-gets-the-number-wrong-building-enterprise-data-assistants-that-can-be-trusted) explains the results and the case we lost.

When evaluating an agency, ask for this level of detail: the original failure, the engineering response, and the limits of the measurement.

### Start with a workflow you can measure

The most useful first brief names one process, the systems it touches, the actions the agent may take, and the result that would justify further investment.

At Lexis Solutions, we build custom AI agents, governed data assistants, and the products and pipelines around them. Bring us that brief and we can assess the integration work, define an initial scope, and agree on how to evaluate it.

**[Discuss your AI agent project with Lexis Solutions](https://www.lexis.solutions/contact-us).**


Compare seven AI agent development companies in Europe for 2026, with guidance on project fit, integrations, security and production delivery.

7 AI Agent Development Companies in Europe to Consider in 2026

Someone asked our assistant how many open projects belonged to one of the company’s operating entities. It came back with 370.

The real answer was 21,314.

Nothing about the response looked wrong. The SQL was valid, the table name matched the question, the result was a plausible-looking count rendered in a clean table. A project director with no reason to doubt it would have taken 370 into a meeting.

What had happened is that the engine picked a table whose name was a good semantic match for the question, and quietly dropped the company filter - because in that schema, company association lives in a joined dimension rather than as a column on the fact table. There was no way for the model to know that from the schema alone, and no mechanism for it to notice it didn’t know.

That is the failure mode that matters. Not the query that errors - the query that succeeds and lies.

We hit this building a company-wide AI data assistant with the data and automation engineering team at a national construction firm. The requirement was easy to state: let anyone ask a business question in plain English and get back a number they can act on, with a real query behind it. Satisfying it took two years and a fair amount of architecture we would rather not have needed.

### What a model cannot infer from a schema

When a question fails to become correct SQL, the cause is almost always one of three knowledge gaps, and none of them are reasoning problems.

__Which table is authoritative.__ Real warehouses accumulate near-duplicates - a raw table, a cleaned one, a certified one, and two abandoned experiments with similar names. Semantic similarity between a question and a table name is a weak guide to which one the business trusts.

__What the table obliges you to do.__ Some tables are only correct when joined to a specific dimension, or when a status filter is applied. That knowledge lives in analysts’ heads and in a data catalog. It is not expressible in DDL.

__What the words mean here.__ A fiscal year starting in April will silently corrupt every period-over-period comparison a model writes against it. So will an entity hierarchy where “the company” means a rollup of subsidiaries rather than a single ID.

A model given only the schema will produce syntactically valid SQL that answers a slightly different question than the one asked, and will present it with the same confidence it brings to a correct answer.

### Splitting query generation in two

The fix is to stop treating query generation as a single step, and to make the first step mandatory.

Stage one takes the natural-language question and searches a curated metadata layer - table descriptions, certification status, join specifications, required filters, fiscal-year semantics. It returns candidate tables with their usage contract attached.

Stage two composes SQL using only what stage one returned, and executes it.

The model still writes the query. But by the time it does, the table choice and the join obligations have arrived as retrieved facts rather than inferences, and the space of things it can get wrong has collapsed.

If you have built retrieval-augmented generation over documents, this is the same instinct pointed at schemas. One difference is worth internalising: a RAG answer degrades gracefully when retrieval is mediocre - you get a vaguer answer. A SQL answer has no graceful degradation. It is right, or it is 370.

Reduced to its shape, it is two tools with the ordering enforced:

```typescript
type TableSpec = {
  name: string;
  description: string;
  certified: boolean;
  requiredJoins: string[];
  requiredFilters: string[];
  notes: string; // fiscal year, entity semantics, known gotchas
};

// Stage one. Resolve a question to certified tables and their usage contract.
// This is a vector search over curated table documentation, not over
// information_schema. The whole point is the human-written context that the
// schema does not contain.
async function searchMetadata(question: string, limit = 5): Promise<TableSpec[]> {
  const embedding = await embed(question);
  const hits = await catalog.query({ embedding, limit });
  return hits.filter((h) => h.certified);
}

// Stage two. Execute, under the requesting user's own credentials.
async function runQuery(sql: string, user: UserContext): Promise<Row[]> {
  const conn = await warehouseConnection(user);
  return conn.execute(sql);
}

```

The code is the easy part. The contract around it is what does the work:

```typescript
You do not have schema knowledge. You must call searchMetadata before runQuery,
in every case, with no exceptions.

Compose SQL using ONLY tables returned by searchMetadata. Apply every
requiredJoin and requiredFilter from the returned specification. If
searchMetadata returns nothing suitable, say so and stop. Do not infer a
table name.

Never compute arithmetic yourself. Use the calculator tool.
```

That last instruction is doing more work than it appears to.

### Taking arithmetic away from the model

Ask a model for a growth rate and it will give you a growth rate. It will be approximately correct, which in a financial context is useless.

We routed every calculation through a deterministic expression parser. The model decides what to compute; something incapable of improvisation does the computing.

```typscript
import { Parser } from 'expr-eval';

const parser = new Parser();

export function calculate(expression: string): number {
  return parser.evaluate(expression);
}
```

A few lines, one dependency, and an entire category of plausible-looking wrong numbers disappears. It is the cheapest reliability win available in an AI data product and it is routinely skipped.

### Making the warehouse enforce permissions

Retrieval-first is what made the answers correct. This next decision is what made it possible to ship the assistant to an entire company rather than a vetted pilot group.

The standard pattern is to connect through one privileged service account and filter afterwards — usually by telling the model which rows the user is allowed to see. That is a request addressed to a probabilistic system. One prompt injection, one confused-deputy path, one unusual phrasing, and the filter is gone. You are also permanently one bug away from an unfiltered answer, because the privileged connection can always see everything and the only thing standing between it and the user is instruction-following.

We inverted it. Every user is provisioned their own warehouse service principal, with OAuth token refresh, and catalog grants derived from their assigned data domain — project delivery, competitive intelligence, or finance. Custom agents are constrained to a single domain by construction.

```typescript
// Connect as the user, not as the application. Authorization is resolved by
// the warehouse: if the user lacks the grant, the query fails at the engine.
// There is no filtered-answer path and no prompt that talks its way around it.
async function warehouseConnection(user: UserContext) {
  const principal = await principalStore.get(user.id);
  const token = await principal.accessToken(); // refreshed out of band

  return warehouseClient.connect({
    credentials: token,
    catalog: user.domainCatalog, // grant-derived, never user-supplied
  });
}
```

The behavioural difference shows up at the moment of failure. Under a service account, a user without finance access asks a finance question and receives a filtered answer that looks like a real one. Under per-user principals, the query does not execute and they get an error naming the missing grant.

Be clear-eyed about what this costs. You are no longer managing one credential — you are managing one per employee, which means provisioning on join, revocation on leave, and grant changes when someone moves teams. We ended up writing a reconciliation job that syncs grants for existing users against the current domain assignments, because the drift between “who should have access” and “who has a working principal” is real and silent. Identity provisioning became an ongoing operational surface rather than a one-time setup task.

It was still the right trade. Governance stopped being a feature layered onto the AI and became the thing that let the AI exist at organisational scale.

### What the benchmark showed, including the part we lost

We ran 21 real business questions — the kind people were already filing BI tickets for — through both our pipeline and the warehouse’s native natural-language engine, and had the results judged on whether the returned data actually answered the question.

Ours won 13. The native engine won 1. Seven were comparable.

Two caveats, because a benchmark without them is marketing. This is an internal evaluation, LLM-judged with human spot-checking rather than fully hand-scored. And 21 questions gives you a direction, not a precise margin.

The failure analysis is the useful part, and it splits cleanly.

The seven comparable results were all single-table aggregations. Month-to-date earned revenue over a five-month window came back identical from both systems. So did a top-five ranking of late-stage pipeline opportunities, down to the same total number. When a question maps to one certified table with no join obligation, direct generation works fine, and the extra retrieval stage buys nothing.

The gap opened exactly where you would predict: multi-table joins, entity filters, and fiscal-year windows. The 370-versus-21,314 case was a missing join to a company dimension. A question about the largest monthly underbilling returned a different project entirely from each system, because the native engine applied no entity filter and surfaced a figure from outside the requested scope. A four-year comparison of projects above a cost threshold returned results from our pipeline and a tool error from the native engine.

The one we lost is worth stating plainly: on a question involving a month-boundary filter, the native engine chose a more appropriate date predicate than we did. It was a better answer and our metadata layer did not encode the convention it needed. That is a curation gap, not an architectural one, which is a useful thing to learn from a benchmark — it tells you where to spend the next week.

### Three things worth knowing before you build this

__The metadata layer is the product.__ We spent more effort curating table documentation than on prompt engineering, and it was not close. Retrieval-first only works if there is something worth retrieving. If your catalog is stale, fix that before writing a line of agent code, or you will have built a sophisticated way to be confidently wrong.

__Enforce tool ordering in code.__ “Always call searchMetadata first” in a system prompt is a suggestion, and under load, in a long conversation, with a distracting question, it will occasionally be ignored. If correctness depends on the ordering, make the second tool refuse to run without evidence of the first.

__Prefer loud failures__. Every place we allowed a degraded answer instead of an error, we later regretted it. Users cannot reliably distinguish a degraded answer from a good one. They have no trouble at all distinguishing an error message.

### Conclusion

The instinct with a capable model is to hand it the schema and let it work. It is the shortest path to a demo, and it is why so many AI-on-data projects look brilliant in a pilot and get quietly shelved after someone in finance checks a number.

Retrieval-first generation is slower to build. It means curating metadata nobody wanted to curate, splitting one clean tool into two awkward ones, and taking arithmetic away from a model perfectly capable of doing it. What you get back is a system whose wrong answers are bugs you can find and fix, rather than an emergent property you can only apologise for.

For enterprise data, that trade is not close.

A technical deep dive into why AI assistants return confidently wrong business numbers, and the retrieval-first architecture that fixes it.

When Your AI Gets the Number Wrong: Building Enterprise Data Assistants That Can Be Trusted

Comparing insurance prices sounds simple on the surface. In practice, it’s a complex engineering problem that combines web scraping, automation, performance optimization, and constant adaptation to third-party systems.
In this article, we share how we helped Pricerobot build a real-time insurance comparison platform that aggregates car and home insurance offers from leading providers across Scandinavian markets – delivering accurate, comparable results under strict time constraints.

## The Problem with Insurance Data
Unlike modern SaaS products, insurance companies rarely expose clean, public APIs for price comparison. Instead, pricing logic is buried behind:
- Multi-step forms with dynamic validation
- Session-based pricing flows
- Anti-bot and fraud prevention mechanisms
- Country-specific rules and product variations

For Pricerobot, the challenge was not just extracting data, but doing so __reliably, quickly, and consistently__ across multiple providers and countries.

Each comparison request had to:
- Trigger parallel data collection from multiple insurers
- Normalize vastly different pricing models
- Return a comparable result set in under 2.5 minutes

### Why a Naive Scraping Approach Would Fail
A single, monolithic scraper would quickly become unmaintainable. Any change by one provider could break the entire system, slow down responses, or silently return incorrect results.

The platform needed to be:
- Modular, so providers could evolve independently
- Adaptive, choosing the fastest and most reliable extraction method per provider
- Observable, with full visibility into failures and performance bottlenecks
- This led to a deliberately modular and adaptive architecture.

### Modular Provider Architecture
Each insurance provider was implemented as an isolated actor, responsible for handling its own data flow, validations, and execution logic.

This approach delivered several advantages:
- Failures in one provider never impacted others
- Providers could be optimized or refactored independently
- New insurers could be onboarded without touching core logic

A centralized orchestration API handled:
- Input validation
- Provider configuration
- Parallel execution
- Aggregation of normalized results

This separation of concerns proved critical for long-term maintainability.

### Adaptive Scraping and Automation Strategy
Not all providers require the same level of automation.
Some insurers could be handled efficiently using:
- Direct HTTP requests
- Lightweight HTML parsing

Others required:
- Full browser automation
- Session persistence
- Captcha handling and security workarounds

The system dynamically selects the most appropriate strategy per provider. Over time, browser-based flows were selectively replaced with faster HTTP-based implementations where possible, reducing execution time without sacrificing reliability.
This hybrid approach balanced __speed, stability, and development effort.__

### Performance as a First-Class Constraint
Unlike batch scraping systems, Pricerobot operates in near real time. Performance was not a “nice to have” – it was a core product requirement.
Optimizations included:
- Parallel execution across providers
- Fine-tuned timeout handling
- Provider-specific performance profiling
- Continuous refactoring of slow execution paths

The result was a system that consistently delivers full comparison results within strict time limits, even as providers change their internal flows.

### Centralized Monitoring and Transparency
At scale, silent failures are more dangerous than visible ones.
We built a centralized monitoring layer that:
- Collects execution results from every provider run
- Tracks timeouts, empty results, and partial failures
- Sends real-time alerts to Slack when anomalies occur

Historical execution data is stored and analyzed to:
- Detect recurring provider issues
- Identify performance regressions
- Prioritize optimization work

This transparency allows both the engineering team and the client to understand system behavior at all times.

### What We Learned
A few lessons stood out clearly:
__1. Isolation beats cleverness__
Modular provider isolation prevents cascading failures.
__2. Performance must be designed, not tuned later__
Real-time systems require performance-first thinking from day one.
__3. Adaptability is non-negotiable__
Third-party systems will change – your architecture must absorb that change.
__4. Monitoring is part of the product__
Observability is essential for trust and long-term scalability.

### Final Thoughts
Building a real-time insurance comparison platform is not about scraping alone. It’s about designing systems that can survive constant external change while delivering fast, accurate results to end users.
By combining modular architecture, adaptive automation strategies, and deep monitoring, Pricerobot was able to scale its platform confidently across multiple markets and providers – without sacrificing performance or reliability.
If you’re building data-driven products that rely on third-party systems, these principles apply far beyond insurance alone.


How we built a modular InsurTech platform that compares car and home insurance prices in real time under strict performance constraints.

Adaptive Automation in InsurTech: Comparing Insurance Prices in Real Time

Modern data-driven products often rely on information that doesn’t come neatly packaged via APIs. In industries like e-commerce, pricing intelligence, and market research, large-scale web scraping becomes a core technical capability rather than a supporting tool.

In this article, we share lessons learned while building a distributed web scraping infrastructure designed to collect promotional and coupon data from hundreds of websites across multiple countries, languages, and formats. The project highlights common pitfalls of scraping at scale and how thoughtful architecture, automation, and monitoring can turn a fragile system into a reliable production pipeline.

## The Core Challenge: Scraping Is Easy – Doing It Reliably Is Not
Scraping a single website is relatively straightforward. Scraping hundreds of them reliably, every day, is a completely different problem.
Each source behaves differently:
- Custom HTML structures
- Aggressive anti-bot protections
- Locale-specific formatting
- Inconsistent merchant naming
- Frequent, unannounced layout changes

At scale, small inaccuracies quickly compound into data quality issues, broken pipelines, and operational overhead.
The goal was not just to extract data, but to build a system that could:
- Scale across regions and languages
- Maintain consistent, high-quality output
- Detect failures automatically
- Be extended quickly without increasing technical debt

### Designing for Scale: Modular Scrapers with Shared Intelligence
One of the earliest architectural decisions was to treat each scraper as an independent unit, while still enforcing strong standardization.

#### What worked:
- __One scraper per source__, isolated and failure-contained
- __Shared core utilities__ for parsing, normalization, and validation
- __Standardized output schema__, regardless of input structure

This modular approach allowed new sources to be added quickly while keeping maintenance predictable. When a site broke, the impact was localized rather than systemic.

To accelerate development further, we introduced templated scraper generation, allowing new scrapers to be scaffolded with predefined structure, logging, and validation rules.

### Data Quality Is a First-Class Concern, Not a Post-Processing Step
At scale, data quality issues are more dangerous than scraper failures. Incorrect data often looks “valid” and can silently pollute downstream systems.

We addressed this by embedding validation early in the pipeline.

#### Key safeguards included:
- __Merchant-to-domain consistency checks__ to detect mismatches
- __Coupon relevance validation__, preventing cross-merchant contamination
- __Prioritized source resolution logic__ when conflicting signals appeared
- __Early filtering__, reducing unnecessary downstream processing

By treating validation as part of extraction rather than a cleanup step, we significantly reduced noise and improved trust in the data.

### Monitoring a Distributed System with Many Failure Modes
With hundreds of scrapers running independently, traditional uptime monitoring was insufficient. A scraper could be “up” and still produce zero or incorrect data.

We introduced __domain-specific monitoring__, focused on data outcomes rather than infrastructure alone.
#### Examples of automated alerts:
- Scrapers returning zero results
- Successful runs with zero coupons
- Build or deployment failures
- Merchant-domain mismatches
- Unexpected changes in output patterns

Each alert included contextual metadata and was delivered via structured notifications, making it easy to diagnose issues quickly without manual log digging.

### Making Large Datasets Navigable for Humans
As data volume grew, internal teams needed better ways to explore coverage, diagnose gaps, and validate sources.
We introduced:
- __Hierarchical data navigation__ (locale → domain → merchant)
- __Coverage indicators__ for supported and unsupported sources
- __Duplicate detection logic__ across domains
- __Extended logging and traceability__ for troubleshooting

This made the system not only machine-reliable, but human-operable.

### Supporting Multiple Locales and Languages
- Scraping across regions introduces subtle but critical complexity:
- Different search patterns
- Localized coupon formats
- Language-specific parsing
- Geo-restricted content

The solution was to make locale awareness a core concept, not a configuration afterthought:
- Locale-specific discovery strategies
- Language-aware parsing logic
- Regional proxy management
- Flexible formatting rules

This prevented the system from becoming brittle as new markets were added.

#### What We Learned
A few principles stood out clearly:
1. Standardization beats heroics
Shared contracts and utilities reduce long-term complexity.
2. Monitor outcomes, not just processes
Data correctness matters more than job success.
3. Design for change, not stability
Scraping targets will change – the system must absorb that change gracefully.
4. Developer experience compounds
Templates, tooling, and clear structure dramatically improve velocity.
5. Continuous refinement prevents collapse
Regular refactoring is not optional at scale.

#### Final Thoughts
Large-scale web scraping is not about clever selectors or bypassing protections. It’s about engineering discipline, automation, and building systems that expect failure and adapt to it.

By focusing on modularity, data quality, and operational visibility, it’s possible to turn a traditionally fragile approach into a reliable, production-grade data platform – even in environments defined by constant change.

If you’re facing similar challenges around data extraction, validation, or large-scale automation, these principles tend to generalize well beyond scraping alone.


How Lexis Solutions built a scalable web scraping platform with data validation, monitoring and support for multiple countries and languages.

Building a Web Scraping Platform at Scale: Lessons from a Global Data Pipeline

As a software engineer at Lexis Solutions, I recently faced a seemingly Herculean BI challenge: distilling critical financial insights from more than 500,000 multi-format company reports. Tackling it pushed me beyond conventional ETL pipelines and into the frontier of AI-powered document classification. By pairing OpenAI’s text-embedding models with the lightning-fast similarity search of ChromaDB, I transformed a mountain of unstructured data into an organised, query-ready knowledge base. Curious how those pieces fit together - and how you can replicate the approach? Join me for a step-by-step walkthrough of the project, from data wrangling to production deployment.

## The problem

We were tasked to extract key-value pairs from inconsistent structure and text from business documents. Therefore, we couldn't quickly develop an algorithm to solve the problem and had to implement a solution to leverage the new advances in LLM. We used a cloud solution to train an AI model to extract the key-value pairs. However, it was still pretty challenging to deal with the sheer volume of documents, as not all documents held relevant information, and if we had to process each page, not only would it take more time, but it would be much more expensive. Manually sifting through these documents would be even more time-consuming and economically unviable. The solution? A classification program that combines OpenAI embeddings and ChromaDB vector databases, using Pytesseract for Optical Character Recognition (OCR). 

Before we delve into how these technologies helped me overcome the challenge, let's understand what vector embeddings and vector databases are. 

### Vector embeddings

In a high-dimensional space, vector embeddings are mathematical representations of objects, such as words or documents, capturing semantic meanings based on their context. These vectors provide a way for algorithms to understand the content and context of documents. 

### Vector databases

Vector databases, on the other hand, are databases designed to store and query these vector embeddings efficiently. They enable us to perform similarity search at scale, which is critical in tasks such as semantic search, relatedness search, or, in our example - classification. 

### Implementation

This is where OpenAI and ChromaDB came into the picture. OpenAI provides a powerful tool to generate embeddings for our documents, while ChromaDB allows us to store and query these embeddings efficiently. By leveraging the power of vector embeddings and vector databases, we can classify documents based on how close their vector representations are, which will help us identify relevant pages in a document.

First, I split the PDF documents into individual pages. For each page, I created a MySQL record, applied OCR using Pytesseract, and generated an embedding using OpenAI. Using ChromaDB, I queried the page embedding with the embeddings of already classified pages (that I organized personally) stored in the vector database. The result of the query would give me the most related page to the one I am querying, and I would classify it with the same type, storing the type back in the database.

This process enabled me to filter out irrelevant pages, leaving only the ones that needed further processing. This streamlined the process and reduced the cost by about 80% of the original estimate.

### A basic example

I will give you a simple example to showcase an implementation of a Python program that does a similar job. To implement this solution, you'll need to create a MySQL database that contains the information for each image and a ChromaDB vector database, which you will use to query the vector embeddings.

Here's a simple schema for the MySQL database:

```sql
CREATE TABLE documents (
    id BIGINT UNSIGNED PRIMARY KEY,
    name VARCHAR(255),
    file_path VARCHAR(255), # path of the document in the filesystem
);

CREATE TABLE document_pages (
    id BIGINT UNSIGNED PRIMARY KEY,
    document_id BIGINT UNSIGNED,
    type ENUM(‘invoice’, 'balance_sheet’, ‘income_sheet’, ‘none), # here we store the type of the image once we classify it
    file_path VARCHAR(255),
    FOREIGN KEY (document_id) REFERENCES documents(id)
);
```

We need to manually classify at least a couple hundred images and save them in a folder. The assigned type of each image should be contained in the name of the image, separated by a dash, for example: ```'[name]-invoice.jpg'``` or ```'[name]-none.jpg'```. Then, we will embed these images into a ChromaDB vector database using the following example:

```python
import chromadb
import glob
import os
import pytesseract as pt
from openai import OpenAI
import uuid

openai = OpenAI('your-api-key')

client = chromadb.PersistentClient(path="chromadb")

# create the classification chromadb collection
classification_collection = client.get_or_create_collection(name="classification_collection",  metadata={"hnsw:space": "cosine"})

classified_images = glob.glob("classified_images/*.jpg") # the location of the folder containing the manually classified images

for classified_image in classified_images:
    # get base name of image
    image_type = os.path.basename(classified_image).split(".")[0].split('-')[1]

    # get the ocr text
    ocr_text = pt.image_to_string(classified_image)

    embedding = openai.embeddings.create(
        input=ocr_text.lower(),
        model="text-embedding-ada-002"
    ).data[0].embedding

    # embed the image in the chromadb database
    classification_collection.add(
        embeddings=embedding,
        metadatas={'type': classified_image.type},
        ids = str(uuid.uuid4())
    )

```
After creating the classification database, you can use the following Python code to perform OCR, generate embeddings, and classify the pages of a given document page:

```python
from models import DocumentPage
import chromadb
import pytesseract as pt
from openai import OpenAI

openai = OpenAI('your-api-key')

client = chromadb.PersistentClient(path="chromadb")

# create the classification chromadb collection
classification_collection = client.get__collection(name="classification_collection")

for DocumentPage in DocumentPage.all():
    # get the ocr text
    ocr_text = pt.image_to_string(DocumentPage.file_path)

    embedding = openai.embeddings.create(
        input=ocr_text.lower(),
        model="text-embedding-ada-002"
    ).data[0].embedding

    # embed the image in the chromadb database
    query = classification_collection.query(
        query_embeddings=embedding,
        n_results=1
    )

    DocumentPage.type = query['metadatas'][0][0]['type']

    DocumentPage.save()
```

## Conclusion

This simple example should illustrate the process of classifying images using the latest trends in LLMs and vector databases. The synergy of OpenAI embeddings and ChromaDB vector databases has revolutionized our approach to document classification, making it more efficient and cost-effective. 

The article has given you a glimpse into the power of AI tools in business intelligence. As we continue to explore and experiment, we are excited about the endless possibilities that AI holds for us, and we will keep sharing our insights about how we can use them in real-world scenarios.


Uncover how OpenAI and ChromaDB revolutionized financial data extraction, streamlining document classification for efficiency.

Unleashing the Power of AI in Business Intelligence: Document Classification using OpenAI and ChromaDB

We are thrilled to announce that our team participated in the recent AI Hackathon organized by AI Engineer Foundation Europe and TeamGPT, and we’re proud to share that we secured 3rd place!

During the hackathon, AI enthusiasts and developers came together to collaborate, innovate, and build cutting-edge solutions.

Our team worked tirelessly to create a powerful AI assistant that helps manage knowledge and streamline daily workflows for both individuals and businesses.

This was an incredible opportunity to showcase our skills and push the boundaries of AI-driven solutions.

A big thank you to all the organizers, judges, and sponsors of the event, including Iliya Valchanov, Michael Montano, TeamGPT, LAUNCHub Ventures, Iris.ai, Appolica | Venture studio - and everyone who made this event possible.

More about the project we built entirely from scratch:
A powerful web-based AI assistant that helps people and businesses manage their knowledge and everyday workflows:
- It allows you to log and organize anything (notes, tasks, calendar) from anywhere, as soon as it pops into your mind using chat, voice, Siri, Google Assistant
- It keeps up with context and fetches anything it needs to complete a task even if the communication channel changes or even if you give it more vague instructions

Check out the Beta version: 🎥👇

[Loom](https://www.loom.com/share/21b7062d75424814ab6d2469ac14e1ad)

See what the Lexis Solutions team built at Sofia AI Hackathon 2024, where our weekend project earned third place.

Celebrating our Medal at Sofia AI Hackathon 2024

Generating documents dynamically is a common requirement in many applications, especially in cases like legal forms, contracts, and agreements where personalized user data needs to be inserted into predefined templates. Laravel, combined with external libraries like PhpWord, provides an efficient way to handle this.

### Key Components of Dynamic Document Generation

The process of generating dynamic documents in Laravel generally involves a few key steps:

1. **Template Processing**: The foundation of this approach is using pre-designed templates, usually in formats like `.docx`. These templates contain placeholders that will be replaced with actual user data. PhpWord’s `TemplateProcessor` is often used to load these templates, replace the placeholders, and generate the final document.

2. **Mapping User Data to Placeholders**: The core logic revolves around mapping user-specific information, such as names, addresses, or other relevant details, to the placeholders in the template. This ensures that each document is tailored to the specific user or case at hand.

3. **Dynamic Image Insertion**: In some cases, signatures or other images need to be dynamically inserted into the document. For instance, a contract may require both the client’s and attorney’s signatures to be embedded directly into the final document. This is done by specifying the image paths in the code and replacing the placeholders in the document with actual image files.

4. **Saving the Generated Document**: Once the placeholders are replaced with the appropriate data and any images are inserted, the final step is saving the document to a specified path. This allows it to be downloaded or sent to users via email.

### Common Use Cases

This approach is particularly useful in industries like legal services, where contracts, power of attorney forms, and other formal documents are frequently required. By automating the document generation process, businesses can save time and reduce human error.

### Benefits of Using Laravel for Document Generation

- **Efficiency**: By leveraging templates, you can generate documents quickly without manually drafting them for each user or case.
- **Flexibility**: PhpWord’s support for dynamic placeholders allows you to easily map various types of user input into your document templates.
- **Customization**: With the ability to insert dynamic images like signatures, you can ensure that your documents meet professional standards without requiring additional post-processing.

### Conclusion

Dynamic document generation in Laravel, powered by PhpWord, simplifies the process of creating personalized documents based on user input. Whether for legal contracts, agreements, or other formal documentation, this approach provides a flexible and efficient solution to meet business needs.

Learn to generate documents in Laravel with PhpWord, including template processing, user data and dynamic images such as signatures.

From the front lines