Building Data Pipelines with the AI Assistant

Jump to the section you need

Timestamps

• 1:08 – What we'll cover today
• 2:23 – How AI changes the developer's role
• 4:45 – The AI Assistant in Designer: companion, architect and troubleshooter
• 8:15 – Bring your own key, bring your own model
• 9:31 – Using external AI tools with the CloverDX MCP Server
• 12:04 – How it fits together under the hood
• 13:19 – Companion mode and architect mode
• 17:12 – Live Q&A: Local hardware and language support
• 20:54 – Demo: Documenting an inherited project
• 23:28 – Demo: Explaining a job and choosing your models
• 26:29 – Demo: Data lineage in a complex migration project
• 30:29 – Live Q&A: Token costs and Microsoft Copilot
• 33:32 – Demo: From spec to implementation
• 37:41 – Demo: The architect, sprints and the decision log
• 43:05 – Demo: AI review and fixes
• 45:44 – Live Q&A: Troubleshooting and access controls
• 48:05 – Closing
  

   

Transcript

Introduction [0:29]

Jonathan: Hello everybody, and thank you for joining us today. I'm Jonathan from CloverDX. Today we're joined by Petr, our Head of Customer Success, and Pavel, our VP of Product Strategy and Solutions, who will talk us through today's session.

In essence, we'll follow a real data project from spec to a working solution and show how the CloverDX AI Assistant can support each step along the way. As always, if you have any questions, drop them into the Q&A box and we'll get to them towards the end of the session. With that said, let's get started. Over to you, Pavel.

What we'll cover today [1:08]

Pavel Najvar: Thank you. Good morning and good afternoon, everyone. Jonathan gave you a sneak peek of what we're going to do, so let me walk you through today's session. It has four parts.

First, I'd like to explain what we've been doing with AI as an assistant and helper for developers in CloverDX. We'll do a quick intro to what it is. Then we'll talk about two options for using AI to accelerate development in CloverDX: either right in the product, or with external tools like Claude Code or Cursor.

Then we have two scenarios to walk you through. The first is for existing projects: you've already invested in building something in CloverDX, and you want to start using AI with it. Think of it as a smooth transition into the world of using AI in CloverDX. The second shows AI building something in CloverDX from scratch — the full spec-driven development approach.

How AI changes the developer's role [2:23]

Before we show you the examples, there are a couple of things I want to make clear. We've had plenty of conversations about whether AI is going to replace developers, and I guess a lot of you have tried AI for development in some capacity. We view AI as something that doesn't replace anyone. It supercharges whoever is working in CloverDX. It acts as a force multiplier for what they're doing.

But it also changes things — and that's where we want to get to. It changes what you do and how you do it. Historically, a developer has been someone who drags components onto the CloverDX canvas, writes CTL or other code to put into a CloverDX job, and writes and uses documentation. Using AI shifts that role towards being a reviewer of the work AI has done. Everyone who starts using AI for development sees themselves becoming someone who looks at what AI has produced.

We also want to push the work from "here's a piece of work I need to get done" to much bigger chunks of work. We call it spec-driven development. You give the AI your intent: this is what I need to achieve, this is the goal, this is the task we need to do together. You hand over a specification and let the CloverDX AI Assistant figure out how to implement it. It gives you a plan for the architecture and the solution, then moves on to implementation, and then you review it in the product. So the idea is to shift to spec-driven development, and to become a reviewer and someone who collaborates with AI as the work gets done.

The AI Assistant in Designer: companion, architect and troubleshooter [4:45]

As I hinted at the beginning, there are two ways to use AI for development in CloverDX. The first is what we call the AI Assistant. Don't let the name mislead you. In my opinion, the assistants you see in some other products are often quite limited in what they can do. The CloverDX AI Assistant is a full agentic system built into the product. It acts as an assistant — we call it a companion — but it can also act as a fellow architect. That's where spec-driven development comes in: you hand over the whole documentation of a project and work with the Assistant on planning how to do it.

It can also act as a troubleshooter. Say your data pipelines fell over last night: let's figure out what went wrong. That could be because the pipeline failed for some reason, or the pipeline could be working fine while there's a problem with the data. You can turn to the Assistant with all of these tasks.

Under the hood, it's a set of agents that work together. You don't have to worry about those agents, but they're there, and they work towards being your companion, architect and troubleshooter in one experience.

