Why every AI Engineer needs an AI Gateway (ft Portkey.ai CEO)

Hey everyone, welcome back to another short version of "Late in Space." As usual, I'm Atlas Sio, partner and CTO at Decibel, and I'm joined by Twix, founder of SmallAI. Hey! Today we are joined by Rohit Agarwal from Portkey.

Welcome.

Very good to be here. Thanks, Twix.

Yeah, so, uh, I think we've— you know, we crossed paths a few times over the last couple of years, I think. And I had been kind of lukewarm on gateways originally, and I think I warmed to it more over the past year or so as I was building, you know, AI news and also I just talked to a lot of other people.

Alessio has thrown two Decibel AI summits now, I think, and it also always comes up in the enterprise. With, I think, Salesforce, Walmart, you know, all these kinds of names that I always personally cite as inspirations. So then I talked to AI engineers, and they're like, "Why do I need a gateway?"

And I kind of— I'm just calling the APIs directly. And I think I needed a blog post or a podcast to point people to. So I started kind of in my head titling this "Why We Need AI Gateways."

So, uh, first of all, I mean, Rohit, like, you know, what is an AI gateway? What are the jobs to be done?

Yeah. So I think AI gateways are essentially, um, the operational platforms that enable teams to connect to LLMs more efficiently. They help you improve cost, performance, and accuracy by not having you to build individual connections to all of these different AI services.

So this is something— almost think of it as, I think it's a little more than a proxy, where it's basically routing all of your traffic to theright LLMs, and then providing value on top of it in terms of monitoring, guardrails, prompt management, governance.

And just because you said the magic word, "routing," writing is not always necessary though,right? People can still use Portkey. Just having one model they want to use, or like specifying. You don't— you don't have to make the decision for them.

Yeah, yeah, exactly. So there's no— and in fact, I would say in production, 90% of the use cases do not use automatic routing. What they want is deterministic flows, as long as the gateway manages authentication, authorization for them, it's perfectly fine the request hitting a specific model that the request was aimed for.

Yep. And just one question that came out yesterday: we had an AI center of excellence group with the Fortune 500 folks, and I think there's increased interest in maybe some routing capabilities because of reasoning models. I think before maybe there wasn't as much value of like routing between 40 or like 40 million, you kind of knew what to use.

But now the latency of the reasoning model is much higher. So people are trying to figure out, "How do I route specific questions to a reasoning model?" versus like, "When I can handle it with a simpler one." So I'm curious if you've seen anything in your customer base.

Yeah, I think so. The more people are building these complex, compound systems, we're seeing the more use cases for routing come up. So I think reasoning is definitely a place where we've seen adoption for the gateway very quickly.

I think DeepSeek was the first model where, within the first 6 hours of it launching, we had so many pull requests on our gateway to say, "Hey, support DeepSeek across all the different layers that the gateway supports." So that's obviously been popular.

I would also say with the rise of agentic systems, where people are building multi-step agents, that's also where routing is becoming really popular. Because you might want to have different tasks point to different LLMs, and then you don't want to build authorization and all of these layers on your own.

So you end up saying, "Okay, my agent is just going to connect to an LLM router, and the router figures out everything else." So it's basically simplifying the interface between an application or an agent to the various different LLMs I might want to use.

Yeah. Like, we actually see this a lot. You know, I think even at a very basic example, just kind of normalizing the APIs between providers. That's a very simple job. Everyone originally, they started out in their code base.

Like, they're like, "Oh, I started with OpenAI, I'm going to add Anthropic, and then I'll, you know, I'll add like an abstracts, you know, class that like has the interface,right?" And then they add Grok, they add Gemini, all these other things, they add DeepSeek, and then it starts to be a whole thing inside of their code base.

And then, of course, they forgot to add logging and all these other controls, and they forgot to add keys and all that stuff. So like, my criticism of like the frameworks, like, you know, like not to pick on them, like, you know, LangChain, Pydantic, which we also just talked to, is like, all this doesn't belong in your app code.

Like, it should just belong in a gateway that's like specialized to do this task. You just mentioned also that you're open source. So.

Yes.

I'm kind of curious. Like, do you— like, so my very strong opinion is people should never write that code. Never even import that code. They should just delegate it to a proxy layer. With the one downside, of course, their proxies can go down.

And if you— so if your proxy goes down, then your app goes down.

