AI applications need a data layer that combines structured, unstructured, and semistructured data, links entities across RAG and memory, and distinguishes first-party data from derived data.
2
MCP is becoming a shared tool layer for AI applications, but production use depends on dynamic discovery, remote servers, OAuth, registries, packaging, and security controls.
3
Specialized models and open weights are making agents, image generation, local inference, and real-time voice systems cheaper and easier to deploy.
Summary
Day two of AI Engineer Paris 2025 covers the infrastructure and model techniques behind current AI applications. Emil Eifrem argues that AI systems need a unified data layer for structured, unstructured, and semistructured information, with entity extraction, cross-source links, and a way to separate owned data from derived RAG data. Docker and GitHub speakers discuss MCP packaging, catalogs, dynamic tool discovery, remote servers, OAuth, and the problems of local installation. Yann Leger explains why agent workloads need fast, isolated sandboxes and scale-to-zero infrastructure. Andreas Blattmann describes Flux's latent flow matching, image editing, and distillation methods. Other talks cover computer-use agents, open LLM deployment, system prompt learning, sparse attention on CPUs, NotebookLM-style workflows, multimodal Google models, and Kyutai's full-duplex voice systems. Across the day, the speakers favor open interfaces, specialized components, and infrastructure that can handle high-volume, short-lived workloads.
AI application state comes from RAG data, agent memory, and application data
Emil Eifrem frames context engineering as filling the context window with the right information for the next step. He separates AI application state into three sources: the RAG corpus, agentic memory, and the application's own state. He describes the movement from conventional applications with structured databases and object storage, through chatbots backed by vector databases, toward agent-based applications that use tools, memory, and several models. His concern is that the data layer has become fragmented, with vector, relational, document, and graph databases each adding capabilities from the others.
A useful AI data layer must combine data types and extract entities from unstructured text
Eifrem proposes four properties for an AI data layer. First, it should store and retrieve structured, unstructured, and semistructured data in one place. Second, it should consistently extract entities from unstructured data. He uses named entity recognition to identify people and concepts, followed by entity resolution to decide that references such as 'Andreas', 'he', and 'ABK' refer to one person. This extraction bridges raw text and typed application objects. His Neo4j demonstration uploads a Wikipedia page about Paris, preserves the raw chunks, and displays automatically extracted entities such as locations and notable people.
Linking entities in the data layer avoids repeated joins across memory and RAG retrieval
Using an online furniture shop as an example, Eifrem shows how a product database, assembly guides, issue reports, community posts, and agent memory may all refer to the same table. One option is to retrieve from each source and join results in the application. He prefers linking the entities in a unified data layer. Multiple retrievals can add latency, require intermediary results, and force application code to reimplement joins. A shared layer also makes changes easier to propagate. If a product name changes, linked data can update across the application instead of requiring text searches over every source.
Agents need standard packaging, trusted catalogs, and containerized MCP servers
Tushar Jain presents agents as a shift similar to the move from monoliths to microservices. Containers remain useful, but developers need packaging that describes an agent's tools, configuration, dependencies, and runtime. Docker is exploring an agent file and has open-sourced Cagent, which packages agents as OCI artifacts for registries and Docker Hub. For MCP, Jain argues that developers need trusted discovery, containerized local servers, security against threats such as rug pulls, and simple client configuration. Docker's MCP catalog and Desktop toolkit let users discover servers, configure them once, and connect them to clients such as Claude Desktop.
MCP production systems need dynamic discovery, remote servers, OAuth, and decentralized registries
Martin Woodward describes MCP as more than tool calling. The protocol also includes resources, prompts, sampling, roots, elicitation, and dynamic discovery. GitHub found that exposing too many tools can confuse models and reduce coding performance, so servers should add and remove tools as the conversation changes. Local installations are convenient for development but hard to upgrade and support across operating systems. Remote MCP servers scale and can be updated centrally. Woodward calls password and personal-access-token authentication an anti-pattern for remote services, and points to OAuth with short-lived tokens. He also supports an open registry ecosystem with company and organizational registries instead of one monopoly.
Agent infrastructure must start isolated code quickly and scale idle workloads to zero
Yann Leger focuses on the infrastructure consequences of agents running model-generated, untrusted code. He identifies secure sandboxes, fast startup, ephemeral execution, high volume, and efficient deployment as requirements. Koyeb's approach uses virtualization to isolate containers and supports CPU, GPU, and accelerator workloads. Networking became a major startup bottleneck as customers began creating thousands of containers per day. Leger describes prestarted machines, cached images, network optimizations, autoscaling, and memory snapshots. The snapshots let an idle virtual machine sleep and resume in roughly hundreds of milliseconds, reducing the cost of services that users create but rarely access.
Flux combines text-to-image generation and image editing through latent flow matching
Andreas Blattmann explains Flux as a family with API-only Pro models, downloadable Dev open weights, and the lightweight open Flux Schnell model. Flux Kontext combines text-to-image generation with instruction-based image editing in one model. The same system can preserve a character, transfer a style, change text, remove objects, or transform a sketch into a render. The model works in a latent space learned by an autoencoder, where perceptually unimportant image details are discarded. Flow matching then learns a vector field from a simple distribution to the image distribution. A context image is added as another token sequence, so removing it switches the model back to text-to-image generation.
Open models are easier to deploy and are closing the gap with proprietary models
Vaibhav Srivastav describes three ways to use open LLMs: serverless APIs, managed deployments, and self-hosting. Serverless providers offer a familiar chat-completions interface. Managed services package model weights behind a deployed endpoint. Self-hosting gives teams control over prompts, outputs, infrastructure, and data. He argues that model weights give developers more provider choice and a fallback when a hosted service has problems. He points to reasoning models, longer context windows, falling inference costs, standard chat templates, and native low-bit quantization as major improvements. Proprietary models still tend to lead in general reasoning, multimodal interaction, voice, and safety scaffolding.
System prompts can learn from annotated production failures
Aparna Dhinakaran presents system prompt learning as a way for agents to improve their instructions from experience. Instead of using only a scalar reward, the method feeds a meta-prompt the original system prompt, the task, the agent's output, and an explanation of what went wrong. The meta-prompt generates revised rules. In experiments with the open-source coding agent Cline on SWE-bench Lite, the system prompt started with an empty rules section. After several update loops, the rules addressed recurring mistakes such as making a narrow fix without checking all valid input types. Dhinakaran says teams should collect traces, categorize errors, and use production evaluations to guide prompt iteration while testing for overfitting.
"Context engineering is the delicate artisan science of filling the context window with just the right information for the next step."22:53
Who should watch
You are building an agent that needs durable memory, RAG, structured application state, or links across several data sources.
Your team is exposing tools through MCP and needs practical guidance on packaging, discovery, authentication, remote hosting, or sandboxing.
You want to compare open and proprietary models, or you are working on image generation, computer use, local inference, multimodal apps, or real-time voice.