The other interesting thing about using AI this way is the integration into the environment. You have the Assistant on the side — you can put it wherever you want — but you also still have the canvas that most of you are used to in CloverDX. The canvas stays there, and it's where you review and see what the Assistant is doing. You can point the Assistant at a component or part of a graph and say, "Can you explain this to me?" — Petr will show that in a second — or "Can you modify this section?" or "Can you fix this problem?"

So it really is integrated, and that's a big difference from the AI-native environments many of us have been using. I'd say the CloverDX experience with the Assistant is much richer, because you have that collaboration between the AI and yourself.

Bring your own key, bring your own model [8:15]

Just a quick note on how it works under the hood; we can get into details later. This is what we call bring your own key, or bring your own model. CloverDX doesn't provide tokens or the LLM service. You point it to an API with your own key — Anthropic, Gemini, OpenAI, or any of the LLM gateways out there, like AWS Bedrock. We support quite a few of these services. So you connect it to your own AI provider, and the Assistant talks to that provider. CloverDX isn't anywhere in that path. We provide the tooling, not the service — and Petr will show that in a second as well.

You can also use local models running on your own hardware. We happen to have a server with a bunch of GPUs that we use for local testing, and it's very useful. It can do a lot of interesting things. If you have that hardware, it's a very interesting alternative to spending money on the frontier models.

Using external AI tools with the CloverDX MCP Server [9:31]

That's the AI Assistant in the product. But we also let people use AI from outside and work on CloverDX Server from the tools they already use. Say you use Claude Code, Cursor or Zed: you can connect to the CloverDX MCP Server. That's the service CloverDX provides to AI. The server provides 60 or 70 different tools, including running graphs and validating CTL and graphs. It also includes a very important knowledge base we've built into the product, which general-purpose AI doesn't have: knowledge about how to build pipelines in CloverDX, and the best practices for building graphs, jobflows, data services and so on.

That combination of tools and knowledge gives Claude Code, or whatever you're using, a lot of power when it comes to building things in CloverDX. It also connects to the server, so it can run jobs directly.

We won't talk about this today. We have a webinar coming up in a couple of weeks that focuses on it. Today is about the AI Assistant in the product, but keep in mind that this option is available.

We don't see the two as one-to-one alternatives, because the experiences are different. We see them as complementary. If you can, using both is the best way of working with AI in CloverDX. The AI Assistant in the product can do a lot of the heavy lifting when building CloverDX graphs and jobs, and it gets to the result much faster. AI-native platforms like Claude Code or Codex are good for a much broader set of tasks — they're universal tools. You can ask one to look something up on the web, connect to an API to see how it works, figure things out, and then write a spec that you hand over to the Assistant. That's how I use it, and I think it's the best way of doing it.

How it fits together under the hood [12:04]

Here's a little more explanation of how it works. We have CloverDX Server and CloverDX Designer. Designer is where the AI Assistant — the integrated experience with the agents — lives.

The Assistant connects to two things. One is the external LLM provider: either a service like Anthropic or OpenAI, or your own local model provider, like Ollama or vLLM. The other is the MCP Server on CloverDX Server. That contains the tools and the knowledge base. By the way, there's the built-in knowledge base, but there's also a knowledge base that comes from you. You can build your own knowledge base on top of the standard one, and the Assistant and the other tools have access to it.

If you want to use external IDEs like Claude Code or Cursor, you connect directly to the MCP Server. That's the setup we have, and again, today we'll focus on the Designer experience.

Companion mode and architect mode [13:19]

That allows us to use AI in what I like to think of as different modes. But they're not something you have to think about — "now I need to use the companion, now I need the architect." It's all seamless. You talk to the Assistant, and it figures out what it needs to do. These are just the levels of engagement it can have.

The companion is the most obvious one. You can ask it how a component works or how you should set something up. If there's a problem, you can ask it to fix it or explain it. You can ask it to build a simple graph: if you have a specific task in mind, just type, "I need you to build a graph that does X, Y and Z. Here's the input file, here's the output database." It will do it right away. I'd say that's the obvious way of using AI.

When we started thinking about the Assistant — the June release was a tech preview, and last week 7.6 came out, so the Assistant is now fully released in CloverDX — we asked ourselves what the next level is. I think it's the architect mode of the Assistant, and it has two sides. We'll see both of them today.

Sorry, the ordering on the slide is flipped. We decided to first show you the smooth transition from an existing project to AI, and then show how to start a new project.