Yes. I agree. I think, um, so a couple of great points there, Twix. I think I agree with almost all of them. And I think the reason people just start with SDKs in the first place, like LangChain, and again, not picking on them, I think it's great to get started with, is just the ease of use.

Saying, "Okay, I want to use OpenAI, great. I want to use Anthropic, great." And more often than not, you'd see code bases, even the open source world, where you have this JSON that keeps getting bigger and bigger and bigger, saying, "OpenAI, this is my key.

Anthropic, this is my key. And these are the models I'm using." And that just keeps growing to a point where it's unmanageable, and then you have to start thinking about alternatives. Not just that,right? Even simple stuff. Retries. When a model fails, how do I route it to another model?

So all of these things are, I would say, the simple, boring stuff that everybody does not need to do in every AI application they're building. So it's just better off delegated to an AI gateway, and the gateway is doing all of this, you know, stuff for me while I focus on building my AI application.

Now, I think the question of reliability comes up very often. Not just reliability, even latency,right? The gateway introduces latency into the entire process. So how do you build a gateway that's reliable and that's extremely fast? So I think in our open source gateway, something that we claim is that we're the fastest, most reliable gateway.

And the way we've been able to do that is just by reducing the size of the gateway itself. So the gateway, when it runs, has a memory footprint of like 21 MB. And the way we've been able to do it is just using a very interesting architecture where we're using transformers in JSON to do everything out of the box.

So that way, the memory footprint is extremely low. You can achieve extremely high throughputs on very low compute capacities, which also decreases latency. So you can run multiple HA clusters without really increasing costs too much. So that's something I think that's unique to our open source gateway, which we also use in our production.

Yeah. One thing I got to double-click on, you said transformers in JSON? What did you—

So basically, yeah. So the way most gateways are written is that you will just write classes upon classes to have support for every single SDK, AI provider, vector database out there. Instead of that, what we've said, every configuration is just a JSON file, and we've written a fast JSON transformer that can help transform an incoming request to an outgoing request as simply as possible.

Because of that approach, we have our code base is smaller, the memory footprint is much smaller, and thus extremely low latencies as well.

Okay. I think, like, when you say transformers, I think we're talking about the sort of LLM type transformers.

Yeah.

Yeah. Okay. Yeah. So like a mapping thing. Yeah, I mean, like, so like, what else are the sort of the next jobs to be done? You know, like, I think we talked about, um, I guess there's like the security element as well,right?

Like, it's also security ops. I don't know what other buckets. Can we— can we sort of at a high level, what's the list of jobs to be done?

Yeah. So I think the first one's routing, as we've discussed. The second thing that I see getting adopted the most is usually observability. Saying, "Can I monitor for price, performance, accuracy?" Because I have these monitoring plugs set up on the gateway itself.

So I have one place where all of my metrics are being emitted, and I can then capture and view them on a dashboard saying, "Is my application improving, progressing, how's it performing?" So observability becomes the second big thing.

And I think with enterprises especially, we've seen the concept of rate limits and budget limits become very, very useful. I think we've seen a lot of cases where teams will not adopt the gateway, saying, "Hey, we don't need it, we're comfortable in our applications."

And then there'll be a point where some rogue code suddenly finishes their budget for the month, and they're like, "Oh, we need to move to a gateway so that we have better observability, we can put better limits in place so that these things don't happen in the future."

So I think observability is the second layer, which I think is really important for teams building with AI. The third thing, I think security, but more than security, I think it's guardrails. A lot of times we've seen, and it's very, uh, it's very common that in streaming responses, you just get an empty response.

So how do you now guardrail for those use cases so that you're not showing like inaccurate or incomplete responses to your users? And when I talk about guardrails, the first thing that comes to mind is, "Oh yeah, we have to do PII redaction and sensitive data redaction."

But somehow we've seen that the more common use cases for guardrails end up being, you know, "Is it theright length? Is it using specific words that I don't want to use? Is it mentioning a topic that I'm not talking about?"

So those are things that I think are really useful on the guardrail side of things. And again, you can decrease latency massively by building this on the gateway rather than building this within your application. So I would say those are the three things we see the most, um, on top of the gateway itself.

Any smaller up-and-coming ones? I think Alessio and I want to dive into the main ones, but just want to do a map, full map, like smaller than the main.

