# Langfuse Acquisition and AI Agent Strategies

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-06-04

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for me.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist Podcast.
I am your host, Tobi.
And my guest today is a German guy called Max Deichmann.
And like different from many other German guests, he doesn't build like B2B software for the German speaking market, but he builds a very international...
product, AI first, at the forefront, I would say.
One of the rare, I would say, deep tech companies, if that term still exists, or AI native companies that I saw recently coming from Germany, he went through an absolutely crazy ride, was acquired by ClickHouse recently, as many of you or some of you might have noticed.
And beforehand, I don't know, went like...
Crazy zigzag growth path to where they are now.
Max, I'm super excited to have you here.
Yeah, thank you so much for having me, Tobias.
Very excited.
I hope the introduction was appropriate.
Yes, thank you so much.
Okay, very good.
So I always start with the same question.
What is your nerd path?
How did you get into computing and why?
Yeah.
Back then, I studied business, actually, and then realized that mobile apps on the iPhone are super exciting and just started with friends building mobile apps, really, because we thought there's so many cool things to build.
And this is how I ended up in engineering.
I did this online course by Harvard.
It's called CS50.
It's like free and online.
So I learned the fundamentals, basically, on a semester abroad in Singapore, I think, at the beach.
Okay.
And then you decided to study at one of the best universities for IT in Germany or IT computer science.
Yeah.
Like I went to technical university in Munich.
This was great because you can go there, take technical courses, even if you have a business background.
And then also ended up in CDTM where I met one of my co-founders, Mark.
And you still look quite young.
You're like...
33.
Beginning of 30s or something.
Wow.
Yeah.
Yeah.
So you hit the right spot straight away, went into like a crazy business, crazy direction and were then acquired.
That's straightforward, right?
Yeah, this was never the plan.
We started building Lengfuse and the traction was really, really good by the end of last year.
And the goal was never to sell this quickly or something like that.
I also believe that if this is the goal, like selling something quickly, then...
Probably it's really hard to achieve this because you really need to care and really need to think long term about what you do.
But yeah, then the opportunity came up and it made so much sense to us that we then decided to sell to ClickHouse.
Okay, yeah, interesting.
I mean, it sounds like the wet dream of every WHU student who then found something, sells it super quickly, etc.
But yeah, as you said, for techies, it's mostly different and also for companies these days.
that really have product market fit, it's supposed to be different and also changed.
And was it like ultimately a scratch your own itch topic or a market call where someone, some investor told you like, hey, you have to go agentic, you have to build something for agents or why did you end up building LegFuse?
Yeah.
So basically we were originally built completely different things.
typical SaaS products.
And we managed to end up in Y Combinator with one of these products.
We had traction, we had users, we had a fully functioning product.
We were traveling to San Francisco thinking, we need to scale this.
How many salespeople will we hire now?
How many engineers will we hire now?
All these things.
And then we quickly realized.
that we weren't too excited about our customers.
And also the product back then, we weren't able to charge as much as we needed to, to afford a sales-led go-to-market approach.
And both of these topics basically ended us shutting down the product that we had.
We basically fired our customers.
This was a very hard moment.
We were in San Francisco and then all the other teams in Y Combinator, they're pushing really hard, having more and more revenue.
And we were in front of a...
Yeah, of nothing basically each week and iterating.
And then at some point, OpenAI released ChatGPT.
We didn't initially jump on the topic because we thought all the PhD AI people, they are much better at this.
We have no idea what's going on until we figured out nobody has a clue what's going on.
And then I think it was a Sunday night, 10 p.m., something like that.
Clemens, my one co-founder, asked Mark and me, guys, like we tried so many things now.
If you just had time, what would you build?
And we were just saying, let's build AI products.
And this is how we started to build AI products.
A very simple product, such as an online course generator to generate an e-learning online course or a first version of GitHub Copilot, just like a PR bot that you could tell, hey, please make the font larger for this heading.
like very simple applications and thereby iterated and learned how it is to build these AI applications back then with like much weaker models.
But we figured out quickly that traditional observability tools with logging and metrics, et cetera, won't really help engineers to improve these applications because they're non-deterministic and they have these long strings as inputs and outputs.
So it was really hard to iterate on this.
And this is how we ended up working on length use.
And also we...
are very interested in DevTools in general.
Like we read the blog post of Cloudflare and Versailles when they come live.
So we care a lot about engineers in general and we love building products in general.
And your product generally is kind of a deterministic, not workflow engine, that's the wrong word, right?
But a deterministic engine to build AI agents, right?
for engineers?
Yeah, it's basically for, we call it an LLM engineering platform.
It's basically a tool for engineers who want to build agents and that they need to iterate these agents to make them better.
Just as an example, you could be an engineer and you want to build a customer support agent, for example.
Before you go to production, you probably have 50 support cases that you already know from your support team.
And before you go to production, you want to already test how does your agent perform here?
Maybe you're missing some tool calls.
Maybe you should adjust the prompt to make a better performance.
And so we built basically tooling, experimentation tooling to test this before you even hit production.
Then our users, they go to production.
Then it's more like a traceability product where you see what's going on in production while users use it.
And then we have something that we call online evaluations, where whenever users use it, we help our users to evaluate what happened.
Maybe a new customer support question came up that the agent is not able to answer properly.
And then you want to be alerted about it.
You want to know that this even happened.
low-performing support case.
And you want to, again, offline experiment, basically the engineer on the machine, on the laptop, take this production example, improve the agent, and then ship again.
And this is basically the loop that we are working for.
So it's basically traditional observability enriched with workflow tooling to help engineers building these applications.
So some sort of like an audit log and a trace for every single request that goes to the agent.
And I guess cost tracking, etc.
also implemented, model selection implemented, and then really like an end-to-end solution to start with developing, to go live, and basically individual conversation.
Yeah, awesome.
Yes, exactly.
We track.
technical data, but also lots of business data.
So technical data such as latencies.
How often do you call a database?
These sort of things that are more infrastructure metadata, I would call it.
But we also track lots of business relevant metrics that you would usually more find in some sort of a data warehouse.
You already mentioned cost tracking grouped by models that you're using, but we have users that do their billing via length use.
They want to see how many AI tokens were consumed by their users and they may have usage-based pricing.
So they use our APIs to fetch the tokens consumed by a single user to then charge their customers.
So it's a wild mix of business and infrastructure metrics.
And it's open source?
Yes, it's open source.
This was an early decision.
We went open source from the get-go.
We thought if we built four engineers, it should just be open source.
This felt so natural for us and it helped us.
in so many ways that we couldn't anticipate.
So the branding aspect of it is the obvious one where we thought about, yeah, this will help us a lot.
And it did.
You could just, enterprise engineers working in a large enterprise, they can just take our product, test it out, run it in their environment without going through procurement.
So this way...
We have lots of adoption of the product, which is for free.
But at some point, they will come to us and reach out and they want to use LengthFuse Cloud because it's way more performant, etc.
But it also helped us in a way where our users use the product in each and every way.
By now, our product is so hardened because...
We ran into each and every edge case and we get reports, bug reports on GitHub on a daily basis.
There are so many of these and they're directly routed to our engineering team, which is then taking a quick action.
So both of these have been very helpful for us.
I think it also makes sense if you look at the pace that the world is turning at right now, especially the AI world, that like for then a native AI tool.
you have to somehow differentiate, right?
I mean, like the big vendors are also producing software like crazy, right?
And also now agent frameworks, like I know OpenAI is most likely going to release something and traffic already released something.
And then observability kind of makes it a technical tool.
And I think this kind of is a nice sweet spot that people don't want to be locked into one vendor.
Yes.
and also want to have transparency on what is happening.
Yes.
I find this quite a good choice.
Exactly.
There's currently OpenAI and Codex, but there's also Gemini and like best models is like changing on a weekly basis by now.
You just want to swap out and try what's the best for you.
And this is why being vendor agnostic is super helpful.
And then also circling back to the acquisition, ClickHouse is open source.
We are open source.
it's basically the same market we are selling to.
This basically opened up this acquisition in the first place.
If we would have been closed source, this would probably not have happened.
Yeah, I can imagine.
And adoption would potentially not have happened.
Correct.
I think people really look critically at what they buy these days.
And maybe they don't see an open source pool as straightaway something they have to buy.
but something they can try out and play with, right?
Especially for engineers, that's quite important, I think.
And this gives a good, let's say, portion of trust that people give you straight away if they see that, right?
Yeah, basically our go-to-market motion was really branding, adoption by engineers, trying it out on a weekend, on a hobby project, just Docker Compose up on the laptop and then bringing it to work, basically, and proposing this as a tool.
And then...
maybe in a larger organization, a manager reaches out to us and they want to procure like an enterprise deal or something like that.
And thus, we don't need to do a lot of outreach to land sales.
Basically, our sales team consisted of my co-founder Clemens and Akio.
It's basically one and a half people, mostly processing what came in by people that are already interested into our product.
So our go-to-market in terms of sales was very, very cheap.
And this helped us to grow quickly with a small team.
And you then raised angel money, I guess?
Yes.
So, yeah, we raised from three investors, Y Combinator, Lightspeed, and back then La Familia.
They are now GC.
So we did our seed round, basically, and that's it.
Okay, cool.
And then you just originally planned to raise CRSA in December, I think, and then ended up… selling, which doesn't sound like a fire sale.
So it was really this moment where Mark Clemens and I, we were sitting together and we were thinking our engineering team back then, we were about five engineers.
It's way too small for what we are building.
It's SDKs, UI, like a data platform in real-time processing.
I don't know.
I think it was back then probably 40 terabytes a day per production region.
It's like lots of scale.
And we were a tiny team.
And even though, yeah.
agentic coding is picking up, we still need to scale the team.
And for that, you do need a bit more money if you want to considerably grow the team.
This is why we thought, okay, let's do a series A.
Let's grow this team.
Let's raise some money.
And then we are good again on that front end.
We can purely focus on hiring a stellar team.
And then Clickhouse reached out and we were debating this internally.
We didn't directly jump on it, but eventually we wrote this short talk about what would happen if we would sell.
like basically playing devil's advocate because it's so easy to be, to just say like...
Did you write that or was that flawed?
No, no, no, no.
It's even less than one page.
It's basically half a Google doc because it's not the amount of words, it's the two, three reasons that really matter.
Yeah, so we basically sat together and thought what would be the benefit.
And it's basically on the data platform piece and on the sales piece.
In the end, if you look up engineering blog posts of Datadoc, for example, they reinvent their internal proprietary databases on a yearly cadence, basically, because they need to scale it further.
They need no more features, etc.
And we run everything off of ClickHouse.
It's basically a real-time columnar database.
It's basically made for observability use cases.
And we use this.
database, but we realized at some point our interests may diverge from whatever ClickHouse has.
And then I'm in a position where I need to hire a database team.
And probably we will fail at it because we need to catch up whatever ClickHouse built and then build the things that we need on top.
Or we branch from ClickHouse and then start developing from there.
It's a very big undertaking and very risky.
And then the second thing is really sales.
We have no idea about how to do open source.
DevTools sales out of Germany.
This is really hard.
And ClickHouse has done this.
They have salespeople that know what Docker Compose is.
They can talk with, yeah, it is how it is.
They talk with engineers from very impressive companies.
And seeing this as an opportunity to basically jump on their sales team and have a direct connection to their CoreDB team is basically saving us so many years in developing.
all of this internally.
And this was basically the reason where we thought if we go this path and we leverage these two points, then the chance of length use coming out at the top in a couple of years is by far the highest.
And that's why we did it.
Okay, cool.
Yeah, makes sense.
And in the pre-discussion, you mentioned that there was a really hot time before, hot phase before Christmas.
Without naming names, what does it feel?
Like when you, when half of the AI ecosystem is suddenly knocking at your door.
Yeah, it's a really busy time.
So you don't really think about it in that moment, how crazy this is.
But yeah, it was a crazy ride because you need to prepare also a lot.
It's a lot of work.
It's really a lot of work to prepare all these meetings and make the fundraise and the acquisition then work.
And this is where Mark and Clemens, especially my two co-founders, they really excelled at that.
And this was very impressive.
Yeah, and then the processing, all of this happens a bit later.
Okay, and how does it feel now, like being part of the ClickHouse team?
Yeah.
Like, how's the cultural fit?
Like, were you surprised by anything?
Or is it now just continuing the crazy riot with a very pushy team that, like, sales your product straight away?
Or is there anything that was surprising for you?
I think in general...
Nothing unexpected, because when we met the founders of ClickHouse, we realized we share so many of the cultural topics with them of move fast, don't micromanage.
Let individual engineers make decisions and give them ownership so they can move fast.
And just their excellence, seeing how often they have IPO'd companies, etc.
It's like a very, very impressive founder team.
And the remaining management team of ClickHouse is also super impressive.
So with this, nothing was surprising.
It's a lot of fun to work with them.
And now we have been in Tokyo last week with the entire ClickHouse organization for an offsite.
And it was so impressive to see what they are all shipping.
It's like 600 people building a highly complex.
ultra-scaling infrastructure product.
So this was very impressive to see.
It feels the decision was perfect to make this shot.
And Clemens, Mark, and I are thinking on a weekly basis like this made so much sense.
And we see the benefits each and every day.
Yeah, cool, cool.
And did your approach to work also change?
I mean, you're like a German team.
You're partly like YC, X post, potentially you were already on a, like, crazy productivity mode where you work like, I don't know, 16 hours a day or something?
Or how is your view on that these days?
I think there are two different perspectives.
One is like, hey, AI makes us so much more productive, we don't necessarily have to work 16 hours.
And the other one is like, work 16 hours or die.
How do you see that?
How did that change for you?
Honestly, it didn't change a lot.
For I think the engineering team, basically nothing changed.
We are still a small team.
We are still understaffed.
We still have huge scale growing about 20% in terms of data intake each month.
This is still a lot to build and our users are demanding so many cool features.
I also think it makes so much sense to build these features.
So it's still a high velocity environment where we need to push.
It's not that Clickhouse is now sending us an engineering team and telling us you can relax now.
No, we need to hire our own team.
We still make our product decisions and need to move really, really fast.
And then for agentic coding, this really took off since Christmas and models became so much better.
I think the velocity per engineer is increasing.
But it's not in a state, I would say, where I'm waking up in the morning and it's just done and I can merge a major PR.
There's still so much to review and understand of what's going on.
I think the next step is to understand how to really review things and make sure that they don't blow up in production because an unperforming SQL query is...
shipped or some design patterns are not implemented correctly.
These sort of things.
So like an engineer still needs to take the time to really understand what happens.
So it's not in a world where basically everything is for free and we can just ship at ultra speed.
It would potentially also be boring, right?
Yeah, I mean, it's the question like, how does building products work in the future?
Is there actually like a software development lifecycle where you just write specs and you get the result in the morning?
Yeah.
I'm not sure.
I haven't seen that really in the wild.
I think it's an interesting idea or a good idea.
But I mean, you somehow accelerate from A to B.
And I think the exploration partly has to be also something that you do.
Yes, but it's also heavily AI enabled.
I mean, we get so much user feedback on GitHub discussions, for example.
It's tons of threats.
I want to build this.
What do my users tell me?
And then let Cloud Cowork give me a summary of what users actually want.
I read an RFC from one of our engineers actually yesterday.
He did exactly that.
It was a perfect summary of what users want.
And then from there, you can again work with Cloud or Codex to figure out what's the best way to implement this and then iterate also on this plan.
So the planning stage is already...
highly AI enabled and then giving this into a context to an agent to execute on top of that is basically just a linear integration to cloud code working off these tasks.
So I think right now it's basically the engineer who needs to decide I want to prioritize this project.
He needs to understand based on the user research what are really the requirements, what's important here, where are the most difficult and important decisions.
And this is where really where taste matters and where understanding the users matters.
For example, for us, we always try to build a platform which is very open and very, like it could be used for so many different use cases.
It's not very specialized, it's not verticalized.
Having this in the mind of an engineer lets them make the right decisions on the plan.
And then after the agent basically implemented everything, it's again this like review step and then making sure that everything was implemented correctly, ship it into production.
And then whatever, like monitoring and production is the next piece where.
I mean, us as an infrastructure product, we are on call 24-7.
Something may blow up at 3 a.m.
on a Sunday night.
Happened often enough.
But then having again an agent being connected to Datadog and all the tools that we have and helping me to understand what's the root cause is super helpful.
Yeah, it gives you a context that actually is already prepared.
Like, hey, the internet is down.
Fastly is down or Cloudflare is down and have you checked this and I already figured out this and this is how to fix it.
But still the human in the loop basically does the rest of it, I guess, right?
I think, yes, I think right now what we try to do is get as much context into the agent harness, basically into the agent, give it all the MCPs, all the tools.
I mean, we are very lucky here in a sense because we are open source and being open source, Also about us as a company, our culture, we have basically a handbook out there.
Our internal company handbook is on our Langfuse.com homepage.
And this is super helpful because now agents can just go and find the content.
And this is just accumulating over time a lot.
And then combining all this content with a very powerful model really helps a lot.
So I think it's currently really...
the figuring out which content you're missing to improve personal productivity, basically your team productivity and making sure all these connections are made to the agent harness.
And where would you say you stand yourself with your own cloud and observability and like this prepared for harness prepared context?
Where do you stand?
Like how happy are you with your status quo?
Like the real?
The real you.
I mean, yeah, exactly.
So, I mean, everybody reads on LinkedIn and X each day how crazy productive everybody else is.
I think we are also not happy about where we're currently at.
We could be much, much better.
And we're investing there.
It's basically projects that are on the...
A quarterly roadmap of our engineering teams.
So no, I'm not happy because I think we could be doing better.
We have lots of ideas of what we could improve and where we want to move.
But I think it's also like a very exciting time to really understand workflows and how you can be more productive.
So yeah, engineers who are curious about these sort of things probably have a very fun time right now to understand what are the next step in the industry and how to be more productive.
And if someone wants to now, let's say, build a similar setup to yours, or given what you learned with your own cloud, building an observability stack for a normal web app these days, what would you, I mean, you mentioned Datadog, right?
Or something similar in your relic, et cetera.
But this is like the old world.
How do you do this in the new world to basically be prepared or be best prepared for?
agentic resolution, which at a certain point will also come that you automatically solve issues with an agent.
What would be your setup if you could restart from now?
So it's a multi-layered answer here because many things matter.
I think the data platform under the hood needs to be blazing fast.
And this is where ClickHouse really excels.
It's like...
processing billions of rows in a database, sub-second, the sum of total costs for a given user.
A query like that is just responding very, very fast on a gigantic amount of data.
And low latency database queries sound very technical, but they have real impact on an agent.
If you, for example, have an agent hooked up with Lengfuse, with our MCP client, for example, and you want to debug something that went wrong in Lengfuse, you want to have a very quick answer and you don't want to wait for 10 minutes to get an answer.
No, you want to have it in a second and you want to run multiple queries and you want to run a lot of these.
So the data platform really needs to work.
You also need to have the basically agentic setup.
But the data platform could also be Datadog, right?
Like traditional traces somewhere.
Yes.
Okay.
So let's say I have data stack for monitoring, which then, I don't know, it's...
an on-call signal somewhere, like my application crashes, there's an incident happening, there's a webhook to where?
What happens next?
You have Datadoc, you have that, and you have that incident happening.
What happens next?
Probably you want to have it hooked up with basically the MCP of Betastack or Datadack Doc or whatever.
You want to have it, the repositories that you have your code needs to be in the context.
So you have to have the actual code base of the servers you're running, but also ideally infrastructure code.
We realized having the infrastructure code in Terraform is extremely helpful because the agent knows what you have deployed in production.
So these need to be in context.
So ideally, you have a webhook that could do whatever, like there's integrations to Linear.
I think Linear could be the workflow engine for this of the future, where you just create a Linear ticket off of a Datadog alert or some of the PagerDT alert.
Or a GitHub issues ticket, right, to keep it even simpler.
And then from there, basically you launch a codex session or a code session to start the investigation.
And GitHub issues from some repository.
That's like an observability repository for your setup.
I mean, for us right now, it's basically we run this manually right now where the alert comes in.
I wake up at the night.
I just take the alert from our Slack, copy, paste it into codecs.
And we have a skill there with all the context.
And then it's just going.
I'm waiting.
So I'm like.
I could now start and this is the next step that we need to take is basically having a web hook and fully automate.
So when I'm getting awake, I'm opening up the laptop, I already have the first investigation, so I don't need to wait.
And then from there also start also like a fixed proposal would also be the next step.
So to stay with our imaginary setup, there would be like a dedicated, let's say, AI context repository, which kind of describes what your company does, describes all the MCP servers that it needs.
and then gets like a GitHub Actions webhook, triggers some workflow that then collects the context, like starts codex or whatever harness you use, right?
Starts codex, collects all the context then, and basically fires then or wakes you up at night in the next step because it can't resolve it itself or sends you like a, I don't know, a Slack message.
hey, do you want me to resolve it?
Yes or no, right?
This is what I would do.
What's our plan currently is run more on EC2 instances, basically having a server running and loads all the contacts in there, cloud code, MCP server skills, everything goes in there.
And then you basically have a standing server that you can just, this should receive the webhook of this is going wrong.
And then the engineer should be able to connect to the EC2 instance, see in there.
the investigation, but then also be able to start a fix in the infra repository or one of the app repositories to then have a fixed life in production as soon as possible.
The GitHub Action is nice because it's very easy to configure, but it's basically stopping at some point and then you need to do stuff.
It's stateless.
So having basically an EC2 instance, which is basically completely isolated and just let...
cloud to do whatever it wants in there is probably the best idea.
And the setup we just described.
doesn't include length fuse at all, right?
Like where comes length fuse in?
Like why do I need length fuse in addition?
Do I need it for the setup at all?
Yeah.
So basically, we just talked about our setup of how we monitor our infrastructure.
But if I'm now building an agent and this is also our length fuse future is to build an in-app agent where we want to render custom UI based on whatever user currently wants to have.
So say...
Again, circling back to the customer support case, maybe someone complained, hey, I just got a really bad response here for this use case.
A human agent needed to take this over and get it over the line and save it.
This could also be dispatching a webhook and then start to interact the same way we just discussed it with Datadog, interact the same way with LengthFuse, where you have all these prompts in there.
understand which tool calls were used by the agents, etc.
And then basically do the same loop of trying to improve the agent off of the negative feedback that we just got.
And it's basically the same use case and the same loop just for engineers' work building these agentic applications.
Meaning that you would not necessarily need length use for this incident agent, but whenever you want to go deeper or whenever you think they're...
I mean, for the incident agent, there needs to be a human in the loop, right?
Like, you basically describe a workflow in code, I guess, and then you say, at this step, I want to do this and this.
And if A then involves a human, if B then goes straight away, and this is what you would do in length use, and the agent would be powered.
Yeah, it's a complex word.
Maybe for this one use case, again, talking about this customer support case, maybe someone asked something completely new that we never used or optimized our agent for.
And maybe the context for this use case is completely missing to the agent.
So then the action would be prepare this context.
And this could be, again, like an agent preparing this or the human realizes, oh, I need an additional MCP server or the MCP server needs additional capabilities.
And from there.
then the engineer is looping and basically coding improvements to the agent, going to production again, and then monitoring with Lengfuse again.
So the Lengfuse monitoring is really about how good is my agent currently working?
It's less about this one EC2 instance just died.
Many of our users are using Lengfuse in parallel with traditional ability to understand these infrastructure topics of my database is just going down.
And we are more focused on the quality of the agent.
And this then often is less the traditional observability, but observability around some agent use case like, hey, I want to automate my customer support.
I want to automate, I don't know, let's say my whole customer outreach and my sourcing engine, et cetera.
And this is what you would do with Langfuse while observability potentially, traditional observability potentially not really, right?
I think really pushes me to a question that if you open LinkedIn, you think the world is already at 99% agents, right?
From your perspective, the non-LinkedIn version, where do we actually stand with agents in production today?
How many companies are really succeeding there already?
And where do you stand?
Where does the world stand from your perspective?
It's obviously picking up a lot because just the models get so much better.
And we are also iterating on how models get context.
So things get much better.
I think in terms of products, there's lots of products from our customers that are super impressive, that are client facing and just work really, really, really good.
So there's, for example, tools to find really good.
candidates for our engineering hiring with AI.
And they're so much better than all the traditional tools out there.
And they find me, based on a text description or a voice input, find me extremely good candidates.
And these tools work extremely well.
And they're, I think, have also tons of traction.
So these use cases exist.
And then also...
Lots of internal operational use cases exist.
So lots of enterprises have manual workflows that you could just automate with agents.
These use cases exist a lot.
This is where we talk a lot with enterprises about.
And then there's also less agentic use cases, but very high volume use cases, such as scanning invoices, for example, and extracting data out of invoices at gigantic volume.
These cases exist as well and are now extremely good.
And you don't need to fine tune a model on your use case because you, I don't know, have Japanese invoices or something like that mixed with English ones.
No, it's just working incredibly well.
And those really narrow use cases that, like you mentioned, flagging invoices or doing customer support in a SaaS company, etc.
I think doing customer support potentially is not...
yet there.
I don't know.
But it's what I feel like.
I think for us, customer support works extremely well.
We have two guys doing customer support and we have an agent that is doing first-level customer support for us.
And I think it's about doing about 10,000 conversations a week.
We would never be able to do this type of support with two people.
Like impossible.
And only a very small fraction is routed to these two guys who are technical and can help our users with like deeper issues.
But in these cases, it's really, really good.
And it works really good for our customers.
Like at least the feedback we get is really good.
So customer support is already, I think, working at least for us extremely well.
Okay, then pens down again.
How does that work exactly in your case?
Like people write tickets somewhere.
Is that GitHub issues or is it email or is it multi-channel?
It's basically, it's multi-channel, but the AI automation, we have it in GitHub and we have it in our in-app support chat.
So we have a, if you log into Langfuse.com, there's a small support button.
You can hit it and then you can, you have a small text box and this is where our agent works.
And then you can also hit a small button, like talk to an engineer and then you literally talk to an engineer.
So yeah, this is how we do it.
Okay, okay.
And that's all proprietary self-build, even open source?
We use a vendor for this.
But again, we made sure that this vendor has all the context.
This is where open source is extremely helpful.
Our code is open source.
So it's like accessible by an agent.
All the documentation, everything, all the GitHub issues is all public.
So this is how the quality of this agent is really, really good because it can find.
lots of context about bugs that we have, features that we have, how like an upgrade path for a certain API looks like.
These are all like fully documented and it's out there.
So easy for an agent to produce a good answer.
Okay.
And from your view, what's the pattern right now you see often?
I mean, you have many customers, right?
That basically try to implement agents.
So every B2B SaaS could be your customer, right?
What's the pattern that you see?
really shipping and what's the pattern teams keep failing or keep trying and then keep failing?
Like, what are the mistakes that people often make?
This is really, really hard to answer.
I don't have a global view on this, but the teams that succeed, they just try the most powerful model.
They just give it, as I just said, as much context as possible.
They try narrow use cases.
Don't try to...
solve everything at once, but go step by step and then try to expand from there.
These are the successful cases where, I mean, I know from some customers, they really understand the workflows they try to automate.
Like they're, for example, founders of a YC startup and they're building something, for example, in recruiting.
They have no idea about recruiting.
They could just say, hey, scrape these profiles and then give a summary and rank them somehow and then return it to the user.
Done.
This could be shipped on a Saturday.
But no, they really try to understand how a recruiting function, world-class recruiting function works and then try to replicate this within their agent and build very thoughtful skills for agents to really replicate basically what humans do.
And they're basically in love with the product and try to improve each and every nuance by doing whatever, like improving the skill, the prompts, the context.
So they're still, I think the team succeed.
are the ones in the end that care a lot about the quality of the output and do whatever it takes to get there.
Because you can also just ask Claude to build you a world-class hiring agent, right?
And probably this will also become better over time.
But then there's again this, yeah, I mean, that's an interesting question where we will end up because it's agents building agents.
This is also the future we are thinking about.
What's the role of a human at some point?
And I currently think of a...
email slash linear inbox where an agent tells me, hey, Max, we need to fix this here because this broke.
And then if I want to, I can just dive into it and see all the context within this notification and also take a corrective course or I just let it go.
And I think this is where a future where at some point agents will notify us that they did something and let us help or not help rather than us needing to.
launch the agent and handhold it over the line.
Yeah, this will be very exciting.
So a decision a day, basically, then ultimately, right?
Here's your decision inbox.
Wake up in the morning, 8 a.m., drink a coffee, go through all the decisions and let it go.
And then if coding also...
becomes so much faster and it's basically a parallelism, right?
So you can just like work on 100 tasks in parallel and then we are bound by compute from OpenAI and by the amount of like basically attention of a human to make decisions if the agent says, I want to have a decision.
And then, yeah, I'm wondering where we end up with because the iteration speed will be crazy fast where it used to take teams to...
build features.
Now things will just happen overnight and yeah, build very exciting products.
Okay.
And if you're honest, where does this all still suck?
Like where does the current status quo still suck?
Like where do you, like what's the stuff that really annoys you these days?
Is it the often changing directions and the new stuff that happens around the globe every day or, and then?
I don't know, the fact that everyone now releases agent frameworks and is it the non-existence of product market fit these days?
Or is it more like really technical issues where you think like, hey, this is too basic.
We're all cooking with water.
What is it?
There's no, I mean, it's bad and exciting.
At the same time, it's not a clear path of what we should be doing as an engineering organization.
Should we now?
build lots of infrastructure to make sure that our coding agents are able to code without reading from our production database and destroying stuff.
So there needs to be lots of layers around arbitrary code execution by an agent, for example.
Should we now go and invest heavily into this and build all these sort of things?
Or should we wait for someone to build all of these things for us?
Or will something else be the future?
I'm fairly convinced that we should be doing this and we will be doing this.
I'm very convinced that this is the right direction.
But yeah, sometimes you don't know what's the best next step we should be doing because we're still so people constrained.
And then making the right bets of what people should be working on is probably the biggest challenge.
Yeah.
So really figuring out what you don't know, right?
What do people maybe are doing in the background that you don't know about?
Where does actually open source exist for this case?
Is OpenAI working on this or whatever?
I can imagine that this really sucks, right?
And this is also the problem of many, I know.
basically start doing something and then realize, okay, shit, this has been built.
Like, I don't need to build this.
It happens every day and you throw away like two thirds of the stuff you're building, right?
Yeah.
But then if you build it, you can customize it.
That's always the nice thing.
If you build stuff in-house, you can always make it work for your use case.
And this is also something what I believe will happen is really, I mean, big tech has always done it in the US, building their own tooling internally.
like their internal task tracking and email clients and whatnot.
And I think this will happen to way more companies to build custom internal tooling for your workflows because building software will become cheaper and then you can adjust it to the workflows that you care about.
Okay.
One little case study that I have for you, like in a real life case study, maybe like slightly.
I'm slightly lying, but parts of it are real.
I don't tell you which ones.
I'm co-founder of SaaS Group, and we acquired roughly 30 portfolio companies that belong to us, really, end-to-end.
Tech, billing, etc.
All of that is owned by us.
We have support, we have on-call, own ops setups, individual teams.
People partly use AWS, partly use Google Cloud, partly use Datadoc.
In the old world, a bit of an IT nightmare, security nightmare, and very fragmented.
If you see this all and you zoomed out, and you were in my shoes, what would be the first thing you would try to solve with agents?
And where would you start?
How would the infrastructure look like?
Would it be the on-call setup?
Would it be support where you would start because you could generate most value using Lengfuse?
And what would be like the concrete stuff you would do?
Yeah, it's all different businesses that are different teams, etc.
Everybody working on their own products.
Yes, yes, yes.
And you have a few things that are uncommon, like billing is often done through Stripe.
Support is often done through one solution or the other.
code is on GitHub, but you don't have a context described necessarily per company, you don't have MCP servers per company.
Would it be like MCPing everything and then trying to really define a context per company to then basically approach the on-call stuff that you described or security?
What would it be?
I think...
Yeah, if you don't want to merge these businesses and make them one, you probably want to have individual setups for each of these companies.
Basically, make sure everybody's AI pilled and thinks about their job each and every day of how they can use AI to make it better.
Like there are so many things like in recruiting.
We also did it.
Use Cloud Cowork to improve the recruiting process.
And then maybe you have some shared learnings where one recruiting tool works better with AI than another one.
And then you can maybe share this knowledge across the different companies you have of like tool selection.
But this will also change a lot.
And people still need to understand all the tools that they're using because we're not there yet where it's just like all on autopilot and this will not happen over the next week.
So I would say.
AI build the workforce, everybody that they start to use these tools for their internal processes.
And then I would heavily think about the product.
I mean, right now, I assume most or all of these products have product market fit.
So understand where do the products move?
And maybe you then need to build something more agentic and then you would adopt length use because you could also lose product market fit at some point because...
whatever your users do right now with your tools may not work in the future.
So what's the future of all of this in a more authentic world?
So I would prepare for that.
Okay.
Okay.
And I think, I mean, that's what we do.
There are some things that you could still provide to every company.
Like, I mean, having those individual teams, right?
Having individual engineers, individual support people, et cetera.
There's still something, some central baseline that you can draw.
And I think like...
On-call, for example, would be something or this, let's say, knowledge about building an agentic on-call process, right?
It's something that you can infuse.
Also, like really raising the bar to a certain extent when it comes to like SLIs, SLOs, etc.
Observability is something that you can do, really.
And then support, etc.
I think there are agent cases, right?
And there's also the translation problem between central people that work for the central organization and the individual organizations.
And I think also there, it kind of makes sense to describe the context in some repository and ship it.
I mean, there's two pieces.
Like one thing is the workflows.
Like how do you stitch tools together so they work well in an agentic world?
I think this is mostly easy because there's so many tools that help you stitch together tools or you can build stuff in-house.
So stitching together tools should be rather simple.
And then the big question is about the...
AgentMD in your codebase.
How high quality is the AgentMD in the codebase?
And it needs to be super custom to your application.
What are the common error scenarios?
What are the edge cases that users run into?
Where do you have scaling problems?
What is your design system?
If you build a new feature, how should it look like?
This will be very different for all the different products in the different companies.
Thus, I would say these pieces.
need to be highly specific for these applications for the customers, how everything works and how the product works.
So yeah, and this needs to be very specific and the people working on this need to maintain this and improve it over time.
Okay.
Yeah.
So this is like the normal dev workflow that you also recommend to improve for everyone out there, right?
Like start collaborating with Claude and Codex, right?
Like start like pushing the context, start optimizing it, start sharing it, and then really start continuing to develop it.
So to make it a workflow and not a one-off thing that ends up on your individual hard drive, right?
And then what's your view on sharing or on a required minimum level of best practice when it comes to multi-agent workflows, et cetera?
Is that something where you personally do use?
like an engineering team on your hard disk or like a virtual one?
Are you using multiple roles?
Are you doing like cloud code and step-by-step or how are you personally doing that?
So we have a bunch of skills for different things in the company and I'm basically selecting the right skill with the harness to do something.
So it's currently mostly differentiated.
for tasks by skills and by giving it one-off context.
So we were working on SOC2 and HIPAA, et cetera, and just giving it all the, again, the right context for the right tasks.
So like, yeah, I try to run things in parallel, but I don't have one agent orchestrating many agents.
I don't have a setup like that running right now.
Okay.
And do you think this would be a big step for you still if you would add that?
Or are you not curious to try it out?
I'd be curious to try it out right now.
I think we need to improve the loop of a single agent to make this better because then like one agent controlling many agents would just like launch different tasks.
Then I have basically, instead of one task, I have 20 tasks to review.
I'm still the bottleneck at reviewing and basically merging stuff or sending out this email or...
doing whatever I told the agent to do.
So basically improving this piece of the loop is probably higher leverage right now.
Okay.
Okay.
Yep.
Fair enough.
I think that's actually the status quo of many companies out there.
And I guess you're a bit further ahead than most because you're also building AI native solutions, right?
But I also see many people that try to really go step by step still and then, I don't know, have...
skills for the stuff that they need to kind of accelerate their software development lifecycle, right?
I mean, do you believe in things like pull requests being alive in a few years still?
Or do you think this won't be required at a certain point?
I mean, a pull request is, yes, I think, yes.
But how fast it will be merged will be much, much faster.
I think that there will be interesting topics.
I mean, the load on the GitHub systems, is incredibly high by now, mostly because like so many pull requests are opened and then they run the GitHub actions over and over.
And now we are opening so many new pull requests, GitHub actions run, and they make sure that the system still works.
So I think having this system where we have this diffing and understanding whether the new thing works better than the old thing, this functionality is incredibly important and also a good checkpoint for an agent to then see what's the diff.
what's the incremental div of the pull request.
If something is again changed on the pull request, see whether all tests succeed and then merge.
And then there will be problems such as merge queues, where now 10 pull requests wait to be merged, where lots of work needs to go into CI pipelines again to make sure they're not running for half an hour, but for less than 10 minutes.
So yeah, it will be these CI pipelines.
there will need to be a lot of work to make them performant and fast so we can iterate fast.
Because at some point, this will be the bottleneck.
This will be the bottleneck, right?
From engineering capacity to then the whole rest of the workflow and then ultimately to decision at a certain point, right?
Yes, decisions, tastes, and then merging stuff and get it live.
What's your perspective on UIs?
I mean, looking at our portfolio, I want to encourage people to maybe step back a little and don't be in love with their UI.
Do you think this is going to come?
Do you think there's a future without UIs?
Heavily debated in our latest roadmapping discussions.
Because if I look at our roadmap, we built...
traditional UI features such as make filters better for users to navigate quickly.
And then we also have this in-app agent, which should be able to render custom one-off UI for customers.
And then we have the discussion around MCP servers, make everything headless, basically just use APIs for everything.
And then let the ones who just want to navigate length use with skills and cloud code, let them succeed and make them never log into the product.
And I think Kind of everything of this needs to happen because just let's go through the user journey.
Someone wants to start using LengthFuse.
They don't want to fiddle around in the UI, copy API keys, then read the documentation on how to install the SDK.
No, you just want to have an SDK.
MCP server, sorry, skill MCP server, and then just let cloud code work until all the data is correctly tracked within Lengfuse and tracing is correctly set up and then give the user just a link to the product of like, hey, here you can see your test traces.
Do you think it makes sense?
And here are the cost and here are all the metadata that are already ingested and then giving a custom link to the user who can hit it and then go in a pretty UI.
This UI could be one-off or like a general UI.
So the UI piece is still important because...
Also, maybe users don't spend that much time in UI anymore.
So then having a very intuitive UI that's easy to navigate will still be super, super important.
And then the last piece is around agentic workflows within length use, where you could, for example, say, I want to create synthetic data sets within length use, like basically test sets.
This could be a very complex workflow.
ish UI or you have an agent proposing these based on some questionnaire that it may render one off for you and then you just accept stuff in a it's more than like a chat UI with custom components rendered into the chat and yeah that's basically how we envision it right now.
Okay yeah cool this is how I also envision it and I feel like I don't know.
I think it was Gregory Orchick recently posting about design now becoming a super important skill.
And I agree for those small, let's say, micro UIs that you kind of get in the middle of chatting to an agent.
But I don't know.
He mentioned, I think, Airbnb as a design product, which people love using.
And I slightly disagree.
I think, I mean, yes, I like Airbnb.
I like the platform or the venues I find there.
And I like that it comes with everything that I need around it to find the right venue.
But I'd say if I can automate this process and don't look at Airbnb, I'm also happy.
Yeah.
And you may need to book a train or flight or rent a car alongside.
And then it would be great to have like one UI for the entire trip.
to see what you're actually planning there and how everything matches in terms of timelines.
So yeah, and then all these tools would need some API MCP setup and you would need to have the capability to build quick front-ends one-off for the case you're interested in.
Yeah, you basically want the journey registry where all the MCP servers are in or all the CLI tools that you need are in, which then basically books the train.
books the venue, etc.
But I think for many companies, it's super painful to, and I can imagine that if I was Airbnb, for me, it would also be painful to say, hey, I let go of this just for a better tomorrow.
It's painful.
I called myself a design company, but maybe now it's no longer that important.
And I want to give people still the best results and the best venues possible.
And that's my job and not necessarily the best UI.
around it and the best faceted search.
I think yes.
And this is how I think companies will change and will have to change because just everything will change of like digital products.
And I totally agree with you.
You can't try to force your users to use the platform you intend them to use it.
Let them do their thing.
Maybe we're also a bit...
Nerdy, right?
I mean, we're deep down, right?
And I think many people still maybe, I don't know, maybe for your girlfriend, it would be different.
And she still values the experience on really searching on Airbnb and doesn't love chatting to Claude.
So this will be a process, I assume at least, like, I don't know, I can't imagine a world where this won't be the case in a year.
Yes, agree, agree.
Like there will always be some default UI that people enjoy and love because it's also a brand and it's thoughtful and well used.
But again, like closing against the idea and shutting down the idea of being more open about it, I think it's also not the right way.
So probably it needs to exist both in parallel.
Okay, agree.
Len?
Before we come to the end, one maybe recommendation from your end.
I assume you treat it quite similar to the agent kit that Vercel released with some open examples.
Do you have some good examples where if people want to dig deeper, that they can check later on?
to basically start with using your product, I guess you have, right?
Like what's the best example you can give to people that I can link in the show notes and people can later on check them?
I think what we did is basically you can just go to langfuse.com slash demo and you can just, and there's a small chatbot that's basically on top of all our context.
You can chat and you can ask like how to use Langfuse, why should I use it, et cetera.
And then there's a small button, log in, and you create an account and you can basically see this demo.
project where you can see what happened.
So you can see the traces of the chatbot you just used.
You can see LLM as a judge, like evaluating whether the answer was good or not of this chatbot.
So it's a very easy way to interact with the product and see what's going on there.
Okay, so try the demo.
It's quite easy.
And then a little surprise from my end.
I spoke to your co-founder, Mark Klingen.
He told me about a hidden Easter egg in Langfuse.
So I don't know if you knew that, but if you create a trace with the timestamp from before Langfuse existed, the system actually pulls you to that very moment in time.
And we now imagine that we go back to the year 2014 when you were still studying at Tio Munich, I think, and you're building iOS apps, and you can't imagine what might have...
What might happen in a few years?
What would be the one sentence that you would whisper into your younger self's ears?
Be curious and work hard.
Okay, but I think this is what you actually did, right?
You don't change anything.
And enjoy the ride.
It's so exciting.
And buy Bitcoin so that you don't have to sell your company.
No investment advice here.
Okay, cool.
So thanks a lot, Max.
It was great having you and I wish you all the success with Langfuse and really looking forward to observe your crazy ride and hope to meet you soon.
Thank you so much for the time, Tobias.
Thank you.
Bye.
Bye.
Thank you for listening to the Alphalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or, as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.