Conference talk by Bilge Yücel (deepset GmbH) on building AI systems under sovereignty constraints. Covers four sovereignty pillars — data, model, infrastructure, and operations — and what breaks when retrofitting each: re-evaluating performance after swapping a frontier API for a self-hosted model, managing databases across jurisdictions when moving private data, and uncovering vendor lock-in when moving on-prem. Closes with a three-question checklist: can you swap models without changing application logic, are run logs reproducible and stored in a compliant location, and can your team handle incidents without contacting a hyperscaler. # Channel Identity Observations: "What Breaks When You Build AI Under Sovereignty Constraints" ## Speaker & Affiliation - The speaker introduces themselves as **"Viguen"** (title says **Bilge Yücel**), working as a **"senior developer relations engineer at Deepset."** - The talk is a **conference session** ("Thank you for joining this session," references to "you are here in the conference this week"). ## Explicit Self-Description (Creator Claims) - **Company framing:** "Deepset is the company behind the open source orchestration framework called Haystack. We also have our enterprise platform." - **Claimed customer scope:** "solving customer AI challenges for big organizations like Airbus, Bosch, Siemens, but also public sector organizations like European Commission, Federal Ministry of Research and Technology... and other ministries." - **Claimed relevance of topic:** "you can imagine sovereignty is a very big and important topic for us." - **Product capability claims for Haystack:** consistent interface for cloud-to-self-hosted transitions, "explicit data flow," YAML serialization for versioning, "truly open source... no black box," OpenTelemetry integration, swappable components "without vendor lock-in." - **Self-aware product promotion:** "I want to shamelessly plug Haystack because a good orchestration framework I think solves some of these problems." ## Intended Audience - **Engineers, explicitly:** "But we are all engineers here. We are not policy makers, we are not lawyers." - **Practitioners facing organizational mandates:** a scenario is addressed to developers whose "manager or CIO comes and says... now we need to make it sovereign." - **High-stakes domain workers** are called out: "if you are in finance, in healthcare, in high-stakes domains, you might need a fully air-gapped solution." ## Claimed Scope of Content - **Topic:** sovereign AI, defined as "the ability of an organization to design, deploy, and operate AI systems on its own terms," translated into "explicit control over data flow, model choice, infrastructure, observability, and operations." - **Structural scope:** four pillars — data, model, infrastructure, and operational sovereignty — plus a "what breaks" migration analysis and a live architecture/code walkthrough. ## Observable Presentation Patterns (Demonstrated) - **Hands-on technical depth:** walks through guardrail code, MCP tool sets, BM25 dynamic tool search, agent confirmation strategies, and pipeline assembly in concrete detail. - **Vendor-landscape neutrality within a product pitch:** names Mistral, Google, Nvidia, Jina as local-model options alongside the Deepset pitch. - **Audience interactivity:** opens with a show-of-hands question ("How many of you are familiar with the term of sovereignty?"). - **Practical takeaway framing:** closes with a self-audit checklist ("Can you swap models without changing the application logic?... Can your team respond to an incident without calling a vendor?"). - **Relationship-building close:** invites follow-up via a form and social media — "happy to talk to you about agents, Haystack, and especially in a sovereign setting." ## Notable Ambiguity - Speaker name mismatch: transcript self-introduction ("my name is Viguen") vs. title attribution ("Bilge Yücel") — possibly a co-presenter or transcript/introduction artifact; cannot be resolved from the source alone. # Delivery Observations — Bilge Yücel, "What Breaks When You Build AI Under Sovereignty Constraints" ## Overall Tone & Register - **Conversational, engineer-to-engineer tone**: The speaker explicitly positions herself with the audience: *"But we are all engineers here. We are not policy makers, we are not lawyers."* - **Friendly, low-pressure opening**: She starts with a sound check and audience interaction — *"Can you all hear me well? All right, amazing."* — and quickly polls the room: *"how many of you are familiar with the term of sovereignty? Wow, okay, amazing."* - **Self-aware humor**: *"I want to hear shamelessly plug Haystack"* (apparent transcript artifact of *"I want to shamelessly plug Haystack"*) — a candid acknowledgment of the promotional segment. ## Vocabulary & Framing Habits - **Policy-to-engineering translation**: She repeatedly converts abstract policy language into concrete technical terms, e.g., turning a policy definition into *"having explicit control over data flow, model choice, infrastructure, observability, and operations."* - **Regulatory vocabulary used naturally**: GDPR, EU AI Act, Cloud Act, air-gapped environments, VPC, vendor lock-in. - **Concrete named examples**: Real organizations (*"Airbus, Bosch, Siemens"*) and jurisdictions (*"an embedding API hosted in Virginia in the US"*) anchor abstract points. - **Relatable hypotheticals**: She frames problems as second-person scenarios — *"your manager or CIO comes and says like, 'Okay... now we need to make it sovereign.'"* ## Teaching Habits & Structure - **Pillar-based decomposition**: Core content is organized into four explicit pillars — *"data sovereignty... model sovereignty... infrastructure sovereignty... operational sovereignty"* — each introduced with a defining question (e.g., *"where does compute happen?"*). - **"What breaks" pedagogy**: After the conceptual section, she shifts to failure modes: *"what you do first usually and what you break in this existing system."* - **Rhetorical questions as transitions**: Frequent self-questioning moves the talk forward: *"What does it mean?"*, *"So how do you handle search?"*, *"who can update it?"* - **Checklist close**: Ends with a practical self-assessment — *"can you swap models without changing the application logic?"* — converting the talk into actionable takeaways. ## Recurring Phrases & Verbal Patterns - **"So" as a connective**: Extremely frequent clause opener — *"So, it's about where you store your data"*, *"So, where does compute happen?"*, *"So the first thing is..."* - **Hedged qualifiers**: *"kind of"*, *"basically"*, *"maybe"*, *"like"* appear throughout: *"sovereign cloud, this kind of depends on the provider"*, *"it's basically having explicit control."* - **Reassuring refrains**: - *"sovereignty is a spectrum"* — used to soften the strictness of the requirements. - *"vendor lock-in"* recurs as a unifying threat concept. - **Repeated "amazing"**: Used at the start for audience response (*"Wow, okay, amazing"*, *"All right, amazing"*) — appears only in the opening, so it's a limited pattern. ## Communication Patterns - ** concession-then-pitch structure**: Before promoting Haystack she limits the claim honestly: *"I mean, good orchestration cannot solve your GPU limitation, but can help you with so many different stuff."* - **Enumerated feature walkthroughs**: Both the pillars and the Haystack features (*"consistent interface"*, *"explicit data flow"*, *"YAML"*, *"truly open source"*) are delivered as numbered lists. - **Code walkthrough in plain language**: The guardrail demo is narrated step by step in accessible terms — *"You just start with a model provider... You give the name of the model..."* - **Stuttered restarts and filled pauses** (*"Uh"*, *"um"*, repeated words like *"the the duty of Haystack"*) suggest an unscripted or semi-scripted live delivery, though they do not impede clarity. ## Uncertainty Notes - Timestamps are unavailable beyond bracketed line numbers; no pause lengths or emphasis data exist, so **pacing and vocal emphasis cannot be assessed**. - Transcript likely contains artifacts (e.g., *"I want to hear shamelessly plug"*, *"modern sovereignty"* for "model sovereignty", *"max control"* possibly "max[imum] control"), so **some quotes may not reflect exact spoken words**. - Audience reaction beyond the two noted moments is not observable, so engagement patterns beyond the opening cannot be claimed. # Position Record: "What Breaks When You Build AI Under Sovereignty Constraints" — Bilge Yücel, deepset GmbH ## Speaker - **Bilge Yücel** (transcript self-introduces as "Viguen"), Senior Developer Relations Engineer at **deepset**. Note: transcript audio rendering of the name differs from the title metadata; both refer to the same speaker. ## Context / Positioning Claims - deepset builds the open-source orchestration framework **Haystack** and an enterprise platform, serving customers including Airbus, Bosch, Siemens, and public-sector bodies (European Commission, German Federal Ministry of Research and Technology, and other ministries). Claim: sovereignty is therefore "a very big and important topic" for the company. ## Core Definitions (as stated) - **Policy definition:** Sovereign AI is "the ability of an organization to design, deploy, and operate AI systems on its own terms." - **Technical definition (speaker's translation for engineers):** "explicit control over data flow, model choice, infrastructure, observability, and operations." ## Four Pillars Framework ### 1. Data Sovereignty - Data should be stored and processed within trusted jurisdictions for compliance. - Example: GDPR implies EU citizen data stays in Europe; sending data to a US-hosted embedding API is "already losing the control of your data." - **Access permissions** count too: internal users seeing data they shouldn't is a breach of data sovereignty. ### 2. Infrastructure Sovereignty - Where the application layer (RAG pipelines, agents, tools) runs determines sovereignty. - Spectrum from **max control to max convenience**: - Air-gapped → "EU AI Act safe" - Private VPC → GDPR safety - Sovereign cloud → depends on provider - SaaS → **Cloud Act risk**: a US-headquartered provider may access running data even if everything runs in Europe. ### 3. Model Sovereignty - **Freedom to choose and switch models**: tight coupling to one provider means API downtime and price increases hit you directly. - **Swappability without architectural changes**: even if other models are technically usable, slow code changes undermine sovereignty. - **Training data origin**: speaker flags this as "a bit controversial" — no reliable way to know training data provenance; stated position: European model providers have "a better advantage" than US-based ones. ### 4. Operational Sovereignty - Monitoring system behavior in production, including model inputs/outputs. - High-stake environments (HR, finance) require **human-in-the-loop**. - Controlled, auditable versioning and updates of models and application layer. ## Key Qualification: Sovereignty Is a Spectrum - Not everyone needs full sovereignty across all pillars; finance/healthcare may need fully air-gapped solutions, while other enterprises/startups may not. - The essential requirement: "you need to know the level of control... the level of vendor lock-in you have." ## What Breaks When Retrofitting Sovereignty - **Replacing frontier API with self-hosted model**: translating API logic, updating prompts, re-evaluating performance from scratch, writing lots of code. - **Moving private data into jurisdiction**: managing multiple databases/instances; search becomes problematic (query classification vs. federating requests). - **Replacing managed infra with on-prem**: you feel the vendor lock-in — Kubernetes management, CPU/GPU connection and network management. - **Adding observability/tracing**: you discover a "fully black box" system; logging and version control become new problems. Speaker's aside: lacking observability until this point "is an important issue already." ## Haystack as Solution (self-described "shameless plug") - **Consistent interface**: cloud-to-self-hosted transitions with "couple lines of code." - **Explicit data flow**: typed, declared inputs/outputs; tool calls/outputs traceable even in agents. - **YAML serialization**: pipelines versionable via version control and commit history. - **Truly open source**: no black box, customizable components. - Acknowledged limit: "good orchestration cannot solve your GPU limitation." ## Reference Sovereign Architecture (speaker's outline) - Input **guardrail** (prompt injection detection, regulatory checks, intent checks) → unsafe input exits immediately. - **Agent** (LLM + system prompt + tools: APIs, knowledge base search, sub-agents, MCP servers). - Output **guardrail** for compliance / preventing leakage of sensitive information. - Haystack's stated role: making everything "swappable, traceable, and without vendor lock-in." - Implementation details: guardrails via model + LLM message router; selective MCP tool picking; **searchable tool set with BM25** for dynamic tool search (avoiding context overflow with hundreds of tools); custom on-prem chat generator components; **confirmation strategies** for human-in-the-loop (e.g., human approval for payment requests); tracer components connecting to LLM observability via **OpenTelemetry**. - Stated tool-selection logic: proprietary models permissible for public data; local/self-hosted models (Mistral, Google, Nvidia, and "Gina" — likely GINA/transcript rendering) for guardrails, knowledge base, LLM. ## Closing Sovereignty Checklist (speaker's questions) 1. Can you swap models without changing application logic? 2. Do you have reproducible run logs stored in a complying way? 3. Can your team respond to an incident without calling a vendor/hyperscaler? ## Preserved Tensions / Qualifications - Training-data origin is explicitly called "controversial" and unverifiable — the European-provider "advantage" is asserted without evidence offered. - Sovereignty requirements are domain-dependent; the speaker does not claim universal necessity. - The presenter acknowledges the promotional framing of Haystack while conceding its limits (GPU constraints). # Speaker & Provenance Attribution Record ## Video Metadata - **Title:** What Breaks When You Build AI Under Sovereignty Constraints - Bilge Yücel, deepset GmbH - **Video ID:** `01a15ca9-469a-7436-a5e4-4c5b9aff951d` - **Format:** Conference session talk (single presenter, live audience) ## Speakers & Roles ### Sole Speaker: "Viguen" (as self-introduced in transcript) - **Role:** Creator / Presenter / Company representative - **Self-identified title:** Senior Developer Relations Engineer at Deepset - **Note on identity:** The video title attributes the talk to **Bilge Yücel (deepset GmbH)**; the transcript speaker introduces himself as "Viguen." This discrepancy is recorded without resolution — no metadata resolves whether these refer to the same person, a co-presenter, or a naming/transcription difference. - **No other speakers:** No guests, narrators, panelists, or audience voices appear in the transcript. ## Company & Employer Affiliation (stated by speaker) - Speaker is employed by **Deepset** - Deepset described as the company behind: - **Haystack** — open source orchestration framework - An **enterprise platform** ## Promotional Segments — Flagged 1. **Explicit self-acknowledged promotion:** > "I want to hear shamelessly plug Haystack because a good orchestration framework I think solves some of these problems." - Segment promotes Haystack features: consistent interface, explicit data flow, YAML serialization, open source nature. 2. **Customer-name promotion:** - Deepset claimed to serve organizations including **Airbus, Bosch, Siemens**, and public-sector bodies (**European Commission**, German Federal Ministry of Research and Technology, other German ministries). Claim sourced to the speaker only; no citations provided. 3. **Ongoing product framing:** Much of the second half of the talk (architecture walkthrough, guardrail code demo, tool integrations) is structured around Haystack usage. ## Referenced Sources & Third-Party Claims (as cited by speaker, no independent verification) ### Regulatory / policy frameworks referenced - **GDPR** — claim: European citizen data should remain in Europe - **EU AI Act** — referenced via "air-gapped environment gives you EU AI Act safe" - **US CLOUD Act** — claim: US-headquartered SaaS providers may access data even if hosted in Europe ### Third-party companies / products named - **Models/providers:** Mistral, Google, Nvidia, Gina (Jina — spelling uncertain in transcript), OpenAI (via "Open AI API compatible endpoint") - **Standards/tools:** OpenTelemetry, BM25, MCP (Model Context Protocol) servers, Kubernetes - **Vendors implied but unnamed:** "hyperscalers" (incident-response checklist item) ### Unverifiable third-party claim flagged - **Training data origin:** Speaker states "we don't have a way to know where the model was trained" and that European model providers "have a better advantage" — opinion/claim by the speaker, not sourced. ## Comment Availability - **Not established** in transcript or metadata. Speaker instead directs questions to a **form** ("you can get the presentations and ask the questions to me by filling in the form") and to **social media** — no comment channel identified. ## Uncertainty Log - Speaker name discrepancy: title (Bilge Yücel) vs. self-introduction ("Viguen") — unresolved - "Gina" in transcript likely refers to a provider (possibly Jina AI) — transcription uncertainty, not corrected - No timestamps, citations, or external sources supplied beyond those listed above Hello everyone. Can you all hear me well? All right, amazing. Uh thank you for joining this session. In this one we're going to talk about sovereignty. Uh my name is Viguen. I work as a senior developer relations engineer at Deepset. But I want to start with a question. So how many of you are familiar with the term of sovereignty? Wow, okay, amazing. Maybe I don't need to do a lot of introduction for this one. And um just a little bit of context here about Deepset. Uh Deepset is the company behind the open source orchestration framework called Haystack. We also have our enterprise platform. And with those products we are solving customer AI challenges for big organizations like Airbus, Bosch, Siemens, but also public sector uh organizations like European Commission, Federal Ministry of Research and Technology uh and space in Germany and other ministries as well. So you can imagine sovereignty is a very big and important topic for us. So here is a like a policy definition you can say what sovereign sovereign AI is. Sovereign AI is the ability of an organization to design, deploy, and operate AI systems on its own terms. But we are all engineers here. We are not policy makers, we are not lawyers. So if you if you turn that into a technical uh definition, it's basically having explicit control over data flow, model choice, infrastructure, observability, and operations. And um for us to understand it better, I want to split that into four pillars. So the first one is data sovereignty. So, it's about where you store your data, where does it get processed? The second one is model sovereignty, who controls the running models, the origin of the training data. The third one is infrastructure sovereignty. So, where does compute happen? And the last one is operational sovereignty. So, is your application, is your system traceable? Who can update it? Who owns the incident response? So, let's go into the depths of this for a minute. Um data sovereignty. Data is the most important assets that we have in in an enterprise. And for us to have data sovereignty, data should be processed and stored within trusted jurisdictions to meet compliance requirements. What does it mean? So, basically, GDPR says that your the European citizen data should stay within Europe. But, if you send that data to an embedding model, to an embedding API hosted in Virginia in the US, then you are already losing the control of your data. So, that's against data sovereignty. And the other aspect is access permissions. So, this not exactly about how the data is stored and processed, but if there are users in your organization, within your organization, that are that has access to data that are not that they are not supposed to see, there's also a breach of data sovereignty. The other one is infrastructure sovereignty. So, where does compute happen? It means like we we have the AI application layer. So, we have our rag pipeline ingestion, we have agents, uh these the tools for the agents, and they all run somewhere. And where this application layer runs defines the infrastructure sovereignty of your system. Um and this and there's this whole spectrum from max control to max convenience. Maybe you run everything in an air-gapped environment, it gives you the EU AI Act safe. Maybe you run on a uh private VPC, this gives you GDPR safety. There is also sovereign cloud, this kind of depends on the provider that you're going with. And there's also at the very end there's SaaS. So with SaaS, you kind of face the cloud act risk, meaning that if you are for example using US headquartered company, although you store, you run all your date all your application within Europe, uh they have ability to get access to your running data. So that's against the sovereignty that you have over your system. The other pillar is modern sovereignty. So who controls the model and the origin of the training data? Um so the you should have the freedom to choose and switch models. But what it means that if your system can only work with one specific model, you are tightly coupled with that model provider. If they are if the API is down, then you lose access. If they increases the price, then you also have a cost issue. Um this is kind completely against the model sovereignty idea. And the other one is swappability without architectural changes. So maybe you're not tightly coupled with that model provider, maybe you can use other models as well. But if your system, if your code doesn't allow that immediately, then you are although technically you are not tied to that provider, but you cannot just change the whole code base within one day. And the last one is training data origin. So this is a bit controversial because we don't have a way to know like where the model was trained, which data was used to train this model. Uh but uh if a model provider is a European company, then they have a better advantage than other companies based in the US. The The last pillar is operational sovereignty. So, like building the whole AI system is one aspect, but monitoring So, basic basically maintaining this whole system by monitoring, evaluating, managing is also another. Uh operational sovereignty is about monitoring how these systems behave in production, including model inputs and outputs. And in high-stake environments like HR or finance, it requires human in the loop. And managing versioning, updates to models and the application layer uh in a controlled auditable way also goes under this operational sovereignty. But the good news is sovereignty is a spectrum. So, not everyone needs like needs to be sovereign in all of these pillars. Of course, like uh if you are in finance, in healthcare, in high-stake environment in high-stake domains, you might need an fully air-gapped solution. But if you are an enterprise or a startup working in a different domain, then maybe you don't need everything at all. You're You don't need to comply with every sovereignty pillar that I showed you. The important thing here is you need to know the level of control, so the the level of vendor lock-in you have with your system. So, you are here in the conference this week, but next week on Monday you're going to go back to work and maybe your manager or CIO comes and says like, "Okay, now we need to make like we have this working system, but then now we need to make it sovereign." Uh and in this slide I want to show you what you do first usually and what you break in this existing system. So, probably intuitively the first thing that you do is the model and you replace the frontier API that you have with a self-hosted model. And what happens? Then you need to translate this whole API logic to this new model architecture. Maybe you need to update the prompts. Basically, you need to evaluate the performance of the system from scratch. And you need to write a lot of code. The other one is you move private data into the required jurisdiction because you notice that okay, we have some information hosted in in the US. Now we need to take them somewhere in Europe and you do that, but you find yourself managing multiple databases and instances. Then search becomes a problem. So how do you handle search? Do you do classification like query classification first or do you send the request to both of those databases and get information from those? That's just one challenge that comes with this change. And the other one is you replace manage infra with on prem and you immediately notice how much you had vendor lock-in in this area. You because now you also start thinking about okay, Kubernetes cluster management, how do I like deal with all these all these things that all these model pro all these cloud providers were handling for you? And there are also hardware limitations because now you need to think about okay, I have this application layer running in GP CPU, but now I have my model run now running GPU. So I need to connect them in a way and this connection management, network management also becomes a problem. And the last one is you incorporate observability and tracing. I mean, if you if you didn't have observability until this point in your system, that's an important issue already. But if you now you when you need to incorporate it, you notice that you have this fully black box thing. So you don't know actually what's happening in this AI application layer. So you need to understand now because you need to log it somewhere so that your system is auditable. And there's is version control aspect. How do you do version control for your application layer, for this whole system that you are managing? And I want to hear shamelessly plug Haystack because a good orchestration framework I think solves some of these problems. I mean, good orchestration cannot solve your GPU limitation, but can help you with so many different stuff. Uh the the first thing is uh Haystack is has this consistent interface. So, basically, it when you want to transition your system from cloud to a self-hosted application, you can easily do so just changing couple lines of code and just focus on the hardware that you have and this hardware connection. The second one is explicit data flow. So, every input and output in a Haystack application is typed and declared. So, you can read the pipeline definition all over the this whole application uh in a in a in a regular way and know exactly what data was where and even in less deterministic architectures like agents and uh like agents the whole data this tools tool calls and tool outputs are traceable. The third one is YAML. So, the Haystack applications are serializable to YAML making them very easy to version. So, you can just after creating your application with Haystack, you can turn it into YAML, put it into your version control, and then when you need to go back to the history, you just need to go back to the the commit and you you can see the hash. And the last part is it's truly open source. So, there's no black box, no hidden assumptions. And when you need to customize some code or extend one of the components, you can easily do so because you actually understand what's happening under the hood. And here is one Here's a sovereign architecture that I want to show you um today just as like a high-level overview. Uh imagine you're building this agent, but it needs to be some sort of sovereign. So, first thing that you do probably you add some guardrails before, and then because this guardrail needs to check if there's like a prompt injection coming from the user input coming through the user input, and it needs to also check some specific regulatory checks maybe because I this is like a very specific agent that needs to be used in a certain way, and you want to check if user has this intention. And if it's unsafe, it just leaves the application layer immediately. Uh and if it's a safe uh request safe input, then it goes to the agent. And agent here is basically an LLM with a system prompt and lots of different tools. And these tools can be API calls, maybe they're connected to your knowledge base that you're you're doing some sort of search. Maybe you are using other agents if you're dealing with a um multi-agentic systems, and there are also MCV servers, of course, that are connected to your agent. And agent creates an input, so does the uh does the work for you, and there is the last guardrail doing a compliance checks because you also don't want to leak sensitive information to your user, and then there becomes an output. And uh but of course, like how you design a system as a sovereign system is a challenge. And the the duty of Haystack here is to make sure that everything is swappable, traceable, and without vendor lock-in. Um so, you know, you can work with the right level of sovereignty uh that you need. And here are some of the uh the tools that I picked from that I picked that you can work with Haystack. Um so, maybe you uh you decide you need like different models based on the task. Maybe you decide that for public data, you can steal some proprietary models from those providers, so you don't worry about those. But for some of the task, for guardrails, maybe for your knowledge base, for uh for your LLM, you think that you need local models running on on like self-hosted local models from other different providers like uh Mistral, Google, Nvidia, and Gina. And then, of course, uh there's traceability aspect. And as I said, in Haystack, everything like every input coming to a component and every output, but as well as the traces in the agent is easily visible, so you can just connect those spans to your LLM observability tool. And you can since there is OpenTelemetry integration, you can also implement your own observability. And as the last part, there's the storage. I wanted to pick some of the providers who can give you cloud and also the open-source version of them, so you can easily host these ones uh locally uh on your prem. And here is the um here is a guardrail um code. So, uh basically, how you connect a guardrail or how you define a guardrail is quite simple with Haystack. You just start with a model provider. For example, in this one, it's the Nvidia chat generator. You give the name of the model that you want to use. And by connecting it to your LLM message router, it helps you do the classification. So, it checks the input, if it's safe, it goes to the safe route, and if it's unsafe, it goes to the unsafe route. And then, you add you start adding tools. So, you connect your MCP server that you host locally with uh with MCP tool set, and you give the names of the tools that you want to pick from that MCP server. Because probably you have lots of tools running on that on that MCP server. You don't want to get all of them. You don't want to have access to all of them with just one agent. And you pick, for example, knowledge base search and generating PDF report one. And but of course like you can add the different tools. You can add just like you can start defining tools from a Python function or you can connect other components in Haystack like agent component into a tool or maybe there's some functionality that you define like data ingestion or rack pipeline and you can also convert those workflows into tools as well. And by after this defining all of these tools, you put them in a searchable tool set. So this gives you a dynamic tool search with BM25 because you probably now have more than hundreds of tools to for your agent, but you don't want to fill in the whole context with just tool definitions. Then there's this agent component. So basically you define a system prompt. You say like you're a sovereign agent with access to multiple tools and you define the intention of this agent and then you put a brain to this agent. Basically a chat generator. If you are running this model locally on prem, maybe you create your own custom component saying now this is my own prem chat generator connected to this internal company URL and getting the model inference from that. But of course if you have an open AI API compatible endpoint, you can already use an existing component in Haystack and then you give the tools and then you define confirmation strategies. So basically you incorporate human in the loop saying that so if the user wants to submit a request, the agent should always ask for human approval, but if the agent wants to use the list payment request tool, maybe ask for a permission first from the human and then you can use this tool as much as possible, as much as you want in this whole cycle. Then you bring it all together. So, you start defining your pipeline. You first add the component as a tracer that connects to your LLM observability. Then you put the input guardrail. You connect your agent, the output guardrail, and you you can just run this agent saying that pull the outstanding payment request for Q3 and generate a PDF for me. And by using the tools that this agent has, it creates the PDF for you and saves it under this directory under this name. So, with that, I want to give you just like when we are coming to the end of the presentation, I want to show you a checklist. So, if you want to check if your system is sovereign, you can you can take a look at this question. So, you can think about can you swap models without changing the application logic? Do you have reproducible run logs stored in a complying way? And can your team respond to an incident without calling a vendor like one of those hyperscalers? Thank you for joining the session. And you can get the presentations and ask the questions to me by filling in the the form. And you can also find me on social media if you want to connect there. I'm happy to talk about you about agents, Haystack, and especially in a sovereign setting. Thank you.