I think the smaller ones is, can we manage prompts directly on the gateway itself? So prompt templates on the gateway. So that's interesting. Um, we're now seeing applications for governance on the gateway. So can I just do audit logs, et cetera, directly on the gateway and then send out those reports to my CISOs?

Cost attribution and chargebacks is becoming a use case quite a bit. So you've seen teams connect Portkey's data into their metric system, into their cost metric system, and they're doing chargebacks to the different teams. So those are smaller use cases.

Chargebacks meaning sort of like internal, internal costing.

Internal costing, yes.

I see. Okay, cool, cool, cool.

Yeah, yeah.

Yeah, not much to say there. Yeah, Alessio, I don't know if you have a, you want to start on observability or the guardrail side. I can take the other one.

Yeah, I would love to start on the guardrails side. We had Guardrails AI on the podcast way back in the days, almost two years ago. I think this started as something that people were maybe naively doing with structured outputs in a way, where it's like, "Hey, we're putting guardrails by forcing the structured output to only say certain things."

And then the models are obviously taking their own stance, and we should own the guardrails, and we'll say what you can and what you cannot do. So I'm curious about what you've seen people do in guardrails that the models let you do that shouldn't.

And maybe on the flip side, what I like some use cases that are not able, people are not able to do because of the model guardrails, where maybe open source has like an advantage.

Yep. Yep. I think, so I'll tell you this, there's a dissonance between what is a demo wow in guardrails versus what actually gets used. So I think in demos, what people like the most is, "Oh, can I redact sensitive data?

Or can I do PII redaction so that no personal data ever leaves my system and goes to the LLM?" This LLM could be private, but I still don't want this data leaving my servers to go out, and I want to build guardrails around that.

In reality, we've seen what gets deployed the most is regex-based guardrails to say, "You know, I want to catch for specific words and then take certain actions based on that." Or, "I want to catch for empty outputs." A lot of times, people will set up rules within their prompt that say, "If you don't know something, say IDK.

Can I now capture that IDK as part of the guardrail and then do some orchestration based on that itself?" So those are, I think, the use cases which are a lot more practical today, which are getting implemented in guardrails a lot faster.

But I think, interestingly, moderation, PII redaction, sensitive data, blocking harmful requests, all of this is getting rolled up into the models directly itself. So if you're using open source models, then you would want to build your guardrails yourself.

But for a lot of the commercial models, content filters and moderation is very much built into the model itself.

Yeah. And so like, there's only so much you can do about that. So I'm kind of curious, like, when you say these kinds of, like, you know, you capture things in guardrails and you do orchestration around it, does that happen inside of Portkey?

Or is it, am I calling Portkey again? Okay. So you run code.

Yeah. So what's, so it's actually not, so the guardrail code runs on the gateway itself. This could be like webhook calls outside to third-party guardrail providers as well. So we have integrations with Petronas and Pangea, Pillar, and more.

So these could be guardrails that are getting executed elsewhere, but then Portkey is driving orchestration for this execution. The other interesting thing is, so we, HTTP status codes aren't built for inaccurate LLM responses. So what we do is, whenever there's a guardrail failed thing, we send out a different status code.

So we'll just say 246, which means API was successful, but the guardrails failed. And because on Portkey you can write orchestration, like, whenever you see this HTTP status code, retry the request, you could probably just set it up to say, "If you see 246, retry the request."

And those, that's the kind of, like, retry, fallback, load balancing implementations you can do directly on the gateway.

I'm trying to look up status code 246. That's not a standard code,right? You made that one up.

Not yet. Yes.

Okay. I mean, we can make that an industry standard. Why not? Okay. So yeah, I mean, my trouble with that is with just a dumb retry is that usually the retry prompt should be different than the original prompt.

This is what I found. So I actually take it, take one to take control in my application again, because you don't have my context, you don't have my tools. Like, there's just a bunch of things that you'll never have.

So I was just kind of doubling down on that part. Okay. Shall we move to observability or anything else in guardrails? So observability, the difficulty here is that there are a bunch of existing observability companies,right? So there's a question of, do you eat their lunch or they eat your lunch or do you, you know, coexist and be happy?

What is your philosophy here?

So I think, do we want to become the best AI observability vendor on the market? I'm not sure that's our goal. We're saying that the best LLM metrics can be produced directly on the gateway without every team having to instrument their own code bases to pick out these metrics.

