Skill issue: Lessons from skilling up coding agents to use Langfuse - Marc Klingen, Clickhouse

Okay, that was quick. Hi everyone, super excited to be here. I'm Marc, one of the founders of Langfuse. When we started Langfuse like 3 years ago, when everything was— felt quite early— building agents that didn't work, and then realized, okay, there needs to be like some evaluation, tracing.

Build, like, Langfuse is the open-source project in the space by now. And we met the metrics that we track; we seem to be the largest one in the space. We do our product engineering out of Europe, thus I'm very excited this conference is coming to Europe because there are so many great people here.

And we always need to resist the urge to, like, ship the whole team to another continent because actually being here is very nice, and you can just travel and hang with people on Discord and Zoom. So yeah, very excited to be here in person.

And what I want to talk about today is how— well, the lessons we made from scaling up coding agents and actually adding Langfuse to an application, because, like, back in the days when you added, like, observability or evals, you needed to read like hundreds of pages of docs, like, figure out your own mental model, and now you kind of expect, like, to be hand-holded by a custom agent to do this.

And we've come a long way in achieving this kind of vision, and I just want to explain what we learned on the way. First of all, like, I'll start very conceptual, very easy, then a bit more conceptual deeper, and then I'll go to the learnings.

So my mental model for skills is just like, I get this Rubik's Cube when I was a kid, I had no idea what to actually do, but I mean, I basically have a bash tool, I can do whatever I want with this Rubik's Cube, but it just looks colorful in different ways and no idea how to solve it.

So skills was like a great way. Once you get the manual, it's easy, you just need to follow the manual and you can solve a Rubik's Cube. And I feel like the same thing now applies to agents, where, like, there was this whole debate of, like, workflow versus fully autonomous agent, and there was, like, a huge fight on X of, like, what is the best way to build an application, and everyone was kind of like, yes, you kind of need both.

And I think Malte this morning had, like, a good note where, like, the surface area of deploying agents is so broad that, like, for some you don't need, like, a coding agent even if it's, like, the best way you can build agents at the frontier today.

Like, you don't need this for every application, it makes things slow, expensive. And, like, there's this kind of, like, balance between workflow being very reliable and the agent now having kind of, like, unlimited capabilities. And I think what's very exciting is that then skills are kind of like a formalized shortcut to make things more reliable, where you historically would have built a workflow.

Like, I don't know, you have a customer re- like, customer support agent, and someone asks for, like, a password reset. Then historically you would have built like a workflow that's very reliable of, like, ah, you have a router that routes to, like, an agent that can only do password resets, and that agent has, like, the context to do password resets well.

That was great, but also if the user then wants to do password reset but also change the email address at the same time, then, like, the router is kind of like, okay, I have this email router, I have this password reset router, what do I even do?

And I think what's very exciting now is that an agent can just, like, progressively get the context needed to then solve, like, a problem that's multi-domain, like, that would have historically been in multiple workflows. So that's very exciting.

However, it has always been hard to kind of, like, how to— how to build an agent, what kind of use cases even exist, because you have, like, this open-ended text input box often or, like, open-world context, so you didn't really know.

So what we now see is what many teams do is they have the agent runtime, they trace everything. I mean, I'm building Langfuse this, I put my logo here, but you can also use whatever you want. In the end, it's more about, like, the concept of tracing is what you need to, like, identify what happens at runtime when a trace— when, like, an agent executed, because then it helps you learn two things.

One, like, new kind of, like, use cases that you didn't expect users to do, because you might have expected that nobody ever wants to change a password, but now they want to change a password. Thus you need to see the execution trace of someone being upset by, like, a production eval to then derive that you need to add a skill for handling password resets well.

And two, once you have these skills, they can get out of date or you can realize they're not the most efficient way of actually solving for this use case. So it's like the second thing of, like, helping you improve skills that you already have in your agent.

So this is very conceptual, but this is what we— what we now see most teams do that use Langfuse. Now more towards, like, the learnings we made when building a skill to help customers add Langfuse to their project.

So what was the lay of the land before we got started with this? Like, 478 pages of documentation. Whenever I see, like, the thing deploying, I'm like, who wrote all of this? So apparently if you build a project over 3 years, it just grows in complexity.

People can do all of these different things, but then you need to read all of these things and nobody has the time. Across, like, 5 different feature areas and a lot of implementation flexibility, because there have always been, like, projects in, like, the eval space that were very, I'd say, opinionated.

