Turning My Obsidian Vault Into a Local AI Engineer — Filip Makraduli, Superlinked

Hello, hello. Um, I guess we're starting. I know some of you are still joining in, but I'll go on and, uh, you can jump in at any time. Uh, so you might have seen the title of this talk. Um, and what I have on the slide here is slightly different, but I promise it's the same direction and the same general idea. So it all started from me wanting to build a use case that's

around privacy and token costs, basically. So, um, I started with Obsidian. I had some markdown files there. Um, and as you know, it's like you have this nice, um, graphs and it's all good. Looks very nice. However, um, I had certain issues beyond just organizing the files. So a lot of people do these knowledge graphs

and so on, and like memory for agents, and that's quite good. However, I needed to approach this differently because there was a concern around privacy. So when using agents, when using Claude Code, when using Cowork, uh, you can expose your files and for some institutions, for some people, this was, um, a requirement that, um, needed to be met. So

the goal was to keep things private and self-hosted, but also make them quite usable and friendly so that people could actually do these things. And, um, there was kind of this openness to fine-tune, to be very adaptable, to use open source models and, um, I found that the solution was, um, in Superlinked, which is a model inference,

um, engine that's open source. So it has both a cluster and a model inference solution. And I will be talking about that today and how I managed to kind of merge these concepts together and, um, create something that leans on these three things. So the first main idea was I wanted to make Claude Code a bit cheaper and save on tokens. So we know

how with the release of Fable, there initially there was this, um, API-only pricing and that kind of, uh, maybe disappointed a few people or the token economics got a bit more attention now. So that was one thing. Especially for document processing, sensitive document processing, where you need to do OCR, there are a lot of scans, images and stuff like this. The token cost can ramp up, so I wanted to find a way to kind

of do this. But also having smaller artifacts means that you get better context, so you kind of limit context loss in a way, and you don't like fill out, um, the context with data that can be processed in some way else. Um, and I wanted to make this private. So yes, for certain situations it's fine to paste everything into Claude Code or have that API working there,

but what if you could kind of self-host and have your own VPC or your own cloud to pre-process your sensitive documents and then return something back? So this was another target of mine when building this. And also I wanted adaptability. So it wasn't just, um, privacy and lowering token costs, but also having the chance to test out multiple models, maybe host LoRAs that are very task-specific

because with these very sensitive use cases, usually there is some sort of fine-tuning or adaptation towards that niche use case. So I had to do that as well. And the setup, um, involves Superlinked, um, and SIE, the repo. So you can-- For the purpose of today, you can go to, um, the repo which is fully open source.

So you can find it on GitHub. It's Superlinked SIE. Um, you can... Yeah. So this is it. This is the logo. And I'll be talking about, um, an integration that's, um... Sorry, not here. So an integra-- an MCP integration, which is basically a package that we did, which is this one here. So you can also have a look at this sub-directory. So this is where most of the talk

will be about, but I'll also mention why actually the inference was the bottleneck when building something like this. So it was easy to figure out how to store the data, maybe in Obsidian and so on, and have these connections between the data. Um, that was the easy part. I could also use an API. However, if I wanted to do open source, if I wanted to do open source inference at scale and testing out multiple models, being

able to deploy this in production, things got a bit difficult. And that's why the infrastructure advantage that SIE offers, the fact that you're able to kind of deploy both a cluster and the models themselves was a very big advantage in my case. Um, here you can see this, um, Obsidian example, so I'll work with kind of some of these things. Uh, but you can also

try this yourself. Um, however, I will be using a managed cluster. We cannot, um, I cannot give that to you right now live. However, you can go to our website, which is this one, and here you have this Apply for In-Inference Grant. So you can go there, and you'll receive your, um, API key that you can try, and you can do things quicker. If not, you can do things locally 'cause there is a Docker

container and all that. Uh, it will just take a bit slower to do these things. But I'd prefer if you kind of listen to me now and then try things after, but also in parallel if you want. And we also have this very cool, um, kind of QR codes memorabilia stuff where you can get an even better cluster as a thing, and you can find them here, uh, after the talk.

