Capabilities

AI architecture and advanced systems

Turning new AI capabilities into architectures that can be integrated, operated and evolved.

On one page

We design architectures for models, agents, inference, distributed systems, cloud and edge, runtimes and components of our own. We evaluate emerging technologies, build prototypes when necessary and take the ones that add value into architectures that are maintainable, observable and ready for production.

01Exploring the frontier and building on solid ground. We explore the frontier of AI, knowledge systems, software and robotics, and we combine their advances with foundations able to sustain a real operation.
02We build our own layers where the differential knowledge resides. We develop components of our own when the value resides in the representation, in the contracts or in the way the work is coordinated.
03Generative AI, agents and intelligent programs. Generative models have extended the ability to interpret language, compare information, use tools, generate code and compose content.

We are interested in a technology when it opens a new capability and when it makes it possible to take that capability into a real system.

We follow closely the evolution of foundation models, agents, memory, retrieval, semantics, optimisation, simulation and robotics. We test early, compare with simpler alternatives and build layers of our own when the available tools still do not represent the problem well.

Our technological ambition has two complementary directions:

exploring techniques that are still defining what will be possible;
building on foundations able to sustain data, state, permissions, integration, evaluation and maintenance.

That combination allows us to work from a documentary source or a business rule through to a durable workflow, a fleet of agents or a physical operation.

Exploring the frontier and building on solid ground

We explore the frontier of AI, knowledge systems, software and robotics, and we combine their advances with foundations able to sustain a real operation.

The speed of AI invites you to choose a tool for what it demonstrates over a few minutes. Real work demands finding out what happens afterwards:

how it integrates with existing data and systems;
what context it needs;
what cost it introduces;
how it behaves under adverse inputs;
what state has to persist;
how its authority is limited;
which part can be replaced;
what knowledge ends up tied to the provider;
what evidence makes it possible to evaluate it;
how the system responds when the technology changes.

We explore with curiosity and adopt with judgement.

A technique can be in one of four states:

Explore: We use it to formulate a question better, understand its behaviour or discover a capability.
Evaluate: We compare it in representative and adverse scenarios, with explicit metrics, costs and limits.
Apply: We integrate it into a complete journey and subject it to requirements of data, security, latency, recovery and maintenance.
Build: We develop a layer of our own when it represents knowledge, logic, orchestration or interaction that we consider central and lasting.

This classification distinguishes exploration from operation, and makes it possible to maintain an ambitious technological stance while declaring what already sustains a system and what remains under evaluation.

We build our own layers where the differential knowledge resides

We develop components of our own when the value resides in the representation, in the contracts or in the way the work is coordinated.

DocuLogic: Reconstructs business logic and operational knowledge from code, configurations, documents, tables, tests and traces, and preserves them as knowledge that is legible, versionable and joined to its evidence. It makes it possible to examine each rule with its provenance and its state: observed behaviour, inferred logic, validated knowledge or agreed decision.
KIR: An intermediate representation of knowledge, typed and canonical, that decouples the sources from their uses. It makes it possible to examine what projection each consumer receives — relational databases, graphs, semantic indexes, rule engines, APIs, MCP, agents and reporting — and what version of knowledge sustains it.
ERP-Bots: The line of operational bots and agents that complete work inside ERPs and business applications under policies, state and verification. It makes it possible to examine the trace of an operation: what context was retrieved, what policy decided, what tool acted, who authorised and what signal closed the case.
SuperSocrates: The system that asks: it interrogates the material of a project to find gaps, information that does not match between sources, decisions that contradict one another and assumptions nobody wrote down, and it proposes the next useful question. It makes it possible to examine a collision with the sources that gave rise to it and the question it opens.
SuperQuestions: The product that represents and manages the questions of a project together with their evidence, their decisions, their dependencies and their work. It makes it possible to examine a question with what sustains it, what contradicts it and what depends on it. SuperSocrates asks; SuperQuestions administers what the question produces.
SuperPythagoras: A harness for building software as a team when people and bots share the work: roles, delivery contracts, orderly handovers, review and SecondOpinion, an independent perspective on every change with consequences. It makes it possible to examine the journey of a change and the evidence of why it was built that way.
Finaz: An editorial architecture that separates evidence, information structure, composition, controls and multimodal production. It makes it possible to examine the intermediate schema shared by report, script and narrated piece, and the point where the deterministic ends and the generative begins.
Excorpora: A research and evaluation environment for translation and localisation, built on declared invariants, aligned corpora and adversarial auditing. It makes it possible to examine where the sense changes even though the sentence sounds natural.

These layers can evolve even if the models or providers placed around them change. Domain knowledge, logic and evaluation criteria remain in representations that we control.

Generative AI, agents and intelligent programs

Generative models have extended the ability to interpret language, compare information, use tools, generate code and compose content. We use them inside systems with explicit contracts and responsibilities.

Foundation models

We work with linguistic, multimodal and specialised models according to quality, language, context, reasoning, tool use, structured generation, cost, latency, privacy, deployment capability and provider stability.