So they were like, oh, you have a chatbot, then add this project and it'll just solve this for you, opinionated end to end. We always were like, no, no, we are infrastructure. We do, like, tracing well, like, if you ingest, like, billions of traces, it will still work.

If you want to customize your evals, it'll still work. So we were always, like, more on the unopinionated side, which was always, I'd say, a weakness compared to projects that are more opinionated, but now I think it's a strength, because in the end, what do you need when agents do all of this?

You only need the infrastructure piece if agents can then customize for different workflows. So, but there's the problem if people want to add Langfuse to a project. How to do it correctly for a project is to be figured out by an agent.

And interestingly, when we first got into model pre-training context as a project and you can just ask an agent how to add Langfuse and it'll spit out, like, Langfuse SDK logic, the first time this happens, it's amazing. But then if you're, like, 2 years in, like, the project evolves, like, interfaces change, and now being in pre-training context might even be, like, a disadvantage if you don't fetch up-to-date information.

So we were just like, oh, we get, like, all of these hallucinations of methods that have been available in the past but they're not available there today. So yeah, we felt like when skills launched, this is, like, the exact pattern that we need in order to help teams achieve this.

So I'll use an example. When you just ask Claude Code to add Langfuse to a project, it just worked, but it was not working in the best way possible. So for example, user ask, add tracing to my agent, and then Claude Code kind of, like, implements the instrumentation based on the outdated pre-training context, then tries to verify whether the tracing works, then realizes, oh, it doesn't work, and then only in the second step fetches up-to-date information to then correct the issue.

At the same time, how you add tracing or evaluation to a project, they can evaluate in, like, gazillion different ways. Like, online evals, offline evals, human in the loop, there are so many different things, and often the question is, like, what even is relevant for your application?

So human agent kind of need to figure it out on the way, but agent is not tasked to help you, like, figure out what's the best thing for your application. So main problems, outdated training data, the non-optimal setup, because the agent wasn't really, like, primed to help you discover what to do for your app.

And it's very slow, because you first add instrumentation the wrong way, then you figure out it's wrong, and then you need to fetch more documentation to fix the issues. So what did we do? Ah, yeah, this is how the— this is how— just mental note, this is how the trace looked like when we just tried it with Claude Code.

So, like, it just tracks two LLM calls in an agent, but, like, you still don't know what the agent is actually doing. So what was the goal of our skill? Like, give every Langfuse user, like, there are thousands of teams in the community, thousands of customers on our cloud product, give them all, like, a Langfuse expert to help them quickly set up observability, prompt management, evals in line with, like, best practices and up-to-date docs and, like, references.

Because all of you, I mean, there's Annabelle from the team here as well. Like, if you have questions regarding observability evals, you can talk to us, but in the end, that doesn't scale to thousands of people to basically talk through your problems and figure out what the best strategy is for you.

So we were like, okay, skills is the way to go. And this is, like, very conceptual how our skill works, where, like, user comes in, asks coding agent to do something, and then the skill kind of has, like, a reference of, like, the skill MD is more like, well, what kind of style do we want in order to implement Langfuse.

So for example, ask follow-up questions before making a decision, because there's so much you can be doing, and then references for the different product modules to kind of, like, progressively disclose additional hints that the agent might need to have.

And then it can call the documentation. And interesting enough, as we started open source and, like, saw ourselves as, like, unopinionated infrastructure, we always had, like, APIs for everything, because teams built their own, I don't know, own labeling UIs on top of it, own evaluation execution logic on top of our backend.

And we had APIs for everything, now we've wrapped it in a CLI, and now an agent can just do everything humans needed to do in the UI in the past, which is very cool, because, like, so many teams spend so many hours every week in clicking around in our UI to evaluate and improve their application.

And in the end, how will this look like end of year? It'll probably just be like, like, connect repository to Langfuse, and then agent just does the whole thing, like, auto-regressively. I mean, that's what we are building towards.

That's what everyone is building towards. And I think that's a cool step in theright direction. So to shortcut to the end result, okay, after, like, conversing with the agent now for the— for a similar thing, it looks way more detailed, like, like, detailed evals that are relevant and detailed steps regarding tool execution.

So just, like, there's a stark difference. And yeah, what did we learn on the way? Six main things. I'll go through every single one of them of what were basically our realizations when building the skill. And, like, one, looking at traces still, like, gets you to, like, 80% of the detail.

This was always what we kind of, like, tried to preach regarding, like, evals, where many people try to complicate thingsright away while they haven't digged through, like, just, like, what did the agent actually do at runtime themselves a couple of times.

