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

Okay, that was great. Hi everyone, super excited to be here. I'm Mark, one of the founders of LangFuse. 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." Built like LangFuse is the open-source project in the space by now. And with 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 what the lessons we made from scaling up coding agents actually adding LangFuse to an application because like back in the days when you had 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 do 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 didn't have 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. I had 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 you can solve a Rubik's Cube. And I feel like the same thing now applies to to agents where like there was this whole debate of like workflow versus fully autonomous agent. It was like huge fight on X of like what is the best way to build an application.

Everyone was kind of like, "Yes, you kind of both." And I think Mars 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 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. Like you have a customer like customer support agent and someone asked for like a password reset. Then historically you would have built like a workflow that's very reliable of like 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 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 two things. One, like new kind of like use cases that you didn't expect a user to do because you might have expected that nobody ever wants to change a password but now they want to change the password. This you need to see the execution trace of someone being upset by like a production email 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 see most teams do uh that you use LangFuse now more towards like the learnings uh we made uh when building a skill to help uh customers add LangFuse to their project.

So, what was the lay of the land before we got started with this? Um 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 five different feature areas, and a lot of implementation flexibility because they've 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, we'll still work. If you want to customize your evals, it'll still work." So, we always take more on the opinionated side. Uh which was always, I'd say, uh a weakness compared to uh projects that are more opinionated, but now I think it's a strength because in the end, what what what what do you need uh when agents do all of this?

You only need the infrastructure piece if agents can then customize for different workflows. Um so, uh 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. Um and uh interestingly, uh when we first got into model pretraining 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, uh and now being in pretraining context might even be like a disadvantage if uh you don't fetch up-to-date information. So, we're just like, "Oh, we get like all of these hallucinations of methods that have been uh available in the past, but they're not uh available there today." So, yeah, we 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 uh when you just ask Cloud Code to add a language 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 Cloud Code kind of like implements the instrumentation based on the outdated pre-training context, then tries to verify whether tracing works, then realize, "Oh, it doesn't work." And then only in a 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 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 for your application.

So, main problems are outdated training data, the non-optimal setup because the agent wasn't really like primed to help you discover what to do for your 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 to fix the the issues. So, what did we do? Ah, yeah, this how the this how I just mental mental note, this how the trace look like when we just tried with Cloud Code to like just trace two LM 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 LangChain user, like there are thousand of teams in the community, thousand of customers on our cloud product, give them all like a LangChain expert to help them quickly set up observability, for mentionment, evals in line with like best practices and up-to-date docs and like references. Because all of you, I mean, there's Anabel 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 a thousand of people to basically talk through your problems and figure out what the best strategy is for you.

So, we are like, "Okay, skills is the is the way to go." And this is like very conceptual how our skill works where like user comes in, ask coding engine 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 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 start open source and like saw ourselves as like an opinionated infrastructure, we always had like APIs for everything because teams built their own, I don't know, on labeling UIs on top of it, on evaluation execution logic on top of our our back end. And we had APIs for everything. Now we 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 spent so many hours every week in clicking around in our UI to evaluate and improve the 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're building towards. Everyone's building towards. I think that's a cool step in the right direction.

So, to to shortcut to the end result, okay, after like conversing with the agent now for the for similar thing, it looks way more detailed like like detailed evals that are relevant and detailed steps are regarding tool execution. So so just like there's 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 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 things right away while they haven't dig through through like just like what did the agent actually do at runtime themselves a couple of times. So so what did we do? We have instrumentation for cloud code and just ourselves interactively like tried to use LangFuse with cloud code and then look through traces in length use to understand whether there is an 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 to the target.

And 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 length use. So, for example, we just auto assumed a data region. Like, length use is available in Europe, it's available in the US. Funny anecdote, we assumed that only Europeans like care about data regions, so we made Europe the default.

Then we learned some US enterprises also care about data regionality. Now we have a US data region, 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've seen trace things in CLIs before. I just assume what what we could be doing here. And we just advertise the 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 try to help the agent understand how to navigate available information because like I mean, 500 documentation pages, how to find the right 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 LLM stakes see, which was very hyped 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 by 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 an a request header that you want markdown that you get markdown 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 pass the HTML, which just adds additional tokens. So, like for length use, for example, you can just add like a dot MD to any documentation page or you can request markdown and you'll get a markdown page. Uh three, um I think that was uh like one of the things I was most excited about. Uh we always had this uh like docs Q&A agent that was able to answer questions about LangFuse more like interactively.

Therefore, we built like a rec stack and now we just surface this uh rec stack again via like a search endpoint. So, like a coding agent can just ask whatever natural language query about LangFuse and we'll get back documentation chunks for this query. Why is this exciting? One, you don't need to fetch five different docs page where you can just ask a question, get something back that's relevant directly. It solved for the problem and two, we get to track these search parameters um because uh like if a coding agent fetches documentation, it's very difficult to understand what did like cloud code and our user laptop do.

But if they um 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. So, adding a search endpoint was like was really cool to um capture more data. Um then uh 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 uh software. Like so many different use cases where then the question is, what's even like a good evaluation uh like setup? And we just created like five uh different ones and this was already helpful. Um because otherwise uh it's really hard to uh to kind of like measure measure anything.

And what we did here, um I don't know, can I zoom in? No. Um so, basically we have this uh like just like a prompt instrument application with LangFuse and then like a sample uh repository folder. So, for example, like an OpenAI custom function rec, whatever, application. And our checks are just natural language statements that we then via LLM as a judge try to um like evaluate on top of the file system and diff state before and after um running the skill.