The architecture makes it possible to compare and route models. A task can use a different model for analysis, programming, generation, extraction or review.

Agents

Agents interpret context and choose between permitted actions. We build with typed tools, bounded memory, state graphs, policies, budgets, stopping criteria, human intervention, traces and evaluation of journeys.

MCP and FastMCP

Model Context Protocol makes it possible to expose tools and resources through common contracts for agents and applications.

FastMCP makes it easier to build MCP servers, clients and applications in Python, with schemas, validation, transport and integration mechanisms.

We use it when it provides a coherent interface between agents, knowledge and systems. Business permissions and effects continue to reside in the architecture of the application.

LangGraph and PydanticAI

LangGraph makes it possible to represent agents and flows as graphs with state. PydanticAI contributes typed models of inputs, outputs, dependencies and tools within the Python ecosystem.

The choice depends on the kind of control, durability, integration and evaluation each journey needs.

Durable workflows

Hatchet and other durable execution engines preserve state and resume work after waits or failures. We combine them with agents when an operation needs contextual interpretation and continuity over time.

DSPy and GEPA

DSPy makes it possible to treat parts of an AI system as programs that can be defined and optimised through evaluations. GEPA explores the improvement of programs, prompts and strategies from performance signals.

These techniques are valuable when a sufficiently representative evaluation set exists. The definition of what a good result means remains in the hands of people.

Structured outputs and contracts

We use schemas and validation so that models and agents produce objects the software can check before using. Pydantic, JSON Schema, validators and deterministic tests help to separate flexible language from controlled effects.

RAG, memory and knowledge systems

A RAG system relates retrieval, context, evidence, permissions and composition in order to answer in an examinable way.

We build hybrid retrieval combining exact matching, lexical search, trigrams, embeddings, filters, relationships, graphs, code structure, reranking, context expansion, provenance and permissions.

PostgreSQL and pgvector

PostgreSQL offers the relational and transactional base. pgvector makes it possible to store and query embeddings within the same system, keeping metadata, permissions, states and relationships close by.

It can be combined with full-text search, indexes, SQL and structured filters to build hybrid retrieval.

Graphs and semantics

TypeDB and other knowledge-oriented databases are useful when the domain demands typed relationships, inference or complex navigation.

LinkML can define interoperable knowledge schemas and generate representations for different environments. Datalog makes it possible to express certain deductions. DMN helps to formalise decisions. CEL can be used for conditions and validations.

Code as knowledge

Tree-sitter, LSP and specialised analysers make it possible to retrieve symbols, relationships, calls, inheritance, references, tests and dependencies.

Code retrieval combines semantics and structure: answering which component calls another, or which test protects a rule, demands navigating that structure.

Embeddings and reranking

We evaluate embedding models and rerankers for text, conversations, documentation and code. The choice considers language, domain, length, cost, latency, stability, ability to contextualise and performance on real questions.

Embeddings form one route of retrieval. The answer preserves the link with the sources and with the structure that makes it possible to examine it.

Machine learning, forecasting and optimisation

We work with classical techniques and recent models.

Tabular data: CatBoost, LightGBM, XGBoost, scikit-learn, linear models, probabilistic models and ensembles. These tools remain competitive when the problem lives in tabular data and the decision needs speed, calibration or explainability.
Deep learning: PyTorch, architectures for text, vision and signals, multimodal models, adaptation and fine-tuning, representation learning.
Time series: We explore and evaluate families such as TimesFM, Chronos, MOIRAI, PatchTST, N-HiTS, Temporal Fusion Transformer and statistical and seasonal models. Each family is compared with baselines and under horizons, regimes and frequencies that correspond to the decision.
Optimisation: Mathematical programming, constraints, search, heuristics, simulation, multi-objective optimisation, predictive control, policy optimisation, resource allocation and sequence planning. Optimisation is connected with the operation through variables, limits and signals that the people in charge can discuss.

Python as the connecting language

Python makes it possible to connect research, AI, data, APIs, automation and robotics within a single ecosystem.

We use it for models, pipelines, agents, MCP tools, services, evaluation, simulation, vision, control and integration.

Responsibilities are separated through services, events, workers, contracts and appropriate storage, so that the system can grow without concentrating in a single process.

Django, FastAPI and enterprise software

Django: Provides a mature base for enterprise applications, administration, data models, identity, permissions and processes with a long life. We use it when the system needs a complete and maintainable application structure, with interfaces for teams, configuration and governance.
FastAPI: Is well suited to typed APIs, inference services, tools, integrations and low-latency components within the Python ecosystem. Pydantic helps to validate contracts and share schemas between inputs, models and outputs.
PostgreSQL: Works as a transactional and relational base and, through extensions, also a lexical and vector one. Its ability to bring together operational state, metadata, relationships and retrieval keeps the infrastructure proportionate to the problem.
Events and messaging: NATS and JetStream make it possible to distribute events, decouple components and preserve messages when an operation needs resumption and independent consumers. Events are designed as domain contracts.
Containers and deployment: Docker makes it possible to reproduce environments and separate services. Cloudflare, edge, GPU and local environments are used according to latency, data, cost and hardware dependency.
Web interfaces: Django, APIs and static generators such as Astro can be combined to create operational applications and fast websites, keeping content and behaviour in appropriate layers.