So if the gateway is already able to produce these metrics, clean it up, and share it to an observability vendor, I think that's the best approach that we want to take. So our goal is, can we surface the best metrics for your agent, for your application easily?

We do have a dashboard where we'll show these metrics directly as well, but we've built extensive integrations with all of the monitoring and observability providers that you could take this data, put it into your observability vendor, because more often than not, you might want to do tracing and tracking before and after the LLM request as well.

So it's not just AI observability, but there's tons of other things that you need to do around it, which probably is better done on like a Splunk or a Datadog or a Grafana, and we're totally okay with that.

Yeah. Yeah. There's been, I think one of your competitors, TraceLoop, not really your direct competitor, but there's been some attempt to standardize. Even in OTel, the standard things that people emit. Any adoption there? What is your view on LLM-metry or anything of that sort?

I think, so we get asked this a lot saying, "Are you OTel compliant?" And that's, I think, more to do with cross-compatibility than anything else at the moment. I think I'm really excited to see where does open LLM-metry take this.

There's standards that are evolving directly in the open telemetry libraries as well, especially for agentic flows. So I think we're just keeping it open, saying we'll produce logs in an OTel compliant format, but does it then also follow additional rules being set by players like open LLM-metry or others?

We're not completely sure yet, because I think they still bring in their own flavor, and I think it'll be some time before standards are established. I think today everybody does expect that, "Let's use an interchange format," which works well with multiple providers, and I think that's where we're saying, "This is what we'll do for sure."

Yeah. I was saying, like, my criticism of this attempt so far is that usually they end up encoding the previous paradigm. So when, you know, completion paradigm, yes, chat completions, yes, and our reasoning, you know, it keeps changing and you're always behind.

Exactly. Yeah. I think, I don't know how you think about this, but, you know, standards usually evolve and there's some amount of coherence and stability in an API. I think the APIs themselves change every month. So I'm not sure how there's going to be standardization that occurs.

I also heard this on just the chat completions API request. Like, I heard this from customers quite a bit that, "Why don't all providers just use the same format?" I'm like, "Which format should we choose and what features should we leave out?"

Yeah. I mean, it's always tricky. Okay. Then one more thing, you also mentioned agentic logging. What's going on there? What is, what's new? What's different than normal completions?

Yeah. So I think two, three things,right? One is.

Sorry, sorry, sorry. Oh, yeah, yeah. I pressed mute for myself and I accidentally paused it.

Okay. No worries. Good. So agents,right? So I think two things that are interesting in agents. One is it's much harder to see what's happening within an agent when an agent fails. And agents today fail a little more than LLM calls themselves because of error multiplication over multiple calls.

And plus, there's so many moving parts within an agent, you want to be able to see very quickly what happened within a session. And I think that's something that's really critical for observability. It's not just tracing, but do I have theright UI to follow the flow of an agent and see what wentright or what went wrong?

I think that's really interesting that we want to capture. The second part is, which is, I think, a lot more interesting to me is different parts of the agent can use different LLMs and different services to complete their tasks.

And for that, how do we make it super easy for teams to be able to use all of the resources that they have rather than having to, you know, manually go and do everything themselves? So you could always say, "Okay, if it comes to node A, always hit GPT-4.0 and node B is DeepSeek R1," but then it'll be so much more interesting that the LLM and the agent itself is able to decide, make these requests, and the gateway is always there saying, "Let me know and I'm going to make those requests out there."

I think those are two things that are really exciting. I'd love to see how agent fine-tuning comes into play as well, but I thinkright now it's observability and multi-LLM agents.

I think multi-LLM agents is something that I'm still trying to form an opinion around because it's not really about changing LLMs, it's also about changing prompts. It's a whole set of things that need to change, changing tools. And so, like, I don't super care about which LLM is driving it.

I'll use the best LLM that fits the need, but also I don't really want to change it that much because the endpoints I add in, the more downtime I accumulate, you know,right? So, yeah, obviously there's routing and all that that you do.

Okay. Anything else in regards to just the general observability trends that people want? I don't super know, you know, what else, but like, I'm just kind of throwing it open in terms of like, what are people evolving towards or what are people discussing that is up and coming?

I think the other thing that's interesting is how do we connect guardrails information to create like a real-time feedback log of how your application is performing? So while you have evals on the development side, what do evals for production look like?