So, um, as I said, the idea was to have this privacy element and have a way to offload. So basically, I didn't want to disrupt my normal usage day-to-day. Um, so I'm just working in Claude Code, and then if there's a specific task that needs to be done on my virtual private clouds that needs to be processed, that's sensitive, that costs a lot of tokens, I can just offload it and continue my work.

So the natural direction was to build some sort of, um, skill or plugin, but this was even elevated more by building a whole MCP server that's, that gets called, um, in Claude Code. And, uh, there's that element of like using skills, but also having actually a dedicated edge that, uh, can actually do the heavy lifting. And you can also benefit from

Superlinked Inference, which I will talk about later on, kind of how we've done this and what are the advantages of using, um, Superlinked Inference engine. So it saves tokens because, for example, um, a number would be to have like maybe ten pages of a PDF that has images, different details in there. So if you pre-process that with good open source OCR models and then return to your main, uh,

agent, uh, harness or Claude Code or whatever you're using, you get the context, but also, uh, benefit on the lower token spend and better context and so on. So that's the general idea, especially for OCR, this is apparent. However, there are multiple, um, kind of token-saving advantages even beyond OCR. So why MCP and not

just an API or a plugin? Um, because we have a dedicated cluster, it was much better to kind of separate the responsibilities and, uh, have this as like the backbone to then build more, um, details and more, um, features further on, for which I will also talk about later. And everything runs on a server you can control, so through SIE you can pick your, uh, worker pools, you can pick your,

um, GPUs basically, and understand which models are pinned where. And that flexibility from a cloud perspective was an advantage and, um, I wanted to keep it that way and that's why I went with MCP rather than just a skill. Um, and it exposes the relevant tools. So this is roughly how it would work. Um, if it's just a plugin, it's also on your laptop or on device. In this way, you can kind of

offload the same experience, but bring it to the cloud, which is your own cloud, and you can control things there. So it's a much cleaner setup. Um, also a lot of the examples here are with PII, so personal identifiable information, and there is a tool that gets called for like redacting specific details around documents, which is one of the central use cases of this privacy aspect. Um, and

the MCP setup, it has three tiers. Um, so there is-- You can see in the middle the SIE MCP. There is the MCP client, um, that's, um, kind of client and host through Cowork or, um, Claude Code or whatever you use, and that communicates with the SIE MCP server. And then you have actually SIE, the cluster that has the, um, GPUs and the worker pools that do

the work by communicating to the, um, MCP server, and you have different models that are available. And we also have a good queuing mechanism for this, uh, GPUs, um, and I will go more into that a bit later. And the idea with M-MCP, as you know in general, is to have like one interface of communicating, especially if we're building more and more tools with this direction of model routing. Because the demo and

the version that we have now is around tool calling. However, we're building stuff around model routing and understanding which models to pick for different tasks based on, um, evals and based on costs. And all of these models would be open source and on your GPU. So, um, there is this important direction as well. Um, so it's a forward-thinking approach. Um, and there is the host, the client, and the server. Um, you can do

this like with any- Mm, mm, setup that you want, like whether it's Claude Desktop, Claude Code, and so on. And the communication is kind of done through JSON-RPC, so there are three, like, response, request, and a notification just to kind of, uh, initialize this and have this handshake, uh, protocol done so that you can authenticate the MCP Edge and so on. And, um,

an important detail is that the server exposes, um, different stuff. So in the MCP standard, that has changed a bit since its inception. Um, but the main thing is that it exposes tools that then, um, Claude Code would use. However, in general, there is, in kind of the MCP universe, there is a situation where, um, the client can also expose stuff like

sampling or elicitation, which kind of make this a two-way communication, so not like a standard client-server setup. However, in our case, just because this was more of a privacy setup, we do not do this. So, um, basically the SIE MCP Edge, um, only exposes the tools, and they can be used, the ones that kind of were initialized in the handshake, and that's it. Um, so