Evaluation, observability and security

A technology is adopted together with the way of examining it.

We build deterministic tests, model evaluations, adversarial sets, simulations, traces, metrics, cost comparisons, monitoring, version control, tool limits, permissions, recovery and stopping mechanisms.

Observability connects the output of a component with the state it received, the decision it took, the tool it used and the result that appeared afterwards.

In agent systems, we record journeys and policies. In machine learning, data, model, version and calibration. In physical systems, signals, estimated state, command, limits and observed effect.

Physical Intelligence, simulation and robotics

Our technological stance extends to systems that perceive, estimate, plan and act.

Newton: A GPU-accelerated, extensible physics simulation platform built on technologies such as NVIDIA Warp and OpenUSD. We use and evaluate it to represent geometry, dynamics, contacts, joints, materials and other phenomena that make it possible to test physical systems before taking them to the hardware.
NVIDIA Warp: Makes it possible to write GPU-accelerated kernels from Python and is especially useful for simulation, geometry and parallel computing.
cuRobo: Provides GPU-accelerated components for inverse kinematics, collision checking, trajectory generation and motion planning in manipulator robots. It can be used as an acceleration backend when the geometry and the task allow it; the final validation incorporates tolerances, load, tools, safety and the behaviour of the real equipment.
Predictive control and low-latency MPC: Predictive control uses a model of the system and optimises actions over a horizon while respecting constraints. We explore it for navigation, tracking, manipulation and physical coordination, where time, dynamics and limits have to be considered together.
Computer vision: OpenCV, detectors and vision models, AprilTag, calibration, pose estimation, signal fusion, GPU processing and vision at the edge.
Edge and GPU platforms: NVIDIA Jetson, CUDA, TensorRT where appropriate, GPU for perception, optimisation and simulation, and local execution for latency, continuity and safety.
Robotics and planning: Forward and inverse kinematics, geometric models, distance fields, collision detection, trajectory planning, control, navigation, state estimation, manipulation, telemetry, stop and recovery.

Simulation accelerates learning. The hardware determines the tolerances and conditions that finally matter.

Technology radar

The radar organises our technologies into four orbits — we build, we apply, we evaluate and laboratory — and shows families before names.

Some technologies already sustain systems in operation; others remain under evaluation or in the Laboratory. The state is reviewed internally and the public classification indicates which orbit each family is in.

What a client can expect

A technological conversation with 3.14 may reach models, graphs, APIs, GPU or robotics, but it starts from the capability and the result.

You can expect:

a reasoned recommendation;
comparison with simple alternatives;
prototypes that go through a complete case;
emerging technologies subjected to evaluation;
components of our own wherever they represent differential knowledge;
integration with the existing landscape;
an architecture that makes it possible to change models and providers;
observability;
clarity about maturity and limits;
enough transfer to carry on.

Closing

Our technological stance consists of extending capabilities without losing the architecture that turns them into systems. We explore early, build where the differential knowledge resides and take each technology to the level of integration and evaluation that its responsibility demands.

How we choose a technology

01function: what responsibility it fulfils and what alternative exists
02quality: how it behaves in real, adverse and out-of-distribution cases
03integration: how it connects with data, identity, permissions, workflows and existing systems
04cost: infrastructure, model usage, development, observability and maintenance
05latency: the total time of the journey, not just the speed of the component
06control: the ability to limit tools, review results and stop effects
07portability: which parts can be replaced and what knowledge stays coupled
08maintainability: how it is debugged, versioned, documented and transferred
09maturity: what has been explored, evaluated, integrated or operated
10result: what observable change it makes it possible to produce

Technologies we build, apply and evaluate

Select a family to see its technologies.

See all the technologies

We build

Layers of our own: DocuLogic · KIR · ERP-Bots · SuperSocrates · SuperQuestions · SuperPythagoras · Finaz · Excorpora · evaluations and contracts of our own · domain representations

We apply

Foundations in operation: Python · Django · FastAPI · Pydantic · PostgreSQL · pgvector · PyTorch · CatBoost · APIs and events · Docker · hybrid search · durable workflows · models and agents with tools

We evaluate

Under active evaluation: LangGraph · PydanticAI · FastMCP and MCP · Hatchet · DSPy · GEPA · TypeDB · LinkML · recent time-series models · specialised embeddings and rerankers · model routing · multi-index memory · Newton · cuRobo · GPU-accelerated optimisation

Laboratory

Laboratory: complex multi-agent systems · operational learning · simulation and transfer to hardware · low-latency MPC · physical planning and control · bounded autonomy · machine coordination · world models and VLA within defined tasks