🐳 AI Tinkerers Paris Agentic Workflows with Docker - towards autonomous, secure and orchestrated systems

on April 22, 2026

During this meetup organized by GitGuardian and sponsored by Docker, several speakers shared their vision of modern agentic systems.

The goal is clear: to move from simple AI assistants to true autonomous agents capable of acting, collaborating and executing in production.

🎤 Introduction - Security & Context (GitGuardian)

The evening begins in the Paris offices of GitGuardian, which reminds us of a point often underestimated in discussions around AI agents: before even talking about autonomy, we must talk about access security.

The message is simple. Secrets are everywhere: API keys, JWTs, tokens, credentials, or any information capable of granting access to a resource, service, or infrastructure. In a context where agents increasingly interact with code, repositories, collaborative tools, or connected systems, the detection and control of these secrets becomes a critical layer.

GitGuardian is positioned precisely in this area: helping developers, security teams and infrastructure profiles to identify exposed secrets in their environments, whether it be Git repositories, collaborative platforms like Slack or other surfaces where sensitive information may leak.

Another interesting signal emerges from this introduction: agent security is no longer a theoretical subject. It is becoming a concrete market need, to the point of accompanying a phase of active growth at GitGuardian, which indicates it is recruiting for several profiles, including software engineers and AI engineers.

👉 Key point:

Agents should never expose sensitive secrets without strict controls.

🥽 Speakers

The quality of this evening also stems from its lineup. Rather than presenting purely theoretical profiles, the event brought together speakers directly involved in building tools, runtimes and infrastructures related to agentic workflows.

Sébastien Blanc - making agents truly deployable

Sébastien Blanc, Technical Director at Sciam, presented SAIL: Serverless Agentic Containers, a distributed execution-oriented approach where agents are no longer conceived as simple local assistants, but as workloads capable of running in a serverless environment. His presentation naturally extends the discussions on Kubernetes, Knative, and event-driven architectures, with a fundamental question: how to build robust, scalable, and resource-efficient agentic systems?

Philippe Charrière - exploring the limits and potential of tiny LLMs

Philippe Charrière, Principal Solutions Architect at Docker, presented a session entitled Compose and Dragons: Tiny LLMs, undoubtedly one of the most experimental of the evening. His approach was particularly interesting: demonstrating that small, local models are not merely technical curiosities, but can serve as the foundation for multi-agent systems, provided their memory, performance, and orchestration constraints are accepted. His work highlights a possible future where agents rely not only on large, remote models, but also on local, specialized, and composable building blocks.

David Gageot - simplifying agent creation

David Gageot, Senior Principal Software Engineer at Docker, spoke on Docker Agent: No-Code AI Agents. His presentation focused on radical simplification: reducing the friction between the idea of an agent and its concrete implementation. The value of his presentation lies not only in the "no-code" aspect, but also in the ability to make agents more accessible, more declarative, and easier to integrate into real-world workflows.

Guillaume Lours - securing autonomy

Guillaume Lours, Staff Software Engineer at Docker, presented Docker Sandboxes, probably one of the most strategic topics of the evening. While many discussions around agents focus on models or prompts, his presentation puts the runtime back at the center: if an agent is to act, it must be isolated, observable, and governable. Docker sandboxes provide a very concrete solution to questions of secure execution, network permissions, secrets, and access control.

Djordje Lukic - think of the agent as a system, not as a gadget

Djordje Lukic, Principal Software Engineer at Docker, shares a presentation on Docker Agent with David Gageot. His contribution is significant as he situates the topic within a broader discussion on agentic frameworks. Beyond the promise of “easy-to-create” agents, there is a more structural ambition: to provide a framework where models, tools, instructions, and orchestration can be neatly assembled, with a true engineering logic behind them.

🧠 David Gageot - Djordje Lukic - Docker Agents - from assistant to true agent runtime

The Docker segment opens with Georgi and his team, who present Docker Agent not as just another assistant, but as what they themselves call a “Swiss Army Knife” of agentic frameworks. The idea is quite clear: to move beyond the ad-hoc use of the model and into a logic where AI becomes a fully-fledged execution component. Their starting point is not theoretical. They explain that Docker has been working on these topics for nearly two years, particularly around Gordon, the assistant integrated into Docker Desktop, and that Docker Agents is now used internally to build and evolve its own tools.