it only kind of does these responses. It wouldn't, um, do these more complex tasks, uh, in our case. And this is the idea, that the tools are discovered and you just go from there. Basically, you, uh, kind of have the tools which give you different, um, abilities and, um, you can run, run that. Another detail is that, um, you can do this also locally. So in the

MCP universe, again, the stdio is like for local development. However, we wanted to use the streaming HTTP responses. This was done in the past by two endpoints, um, that did, uh, the streaming and one did the HTTP handshake, but now there is a standard that kind of does this all at once, so that makes things smoother. And these are the tools that we have, so I'll spend a bit more time on this

slide. So currently, the kind of setup and, uh, things you can try are around these models. So there is this tool that's like docs to markdown, and, um, that one uses OCR, um, models. Um, these are the open models that we have currently. So the idea is it saves token costs. It uses also a very good open source model. Um, a detail here is that with

OCR models especially, the open source models are very good, so you're, you're not compromising in quality by offloading some of the work to open source, um, OCR models. So it's not that, "Oh, I'm using open source, I'm sacrificing something." That's not the case at all, especially here and even in general, uh, open source models are catching up, and finding a way to bring them out there, bring them in production is, um, quite

useful and quite important. There is extract entities, which would just generate the relevant entities in the docs with different NER models. There is-- are different tools around captioning and tagging. There is also, um, a capability around, uh, structure generation, uh, summarization, question answering. And the good thing is also this is open source, so you can also do a PR and add a different tool

there right now, and that would be something that kind of we can make, make it as a part of this and, um, still it will utilize the inference, which is the bigger bottleneck in situations like this. Um, and that would be the idea. You can kind of clone the repo that I showed before and, um, you can bring up the cluster locally. But also, uh, if you, again, go on the website and request that, you'll

receive an API key at some point. And this would be kind of the setup. You need to get, uh, the API key. You can also self-host if you're in for the longer term, let's say. Uh, so it doesn't have to be our cluster, it can be your cluster. Um, and you just need to set these things up. I'll also be releasing, so an article that will kind of explain this in a bit more detail, and you can

go step by step and run this. So no, no rush. Uh, you can enjoy the talk and relax and try things out at your own time in many ways. And, um, here we have the repo, and also the link to kind of getting the, uh, the computes and the cluster. So you can basically request, and you get some form that you fill out, and then you'll receive the API key. And this is just the setup that I'll be going through and then

trying out. Uh, and hopefully the demo gods are good. Someone mentioned this as, uh, a thing at one of the talks, so I like the idea. Um, and yeah, this is kind of just the setup, um, which I have kind of done to an extent. And I will now do the demo. So I'm going to kind of Claude Code. I am in the relevant packages directory. So I can

say, "Okay, can you..." So I have basically just a set of files that are in an inbox. Um, folder. So I'll just show you here. So for example, this is the graph, and it's like inbox, and you have different... Imagine these are different emails. So this is all synthetic data, but, uh, relevant data. I'm not using the real data that inspired this project. But, um, obviously, these are

stuff like, okay, um, there are some emails about an invoice and, um, some sensitive information all over, and you can just go through this. There is, um, some NDA that would have like phone number and social security number, for example. So that's how the data looks. And for example, here you can go and, uh, maybe say, "Can you,

uh, redact the data from the NDA document?" Something like that. Uh, cool, we get free credits. So, um, the way things look, one example is this. So this is some, some of the stuff I tried before. So this is the NDA, and then you get this kind of like, uh, redacted, uh,

document that extracts the relevant details, but obviously there is only email and person, and the entities are masked. And all of this is done on your VPC. So Claude Code doesn't see this stuff or whatever agent you're using. Um, and in c-certain situations, you can get better performances with the OCR stuff. Um, and so for

example, you can see here successfully loaded skill. I found the NDA document. So here I've set up the cluster, so I just input the endpoint and the API key. You would need to do this slightly different, but you can totally prompt even Claude Code, uh, and so on. And here, um, we get, okay, the file contains the freshly redacted output, um, redacted then spans from this to this.

