One connector per provider
OpenAI, Claude, Gemini or local models are switched by configuration, not code.
Our own cores
Enterprise AI core
AI as an internal service: one integration, many products.
.NETLaravelpgvectorRedis
The challenge
Different products needed AI: reading documents, answering from their own information and drafting reports. Integrating an AI provider in each product duplicated code, prevented switching models and made per-customer cost invisible.
How we solved it
We centralized AI in a platform the other systems consume via API. It converts documents into text, indexes them for semantic search, picks the model and records every use with its cost.
Architecture
How it is built.
Simplified view of the components and how information flows.
01
Products
SaaS platforms
Messaging & inboxes
02
AI API
Per-company tokens
Credits & limits
03
Processing
Ingestion & OCR
Semantic search (RAG)
04
Models
Cloud providers
Local models
.NETLaravelpgvectorRedisOpenAIClaudeGeminiOllama (local models)
Technical decisions
Why we built it this way.
Isolated knowledge spaces
Each company and app searches only its own documents.
Token, cost and latency logging
Every query is measured for billing and optimization.
Idempotent executions
A retry never consumes credits twice.
Vectors inside PostgreSQL
pgvector avoids running an extra vector database.
Outcome
What changed.
- A new product adds AI by consuming an API, reimplementing nothing.
- Sensitive data can be processed with local models.
- Templates that generate ready-to-use DOCX, PDF or JSON documents.
Ready to build what’s next?
Let’s find the right solution for your business.
Tell us about your goals and one of our engineers will get back to you personally.