Which is more like monitoring in the traditional engineering world, what are you monitoring in an LLM application or an LLM agent is basically, I have a set of guardrails or checks that I have defined, and then I'm going to run these checks on every request so that I find out if my application is doing well or doing worse.

And that's almost like evaluations in real-time over large sets of data. And this is becoming that performance metric, which is the third leg of this tool here, which is you've got price and performance, which is solved for, but then accuracy is what people are now solving through checks, check adherence, and human feedback together.

So that's an interesting area. I think it's evolving very quickly. So we're also trying to figure out what works best, but that's an interesting place where teams can then figure out if their applications are doing better or worse.

Yeah. You know, the topic of human feedback is something I'm interested in. Subjectively, I know that all the platforms have it, but I don't use it. Human loop, brain trust, whatever, lag views, I'm sure you guys have human feedback.

Is that true?

Yes. I think it's not used as much. I agree. And I think that's something I tell every customer that you need to close the loop and feedback is going to help you. I think the teams that are doing it are really happy.

They're not doing it.

They're not doing it.

Yeah.

So how much additional work? Is it not important? Like, how can we make them different?

I think it's just, it's just like, at this moment, it seems like people just want to get it done and get it up and running and then keep improving the input side of things. I think the output side of things will come.

Once we've reached stable state with their production applications that are stable and then they want to start optimizing is when they'll start looking at human feedback as well. Because I'm also assuming people haven't figured out theright paradigms to collect human feedback.

Like, the thumbs up, thumbs down is really boring. Like, when was the last time you did it on ChatGPT or Claude? We just don't do it. And because those feedback collection metrics are so poor, you tend to not collect them at all.

So I think the teams that have been successful is when they're mapping these feedback metrics to a business metric that they track. So, for example, there's a customer that uses AI to generate videos automatically and they track the download rate of the video.

So every time a video is downloaded, they send a positive feedback into Portkey. So that's when they're able to complete the loop, which works really well for them. But if it's just a thumbs up, thumbs down, even I've begun to feel that that's probably not very interesting to track.

Yeah, it's not. Yeah, not super useful. When you send the positive feedback, whatever that means, is on a trace ID,right? Like, you generate a trace ID and it says.

Yes.

Have you guys published a best practice around what is a trace, what is a session? I think, you know, this is something I struggled with in building my own applications. Obviously, there's a lot of philosophies. This is like old school observability stuff here, but I would love some guidance.

Yeah. I think, I think this is something we should do. Maybe just look at all of the different use cases and then publish a guide on what's a trace, what's a session, et cetera. I think we try to keep it as close to the open telemetry standard as possible, saying a trace ID actually is not a hierarchy.

It's more just a thread that's putting multiple log calls together. So every individual request, so this could be an LLM completion call, a tool call, an agent run, you know, any part of the process is a log, which can have multiple events in it, et cetera.

And then multiple logs have linked to spans. And similarly, you can have, you know, a hierarchy of spans. But then all of these have a trace ID, which is more an attribute that's linked to it, which allows you to trace how the request completely went through from start to end.

And a trace can have multiple sessions within it as well. So a trace is a lot more loose where you can apply it however you want just to trace the flow of a request. A session is more, I think, within a trace, how does a session perform?

I think now that I talk about it, in chatbots, I'm not really sure what a session could mean to multiple people. So yeah, maybe something for us to think about a little bit more as well.

Yes. I think guidance, thought leadership, I mean, this is the kind of stuff we want to publish on latent space,right? So when you have it, let me know.

Sure.

Yeah. I mean, it also differs by use case,right? Chatbot with single person, chatbot multiple people, but then also like passive agents are coming up, you know, like working in the backgrounds, you know, if they're like reading my emails for me and notifying me.

LangChain is building this like ambient agent thing. Then obviously they're tooling LangSmith for that stuff. And then there's also the sort of the long-form

sort of passive commentary type things. So like, you know, I recorded an episode with Bee, which is one of the AI wearables.

Okay.

That is just recording everything I say and just giving me reviews and feedback. So what is a trace? Trace is me living my life.

Yeah.

So every day is a session? I don't know. Every conversation is a session? Every, you know, hour? I don't know. You know, it's very, very vague. And I'm just making up as I go along. Like me, hands on keyboard, coding this thing.