Um, and these are kind of the label counts. It gives us some info there. Um, and maybe we can do something like, "Okay, can you pre-process the scans and also redact them?" To try to see-- So this is in natural language to try to get the OCR models to work and that tool to be called. So you can also configure the tool calling and

all that. Um, and also there is this, uh, status line here that counts the token saved, but I need to also update this a bit to kind of do it properly. But that's also part of the, um, kind of advantage that you can actually see you're saving on token costs. So I'll pre-process the thing to markdown, then redact it. Um, and it's working. And for

example, we can see-- I'll just show you some of the files, just so that I don't like go through all the stuff all the time. There is this, um, let's say, contract before. So this is how it looks. And this is a scan, so I don't know if you can see now 'cause it's a clean one, but this is-- You can see. So it's an image. It's not like text, so it needs, um,

OCR probably. And then if we do the

after one, this is some-- You can see markdown file here, um, that's extracting this stuff, but also redacting them. So... Whoops, cursor. So, um, the idea is that you pre-process the document through the OCR tool calling thing. You get, um, the token saving cost, the better context management, and so on. But you also get the

redacted file, so personal information is not leaked. And

this is also getting done in the meantime.

So that's the idea from kind of a functional perspective, but a lot of things are happening in the background, so it's not just like, um, the privacy aspect and this looks easy, but the heavy lifting is done by this part. So Superlinked, um, and the inference engine and the cluster is set up in a way that it allows you to have multiple models, have hot swapping, uh, of models on different GPUs,

um, have smarter batching so that you can kind of test out multiple models. For example, if you have five LoRAs, uh, fine-tuned to different sub-areas of your, um, work, you can kind of hot swap between them and test out which one is the best even. So we have, uh, a gateway that, um, kind of, um, helps us connect this to different worker pools that each have, um,

this batcher per worker, so that the batching is done per worker, and that gave us better performance instead of just having all the batching upfront. And this is, of course, the architecture of the MCP, uh, solution. So how it works with, um- SIE, so you can see this part on the right, um, is in your VPC. So both the kind of the MCP

work that gets offloaded to Superlinked SIE is in your own private cloud. Um, and this is what gave us the advantage performance-wise, or at least one of the advantages, was the batching technique where, um, if you kind of do the batching without having one shared queue that then each of the workers pull from. In our testing and in general, performance

was lower, so we were able to kind of do this, um, setup and have an end-to-end improvement on latency and performance, even with different models. And the idea is that you also want different worker pools because, for example, at some point you might want to try a heavier model but also have another one that can totally run really well on an L4 spot instance. So you might be like, "Okay, I don't need to waste, um, kind

of this more expensive hardware." And also we have auto-scaling, so this, um, can kind of come down when not used and so on. So, um, that's the setup. And there is the hot swapping of models, so, um, especially around smaller models that can fit into one GPU that are doing like named entity recognition or, um, even smaller generation or

embeddings and so on. Um, you can benefit a lot from having multiple models on one GPU being switched around and swapped. And this goes in the direction of kind of what the MCP does and the tool calling aspect, where you could build agents and have this inference part offloaded using Superlinked, and you can get different bundles of tasks set up, so basically

document parsing, like I explained, or embedding content, or writing code with, um, some generation models, or extracting images or captions from data and so on. Uh, or even like guardrails and structure generation stuff for policy checking and so on. So I'd be also happy for you-- So you get more credits if you, um, kind of build a project and so on. So if you contribute a tool, um, that is maybe around

content guarding or policy checking or whatever you find useful, um, we'd, we'd love to kind of, uh, have that as a contribution. And in some of our tests, we've also, uh, seen that due to this infrastructure that I explained, um, we get very good performance around embedding models. So we also have generation models. Um, but the tests that we have, the benchmarks for, for now