So first, we'll show how to use the architect to enter an existing project and help you document it. Everyone loves writing documentation, so now we can use — and abuse — AI for that. I'm not a big fan of writing it myself. You can use AI to enter an existing CloverDX project, ask it to document the project, and move on from there. You can plan extra work as an evolution of what you have, or use the Assistant to help you understand a project you don't know. We've talked to a lot of customers about this, and it seems to be a really interesting use case for AI. You inherit something from a colleague who's leaving or changing roles, and maybe the documentation isn't the most up to date. That's one use of the architect: transitioning from what you've been doing before to doing things with AI.

The other mode is SDD, spec-driven development. Instead of saying, "I have this very specific graph I need to build," you say, "Here's the problem. These are its parameters. This is how we need to solve it. Go figure it out." It will analyse the problem and talk to you about it — maybe there are questions to answer and decisions to make. You can provide the spec as a file, such as a PDF, or type it in. The result is a piece of documentation and a plan for development. Then you can ask the Assistant to implement the plan, review it, and continue.

Those are the two demos we'll do today.

Live Q&A: Local hardware and language support [17:12]

Pavel Najvar: If we have any questions, we can address them now.

Jonathan: Yes, we have two so far. The first one: what local hardware are you using for local models?

Pavel Najvar: That's a good question. There are a lot of options. We currently have two RTX 6000 Pro cards — the 96 GB models. I think the model we're running has around two to three hundred billion parameters, so it's a pretty big model. But we've seen good results with models of a couple of dozen billion parameters. It's not something small you'd just run on a Mac mini; it needs a more powerful GPU. So it's dual RTX 6000 Pro. I'll send the exact type in the chat as an answer. But we're not saying this is what you need in order to use it. It's just what we use.

Jonathan: Nice. The second question: does it support multiple languages — for example, German mixed with some English words?

Pavel Najvar: That's a good question. The product development team is Czech, so we have some people using Czech. But I wouldn't be confident saying you can switch completely to German and it works.

Petr Drabek: I'm not entirely sure the experience is on par with English. I'd add that the whole interface is in English. But we've found that if you provide a specification file, or a data file with sample data, in another language — we tested Czech — it will understand it, provided the LLM understands it, which it usually will. So if you want to provide the specification in German, you can, and it will be able to work with it. But it will probably answer, and the whole chat will be, in English.

Jonathan: Thanks, both.

Pavel Najvar: I'll add one more thing. This is useful when you're dealing with data in different languages. It's not just about the interaction, it's about the data, because we use whatever LLM you give it. If you provide a good enough LLM, it can work in different languages and help you understand the data. We have an example we're not showing today, where we use a data file that combines Czech and English. It helps you understand what's in it, and it also identifies some problems in the file. So it's also good for orienting yourself in multilingual data.

All right, I think that's the questions. If you have more, feel free to jump in at any point. Petr, at this point I'll hand over to you for the first example.

Demo: Documenting an inherited project [20:54]

Petr Drabek: Sure. Thank you, Pavel. Let me quickly share my screen. Can you see it? Just a quick check. Great.

Hello everyone. I've prepared two sample projects. The first is the data warehouse example, which is distributed with the product. When you install CloverDX Server or Designer, you'll have it as a sample project, so you can look at it on your own. It loads files into a data warehouse, and it's a complex, multi-layer jobflow, as you can see here.

The scenario is: here's an existing project, and we want to document it and maybe continue developing it. I pointed the Assistant at the project and said, "Orient yourself in the project, and then we can move on from there." It analysed it for a while, gave me an overview, and asked how I wanted to proceed: start building and continue development straight away, or document it first. I chose to prepare the documentation first, and it wrote it out into files.

Here's what those files look like. I have them in a subfolder called Assistant, with all the project documentation for that specific sandbox. It prepared an architecture.md for me, which describes everything from the purpose of the project to a diagram of the end-to-end flow — how the data flows and is processed through the hierarchy of jobs. Then there's a detailed description of that hierarchy and what happens step by step as it loads data into the database. It gives me the database schema, which it derived from the jobs, and then the whole business logic: a description of the layers, the data services involved, configuration notes. It's quite detailed documentation.

What you can do next is just continue in the chat and start building something. Or you can dig deeper if you need a more detailed explanation of a specific part of a job.

Demo: Explaining a job and choosing your models [23:28]