So what did we do? We have instrumentation for Claude Code and just ourselves interactively, like, tried to use Langfuse with Claude Code and then looked through traces in Langfuse to understand where did the agent error, how can we improve the skill to make it, like, straight shooting at the goal instead of, like, wandering in different ways to the target.

That was really helpful too. There were, like, some of the interesting learnings here. For example, for humans, we tried to cut down on the number of environment variables that you need to set in order to set up Langfuse.

So for example, we just auto-assumed a data region, like, Langfuse is available in Europe, it's available in the US. Fun anecdote, we assumed that only Europeans, like, care about data regions, thus we made Europe the default. Then we learned some US enterprises also care about data regionality.

Now we have a US data region and so many different other data regions. So we always defaulted to Europe, and now we kind of, like, for an agent, like, adding another environment variable, like, they don't care. Like, it's not effort for them.

Thus we always prompt for figure out what data region the user is actually in and don't assume Europe, for example. Two, hallucinated CLI parameters, because it just, oh, this, like, includes the word trace. I have seen tracing CLIs before.

I just assume what we could be doing here, and we just advertise the help flag more aggressively. It takes another turn, but it's fast, and thereby, like, it directly knows what the CLI can do. Two, we tried to help the agent to understand how to navigate available information, because, like, I mean, 500 documentation pages, how to find theright one instead of, like, looping through, I don't know, fetching one, then learning something, then fetching another one, always with, like, thought process in the meantime.

So what did we do? We always had this LLMs TXT, which was very hype when it launched but never actually used. I think what's now cool is we have this agent sitemap kind of, that we just expose to, like, a coding agent via the skill of, like, go there first in order to learn what kind of, like, documentation is available.

And two, I mean, there's, like, this whole content negotiation that if you send, like, a request header that you want marked down, that you get marked down back from the docs, but some coding agents don't do this by default.

So we just advertise this, because otherwise some coding agents might try to parse the HTML, which just adds additional tokens. So, like, for Langfuse, for example, you can just add, like, a .md to any documentation page, or you can request markdown and you'll get a markdown page.

Three, I think that was, like, one of the things I was most excited about. We always had this, like, docs Q&A agent that was able to answer questions about Langfuse more, like, interactively. Therefore we built, like, a RAG stack, and now we just surface this RAG stack again via, like, a search endpoint.

So, like, a coding agent can just ask whatever natural language query about Langfuse and will get back documentation chunks for this query. Why is this exciting? One, you don't need to fetch 5 different docs pages, but you can just ask a question, get something back that's relevant directly, solve for the problem.

And two, we get to track these search parameters, because, like, if a coding agent fetches documentation, it's very difficult to understand what did, like, Claude Code and our user laptop do. But if they ask questions about Langfuse to our search endpoint, we can track the searches and thereby understand what problems do they run into, where do we need to add more documentation pages, because maybe we didn't expect this kind of problem to happen.

So yeah, adding a search endpoint was, like, was really cool to capture more data. Then basic eval setup is better than none, because we initially struggled to get this done, because it's, like, so broad. Some Langfuse users built, like, chat applications, real-time voice, video generation, like, batch processing of, like, invoices in the background of some kind of, like, text software.

Like, so many different use cases where then the question is, what's even, like, a good evaluation, like, setup? And we just created, like, 5 different ones, and this was already helpful, because otherwise it's really hard to kind of, like, measure anything.

And what we did here, can I zoom in? No. So basically we have this, like, just, like, a prompt instrument application with Langfuse and then, like, a sample repository folder. So for example, like, an OpenAI custom function RAG, whatever, application.

And our checks are just natural language statements that we then, via LLM as a judge, try to, like, evaluate on top of the file system and diff state before and after running the skill. So for example, we expect that our OpenAI instrumentation was added, because it's, like, an OpenAI example.

And we, because it's RAG, we expect, like, some retrieval spans to show up in our trace, because if there are no retrieval spans, then probably we only captured, for example, LLM calls. This was already helpful, because thereby we were able to make changes and see that we didn't break anything.

The whole thing that why we even built Langfuse for, like, building AI agents now also applies here. Five, dynamic content should be referenced, because there's a huge, I'd say, incentive for, like, developers on the team, but also for users in the community to just contribute a lot of context to the skill, because then you're like, ah, it's kind of like a local cache of the documentation that's immediately available.

