Claude Skills, AI Agents & The Build vs. Buy Decision for Marketing Agencies

Welcome to How to Scale an 8 Figure Agency 🚀. My name is Jordan Ross and I am your host. And over the course of this journey, we're going to be interviewing 8 Figure Agency owners and going through the systems that I've seen work and we've implemented into our clients' businesses that have helped our clients add a half a billion dollars in annual recurring revenue over the last handful of years. I myself have already hit the 8 figures in annual recurring revenue and when I got there, I wasn't happy. I was stressed, I was dissatisfied and I didn't like the people I was working with. So I clicked the restart button and went from 12 million in annual portfolio revenue back down to the mid 7 figure level to a climb back again. And on this journey, I'm going to be documenting my process and how I'm getting back to the figures and bringing you expert industry leaders who will tell you everything they did to get there as well. Thanks for tuning in and enjoy the episode. What is up, everyone? I have Ben Fisher, the founder of Skinny and Bald, one of my friends from Hampton. This guy is probably, I don't know, Ben, I think you're too humble to say I think you're one of the smartest guys in Hampton, that AI channel. There's hundreds of founders in there. And I wanted to bring him on today for a second time to the pod to really rip it on just a lot of deep shit on AI. Like what's actually working right now, FAQs that I'm having, and actually probably pull up a terminal and just build some shit in real time. So Ben, for everyone that doesn't yet know who you are, who is Ben? And then let's rip it from there, man. Jordan, thanks a lot for having me on the pod. Yeah, as I said, I think this is the second time in like the last year. Like the short version on my end is I started coding like fifth grade, a group on a tree farm in Maine, and would sell strawberries door to door to buy computer books. Yeah. So for most of my life, I mean, it's crazy to think like truly most of my life, I have always been coding. It's never been for me about being so much an engineer, but just genuinely being really curious about stuff and wanting to build things. And so, you know, tech has gone through a bunch of evolution in the last 30 years, which I guess is how long I've been, I've been programming on the internet. And so for the last 20 years, 15 years, I've been building largely software companies. So B2B SaaS, you know, happy to dive into any of that where it's relevant. But like, I think from a high level, I don't consider myself, I'm not a full time engineer. I have worked as one before, but I describe myself as 60% product, 40% engineer. And it's really at the service of building cool shit. I've been the CEO twice, the CTO three times. And so like, again, for me, it's largely been, I don't know how unique that is in terms of like my interest space and where I've played. But it certainly has, I think, led to sort of an experience where I'm not like I can speak nerd. I'm a nerd in a lot of ways. But I think part of what I think has worked well for me is that I also am a pretty, like normal human being. Not to be dismissive of my brethren, but happen to dive deep into any of this stuff. I think for me specifically, AI has actually felt certainly this moment in AI has been sort of like the, like the perfect weird moment for someone like me who's more on the product side where a lot of my frustration building tech companies has been like I would build the first version of server product. And then I would quickly shift into customer development, sales, more higher level architectural stuff. And I would, I would hire engineers to take over the day to day building. I would still be involved as a tech leader, but really it was at the business level. And when Cloud Code came out, I guess it was like a year and two months ago, March of last year, it was really the first time in probably like nine years that I was able to sort of like really get in and build stuff really, really quickly, quickly with a feedback loop that just wasn't historically possible when you're managing a team. It's been a cool journey for you is what it has been. Well, first off, thank you for the overview. I think it's really, it is a cool inflection point, especially for a guy like you, because I sit alongside one of my partners who he's a marketer first engineer second, he calls himself a mediocre engineer. But it's interesting seeing like how he and guys like you can move at the speed that you move is a disproportionate to an average person like myself. So with that, what I actually want to do is I want to go into some like real live Q&A for stuff that I'm cooking up that I have a team. I have people I could ask, but I'd like to bring this on the pod and you're just like one of the smartest people. So it's, it's great to have you here. So I come with questions and we'll just see where this conversation goes. For those of you guys listening that want to get a glimpse before we dive in, how to know when to custom code something or use a tool. So I'll give a precursor there. Like I started modeling something out, scoping something out. And then my partner's like, you should just build on and go high level. I'm like, really? Like they could do that? How founders can max out their time. So how do I scope things out with like in Claude and then ship it like, and then portal. So like, uh, I don't know if I want to talk about that one anymore. Cause that was, I have some new developments from last night, maybe just like actual like terminal stuff, like operating from a terminal as a marketer. I'd love to maybe just like we tinker with it. So I want to start with maybe just, I'll give you the situation on that first question. Is that okay? Okay. So my biggest source of, we'll call it leads in both my funnel and my biggest source of like subs to my newsletter is it's called a giveaway funnel. For those of you guys who follow me on X or LinkedIn, I'd published one before this pod. It was 111 page, like super robust, like, um, my AI assistant called it a codex, right? Like super robust manual on how to like maybe 10 pages or 20 pages or how to set up open club. But then like the others are, here's 93 automations that like every step by step by step by step how to build it. Right. So we build these very robust manuals and things that you could upload to LLMs or like open club. And now you could build stuff faster and you know what to build and you have a roadmap and people comment, open club, give me that whatever. And then we, we send them to a landing page. They give us an email from the email. They end up on my newsletter from the, and then if they give us their email, they get routed to a form that qualifies them. And then they get routed to a landing page. So like there's people that comment, people that give us their email for the thing, people that fill out the form and then people that actually book a call. So that's the funnel within that funnel. There's like, if you start at the bottom, the people that give us their email and fill out the form, we have a lot of information about them. What's their biggest problem? How big of a company size of company, like, are they looking for a call right now? Most people say no, but then it's like, we should get their cell phone, probably text them. Thanks for getting this thing. Do you need help? And then we should start working a funnel. So like there's different groups. I run these like three times a week per platform. So I'm running like six different things. Some people are like coming back again. And so there's this myriad of like opportunities to pursue. And I was like, this seems like I could stitch together this tool here and this tool here and this texting and this emailing and then auto DM them. And then like some custom shit. And then my partner was like, you should use go high level. I'm like, why? Like, shouldn't I be building cloud code? So like, what is the frame for you as an engineer of stitching together tools like I just described versus like using a tool like a go high level to that could text that could follow up that could thank people. But like, I don't know if it's as sophisticated as I might want to make it. My thinking has really evolved over the last year, really over the last nine months on this. Like I was among the earliest users of Zapier. I would say that and it's been a joke within my friend group that I like automated out my life. Like I had an assistant, an EA for about 17 years, which was initially an attempt to force myself to learn to delegate. And this is back when Zirtual was around. I don't even know if you remember Zirtual. Zirtual was before my time. So 17 years ago is like, yeah. Yeah, yeah. Because I'm 41. So I don't know how much older I am than you. But yeah, like Zirtual is like the OG within like the virtual EA space. And, you know, the engineer side of me and even the product side of me was like, I want to eliminate unnecessary steps from both my personal life as well as my business life so that I can just focus on, we'll call it, we'll just summarize it as being present in whatever is most interesting to me at the time, which largely is like business stuff. And I get like a deep sort of sick satisfaction out of figuring out how to create leverage. Like there was one point where I had my assistant managing my Airbnb while I was having to travel for work, who had like a maid coming in. My assistant actually flew across the country to like find me a new apartment because my lease was up while I was out of the country in Slovenia. And so it was like a wild, like, you know, there's an element of like how practical was certain aspects of this. But certainly at the time it was actually really necessary. Now, like 15 years later, it's mostly just funny. But for me, a lot of it's come down to like being really interested in understanding how systems work and how can you create a systems that historically, when you're using humans, have their own sort of brittleness. And so when Zapier and these other automation tools came out, I went really deep into figuring out like, how can I orchestrate a bunch of different tools, each tool kind of owning different parts of, you know, whatever that workflow is. I think at the time I was using Trello for project management, but then I was like, you know, I was getting emails. And so I've experimented a lot with automation. And about a year ago, I think N8N was really blowing up, which was really more like the developer centric, more sophisticated version of Zapier. And there's a million versions of Zapier now out there. But N8N sort of stood out because it enabled people to share workflows. And you see these lead magnets all over X and LinkedIn where it's, you know, people sharing these like super gnarly, absurdly complex N8N workflows that honestly, most of them don't work. Right. But you look at them and you're like, this is absolute madness. Who had the time to do this stuff? And so all that to say, where I've arrived at really in the last seven months, especially with Cloud Code, it didn't necessarily make sense for you to ever build something in-house that really hit across all the different components that you would need to build. The conventional wisdom and really, if you think about software, it's like this idea of have one tool that does something really, really well, have it focused and then sort of use the right tool for the right job. Cloud Code specifically, or we'll call it like in general, AI engineering has kind of changed a lot of the math on that. There's some nuance to this, but like for me now, I tend to lean towards using Cloud to build stuff. Now, part of that obviously is because I'm an engineer and so I can maintain this stuff. And there's a very real cost, especially when you're seeing all of the vibe coding that people are doing. There are very real costs to building software and having to maintain it. I don't care how many agents you have, right, or how sort of sophisticated or even agentic and self-sustaining you think your software is. There's a lot that goes into maintaining software once you've built it, especially with everything you're seeing around AI security now and all the supply chain issues. And so, you know, I think I can't speak specifically to like go high level. I'm familiar with it, but I've never actually used it. But I think in general, depending on your team composition and depending on if it's an internal tool or an external tool, I think in your case, you're talking about something that is predominant. It's not fully internal, but it's really more around like your lead magnets and your funnels. Like it's not something that has to have 100% uptime. I would lean more towards using something like cloud code as long as you have someone on the team and maybe it's you that can be like, all right, there's some level of observability that you need to know. Is it like actually sending out the emails or the text messages and stuff like that as opposed to using or offloading all of this to a tool? Because what I would say is it also depends on how much of the job that you're trying to do can be accomplished just within go high level. Or are you having to stitch high level, go high level with a bunch of other tools? And are you still having to create, you know, workarounds where go high level does maybe 80% of it, but there's another 20% of it that you still had to find another way to accomplish outside of go high level. Does that make sense? And I think I don't want to be so broad where it's unhelpful, but it's hard without me knowing really like the nuances of what you're trying to do. But it's at least sort of precursor to how I think about this stuff. Well, the framing helps. Yeah, no, the framing helps because it's like go high level does have texting. I'm not scraping phone numbers there. I could email, but I'm actually not going to be using go high level for my email deliverability because I'm using a different email. So I'm using a different software. I would say the majority of it is like I'm scraping. I could probably plug into it to text. I could use a different tool to text. And here's, I guess, a part two follow up. How do you think about databases? Because what I would like as an ideal outcome requires sophistication around the database, which is really just like a really good CRM. And the issue, I guess, with the structuring and go high level, how I'm doing it and the way I'm doing it, it's like the intricacies of how I want to customize the, if they get a second lead magnet from me. That's its own flow because now we've reached out. They haven't reached plied. So it's its new if then. And now it's a second lead magnet. But the second lead magnet, I probably want customization. Hey, so today's is Open Claw. Earlier in this week, it was, I don't know if it's pronounced Hermes or Hermes, right? Earlier this week, it was Hermes. Or Hermes. Hermes, yeah. That's how I read it. I read it as Hermes. But then I heard Greg Eisenberg say Hermes. And I'm like. Yeah. Oh, they don't know if it's like one of those GIF versus GIF things where we might all just be saying all these things wrong. For sure. So going back to the database thing, when you hear me describe this, I want sophistication. And when I see like, call it terminal first marketers, because I'm looking at this from a marketing. I see terminal first marketers. I don't know if they're engineers, but I think they're thinking through terminal first. They're able to, like, we're in a world where we can now customize based on the very specific thing that someone clicked. We could customize their whole experience around that. So we could have the landing page, the copy is hyper specific to the thing they clicked. And when I hear that, I'm like, that's, I want to build that because I know it's possible. And I think Sam Parr, our furious leader of Hampton, he just had someone on the podcast that sold his brand for 1.3 billion because their whole marketing funnel was all custom. My assumption is that's not a tool that's like, I have to build, like, that's a terminal first thinking, but I'm not a terminal first thinker. So that's why, like, how do you think through when I describe this, maybe a layer deeper on having a database or databases to allow for this customization? How would you just think through, like, what's your thought process and like, how would you start to tackle it? That context is helpful because I think at some level, what I hear you describing is pretty straightforward. And what you're saying is like reasonable, right? I'll give a quick anecdote because I think it's relevant. Like, I still use kit.com for my newsletter, right? I have lead magnets that I use through kit. I have quizzes that I custom built that tag people within kit. And then I use kits automations to deal with a lot of the funneling around, you know, who's getting what. I have a trigger like a, when someone signs up for my newsletter, I have kit send them a survey to fill out. That survey then is tagging that person with what their responses are so that I can reference that and segment them within my newsletter flow. Like, I didn't rebuild kit. What I did do is I used kits API to layer in additional functionality that enriches the experience of everyone who goes in and signs up for my newsletter. And I have that, by the way. I have the API key folder open. Yeah. So I have loops, beehive, and go high level. So those are the three tools that have the API keys here. When someone opts in, we're going to push them to loops. I don't know why we decided that. Someone was using it. It was a YC back thing. I don't know. They end up on my newsletter. And I actually have no clue if they're actually being pushed into my CRM even, which is like a different conversation. So I had the APIs. And that's also like, okay, here you. They're in these tools. I have it. I'm not doing anything with it yet. More context. Like the devil with any of this stuff is in the details where it's like, for example, if you want to send text messages, the tradition, I mean, really the only way is to do text messages these days is some version of Twilio. Unless you're using a service. I know that you said that go high level has SMS built into it. So I assume you've got through. But I think they're back ending into Twilio or something. Yeah, I guess what I'm saying, like, even as a developer, Twilio is complex, in part because of a lot of the regulation on texting. Right? Like, so even setting up like WhatsApp or like Twilio phone numbers to be able to send marketing messages, that can spiral into it like a several day thing, even if you're using cloud code. There are certain things where the effort to try to do it, even if you can using AI, I'd argue, does it really make sense for you to, you don't always know these things before you do them. Got it. So what I'm hearing, and I guess this leads to a second question, it's like, I'm almost hearing it's worthwhile having like an AI use case specific consultant at an arm's length or figuring out how to interface like with cloud first before building. So it's like, I think this is anything, right? Like moving slow before fast. I move fast. I'd like to just go. But like in practicality, the best, the entrepreneurs who have the most, I would say leverage and get the best results in terms of like fiscal distribution, they're cautious with their time and their strategy. So they make sure they pick the right thing and do really well at reverse engineering and mapping it out. It's almost a similar principle here almost. How would you think through now? You're a founder like me. I'm not engineer. I'm a founder. I'm not a marketer either. I'm just like, I do know marketing because I work a lot. How would you think through when is it I should talk to Claude? Because Claude's who I'm going to talk to first. Should I use Go High Level or should I be building this? Or should I be talking to someone who's actually probably done this as a consultant? How do you now decipher that? Yeah. I mean, I wouldn't even think necessarily like from the perspective of a consultant. I would think about, I'm sure you've reverse engineered or dissected other people's funnels. I would look at who are people who are doing similar flows or flows that are doing a lot of what you want and ask them, hey, what have you learned doing this? Like, what's your tech stack? It's interesting. Like, my inclination now, and again, I'm skewing in part because I'm technical, but it's like my inclination now is to build things custom using Claude. Now, exceptions to that are oftentimes if I perceive something like, let's say, SMS. Like, that on itself is like, can be a rabbit hole. On the outside, you don't know that. But, like, I oftentimes am looking at, and you can talk to Claude to try to understand this stuff. The challenge, and I'm sure you've experienced this in anyone listening, is the hallucinations. A lot of, and this goes back to like when you're building with Claude, whether you're using Claude just to vibe code something or to build something more serious. It's like a lot of the distinction between what, when people get good results building stuff with AI versus not, comes down to workflow. Like, we all have access to the same AI models, whether it's, you know, Opus 4.7 or, you know, Codex 5.5. It's like what distinguishes, I would say, really effective builders really comes down to some level of workflow. Like, the sort of simplest thing for anyone, including you, when you're thinking about building something is anything you build using Claude code, you should follow a test-driven development approach. Now, that might not mean anything to anyone who's listening who's not a coder. You can ask Claude about it to explain it to you. There are certain, like, Claude skills that I think you even mentioned you want to talk about with Claude skills and custom skills. Like, superpowers is a great example that superpowers is a popular Claude skill or harness that specifically is for creating software that follows a test-driven development approach. And all that means is that what you're doing is you're building, you're planning out what you're building, and you're creating essentially tests before you actually implement features that verify what's being built, in this case by the AI, actually, like, exists. Because one of the most frustrating things when you're building something with AI, we've all had some version of this, is the AI telling you that it's built the thing, and then you, like, dig into it, and the thing doesn't work. Like, I think the sort of colloquial joke is, I want you to build this, but make no mistakes. That's not going to help. One last quick example is a buddy of mine who's actually in Hampton had reached out to me about building a chief of staff agent. He wanted to build, like, a true agent that he could make accessible in Slack and WhatsApp for people on his team, in that he's putting in all of his playbooks, a lot of sensitive data. And I had asked him, I was like, dude, like, what have you done? And I was like, what are you doing on security if you're making this accessible to people through, like, WhatsApp, Slack, whatever? He's like, well, I asked Claude, and I ran Anthropics security review skill, and it says it's all good. And I wrote back to him. I have a screenshot of our conversation. I wrote back. I was like, what about this, this, this, and this? He copied my message that I sent him, pasted into Claude. And Claude wrote back, your friend Ben is absolutely correct. We don't do this, this, this, and this. It's one of those hilarious things where there's, like, a, especially for when building something, if you don't have a background in software, you can get the illusion of things being built completely. And you can't just rely on asking the AI if that's correct or not. Jeff Bezos didn't build Amazon by being the smartest guy in the room. He built it by building systems. In his own words, good intentions don't work. Mechanisms do. And that's the whole game. Most angelians are stuck at seven figures because they're running their business on poor, ineffective, or non-existent systems. There's no repeatable way to analyze data, to root cause constraints, to build the correct strategic plans, to source, hire, onboard, train, retain, develop, manage talent, and clients. Everything is dependent on the founder showing up every single day and willing their business to success. If you want to hit eight figures in annual revenue, you need my 13 systems. Not 12, not a couple processes, but all 13. When you plug all of these into your business, when you identify what you don't currently have, and build all 13 of these systems so you can truly scale, you will stop firefighting and start compounding. That is the difference between running an agency job and running an agency machine. If you want to learn all about these 13 systems to get your business to the next level, go to the link below and get my ebook on the 13 systems so you could finally build a business that worked without you and hit eight figures. In 2024, I found out that I had four years of tax returns filed wrong because my IRS CPA didn't bother to make sure my taxes were correct. The guy that I thought I was safe with, the guy that used to work for the IRS, screwed me. Because I assumed he was actually making sure that the taxes he was filing were accurate. And to my surprise and my detriment, he didn't even care to look. Not because he's incompetent, because he was too busy. He was booked with clients out the wazoo. And he's not an operator. He did not know how to actually scale a practice. And this is the issue with the financial services and accounting industry. And this is exactly why I started Eight Figure Finance. Led by an amazing forensic accountant, CPA, Ben Sternberg, we have been delivering exceptional service and finances and books and taxes that you can trust with your agency. And not only your agency, your life. If you're unhappy with your accountant, CPA, or bookkeeper, or if you want an external party to validate and make sure your finances and books are actually correct, go to eightfigurefinance.com where we will review your finances, P&L, and books complimentary to ensure you're not getting screwed. That's why I wanted to bring you on, too, because it's like it's those use cases that I think the non-coder background people who are not technical, we don't have the frame to even know what is the mitigation ask or the question I'm not going to ask. That's going to a future scenario is going to derail it. But I didn't know how to prompt a question to actually make sure that doesn't happen. Right. I love that take, and I think that's actually a good segue to skills, because skills are something I think about a lot. I think a lot of people who've never built them are actually thinking about a lot. And if you're cool with it, I think this would actually be a really good use case of maybe let's pull up like a screen share for Terminal and talk about skills, because when I think about who listens to this, these are marketing agency owners. So these are people that they have their selling services that they want to agenticize as much as possible. But they have team members that just like anything, they have everyone. A lot of team members are doing different things. So in the past, it was here's an SOP on how we want to write content or make ads or whatever. And now skills, in theory, if you're using like this type of approach, allow standardization around a pathology. Can we use this, maybe the second part of this conversation to maybe we'll just do it around content? Because I think content's like the most ubiquitous and easiest. And I think we're all doing content in some capacity. How do we actually build a scale from scratch around content to elicit, like whether it's mine or your thought process on like, here's how I want to write just social. I don't know. I really don't, we could go wherever direction you want to go with it. But I think it's a great use case of like skills and cloud or whatever. Yeah. And it's an interesting problem space in part because, you know, LinkedIn is now, and X, anywhere with content now, you can see how much of it's like obviously written by AI to the point where I can read stuff. And I, even if there's no specific tell, I can just tell, right? Like it used to be that if it, there's that the AI would always do that. It's not X, it's Y. Like there used to be very specific. There is an element of like sort of predictability in the cadence. I found myself as someone who historically used M dashes. I now actively remove M dashes to try to like make it seem to basically be like, no, this is a human. I'm like, this is silly because, because even though it's on my own AI writing, I have it like remove M dashes and use two dashes. I'm like, this is stupid. Like ultimately, even when I look at myself consuming content, I'm looking at whether it's written by AI or not. I'm like, is there an interesting point of view here? And is there substance to what the person's writing? None of us want to read things that are like, obviously like there's no sort of depth to the, like the, the thought behind it. I have read some things that are obviously AI written. I hope that the author, it seemed what I read was I got something out of the, out of the article. So that's sort of the important point of this is like the way I use AI, especially to help me with writing is I'm putting a lot of thought into challenging. What am I trying to convey? What am I trying, like, what do I actually think? So I use AI genuinely as a sparring partner and I've done a lot within my own and I'm using quad skills that I've built to try to articulate and challenge my own thinking and really, and clarify my thinking. And then I'm using AI sort of for the last mile to help me deliver it in a way that is easy for people to read, skim and understand at a way that hopefully still sounds like my voice, but better. Ironically, I studied journalism in college. I didn't study computer science. I had audited some upper level CS classes, but as I said, like I never wanted to be a software developer, I guess my career. I just, I love it for building stuff. And so I studied advertising and that was a part of the journalism program. So it's funny for me, especially as someone who thinks a lot about writing and communication where I spend an enormous amount of time in anything that even if I'm using AI to write it. The folks at Every, I don't know if you're familiar with Every, they've published a lot around how they approach writing in your voice using AI. And they are very, very public about the fact that they use AI throughout their entire editorial process. They've written a lot around how to like create like an anti-AI style guide. There's another guy named Ruben who's popular on, on the internet. Who's, I think it's like how I AI, I believe is the name of his like sub stack. I think it's one of the fastest growing sub stacks on the internet. And it's about like how he uses AI. Like there's a lot of sort of rich writing, obviously written by AI to some extent about how to use AI to write in your voice and to, but also, and I think this is an important piece is like, how do you use AI and skills to write using AI, but do not have it lose the piece, the thinking that goes into what you want to say. That actually like is capturing what you were thinking about. I like this. And I think that's plugging, that's a good plug for every, I'll pull up a domain. It'll be in the show notes. Yes. Every dot two. If we were T O or T O. Uh, T O T O. So if we were to say like, let's just, I guess, use me as a practical example. I have a flow of how I write. So I write all my newsletters. I usually, I write all my content still. And part of me knows I could augment it better and I haven't had a business need to really build skills, but I'm like, maybe it's practical because I do have all these, I'll have a lot of these conversations. I speak to a lot of founders every week. I had a call this morning. I'm like, that was a great call for a newsletter. And if that got queued up and I have an editing team for my newsletter, that's going to scale. How would you suggest like, let's we start that as a process? In this case, are you saying that you want to have a skill that's extracting like the insights into like the newsletter or? So let's just, let's just use a practical workflow. So I think the most common workflow that people in companies would probably use for content is conversations with clients or prospects turn into an idea, turn into a first draft post from the idea and then get edited. So I guess that would be the most common flow of like ideas and real conversations should become ideas, should become content. Are we starting with a skill on the ideas? What make, like, how do you think through what you know about skills and is skills even the right question here? Do you have a different frame as a native nerd? Yeah, so I can speak exactly what you're talking about because I have that exact flow. And I can also speak to how have I created, we'll call it, how have I organized it? Because I have a different skill for writing for LinkedIn versus writing for my newsletter versus writing for my podcast, like podcast show notes and stuff. Although all of it's still rooted in my voice. So the way that I organized this and I can even pull up some files on my computer to show you. Whatever you want to show, I would love to see it all because as long as it's cool. Yeah, no, no, that's good. But before I jump into any of that, I think it's really easy to get kind of lost in details. So let me just kind of share the way that I have refined and evolved my workflow. So I have like an AI recorder that joins all my meetings I have for years. That recorder, I use Fireflies today, saves a transcript of my meeting into, we'll just call it into a folder. It could be a Google Drive. It could be an actual like markdown file in a folder on your computer. It doesn't matter. You have transcripts of your meetings. I have a skill that is specifically runs on a schedule to go through and mine for insights from all of my calls over the last 30 days. Can I pause you there first? Sure. So it's in a file on your computer, you said? Yes. Yes. That is currently what I do. Yeah. So I have Fireflies on everything. Yep. Just for what you think is the most efficient and the most practical, what would you suggest as a starting point taking these transcripts, going back to my database question for where does it go? Where should it go? How do we get it automated to first from a note taker to a place? And then from place, let's build skill and then automate the mining of content. Right. So let's start with that flow. Initially, when you have a note taker join your meeting, like all of the meeting notes that it automatically generates, which I generally find are pretty shitty, and the transcript exists within your note taking app. I have a Claude skill that's specific for processing meetings. I have chosen for a bunch of reasons to, rather than have an AI agent automatically run after every single meeting, I've chosen to explicitly run the skill to basically extract whatever meetings I want. Like if I don't specify meeting, it grabs all of the meetings in the last three days that I have not processed. And it creates a meeting note for every single conversation or every single meeting. And then it also saves a copy of the transcript in a transcripts folder. The reason I have it on my local file system is so that my second brain has access to all of my meeting transcripts. Because I'm oftentimes talking to or exploring ideas, and it's much faster for an AI to read your local file system than for it to maybe making a bunch of remote calls to like Fireflies, for example. That's purely an architectural decision. And if I wanted to review like the last nine months of notes and like using multiple agents, it's going to struggle and be very, very slow generally, if you have all of those transcripts within the service. Let's do a quick pause. For people that don't have good hardware, what do you recommend for hardware? Like what would you plug here as Ben's plug of approval? What would you say for someone that will start that process? Because I don't know if meeting notes take up a lot of space. Like the thing I'm navigating personally, I'm like, I'm downloading more things. I'm storing more things. And I don't actually know at what point does my setup, which I purchased as a non-engineer. I hired an IT guy. I say, what? In 2024, I say, what should I buy? In 2024, just told me this is the laptop. And then here's the desk, whatever. So meeting notes, just don't even think about it. Just like I should build a automated process using Claude code to download it to a local file, you're saying? All meeting notes? I have a skill that... So build a skill. I built a skill. And what's the difference between a skill and an automation? Because I actually thought what I'm hearing is download meetings into file sounds like automation. So what's the variance between that and skill? Yeah. So an automation is more conceptual. It's like I'm automating something, right? And you can have automations that run on their own where you don't have to tell it to do it. The way that I'm using in this conversation is I will run a Claude skill. So it is a skill, in this case, that kicks off a bunch, a series of different things. And sometimes it's a skill that calls other skills. So this thing get pretty meta. A skill, in this case, really sort of used in the same language as in automation. To answer your question about file size, it's negligible. It's literally a text file. So it's like, let's call it like 10 kilobytes, right? Any modern computer, not an issue at all. The most important thing is having, using a note taker. And I think the other piece of that is having a Claude skill that can connect to your note taker to be able to, you can analyze your notes as one-offs or you can have it actually extract a meeting transcript and store it within a transcripts folder on your computer. And I have a follow-up question to that. Do you store it as like a, I'm a Windows guy. So like I actually have like a text file, like Notepad versus like Word doc from the engineer's brain is one better than the other for like the non-engineers that are listening? Yeah, in this AI world, everything is for the most part markdown files, which if anyone's seen the file extension, it's .md. There's text files that have, they use something called markdown notation. Most people might not be familiar with what that is, but like you've probably experienced it where you use like a pound sign to indicate a headline and like two pounds to do like a sub headline. All it is, it's a text file where you're able to add rich text through like using pound signs and asterisks for bold and stuff like that. Frankly, that part doesn't matter this much. You could actually use a normal text file. You could even use a Word document. It honestly doesn't matter. If you're downloading from like a note taker, like even if you're in the note taker, it probably would say, do you want to download it as a text file or a markdown file, like, or a PDF? Like at this point, markdown files are sort of the convention that people often use, especially when dealing with AI. In part because it enables an AI to be able to identify a hierarchy of information. Like here's a headline, here's a sub headline. Are you familiar with Obsidian? That will be a lead magnet as well, but like haven't touched it yet. Obsidian is all markdown files. You can't even use text files. And so like we've kind of come into a weird time where markdown files have become like especially like somewhat mainstream. So we could download as markdown file. Yep. And now when we get to the part of the skill, we actually, we're going to run out of time. So maybe we'll wrap. This will be our point. But for the skill part, yeah, like do you want to like just break down like a short, super short tutorial on how you think through building the grabbing ideas, like the enriching ideation part that you talked about as a skill and like what that actually looks like from scratch? What might be helpful is to show what my skill looks like. You know where to take this. Yeah, let me first find it. I'm prompting in the dark here. I'm asking things that I think make sense, but I know you know the better place to take it. Okay, I've got it. So I actually have this meeting processing skill available publicly in a repo that I call phish skills. Hey, we'll get that in the notes. Yeah. I will say one challenge that I found with skills is that skills are very highly sort of unique to you. And so there was a period where I would just try to like share the skills that I was using, but then realizing that some of the nuances of them were very specific to my use cases. I might even decide honestly at some point to like just remove the public repo because the more I've added on and like tailored this to my use cases, the less useful it probably is out of the box to other people. I think the, as a quick caveat for like, I think it's a great moat for, I think that's the new courses because like courses and training, like cause you, if you just download someone's repo to your point, it's like super specific. So it comes with a need to train on the methodology and go through things later at a time. So it actually is, and then teach you how to edit that thing for the person. But yeah, I think that's where courses end up going personally. That makes complete sense. And I think one recommendation I have for anyone is like there's certain skills or harnesses out of the box where I wouldn't even frankly try to recreate them myself. Like superpowers is a great example, but by and large I will often use other people's skills as just a frame of reference to understand how do they build it. And you can even have quad analyze and explain to you how a specific skill works that you downloaded. And then I'll have it use that to help me create my own version or flavor of it that's specific to what I'm trying to accomplish. That's actually an interesting thing about skills is because they're just, for the most part, just plain text files that the AI reads. And so what's kind of neat about that is you can read it and it's pretty normal English. Now we're getting to a place where skills can actually run code. And like, and part of that being that like AIs are probabilistic, not deterministic, which you've probably heard that phrase thrown around where all that means is that when you tell an AI to do something, it's not going to do it the same way every single time. And so what you often find that to be able to get consistent results, you often need to use some combination of I have an AI workflow and then I'm pairing that with that code that I'm having the skill run. Part of me was like, I kind of want to talk about context files, markdown files, like skills, like the interwebs of this, because I think especially for the newbie, it's like, what the total F? Let's do this because I know we're going to run out of time. What do you think is worthwhile? Have it open if you want me to just pull it up quickly. Yeah, let's do a nice show and tell and then we'll make a nice call to action. So if anyone wants to end up on your repo or in your Ecoverse where they could go. So here's my process meeting notes skill. And one thing you'll notice, can you see my screen? Is it big enough? All right, great. So this skill, if you look at the left-hand side of my screen, it's a folder called process meeting notes. It actually has a skill file, which every skill has, a skill.md. And then it actually has a bunch of other folders. Those other folders reference like sub workflows that I have embedded in this one skill. One of which is like creating GitHub issues based off the notes from a meeting transcript, which I won't get into exactly what that does. And this is a good example where, you know, skills will get very specific very quickly to the individual. But like this skill right here, or this file that I've opened is essentially text. And this is what the skill is. So, you know, it's going through and it's explaining, yeah, I won't read all of this out and someone can check this out themselves if they want. I'll give you the link to this specific skill within the repo. But what it's saying is there's access to Fireflies as MTP, which is similar to an API that enables it to access meeting data. The next piece I'm having to do is more around like, when I have a meeting, sometimes it's related to like a business project that might have its own code base. And so part of what this is doing is it's orienting the AI into, are we, if we're going to create to-dos and stuff, are we creating to-dos, making sure that you're creating to-dos in the right code repo? The next piece here, we'll jump down to principle five, is for every meeting I have, it follows the EOS, Entrepreneur Operating System, level 10 format, to create a very specific format for every single one of my meetings, where there's a clear accountability for who's responsible for what, what was agreed upon, and then how it goes about identifying, creating, and assigning checklists or action items. This is awful. No, yeah, this is very cool. Yeah, no, I appreciate, and just for the sake of, because we're going to run out of time, I appreciate you pulling this up. Really insightful. So many, right? And this is why I knew like, just kind of one direction for the call and we're going to end up on a rabbit hole after rabbit hole after rabbit hole. But for everyone that like, has really enjoyed this, stay the whole time. They now want to learn, they want to get into your ecoverse, they want to listen to the pod, they want to read any content that you put out there, or they work at a larger business and they want to hire you to consult. Like where could they find more about you or your companies, your content? So two places. I have my personal site that has like all my consulting offers, which is skinnyandbald.com because I'm kind of skinny, now very bald. I've had that company for about 20 years. And then I also have an AI podcast where people submit, CEOs submit questions to me and then I answer them live with a screen share and that's called Dear Ben. And that's dearben.ai. Very cool. So if you have a burning AI question and you're someone within like executive leadership within some company, feel free to just go to dearben.ai and submit your question. You can sign up for my newsletter there. And then also if you're interested in potentially working together, you can go to skinnyandbald.com. Cool. Well, Ben, dude, thank you so much for coming on and guys, skinnyandbald.com, dearben.ai. You guys are here. Thanks, Ben. Thank you for listening to this episode of How to Scale an Agency. It would mean the world if you could like, subscribe and comment on this podcast so more people can find it organically or share it with a friend. If you're looking to scale your agency and you need help, you're looking for a true partner, go to eightfigureagency.co forward slash call. My business has been built on becoming fiduciaries for other companies. We are going to be your partner where I will bring in my eight figure talent to help you grow working side by side. If you need help with that, go to eightfigureagency.co forward slash call or like, share, subscribe to the pod. Thank you so much. We'll catch you on the next episode.