What immediately stands out is the desire to make agents configurable, composable, and usable in real-world conditions. Docker Agents can connect to various models, local or remote, integrate with diverse tools, and, most importantly, be described very lightweightly in YAML, without systematically requiring a complex implementation. This is one of the demo's strongest messages: getting started with agentics doesn't necessarily begin with a cumbersome SDK or a distributed architecture, but sometimes with a simple, clear declarative definition that produces useful behavior.

The first demonstration deliberately plays on something absurd—a hacker agent—to show how low the barrier to entry is. With a template and an instruction, the team already has an exploitable agent. The demonstration is lighthearted, almost mocking, but the subtext is important: an agent doesn't need a huge infrastructure to exist; it primarily needs a clear execution framework. From there, Docker can scale it into something much more serious.

This is precisely what happens in the second part, which is much more technically compelling. The team demonstrates how to connect an existing API to an agent using its OpenAPI definition. In their example, it's a Pokémon API—used as a deliberately playful substitute for a more traditional business API—but the message is clear: in a corporate environment, it would be possible to use the exact same mechanism to connect internal services, knowledge bases, or specialized tools. The OpenAPI specification is transformed into a set of tools, and the agent can then query the system without the user having to directly manipulate the endpoints. It's no longer the human navigating the API; the agent handles the mediation.

The demo also highlights an often underestimated architectural point: the question isn't just about giving an agent tools, but about giving it the right tools. During the Q&A session, the team acknowledged that an overloaded agent quickly becomes ineffective. Even if an OpenAPI specification can expose dozens or even hundreds of tools, it's better to filter them heavily and keep only a subset that's relevant to the task. The key idea here isn't "more tools = better agent," but almost the opposite: a specialized agent works best with a limited, readable, and intentionally defined scope.

The most interesting part comes next with the more advanced use cases. Docker Agents isn't limited to a single-agent approach handling a few API calls. The team demonstrates a multi-layered system, with a main agent, dedicated commands, and then sub-agents, each with its own role, instructions, model, and potentially its own tools. The interactive quiz and the Pokémon battle simulation primarily serve to illustrate a broader idea: useful agentics relies less on a single “super-agent” than on an orchestration of clearly separated responsibilities. The root agent coordinates, the sub-agents execute, and each operates within a more clearly defined context.

The answers provided during the Q&A session reinforce this point. Docker distinguishes, in particular, two forms of inter-agent interaction: on the one hand, sub-agents, which receive a task with a new context; on the other hand, handoff mechanisms, where the conversation can switch from one agent to another. The team also mentions the possibility of sharing certain memory or to-do tools between several agents. Here again, we find a structuring idea: agentics becomes interesting when it ceases to be solely conversational and becomes organizational. We are no longer simply asking a model to respond; we are distributing work among several specialized entities.

🔐 Guillaume Lours - Docker Sandboxes - giving autonomy without relinquishing control

The second part perfectly complements the first. After demonstrating how to build agents, the Docker team poses the real question: where and how should they operate? This is where the demonstration of Docker Sandboxes comes in. The initial observation is very concrete: as long as an agent needs to read files, install dependencies, run commands, or access the network, it becomes impossible to run it reliably directly on the host machine without accepting an excessively high level of risk. The presenter states it very clearly: granting this level of access to an agent on your laptop is out of the question.

Docker's proposed solution is an isolated execution environment in the form of a micro-VM, containing its own Docker engine, within which runs a container hosting the agent. This represents a significant shift in perspective. The challenge is not simply to "restrict" the agent, but to create a framework that, on the contrary, grants it greater autonomy, while still allowing the ability to observe, filter, and interrupt its actions. The goal, therefore, is not to render the agent harmless by blocking it entirely, but to give it enough freedom to truly function within clearly defined boundaries.

The demonstration is compelling: in a simple web project, the agent can independently install the necessary dependencies, launch build commands, and execute tests, even when this involves operations that one wouldn't readily accept on their personal machine. The key advantage isn't just technical isolation; it's also visibility. Sandboxes expose an interface that allows users to list running environments, inspect active processes, observe network traffic generated by the agent, and, more broadly, understand what it's actually doing. Therefore, delegation isn't blind; it's delegation within an instrumented environment.

Network management is probably the most compelling aspect of this section. Docker demonstrates several network policy modes, ranging from outright denial to a much more permissive openness, with a balanced intermediate option. Crucially, the interest lies not so much in the names of the modes as in the granularity they subsequently enable. Blocked access can be visualized in the sandbox's network logs and then explicitly granted. This transforms the agent's network behavior into an observable and adjustable policy, rather than a global permission granted once and for all. In other words, access to the web or a specific domain is no longer based on implicit trust, but on an explicit decision.