are around embedding models. Um, so you get kind of, um, 10X lower price roughly, um, with very similar quality. So you can see there the kind of... The best, uh, model we had per task for embedding was 99.8% to, uh, kind of the frontier one, and this-- we evaluated this using MTEB tasks. Um, so yeah,

that's, uh, that's the case. We'll have more benchmarks and details around this soon as well. But the point of this is the-- is that, um, sometimes, especially in production use cases and in-- with certain loads, you get the advantage, um, through the end-to-end improvement. So if your infrastructure and architecture is set up well, you basically get the latency improvement and the better performance, um, even

if your per model inference is not optimized. And we're doing both in our case, but that was a revelation that for production use cases was very helpful to know.

And on the example around LoRAs, we've seen that you could kind of, mm, test out LoRAs fairly quickly and fine-tune them, so we're exploring work on that area. Um, so some of the colleagues worked on this German language-specific LoRAs that were fine-tuned, and they were fairly cheap. So having a way to do multiple LoRAs and test them out in production and deploy them quickly,

um, seemed to be quite useful and, um, improved performance in this very, let's say, niche, um, use cases like German legal language, let's say. And, uh, this is kind of how the MCP works. Um, I mentioned a bit around this.

And there are some failure modes that are already there. But again, this is working and it's well, but there are so many more things to do, and I'm kind of very happy to have your, uh, input and PRs and, uh, even just like, um, comments. So you can add me on LinkedIn and all that, and I'm happy to chat always. And that's the idea that the same kind of MCP edge handles every

document job. So you can do question answering, pulling facts, reading documents. Um, so yeah, this should also

work and there is different, again, labels extracted and so on. And you can try this like, um... This, I think, moved the number. But again, um, you can test this live and, um, test out different tools with kind of your own demo data.

And I've explained this to a certain point and what it does now. Um, and yeah, there's the token-saving aspect, and that's very important, um, and not sending data to external APIs, and it all runs in your cloud. Um, and there is a lot of stuff to do kind of in the future. Um, but the operational capability is still there. So we have the

Helm charts and the Kubernetes cluster, and you can use also Terraform Apply to deploy a cluster, which is also open source, so it, it's not, um, hidden, like kind of, uh, just the code is open source, but we have basically everything. Um, and this can go beyond just documents. So if we look at this idea of having the inference solved as a little box in your whole workflow, it unlocks a lot of

opportunities that can go kind of beyond text with other models, um, looking at transcripts, um, even graph-based data, generating ontologies and so on by different tool calls, structure generation. So there are, um, different opportunities and, um, one direction that we're exploring as well is model routing within your own private cloud, um,

which is quite powerful, and I think the, the field is moving a bit in that direction with usually teams exploring, um, this API-based optimization where you have, um, a combination of models working together and the end-to-end performance is better. Um, and there is an option to do something similar in this way. However, this is more like a future roadmap idea, so this is currently not built in. But, um,

the idea is to also pick the models based on the task. So the tool calling will not be tied just to the tool itself, but you could also understand which model to pick for the underlying tool. So if I've only set up, um, one OCR model, I could say that, "Okay, for this tool call, I actually want OCR cheap," or some other sort of tool call that, depending on the task, adapts to what I'm trying to do. And, um,

that's a powerful direction. And there is also playing around with like intent, and there's this mixture of agents approach. Um, because if you already-- Another powerful aspect on why SIE is really good for this is that if you already have the models warm in your GPU, you can hit them much quicker and get the responses quicker, and you can do this model routing based on also

the, the-- how hot the model is or how kind of-- what, what was evicted last, what wasn't. So there is a lot of options also playing around this, uh, card of latency and trying to figure out what are the best models, not just from a general perspective, but from an infrastructure perspective. And, um, doing this is, uh, quite useful, and I, I think a lot of, um,

stuff will be done in this, in this way, um, kinda fairly soon. And, um, yeah, this is the idea that you can kind of, um, estimate, uh, per model to find which models are warm. Um, and then in some cases it would be cheaper to hit a model that's already hot but more expensive rather than reloading a model that's cheaper but kind of, uh, not already there in your GPU. So