Let's actually try it. I have one of the underlying jobs here, which processes and stores the file. Let's do it in the AI Assistant. You can have multiple sessions, so let's start a new one. I can open the job, select a component in it, or just have the job open and say, "Explain this job for me." It starts analysing the job.

It will take a couple of seconds, so in the meantime let's look at the models. Pavel described how you can combine bring your own key and bring your own model. In Settings — it's already done, but let's quickly finish this part — under the CloverDX preferences there's a new setup where you can point it to different providers. You can simply add a new one. A couple of the most common providers are supported, and you can even point it to local models. Here I have our local models, as we described: in our company we're currently testing DeepSeek, plus a key from Anthropic.

Here I can combine these connections with models and choose them for the different providers. I can even create profiles with different combinations and switch between them, even inside a session. For example, if I don't need as powerful a model for troubleshooting, I can switch completely to the local one, or switch fully to Anthropic. I can really play with the combination of models. That's how easy it is to combine local and external models.

Now let's look at the result. Let me make it a bit bigger. It scanned the job and gave me the input parameters, the flow between the components, the data flow and the business logic. Then there's a step-by-step description of what's going on in the process, with an extra description of the error handling. It can even point out some design considerations.

So it doesn't just help you prepare documentation at a high level or project level. It can also give you more detail about specific jobs, or even about specific component usage, if you need it.

Demo: Data lineage in a complex migration project [26:29]

That's one example, from the data warehouse. Let's look at something more complex — a project of a certain size. I've prepared something more advanced here: a migration project with several layers of orchestration, with flows for the individual entities being migrated, like fees, orders, customers and so on.

The customer hierarchy is one of the bigger ones. It has a complete orchestration layer that calls smaller jobs. If I open it — let me zoom out a bit — you can see it's not a small project.

With something like this, you can of course create documentation. But if you're interested in something specific, high-level documentation might be too broad for a project this big. So I've prepared a session where I do a simple thing. I say: "In this project, there's a customer master data file on the input. There's a sheet inside it, customer bank accounts. It's read somewhere in the customer hierarchy. Can you please track it down and give me the data lineage for it?"

It scans the project, looks for it, and gives me the results for the data lineage. That's nice to have in the chat. But if you want to export it and send it to a colleague, you can say, "Write me the documentation for it." It simply creates documentation for the data lineage of that specific sheet and file — at a high level, every field and how it's handled, with a summary and so on. It also tells me that only three fields carry real values; the rest are null or constants.

Then I can go further and say: "You mentioned three fields in the document. I want to dig a little deeper. Give me the data lineage, not just inside this graph, but from the very first source to the end, and give me full documentation for the lineage of that field." Again it does the processing, and in the end it gives me the lineage for those three fields.

Here's a quick look at the bank account. Here's the lineage chain, and you can see it takes the data from the very first source files, through multiple temporary files and different jobs, and says what's going on at each stage and step of the process. It gives me a quite detailed data lineage report. So, for example, if an external auditor asks how we're handling bank account information, I can just give them this document, and it describes it in detail.

That's another example of how you can use it for a cold start: when you have an existing project and you want to orient yourself in it, or prepare documentation from it. And that's it from my side, if there are no questions. Back to Pavel.

Live Q&A: Token costs and Microsoft Copilot [30:29]

Jonathan: All right, thanks. Pavel, we do have some questions. Do you want to do your segment first, and then we can get into them?

Pavel Najvar: Let's do the questions now, while they're related to this.

Jonathan: Perfect. There's a question about tokens: how much will I spend on tokens when using the AI Assistant, and is it possible to keep that under control?

Pavel Najvar: It uses tokens, so you will spend money on tokens. There's no magic here. Over the past couple of releases we've optimised it quite a bit, so the token spend is much lower than you'd expect. To give you some perspective, take the exercise I'll show you in a second, which is a full implementation of a project. It won't always be like this, but the whole implementation takes a person a day, maybe two, depending on how skilled they are. It cost a little over $20. So it does cost money, but compare that with how much it accelerates the work. If you weigh the hours against the tokens, there's a big difference.

On reducing that cost: we're doing a series of webinars about AI and CloverDX, and not the next session but the one after it will be on best practices. It will focus mostly on the quality of the output and on how to spend less on tokens.

Jonathan: Nice. Thank you, Pavel. If you need links to those webinars, you'll find them in the chat box in this Zoom webinar. One more question has come through: is it possible to connect with Microsoft Copilot Premium?