Uh so, for example, we uh we expect that our open eye instrumentation was added because they can open the eye example. And we, because it's rag, we expect like some retrieval spans to show up in our trace. Because if they if they're no retrieval spans, then probably we only capture, for example, LM calls. This was already helpful because there we were able to make changes and see that we didn't break anything. The whole thing that why 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 rather try to point us to straight to the reference of documentation and because otherwise you just duplicate all our content. And six, we applied I'm more of like auto research to the scale 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 and try it on a playground like all 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 three out of the six 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's it sounds obvious, but for us defining like the right target function was very hard for this. Um this we we assumed like a trunk migration should be fast. Fast we measured in like the number of turns, but if we uh basically asked to minimize the number of turns, then like our uh like the agent that tried to optimize the scale just took out all of the notes that we had to um like fetch documentation because it was like, "I know how to how lengthy this prompt management works.

I don't need this. I'll just try it myself." Uh 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 um because uh we duplicate information. Two, um like we had like an approval gate usually uh where we want to suggest a plan or ask for a question suggest plan to a user before doing anything because we kind of like push the prompts to like a central repository and it's kind of like their data leaving their laptop somewhere else.

Um but the sandbox didn't have this, so we didn't really we weren't really able to uh to to try for this. And um like LangChain like the 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 the user what they want to achieve and then have like a very full implementation not to start with something and then like 2 months later go deeper.

However, if the target function does not include uh like we want like uh linking prompt versions to prod traces, so then you can see how like different prompt versions impact like for example production results. Um like we didn't have this in the target function. This uh like uh everything that like nudged towards this was kind of like removed because it's kind of like it's just like 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 the six uh main takeaways. Looking at traces gets you 80% of the way. The uh production signals really helps, so the search endpoint uh was really helpful for our documentation. Um help agents to navigate uh the information because otherwise it just searches with like Google, Brave, whatever search and finds all sorts of different things on the internet.

Um even a basic even setup helped. It wasn't that hard to set up. Dynamic content should be referenced, otherwise you have just duplicates, and the auto research was uh very helpful to explore things, but um it's bound by the target function. Um topics basically on our minds here are uh it's so powerful, but at the same time, you kind of then duplicate stuff into like user space kind of like somewhere on on like a machine.

Um like there's no like package management for this, which then like a year like tells the user this is outdated. Um like we could uh we we we thought about just adding like a timestamp of uh this is the current date where it was fetched uh the skill, uh and then just uh oh, if this like older than a month, then try to update. But then we go to 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 uh what you use. Um this user needs to do something to install the skill. This also upgrading doesn't uh auto upgrading doesn't really uh really work, but it really depends on the coding agent that you use. And uh 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 months 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 and 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 it can ask questions to improve it. So, it's kind of like well, what's what's the target for the skill?

That was uh very interesting for us. Uh yep, I would invite you to try it and give us feedback um because that would be really interesting. Um and uh like uh we do lots of lots of calls with people from the community every week, and uh like like uh 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." Um 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 um that you just should ask your coding agent to do whatever you try to do right now. Um I'm very excited that works really well, uh but also I'm I'm excited to see what what comes next. Um for us as a project roadmap-wise, we see the skill right now like our users use this when getting started with the project, but also um uh to drive a lot of automation around the like evaluation life cycle of oh I now want to create like an element as a judge that's aligned with user preferences or um like I got user feedback on 100 different executions, what do they have in common?

And you just then fetch this via the CLI. So many of these workflows that people needed to do manually now coding agents do for them. Um we'll bring this in product via like we will help automate this via skills one, bring this in product two, and then three I I feel like we just need this orchestration agent that does what the team is doing right now. So yeah, I'm very excited for our roadmap to to automate all of this, but yeah if you have any feedback, uh I'm around, Anabel's around.

I would love to talk to you. Uh and yeah, thanks so much FOR YOUR TIME. I DON'T KNOW DO WE HAVE TIME FOR A QUESTION? OKAY. YEP. UH YEAH, it was kind of um like I mean you kind of want to be out of the loop for the experimentation and then just review the suggested changes. Uh so it was kind of um like experimental things uh 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 uh 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 >> Yeah, that's what we had tried 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 like add slightly student application.

So we just use it ourselves to get a sense for the feeling because it should like where where you want to go is it should feel 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 eval 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 you what you worry about. You probably don't need like a I don't know hallucination eval but probably 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 some like professional guidance. Yep. >> I really resonated with your last point about skills distribution seems practically insane right now or just like you just install it whatever you get what are your thoughts on sort of like the treating skills as packages like a big C skills kind of approach or like going to pull all in on and you know plug in marketplaces instead like what what do you think is able to be adopted by the community versus being stable long term and you have like prominent set of things. >> Mhm.

As a small team I'm not that excited about plug-in marketplaces because then you need now need to kind of like maintain all of these proprietary integrations, update them and I don't know tell Anthropic, tell OpenAI, tell Cursor whenever you make them. 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 exists.

Uh like we have it across all of our docs, so I think it would be enough if agent can kind of like ask user I want to install 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? Um and then two is kind of like if I have this installed, there's kind of like a cache of something that was up-to-date when it when I install it.

But then the question is how do I know whether it's out of date? So I think so just like time stamping 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." Um I think this would already go a long way. Um but yeah, I'm excited to see like we are going more the time stamp fetch a route or alert user of this might be out of date. Uh that's at least like what we discussed now.

Um but yeah, I'm excited to see what everyone's shipping in this space. Yeah, I'm around. Uh thanks so much. Bye-bye.