However, then the same thing applies that applies to pre-training context. It's kind of, like, it goes out of date, and now we have the documentation, and now we have yet another representation of what Langfuse is. So you'd rather try to point just straight to the reference of documentation, because otherwise you just duplicate all content.

And six, we applied more of, like, auto-research to the skill of, okay, if we have a target function, how can, like, agents help us improve the agent, because there are so many, like, different patterns that we can explore.

So we set up a target function mostly geared towards, like, our experiment here was help teams move prompts from their local Git repository into Langfuse prompt management, which is used by, like, larger teams to collaborate on prompts with their non-engineering counterparts, because then, like, PMs can make changes to prompts, interact on a playground, like, all of this kind of, like, collaborative stuff.

And the task was, okay, how do we improve the skill to migrate prompts out of any kind of, like, code base into our managed prompt system? And in the end, we accepted 3 out of the 6 improvements that were suggested, which I think is a success, but it allowed us to experiment much more than we could have explored manually with the time that we have, as we are, like, a very small team.

Learnings, like, the target function really matters. Like, I think it sounds obvious, but for us, defining, like, theright target function was very hard for this, because we assumed, like, a prompt migration should be fast. Fast, we measured in, like, the number of turns, but if we basically asked to minimize the number of turns, then, like, our, like, the agent that tried to optimize the skill just took out all of the notes that we had to, like, fetch documentation, because it was like, I know how Langfuse prompt management works.

I don't need this. I'll just try it myself, which then negates the whole thing of we want to fetch up-to-date context, because otherwise if you use the skill, install the skill once, wait 3 months, then you'll have, like, wrong context, because we duplicate information.

Two, like, we had, like, an approval gate usually, where we want to suggest a plan or ask follow-up questions, suggest plans to a user before doing anything, because we kind of, like, push their prompts to, like, a central repository, and it's kind of, like, their data leaving their laptop somewhere else.

But the sandbox didn't have this, so we didn't really, weren't really able to try for this. And, like, Langfuse, like, the sole feature, like, usually we try to make it easy to get going with something, but then it's very deep of how to do it in a good way, and we want agents to directly go for the good way.

Like, figure out with a user what they want to achieve and then have, like, a very full implementation, not start with something and then, like, 2 months later go deeper. However, if the target function does not include, like, we want, like, linking prompt versions to prod traces, so then you can see how, like, different prompt versions impact, like, for example, production results.

Like, we didn't have this in the target function. Thus, like, everything that, like, nudged towards this was kind of, like, removed, because it's kind of, like, it's just, like, garbage on the way that we don't need to achieve the goal.

So again, the target function really matters. High level, these were, like, the 6 main takeaways. Looking at traces gets you 80% of the way. The production signals really help, so the search endpoint was really helpful for our documentation.

Help agent to navigate the information, because otherwise it just searches with, like, Google, Brave, whatever search, and finds all sorts of different things on the internet. Even a basic eval setup helped. It wasn't that hard to set up.

The dynamic content should be referenced, otherwise you have just duplicates, and the auto-research was very helpful to explore things, but it's bound by the target function. Topics basically on our minds here are, it's so powerful, but at the same time you kind of then duplicate stuff into, like, user space kind of, like, somewhere on, like, a machine.

Like, there's no, like, package management for this, which then, like, tells the user this is outdated. Like, we could, we thought about just adding, like, a timestamp of this, the current date where it was fetched the skill, and then just, oh, if this, like, older than a month, then try to update.

But then we go to the second problem of skill distribution and, like, installing into, like, the agent environment. Usually this is kind of, like, gated or not possible for the agent, like, depending on what you use. This user needs to do something to install the skill.

This also upgrading doesn't, auto-upgrading doesn't really work, but it really depends on the coding agent that you use. And, like, the target function is interesting for us, because, like, we can either go for user needs to get to, like, an initial aha of, like, oh, this works, or do we want to directly straight shoot for this is the perfect setup of how you would do evals for this use case.

But this is, I mean, without a skill it takes, like, usually, like, an AI engineering team it takes, like, a month to get to a perfect setup. Do we now aim for an agent to do this in a single shot and overload the user with lots of, lots of questions, or do we just try to get to something and then you can still invoke it again of, like, improve my setup, ask, and then it can ask questions to improve it.

So it's kind of like, what's the target for the skill that was very interesting for us. Yep, I would invite you to try it and give us feedback, because that would be really interesting. And, like, we do lots of, lots of calls with people from the community every week, and, like, I think it's not a surprise that I think nobody reads documentation themselves, and everyone is just like, yeah, just add this to my, like, I just want this to work.