Petr Drabek: I would say yes, because Microsoft Copilot uses OpenAI models within Microsoft. If we look at the list of providers here, we test it with OpenAI. For Microsoft specifically, there are a couple of ways Microsoft provides it, and here they are. Right now it's API key based. In development for the next version, 7.7, coming out in December, we're adding the option to use Microsoft with OAuth instead of API keys, because we know our customers use it.

Jonathan: Nice. Thank you, Petr.

Demo: From spec to implementation [33:32]

Pavel Najvar: All right, I think we don't have any more questions for now, so let's move on to the next demonstration. Let me share my screen again.

What we've seen from Petr were two existing projects. One was decent; the other was, let's say, fairly ugly. And we saw AI helping someone working with the project orient themselves in it. The next demonstration shows the other way of using AI: I'm starting on a greenfield, but I know what I need to get done.

I really like this demonstration, and some of you may have gone through this exercise yourselves. When we run trainings for our customers, there's an exercise at the end that everyone has to pass — it's our certification exercise, for those going through the certification process. The exercise covers the full extent of what you can do in CloverDX: some transformation, some orchestration, a file listener to trigger jobs, and data services, like publishing APIs.

Unless I'm wrong, this is the actual assignment we currently give to people going through certification. It has a set of high-level definitions of the task. Files come into an input folder and need to be loaded into a data warehouse in a SQL database — that's the setup. There's some orchestration. The exercise also asks for counting and reporting, like how many records were processed in the load. It's six slides, originally from PowerPoint, now a PDF.

What we did was essentially say: "Assistant, read this project specification and plan the implementation." That's the only real input given to the AI Assistant, plus the PDF I've just shown you.

Petr showed his local models. Here, we're using the latest Opus 5.5 and Sonnet 5.5 for the reasoning tasks — essentially the architect, which figures out the plan and defines what we call sprints: the breakdown of the work into manageable pieces. We use the better models for this, and Opus 5.5 is actually pretty good. For the mechanical work, like implementation and writing graphs, we use cheaper models.

To give you some perspective, as I said, this cost a little over $20 for the overall implementation. You'll see the actual implementation is roughly half of that, and I'll explain why in a second. In terms of how long it takes: it's not instant, which is part of the reason we're showing recorded sessions — we don't want to bore you. It's roughly an hour of the AI doing its thing. There are some questions I have to answer along the way, but mostly it's the AI crunching through the assignment.

Demo: The architect, sprints and the decision log [37:41]

First, it reads the file. We didn't get to this when Petr was demoing, but you can see what happens behind the scenes when the Assistant calls the different agents to do some work.

It starts by calling the architect, which does a lot of things. It reads through the specification, and then it manages the project documentation, similar to what Petr showed in his cold-start scenario. So we have similar documentation here. For example, if I open the architecture document the architect agent built from the PDF, it says it was built from the certification exercise and that it's a data warehouse. None of this was given by me. All I said was, "Read the spec and do it." It then summarises what the process looks like and plans it.

You can see there's a file event listener, which triggers the job, or you can run it manually. Then there's a jobflow that handles the main orchestration. The jobflow decides whether it's processing customers or payments — part of the assignment is that different types of input files can land in a magic folder. Then it plans how to handle errors: it will put files into error folders. It uses a subgraph, some database tables, and a data app — one of the assignment tasks is to build a data app that shows a report of what the logs look like. So it plans the entire exercise, and then it writes documentation for it.

There's a data model — part of the exercise, by the way, is actually building the database. There's business logic that it figures out from the rules set by the exercise. And at the end there's what we call a sprint plan: a plan of what work needs to be done, and in what sequence.

We label the sprints S1, S2, S3 and so on. It figures out that it needs to initialise the database first, then build a subgraph it will need in later sprints. Then it builds one graph for customers, another graph for payments in a separate sprint, and so on.

You'll see there are 15 sprints in total, but they were done in multiple waves. The original plan was, I think, seven sprints. Up to sprint 7 was the original implementation. Then I had some additional requirements, and it said, "All right, I'm going to plan more sprints to implement those requirements." So it doesn't have to be one block of work done in one go. Sprints get added as you ask it to do more.

The architect does the planning. Then there's another agent, the librarian, which records and retrieves knowledge about the project, about CloverDX, and about your organisation's requirements. As we said, there's a knowledge base you can add to. You put it on CloverDX Server, and the Assistant can retrieve information from it: instructions on naming conventions, how you want to build certain things, rules for security, how jobs need to be built, and so on.

