00:27:24 · Brett Caughran, Matt Stockton
[00:27:24] S0: It's sort of become the singular focus of almost singular focus of the consulting we're doing, just helping people map that. We've built a map of sort of what we view as a style agnostic fundamental investing process into 800 sort of primitive subatomic steps to sort of show a salad bar, if you will, of the various steps to sort of inspire, help people address that blank page problem. But it is hard. There's such a combinatorial complexity of what investors do because the way a multi manager utilities analyst approaches his or her day versus a family office long only banks analyst approaches his or her day, the data they're looking at, the decisions they make, what good management means, what a good bank is versus a good tech company. It's a very specific exercise. And so that cloning of your own process is, I think, a real bottleneck. [00:28:30] S1: Yeah, yeah, yeah. [00:28:32] S0: And I like your processes, Matt. We've done similar, but it still does take time off the desk to really start to do that. [00:28:42] S1: Yeah, for sure. I mean, think it's a similar story to having to spend the time to learn AI. You actually have to spend the time to build the materials that will give you this benefit with these models. Right. Yeah. I mean, you know, pulling yourself out of the weeds to do this is hard, right? Because everyone has a real job to do and it's not learning AI or building the tools to make the AI better later.
00:28:42 · Matt Stockton, Brett Caughran
[00:28:42] S1: Yeah, for sure. I mean, think it's a similar story to having to spend the time to learn AI. You actually have to spend the time to build the materials that will give you this benefit with these models. Right. Yeah. I mean, you know, pulling yourself out of the weeds to do this is hard, right? Because everyone has a real job to do and it's not learning AI or building the tools to make the AI better later. [00:29:13] S0: Yeah. One other bucket I've really been struggling with a little bit is, you know, with the open tools now, whether it's co work or codex or perplexity Computer, I can get to very good prototypes very quickly on pretty much every workflow of the investment process. I still struggle a little bit with consistency. I struggle a little bit with accuracy in those. And I struggle with the token economics of how that scales up to an investment process. So that sort of like last mile problem of productioning those demos still feels like a hairy issue. What have you seen? Like, are the sort of the bags in your tool, you know, the tools in your toolkit or what you've seen clients do to actually production these demos?
00:30:06 · Matt Stockton
[00:30:06] S1: Yeah. So it, you know, my view is that if you can find a way, like if you can find a way to use, to assemble the tools that exist in creative ways and kind of limit how much custom stuff you're building, that's ideal, right? So example would be, okay, if you can use one of the main harnesses like Codex or Cowork, and you can build a refined set of skills for your company that are aligned to what you're trying to do. And then you can have the suite of data sources, whether they're, you know, an MCP server, which, you know, allows you to connect to an API via the models. Like, if you can do that and then share the knowledge of, like, how that system that you've built fits into your workflow, like, what are the expectations of when people use the thing and why? That goes a long way, right? I think, you know, and that requires you to have access to the data sources, requires you to spend some time building out your intents and these skills. I think ultimately, you know, and this is probably a good thing, but like once companies are getting value out of that, they oftentimes hit something where, oh, we want to do something a little bit more custom. Like we want to run like reports on a schedule, or we have a data source that we want to integrate that, you know, doesn't have an MCP server. So like that's kind of when it's tricky because if you're like a smaller firm, you can't expect to have like an engineering team to do this. But I think, you know, sometimes you actually do have to kind of build something, right? And back to the bitter lesson idea too, is like, you have to be cautious here because things are like continually changing, So like you don't wanna build something that might be thrown away immediately, or you wanna build something in such a way that such that it can be like repurposed later, which is why I actually really like this concept of skills, because when it comes down to it, it's kind of just like writing down what you want in English, right? And it's a little bit bigger than that, but that's the simplification. And that's going to be, I think, durable over time, right, and useful.
00:32:29 · Khe Hy
[00:32:29] S2: I was about to ask you about skills. You're a big proponent of them. And I've found that many of the folks I work with, they can kind of get their first couple skills, you know, like, oh, you know, earnings call, like, transcript reviewer, kind of like the blocking and tackling. But once they kind of get those kind of core, and they tend to usually be summarization skills or synthesis skills, struggle, and myself too, to kind of expand the map of what's possible. And I know like OpenCLOF, for example, a lot of the code is actually skills files. And so how do you, how would you guide folks who are kind of earlier in their skills journey to move beyond just synthesis skills? Like whether it's a mental model or an actual, like, tactic that you would recommend for them?
00:33:18 · Matt Stockton
[00:33:18] S1: Yeah. You know, I still like to think about in terms of like, okay, what are you trying to accomplish? Right? Like, not necessarily like, what's the skills library I should build out? But, you know, back to Brett's point earlier is like, try something that you think the model will not do correctly. And hopefully you'll be pleasantly surprised. So I think it's more about expanding, first of all, expanding people's view on, like, what these things can do and then experimenting with it. Like, maybe you do something that's, like, more cross cutting in nature than what you're generally using these tools for. But it turns out too, like, if you go at it with an applied approach of just trying something and you get to a really good output, like, you can turn that into a skill, right? Like, you can ask the model to be like, Hey, like, let's do that again later. Can you help me turn that into a skill that I can reuse? So I like that applied approach versus, you know, just like once you kind of do have a recipe that works and you're like, This is what I want. Like, I think that the objective there is then to kind of make that durable and reusable, and then ideally, you know, share that knowledge back with your team, right? Like, embed that new skill or that workflow in the shared repository where other folks have access to it. Like, share that knowledge.
00:34:39 · Brett Caughran
[00:34:39] S0: Matt, have you found any best practices on skills creation? I mean, back to prompts, we had a speaker say beyond four to six pages, the chatbot starts to lose attention. There any equivalents that you've found in skills in terms of depth versus efficiency or other elements in creating skills that you've found helpful for people to think about?