Like, just add it. So yeah, the skill is the primary way of how things get done. This is also, like, now the advertised way across all of our documentation that you just should ask your coding agent to do whatever you try to doright now.

I'm very excited that it works really well, but also I'm excited to see what comes next. For us as a project, roadmap-wise, we see the skillright now, like, our users use this when getting started with the project, but also to drive a lot of automation around the, like, evaluation life cycle of, oh, I now want to create, like, an LLM as a judge that's aligned with user preferences, or, like, I got user feedback on 100 different executions, what do they have in common, and users then fetch this via the CLI.

So many of these workflows that people needed to do manually, now coding agents do for them. We'll bring this in product via, like, we'll help automate this via skills 1, bring this in product 2, and then 3, I feel like we just need this orchestration agent that does what the team is doingright now.

So yeah, I'm very excited for our roadmap to automate all of this, but yeah, if you have any feedback, I'm around, Annabelle's around, I would love to talk to you. And yeah, thanks so much for your time.

I don't know, do we have time for a question? Okay. Yep.

Can I ask? You said, like, when you were tuning the skill, the human was completely out of the loop, so you were, like, it was basically, like, Claude Code directly trying to implement using the skill theright implementation and then you measured this?

Or.

Yeah, it was kind of, like, I mean, you kind of want to be out of the loop for the experimentation and then just review the suggested changes. So it was kind of, like, experimental things, give us, like, all sorts of different recommendations and then human review the suggestions.

Like, we didn't accept all because many didn't make sense, because our target function wasn't perfect. It was really difficult to get to, like, a very perfect target function, but it's good at just creating ideas and then we human reviewed all of the ideas to make the changes to the skill.

But so at the end, the skill might not be optimizing for, like, the human-AI interaction. Like, let's say I work with, like, Claude Code and I try to set up, like, the traits for whichever project, then the skillright now might be optimizing for something different and it's very optimated, or I don't know.

Yeah, that's what we try to kind of, like, you need to try it yourself to just get a sense of how it feels to use the skill to then, like, add Langfuse to an application. So we just use it ourselves to get a sense for the feeling, because it should, like, where we want to go is it should feel like, like, an expert user trying to guide you through what you need for your problem, where usually someone comes in with just, like, I need evals because I read about it online, but I don't know what actually I need for my application, and I kind of, like, it needs guidance of where you want to go.

Like, what is your problem? I don't know. What do you worry about? You probably don't need, like, a, I don't know, hallucination eval, but probably you need something that's very specific to your application. And yeah, that's what we want to achieve with the skill, that you get, like, some, like, professional guidance.

Yep.

I really resonated with your last point about skills distribution. It seems frankly insaneright now of just, like, you just install whatever GitHub repo is on the. What are your thoughts on sort of, like, the treating skills as packages, like, a PC skills kind of approach, or, like, going full all-in on, you know, plugin marketplaces instead, like, what do you think is, you know, able to be adopted by the community versus capable long-term if you have, like, provenance instead of.

As a small team, I'm not that excited about plugin marketplaces, because then you now need to kind of, like, maintain all of these proprietary integrations, update them in, I don't know, tell Anthropic, tell OpenAI, tell Cursor, whenever you make an.

Is Anthropic and OpenAI are now agreeing on sort of, like, broadly plugins?

Yeah. Still, I mean, like, for the skill, I think it would be cool if we just had, like, a well-known skill or something, and, like, whenever someone is like, oh, I want to, for example, use Langfuse, like, the agent can just auto-discover that it exists.

Like, we have it across all of our docs, so I think it would be enough if the agent can kind of, like, ask user, I want to install a skill. Question is, do you even need to ask? Like, I think you only need to ask if the skill is kind of, like, more trusted than the public web.

If it's, like, same trust level, then why even bother asking? And then two is kind of, like, if I have this installed, it's kind of like a cache of something that was up-to-date when I installed it, but then the question is, how do I know whether it's out of date?

So I think just, like, timestamping it is enough. So when you use the skill, that agent can be like, oh, this seems old. I should probably, like, fetch a new one. I think this would already go a long way.

But yeah, I'm excited to see. Like, we are going more the timestamp fetch route or alert user of this might be out of date. That's at least, like, what we discussed now. But yeah, I'm excited to see what everyone is shipping in this space.

Yeah, I'm around. Thanks so much. Bye-bye.