Then, as it works through the flow, it says: "There's a problem. There are dates in the sample input files" — there are a bunch of input files here — "and some of the dates are incorrect and can't be parsed. What do you want to do with that?" It found the problem by inspecting the files. It gives me some options, and I say, "Load them with a fallback date." That's a decision I'm making as part of the conversation, and these decisions get recorded in the project's memory.

Here you can see the list of decisions that have been made, and the first one is actually the payment date problem. If it sees an unparsable payment date, I decided it should take the first day of the month from the payment file name. It's a workaround: the payment files have the month in the file name. I could have made a different decision; I just chose this one to keep it simple.

Then the developer agent takes on the different sprints. You can see the developer taking sprints 4, 5, 6 and so on.

Demo: AI review and fixes [43:05]

Then, somewhere in the middle, it finishes the original implementation and says, "I'm done." That's roughly halfway through the time, so 30 minutes or so.

But it then gave me an option to review what it built. That's interesting, because if you use AI, you know it makes sense not only to ask it to do things, but also to review them. So I said, "Review what we've built and check it against the spec." And that's how AI works: it found a bunch of problems.

The biggest problem — which it couldn't do anything about — was that it didn't set up the file listener, so there's no trigger. The reason is that, currently, the AI can't set up file listeners on the server, so I have to do that manually. It also found a few problems in the implementation. For example, it was counting the success report incorrectly.

So I said, "Ignore the listener problem for now. I'll sort it out myself — write down a guide for how I should do it. Then plan and implement all the fixes." That's where the other sprints come in. The first seven sprints were the implementation, and sprints 8 through 15 are the fixes — small sprints, each updating something. This happened quite some time after the original implementation.

And this is how you actually work with the Assistant as an architect. You have the list of decisions, including decisions made later. You have the architecture plan and the documentation, and you essentially add sprints to it.

At this point, here's everything it built: this jobflow, which orchestrates the whole process, and the graphs and subgraphs it uses. These are regular CloverDX jobs. This is a regular jobflow, and the graphs it built are regular CloverDX graphs. I can come in and modify this graph, make changes, and ask it to incorporate my changes into its documentation. We're back to what Petr was showing. There's no magic difference between the AI Assistant producing something and you producing something. It's the same thing, and you can collaborate however you wish.

With that, I'd say that's everything we had. Let's open it up to questions — or Petr, if you have anything to add. Let's do questions now.

Live Q&A: Troubleshooting and access controls [45:44]

Jonathan: Perfect. We have one question: can it troubleshoot failed jobs and performance problems from a server log?

Pavel Najvar: Yes, it can. We haven't shown it, because that's another webinar we'll be doing at some point. Troubleshooting with the AI Assistant in CloverDX is a whole area of its own. It's pretty powerful, and it deserves its own webinar.

Jonathan: Perfect, you'll have to wait for that one. Another question: how do I stop the Assistant from reaching databases or sandboxes it shouldn't touch, especially in production?

Pavel Najvar: That's a good question. One thing we added in 7.6 is controls where you can provide wildcards as an allow list and a deny list for accessing files. So that's one control: you can restrict sandbox access, which guarantees it can't get to those files.

For databases, we recommend solving the problem at the database level, because AI is very creative. If you tell it, in whatever way, "Don't use these constructs in SQL statements," it might obey, and it might not. The safest option is to have database accounts with permissions you're happy with — read-only, or access only to certain databases or tables. Then, whatever the AI does — and this is something we don't have control over — if it decides it really wants to look into a table or do something with the database, it can't get past the user's permissions. So for databases, solve it in the database. For files, there are controls on CloverDX Server that let you restrict access.

Closing [48:05]

Jonathan: Nice. I think that pretty much sums up the Q&A, unless any more come through. Thank you, Petr and Pavel, for taking us through that, and thank you all for joining us today.

Before we wrap up, it's worth mentioning again that our CloverDX 7.6 release webinar is happening next Tuesday, where we'll cover the latest CloverDX features and updates. We'll also be running a follow-up AI live session focused on using AI dev tools like Claude Code and Cursor with CloverDX to build, run and debug data integration jobs. The links are in the chat, and we'll include them in the webinar recording email, which will be sent to your inbox shortly. That's it for today. Thank you, everyone, and have a great rest of your day.

Pavel Najvar: Thanks, everyone. Have a nice day.