this logic can be set up as well to optimize costs and usage beyond the tool level. Um, and I'm just mentioning this stuff just to kind of showcase how powerful, um, inference is and having good model inference set up, um, with all the infrastructure around it, uh, can actually unlock a lot of, um, use cases. There is also, um, a potential for doing

stuff like, um, judges talking between each other or like the council of models and so on. Again, this is more of a future roadmap, but, um, this is a direction that also is an option for things like this where, okay, if you want to include some maybe reasoning tool calls or adjust the response based on like difficulty of tasks, which models are called. For example, uh, an issue I had when building

this was that for one of the summarizing tools, I had, um, model that was, um-- that had, um, thinking tokens. So basically the summarization, mm, was either very short or it didn't happen 'cause everything was done on the thinking side. So, uh, you have to also kind of keep in mind what models you use and whether you toggle the thinking tokens or not. Um, but sometimes reasoning can be beneficial and,

um, it's useful to have a way to do that quickly from an infrastructure side.

And of course, there are some kind of, um, downsides to having, um- A router or a council and so on. However, um, we're also very strong on evals and trying to test models before doing this. So, um, there are different ideas here that can be done. Um, and yeah, um, basically, we don't want to also spend GPU on some models reasoning forever and then

nothing happens. Um, or also have biased models as judges, um, or kind of optimizing something, uh, that, um, then becomes kind of-- By, by optimizing something, you

kind of escape from making it as a real target, but it just becomes something that, like, the models hack and never actually, um, use it-- You can never use that as a proper evaluation. Um, and you can look at our repo. So this is the, kind of the QR code if you haven't yet. Um, and I think the main takeaway for today is that infrastructure and inference

is far more important even for this very API-friendlier ergonomic designs, where you just work with Claude Code, and you can kind of offset your, um, sensitive data, your specific tasks in different ways. And, um,

still the backbone is, uh, the inference. And for example,

I will go here again. So this will be published as well. And, um, you can also find kind of what files are supported, where the LoRA aspect feel, uh, fits, um, what are the kind of, uh, the troubleshooting guides, and so on. And also, um, the most important thing is ask for kind of your, uh, API keys and so on. We also have a full model catalog. We're kind of

also revamping this to be more detailed and useful. But basically, you can have different, uh, you can select different output types, different architectures, because, um, in order to optimize, um, the models, um, and the inference, you need to adapt models in different bundles. So you need to kind of all models maybe implement attention differently, so you cannot run them and run the forward pass in the same way. So you need to have different model runtimes for different model

families so that this works. And there are a lot of details around this. And you can see that models are tagged based on, like, whether they do encoding or scoring. So you can also use, um, scoring models that do like re-ranking basically, if you-- even in this use case of the tool calls. Um, and the advantage there is that you can basically play with your own version of, uh, retrieval through this, um,

MCP and so on. And I would really love if you could kind of contribute to this or, um, give us ideas on how to kind of set this up and, um, build more stuff on top that, um, people find useful. Um, we did, um, a hackathon in London with TechEurope and DeepMind recently, where a lot of people kind of tested this out and were, um, very kind of happy to

work both on the retrieval and re-ranking side, but also generation. So, um, having the, the way of doing both but being supported by that inference is, is very cool. And again, I encourage you to take this, um, free, um, kind of cluster infrastructure credits that you can use. And we also have a lot of examples and, um, full kind of docs that you can have a look at. Um,

basically a quick start and then different model versions and how you can also look at how you can migrate. For example, if you have some workflow done with like OpenAI API, then you're like, "Okay, cool. I wanna test this thing out quickly. What can I do?" You have those, um, options as well. And, uh, this is the repo. So again, this is the package. Um, and here you have kind of what it exposes,

um, and how the credentials are set up. So the, the README here, um, can be, um, checked out. This is the example. So if you contribute with examples and have something more here, that would be very useful. And, um,