I'm so tired. I don't care what, I'm just going to put it in some random trace. And of course, they're not named well so that when I go and look at my logs later, I don't know what the hell I'm looking for.

It's really messy.

I agree. Yeah. I think there isn't, and I would imagine like with more ambient agents coming in, there might not be a clear start and a clear end. So it'll be interesting to see how we start solving this problem.

Maybe the whole concept of, you know, there's a typical start and a typical end goes away and we rely a lot more on search and indexing rather than having to, you know, browse.

I see. I see. Yeah. True. Okay. Cool. So we'll see you in New York. Any thing you're looking forward to? Anything you're going to announce soon that you can sort of tease?

So I think we've been doing a lot of stuff with MCP of late. I think that is something that I am super, super excited about. I think the future of agents, the way they connect to different services is going to be MCP.

And second, I think there's been a lot of positive developer energy around this. Like today, you can look up any service, just say MCP server, and somebody in the world has already open sourced a really nice MCP server.

And I think that's something that's really interesting. And we're trying to see how we can connect that to the gateway and make it easier for people to connect to MCP servers because I think the networking part of MCPs isn't super straightforward at the moment.

So we want to do that with the open source gateway. So that's going to be something big that we'll probably announce around that time.

Well, we have the creators of MCP there. You can talk to them and I'm sure there'll be a lot of useful discussion. Yeah, just quickly, like, so I think I'm surprised by the adoption of MCP. When Anthropic announced it, I just viewed it as a way to extend the Anthropic desktop app into your local file system.

Okay. And then, you know, more broadly, there's just like, there's OpenAPI spec,right? So MCP is just like a slightly different OpenAPI spec. Like, why is it so revolutionary?

I think the only reason is that LLMs expect a specific JSON that they need to take in the tools parameter and they output it in a specific format as well. So yes, you can always write tools yourself and then connect APIs to LLM requests.

It just, MCP makes it so much simpler. So whenever I need to use Slack, I can just say, register Slack's tools in my LLM agent. And then whenever a tool needs to be called, I'll call the Slack server to say, call this tool.

So it makes the whole process a lot more simpler instead of me having to figure out all of the SDKs and the networking pieces myself. I think that's what makes it really interesting. The other part, which I think nobody's exploited till now, is the two-way communication.

So can the Slack agent at times also come back to the LLM and maybe suggest something or request a completion from the LLM itself? I think this two-way thing hasn't been explored too much, but that could be really interesting in the future.

Super interesting. I didn't even know the two-way agent thing existed. And I read the MCP spec, I think, you know, I browsed through it. What's the mechanism? Is it like a WebSocket or like what?

It's currently using an RPC. RPC style. Yeah, but it's on, it's a STDIO protocol. They support SSE and STDIO. They've not, I think there's a long discussion happening on whether they should support WebSockets or not, but they've not done WebSockets until now.

Okay. I mean, SSE is good enough. Okay. I mean, that sounds like the basis of some kind of multi-agents communication thing, which is super interesting. Okay. Well, looking forward to what you said there. Anything else just broadly, you know, floor is open.

No, I think, so I have to come back to the AI gateway,right? I think something, so we actually started off as an observability player, but then we've seen the AI gateway piece take off quite a bit. And I think the more teams start to go into production, the more they want platforms like this.

And I feel this is similar to what happened with the cloud era back in 2012. You will not have cloud adoption till the time DevOps did not take off and companies like Datadog, Cloudflare, et cetera, didn't help you build applications, you know, for faster, cheaper, more efficient.

I think the same is going to happen in AI as well. As more and more teams go to production, you need tools like, you know, not just the AI gateway, but multiple other operational efficiency tools that will help you stay reliable, efficient in production.

I think that's something that I'm looking forward to in 25, 26 because we're seeing a lot more teams finishing their POC cycles and moving into production with AI.

Yeah. Awesome. Well, that's it. Thanks so much. This is meant to be a quick episode. And thanks for jumping on. You know, we wanted to publish a blog post, but I often like to do these conversations as chain of thought for the blog post so that when we come out, we'll just have something to reference.

No, this was interesting. I think I did not even think I would touch upon too many topics, all of these topics if I was writing it myself. So I think this probably would be very helpful when you write the blog post.

Multi-agent chain of thought. Allright. Thanks, Roit.

Cool. Thanks, Fix. Bye-bye.