The same logic applies to secrets. Here too, Docker takes an interesting approach: secrets are not simply “visible” in the agent's environment as they would be on a misconfigured machine. They are injected when the sandbox is created, with a global or specific scope depending on the need. This detail is truly important in production: it means that an agent should not inherit everything on the development machine by default. It only operates with what has been provided to it in its controlled environment. In practice, this makes secrets an explicitly provisioned resource, and not a side effect of the user session.

The port exposure demo illustrates this point. An application can run in the sandbox without being immediately visible from the outside. To access it, the relevant port must be published; if it's removed, the application continues to exist in its isolated environment but becomes inaccessible from the outside. Here again, Docker demonstrates a clear separation between execution and exposure, which is precisely what's missing in many overly hasty agentic demos.

Finally, the demonstration concludes with a particularly interesting case for modern workflows: multiple agents working on the same source code, but without interfering with each other. The proposed approach relies on the automatic creation of separate branches or worktrees, so that each agent can operate in its own workspace. This part is important because it shows that Docker doesn't just think of the agent as an individual assistant, but also as a parallel actor in a collaborative development flow. The agent is no longer just there to respond, but to take over part of the work in a controlled, isolated, and potentially concurrent space.

The implicit conclusion of this sequence is undoubtedly the most useful of the entire evening:

The real issue is not preventing agents from acting, but building the environment in which they can act properly.

In other words, useful autonomy doesn't stem from blind trust, but from a well-designed runtime: isolation, granular network policies, controlled injection of secrets, observability, and separation of workspaces. This is probably where Docker's approach becomes most compelling for stacks like Darkwood, Flow, or any architecture seeking to move agents from the "demo" stage to the "system" stage.

🧠 Philippe Charrière - Local models, between promise and memory pressure

With Philippe Charrière's presentation, the evening shifted its focus from agentic frameworks to something much more concrete: the actual cost of running a model locally. His presentation had the merit of bringing the topic back down to the level of the machine, RAM, and technical trade-offs. Behind the enthusiasm surrounding "small models," his observation was simple: yes, local models are interesting, but as soon as you want to do more than a minimal demo, the dominant constraint immediately becomes that of resources, especially on Macs.

The main point of friction, in his experience, isn't so much Docker itself as the memory pressure generated by the templates. On his machine—a MacBook Pro M2 Max with 32 GB of RAM—a template might seem to "hold up" in theory, then become unusable in practice as soon as it's actually queried. Philippe emphasizes an important detail: a compatibility estimate isn't always a guarantee of comfortable use. A template might start, respond once, then quickly degrade the machine as soon as the load increases. And if you add a second, different template, or simply more requests, the situation deteriorates even faster. His real-world experience is almost brutally simple: for a long time, what he thought was a Docker problem was actually a memory issue.

His demonstration was based on a relatively straightforward stack: Docker Model Runner, Docker Compose, and a set of local models used as building blocks for a larger system. During the Q&A session, he explained that Docker Model Runner currently relies on engines like llama.cpp and vLLM, with the possibility of future integration with MLX. He also clearly distinguished between different use cases: vLLM seemed better suited for production, while llama.cpp remained more relevant for local or experimental use. Again, the key point is not to promote a single, overarching backend, but to recognize that the model runtime is itself an architectural issue.

But the presentation isn't just a simple warning about RAM. Philippe also demonstrates what can be built despite these constraints, provided one is willing to work with small, specialized, and local models. His example takes the form of a text-based game project, a kind of dungeon crawler orchestrated by several components. This choice might seem playful, but it primarily serves to showcase an interesting architecture: an MCP server to manage the dungeon, rooms, monsters, and rules; a Dungeon Master as the main agent; several NPC agents exposing their own APIs; and a final boss that also functions as a fully autonomous entity. This is no longer a simple prompting demo, but an attempt at multi-component simulation, where each role has its own scope of action.

What makes this section particularly useful is that it shows that local models aren't just a matter of cost or sovereignty. They imply a different way of thinking about the system. Philippe explains, for example, that he reuses the same model for multiple agents to avoid memory overload, rather than multiplying heterogeneous instances. This approach is important: in a constrained environment, good design doesn't necessarily consist of choosing the best model for each agent, but sometimes of designing the entire workflow around an acceptable hardware compromise. The system must then be designed based on the available machine, not just the ideal functionality.