this is where you apply for the credits that, um, help you to build, build things and try things out. Uh, this was very popular at the hackathon, so, uh, very kind of happy for you to try this out. And I think since we're slowly approaching the end, I can take some questions as well. Um, you'll just kind of speak and I'll

restate and reiterate the question because of the recording. So yeah, I'm happy to answer a few things, and we can also play around with this more if you have some query that you want to try. Um, yeah.

So, uh, using MCP through Claude, uh, there-- um, I'm still concerned about the privacy issues, right? Because Claude is gonna consume the tokens of whatever document you might be sending off to be evaluated. How do you control-

So it wouldn't do that basically. So the concern is around, uh, the question is around privacy. So basically, you just-- Claude would just get the redacted version of the document, so it wouldn't get the full document that you're inputting there. So that's kind of the, the setup that we have currently. So it would only see that side of things.

But I'm saying-

Yeah

... you're in Claude, you're telling it to do something-

Yeah

... that's ultimately gonna go to an MCP, right? That's the step.

Yeah.

Claude had to make the decision to call the MCP. At some point, it will-- it could have read the data out of the file as part of its decision-making. How do you-

Yeah. So I mean, this can be kind of evaluated, like whether this happens, like whether Claude does this kind of off, off-rails situation. Definitely, that can be kind of, uh, tested more and more. But in the test that I've done, like, uh, if you host the kind of MCP and everything else is on the virtual private cloud, um, this seemed to have worked without kind of the data leaking. But I'm sure there can be more guardrails to kind of reinforce this at that initial stage.

Or in the worst case even, you could say, "Okay, I'm concerned I can build my own harness and use an open source." Exactly.

Oh, yeah. I, I get that.

Yeah, yeah. Yeah. And in that way, even, um, like you could still save on tokens and get better context even if... Like this is Claude Code in my example, but it can be any harness. If you implement the tool calling well, I think, uh, this can be done. But happy, uh, happy to get a contribution around this as well. Um, could be very useful to have this like pre-processing layer as well. Um, yeah, another-

Yeah, yeah.

Yeah.

Your MCP server's on your private cloud, right?

Yeah.

So then you have that private data like he's talking about.

Yeah.

Uh, it goes through your MCP and reads the data through that, right?

Yeah.

That setup.

You'd have to like advertise the existence of the file to the worker. Yeah. Zero trust, not connected to the same file system. Yeah. So it doesn't have to be.

Mm-hmm.

The SIE would have to pull the file down.

Yeah, yeah. So again, the question is kind of like how do we set this up to make sure that the privacy is well preserved, right?

Yeah, on, on your server. How is it like-

So on, on the, on the SI- side of things?

When I launch a cluster, how is it set up?

So the cluster in this case is like, um, what we have, um, but that can be your own cluster. So through the repo, you can set up your own cluster in your own, uh-

Configure however I want.

Yes, exactly. Yeah, so you can configure the cluster in any way you want. I'm just using a managed cluster that we have for the purpose of, uh, the demo and the example, and we use that, for example, for hackathons and so on. So we host the hardware. But you can totally do this yourself, so it's self-hosted. And y- in the-- as I said, in the repo, you have the ability to do Terraform apply and have all the infrastructure set up. And if you have the GPUs and so on, you basically,

um, yeah, have that set up and it's totally your own.

Your, your MCP has got a file watcher?

Sorry, again?

Your MCP has a file watcher and reads the file?

The-- Does the MCP have a file?

Does it read the file? Consume the file.

So, uh, it just sends it to the main worker and, uh, there the file is processed. So kind of there is that... Yeah.

And yeah, you can, uh, again, I think at the entrance there is the, uh, free compute that you can get to try out. Um, again, if you want to self-host, you can still self-host. It's not, um, strict in that sense. We just do this so that things can go quicker. Um, but again, you don't have to, uh, do it in a way that you use our cluster. You can self-host.

And yeah, we're-- O- also, you can kind of add me on LinkedIn again. We can chat there and, um, thank you for attending.