His “Compose and Dragons” project perfectly illustrates this logic. The dungeon map is generated in advance, and other components then enrich the experience with descriptions, NPCs, and interactions. All of this relies on an orchestration combining local models, Docker services, and specialized agents. It's not yet a demonstration of industrial robustness, but it's an interesting proof of concept: even with limited resources, it's possible to create a relatively rich, autonomous system, provided you accept its limitations in latency, memory, and complexity. Philippe himself states this frankly during the demo: on small models, some interactions remain slow, some transitions fail, and the system still requires adjustments. This is precisely what makes the feedback credible.

Finally, a more subtle but very useful point emerged at the end of the discussion: this local architecture can also be combined with Docker sandboxes, provided that the correct ports are explicitly opened to connect to the model runner from the isolated environment. Here again, we find the central theme of the entire evening: agents, models, and tools are only as good as the runtime that connects them correctly. Local models are therefore not a “simple” alternative to the cloud; they simply shift the problem to another level, where a trade-off must be made between autonomy, performance, memory, and execution architecture.

In summary, Philippe Charrière's demonstration reminds us of one essential thing:

Local models are useful, but they do not eliminate complexity; they simply make it more visible.

☸️ Sébastien Blanc - Production Agents - Kubernetes & Knative

The latest intervention clearly shifts towards a production-ready approach. After agents, models, and sandboxes, the question becomes simple:

Where and how can these systems be scaled up?

The proposed answer is straightforward: Java + Kubernetes + Knative.

🚀 A deliberate stack

The choice is deliberately clear-cut:

Java (Quarkus) for the application layer
Docker for packaging
Kubernetes as the primary runtime
Knative to introduce serverless

A clear stance is even taken during the talk:

Agent workflows will become industrialized, and Kubernetes will remain their operating system.

🔥 From local demo to production

The demonstration follows a very concrete, almost pedagogical path:

Creation of a local chatbot connected to a model via Docker Model Runner
Exposure via a simple HTTP API
Containerization of the application
Deployment on Kubernetes
Execution in a pod… capable of interacting with the local model

👉 Interesting point: the model remains accessible via an OpenAI compatible API, which allows reuse of any existing library without heavy adaptation.

⚡ Knative - the real game changer

Once the application is deployed on Kubernetes, switching to Knative completely changes the execution model.

Instead of managing continuous pods, we're switching to a native Kubernetes serverless model:

no traffic → 0 pods
Incoming request → Automatic creation of a pod
peak load → massive auto-scaling
End of activity → return to zero

👉 Simple but effective demonstration:

a curl → triggers the creation of a pod The request has been processed.
A few seconds later → the pod disappears

We no longer manage machines, but only on-demand workloads.

🧠 The real problem: the agents' memory

This model immediately raises a critical question:

What happens to memory when everything scales to zero?

The proposed solution is pragmatic:

make agents stateless
externalize the state into a dedicated system

👉 Solution used:

Redis as shared memory
Storing the state of conversations/agents outside of pods

Result :

Agents can be recreated on the fly
Memory persists independently of the infrastructure
The system remains compatible with Knative's aggressive scaling

🧩 Towards distributed agentic systems

The conclusion opens up an interesting direction:

Agent deployment via Kubernetes CRDs
communication between agents
large-scale orchestration
Triggering via events (Kafka, HTTP…)

👉 In just a few lines of YAML, you can:

Deploy multiple agents
to make them communicate
manage their lifecycle automatically

💡 Takeaway

This section completely changes perspective:

An agent is no longer a script or a local tool.

It is a distributed, ephemeral computing unit, orchestrated by Kubernetes.

And with Knative + Redis, we obtain an architecture where:

the execution is flexible
the state is outsourced
and agents become truly scalable in production

🧭 Global vision

The talks are converging in the same direction:

🔁 Before

LLM = assistant
occasional use

🚀 Now

autonomous agents
multi-agent
orchestration
actual execution

🧩 The key building blocks

| Domain | Solution | | ------------- | -------------------- | | Agents | Docker Agents | | Security | Docker Sandbox | | Models | Docker Model Runner | | Orchestration | YAML / multi-agent | | Infra | Kubernetes / Knative | | Memory | Repeat |

🎯 Conclusion

The real issue is not limiting the number of agents, but:

give them maximum autonomy within a strictly controlled framework

Key concepts:

sandboxing
network policies
secure injection of secrets
multi-agent orchestration
infra scalable

🚀 Takeaway

We move from:

👉 “I ask an AI” has 👉 “I delegate to an autonomous system”