Latest / The Chief Customer Officer Podcast / EP026: Building Your Company Brain

Transcript

EP026: Building Your Company Brain · The Chief Customer Officer Podcast

• Jeff Breunsbach: All right, welcome back to another episode of Chief Customer Officer.io. it'll be Thursday, July thirtieth. Jay, how's it going? Jay Nathan: Just good just in rally again my home away from home so you know living the dream living the dream. What's going on with you? Jeff Breunsbach: Do I do think it I do think it is a yeah, it's becoming a wait a second home. you know, I'm in the proverbial throes of just parenthood, you know. Jay Nathan: yeah. Jeff Breunsbach: constant chaos, your time is never your own. And so Jay Nathan: Yeah. Jeff Breunsbach: love my children, but I would say we are this is one of those early patches that'll test your your own sanity, your probably your marriage or other relationships. So you Jay Nathan: Yeah. Jeff Breunsbach: know, we're we're making it through though. Jay Nathan: All right. Jeff Breunsbach: Abigail's like six weeks old now. And so she's starting to get some facial reactions, which have done cute, you know, smiling and like little things that she's doing noticing. and then our our two boys are just I like to call them the Chaos Factory right now. Jay Nathan: Mm-hmm. Jeff Breunsbach: My wife cause of I know you had a you had Jack first, but you also had two girls and I'll tell you though, two boys together is we I sent my wife sent me this this little video and it's like a mother who's like recording her two boys who are like the similar ages to our kids and it's just like seven in the morning and it's just like screaming, pillows throwing everywhere. And all the caption says is like, I wonder if girl moms go through this, you know? Like I wonder if girl moms experience Jay Nathan: Thank you. Jeff Breunsbach: this. so that's the the chaos factory we're living in right now. Jay Nathan: I hear you, All right, what are we talking about today? Jeff Breunsbach: let me show you this. I've been working on something that I'm proverbally calling Steve, after Steve Jobs. And it's I think a way for me to you know better use a customer success platform for our team. and so, you know, I'm trying to build a customer success platform in-house and connect it to the right tools. And I think like the I'll the way I'll talk you through this a little bit is I think where I've landed is that I want to keep source data in source systems. And then I want to Jay Nathan: Mm-hmm. Jeff Breunsbach: be there, I want there to be some data that we create ourselves that we can store that essentially like both of those things together create the context for an account Jay Nathan: Mm-hmm. Jeff Breunsbach: that we could essentially leverage. And so I kind of put a a thing to walk through, but like, you know, we already run on a ton of systems. So I've got, you know, HubSpot is our CRM, we Pylon, I've got Google Calendar, Gmail, Fathom. Sequence for billing, we have metabase for our data warehouse, and I have Slack. Like these are probably the eight tools. There's probably a couple more linear, maybe some others that I could like throw in here. But these are like the core eight tools that I would say at any given moment, my team is probably going into a day. Like except for sequence. We don't really log into sequence, but like my team's going to metabase for product data. we're messaging customers in Slack, fathoms in all of our calls. we're we're going to HubSpot for certain things and pylon for tickets. So Basically, what I'm trying to do is build some connectors to these tools, some lightweight connectors. Can I just pull in the source data from these connectors using their APIs? And essentially that creates for me kind of this this initial contacts context layer of like, okay, I'm getting source data from source systems about key accounts that we have. and that's kind of the the first layer. and then this there's this like Steve native layer that I'm trying to build. And so Think about things that I want our CSMs to put on top of that, like any notes that they have, any sort of tags that they want to, health signals that we want to create. we're actually I've created I've actually created a lightweight like project management tool inside of this so that we can have like project plans and and whatnot. But again, like I don't I don't need that to go back and live into HubSpot or other systems. Like I just need that to be something that we can pull on. Jay Nathan: Right. Jeff Breunsbach: And so let me stop let me I guess stop there. Like is this the initial way to think about it? this idea of like I'm calling it composed, but like I wanna pull source data from source systems and then I wanna be able to I guess to capture a layer on top that I'm calling Steve native. I don't know if you have any initial thoughts about that, but that's I that's Jay Nathan: Yeah. Jeff Breunsbach: the way I've I've tried to think about this data so far. Jay Nathan: So yeah, just sort of play it back. I think we're seeing a lot of this right in the AI show and tell sessions that we've been holding in the community with CS leaders. A lot of folks are doing this. they're basically building, what you're doing is building a custom app on top of existing tools that is pulling data via APIs into one, the proverbial like 365 view, because the CRM isn't doing it for us. We know that. So, and then what you're saying is there's some data that you want to store inside of that application that's actually native to what you're trying to do here. I guess my question would be, you know, we've done this as well. Like I run my pipeline calls or my pipeline in general this way. I don't actually Jeff Breunsbach: Yes. Jay Nathan: ever hardly log into HubSpot, right? But what I do is I always, when I write data, I always write it back to HubSpot instead of trying to store data in that. So we have a data warehouse and we have the source systems, but I'm always writing back to a source system. So is there any reason why you wouldn't just write some of this back to HubSpot because notes, tags, insights, you know, some of the things that you have in the, in the, second layer that you're talking about, Jeff Breunsbach: Sure. Jay Nathan: don't those belong in the CRM anyway? Jeff Breunsbach: It could. I'm not opposed to it. I guess like to me, I'm not sold. I guess that stuffing more s putting more things custom built into HubSpot would be like the answer. And I say custom built because I just would have to I I think I'd have to go build custom fields and probably like enhance the architecture of HubSpot for for a lot of these things. And so I think of that as like sure it could go live in that source system, but I guess like at the end of the day, is that going to limit me? in terms of how I think about it, how fast I can move and what are the things I can do. And I think like the short answer could be like no, because you like you're able to essentially use their API probably to develop a lot of these things. But I guess I I don't want to be beholden to for the things that I think we need to be creating, I guess like I don't want to be beholden to a data s an architecture or a system where I have to go create custom fields and everything. Like I'd rather be able to I guess harness that in my own database is the way that I've thought about it. But I think it's a good point that you bring up. But I guess like the the larger Jay Nathan: When you back away from the computer, the audio goes away, by the way. Jeff Breunsbach: Sorry. the so yeah, I'll I I think that's a good it's a good question to to think through in more detail though. You know, is the is the Steve native stuff really st you know, does it really need its own database and architecture that is outside of a source system? I think it's more so like I guess like speed for me that I've thought about it. Jay Nathan: Yeah. And there's nothing to say you can't put it back in there later, but I mean, ultimately you do want a system of record. Now I think the, the bigger question is, especially with the CRM, like every day, every month I look at my HubSpot bill and I'm like, why am I paying so much for HubSpot? now we get a lot of value out of it still, right? It is our central CRM. And by the way, Salesforce is the same way. If you're using Salesforce central system of record, you know, integrated for marketing, integrating marketing campaigns run out of. at for us at least. but like there are less expensive ways to do it. I guarantee you that. So Jeff Breunsbach: Yeah. Jay Nathan: you, know, at some point you may not want to be tightly coupled with HubSpot would be the argument against what I just said. But then like my, my challenge with a customer success platform is always that there's data living somewhere else. It's not the CRM. Why? Right. So you're sort of recreating the same issue. just in a new database somewhere else that you now have to 100 % maintain, right? There's no, you know, there's no fidelity necessarily around what you're building more so than what HubSpot already offers for, you know, as part of their platform. You can build out those components using HubSpot's configuration CLI, like directly in Cloud Code, just like you could with your own custom database. You just don't have to You actually have a UI on top of it. There's some benefits is all I'm saying. I think there's maybe a couple of layers to here that I would just sort of maybe put on your radar to think about. you can think about the HubSpot versus custom database layer that's independent of this. But then the other thing that we're finding is that All of the clients that we're working with the first thing we're building is a context layer. And it's not an application layer, it's a data layer. So for example, we will talk about call transcripts more this morning. And we've talked about that ad nauseam about what we've built for our own call transcripts. But what we've started to build, I think we talked about this last time. It's been two weeks since we chatted, but we talked about ontology. We talked about sort of like the knowledge graph of the. of the company, the company brain, right? So in our world, we deal with customers, we deal with contacts at those customers, we deal with contracts, billing records, invoices, products, features, capabilities, best practices. Those are the main entities that are sort of like the big chunky things inside of our, that our company deals with. Partners is a good example. We have records of those things in the CRM. We have records of them in the billing system. Sometimes they match, sometimes they don't, right? That's the perennial challenge we have. We have the product itself. Sometimes the data in the product matches what's in those other systems. Sometimes it doesn't. what you also have in addition to all those hard records that you can find, there's a lot of missing context there. There's a context of what's going on with every single account that you have right now, right? Product usage, conversations, sentiment. you know, it's all, it's all the goo Jeff Breunsbach: Engagement. Jay Nathan: engagement. It's all the goo that's happening in between to let us know what the status of any one of those entities that we interact with is in business. So what we're doing is building a company brain, which has that ontology laid out. We have a record for every account, every customer, every company that we interact with, whether it was the prospector or a customer client. And then we have. You know, we have call recording, we have Slack messages, we have emails that sort of tell us, okay, here's what's going on with that account at any given point in time. So we have an agent that's running constantly now to build that layer. We know what the entities are. We're always adding to like the history of what those entities are. So all the calls that we've ever had, the key summary of what is going on with that account today, it's all logged in an account record. For us, we started with a markdown file, right? But that could just as easily be your HubSpot record for that account, right? I still prefer a markdown file or a database record because of what you said, right? It's a little easier to work with right now. And a lot of this is unstructured data. So my point is there's a substrate layer underneath that. And then when you start talking about agents, like you're talking about a structured application, that then there are agents that that that you're to want to call to act on that data layer. To do things on your behalf to run a renewal program to do pre, call and post meeting follow up for a CSM to you know capture best practices out of the call transcripts that you're having with customers, right? We do that. So I think there's multiple layers here and then there's a workflow engine somewhere in there too. That's like OK, we're going to run along. There's a 120 day renewal process we run. That's got to be able to keep up with a customer account and a contract that is going to renew over the course of multiple communication interactions over the course of multiple weeks or months as it leads up to that renewal date. So there's multiple layers here, I think, that you have to account for in the long run. If you really want to build something useful, you could build, you already have built something that brings together a view across all these systems. But that only gets you so far, right? Then you need to start taking action once you have the insight. Jeff Breunsbach: Yeah. Jay Nathan: Anyway, so I don't know, unstructured, unfiltered thoughts there, but. Jeff Breunsbach: No, no, no, I think it's helpful. 'cause I think like the like maybe if I was to summarize that, like what you're telling me is that like I'm pulling in all this data from these systems that gives me a snapshot in time, but I still need to go I still would still need to go ascertain across all those systems all that data, right, about like how this customer is doing. and like the the layers of that customer. and I think what you're saying is that like what you need to be doing is that like customer ABC has, you know. effectively a a database entry or a markdown file that is pulling from those systems in real time and updating its knowledge about that in the context about that customer. And so like Jay Nathan: Yep. Yep. Jeff Breunsbach: that living, breathing thing then becomes if if you couple that, let's just say customer ABC with who I am as a company, as junction, coupled with our procedures or our policies or our playbooks, like those three things together. I got context about my business, I've got context about the customer business, I have context about my playbook. And then there's probably other things I'm thinking not thinking about, other days data and systems that it probably needs to interact with. Like, but I think like like you're saying, like all of these things become the context with which an agent could actually go operate on its own to e execute the thing. I think sure there there, you know, you could I think people right now, or at least I feel like, and you can correct me if you've heard this or seen it, but I I feel like the stuff that I'm seeing on LinkedIn and Twitter or X. about agents running right now aren't really agents. Like it feels like a lot of people are calling like almost like automated processes agents, but it doesn't, it doesn't feel like it, it feels like we're still, I guess like I I feel like we've had automated processes forever. it feels like when you have an agent, like the whole idea of the agent is that it can go work autonomously with context and then also like be able to act I guess on on certain things versus like automated processes. So anyways, I so yeah, I think I'm following you though, that essentially like at the end of the day, like context needs to be built and stored in a way that you can effectively inject it into agents and or like other processes that you want to run. Jay Nathan: Yeah, I think you make a good point. Like none of what we're talking about here is really all that new in the grand scheme of things. The one like you, we've talked about this before, right? You need that you have, there are deterministic, like repeatable workflows that need to happen in every business. And that's not necessarily an agent. That's a actual workflow. or something that needs each step needs to happen. You don't need to call an LLM to do that. But then the advantage we have today is that there are certain steps within those workflows like, hey, there's an email exchange with the client we expect to have. We can triage that response and prepare a reaction to that email without getting a human involved or maybe even reply automatically to it without getting a human involved. Whereas before it would have just been. another record sitting somewhere that some of you had to go in and manually work with. So we have the agent layer, but you still have to have the end-to-end workflow layer set up for these key long running processes. Jeff Breunsbach: Yeah, I was actually just talking to my team about this. We were talking about renewals. And I think this is like you were mentioning this earlier. But if I was to look at renewals, right? Like we have a deterministic process about renewals. 120 days I want to do this, 90 days I want to do this. You know, there's there's those steps. But if I'm talking about building a proposal and I want an agent to build us a proposal, to me, that is a kind of inject the AI into a step. And like you said, like I think we're talking about, right? Like in order for the agent to construct the right proposal. It would need to know the context about, okay, who is this customer? What is all the details that we currently know about them? what's our business? and then what's our renewal playbook, right? Like what are the things that we're hoping to achieve with renewals? and then it's it's taking that into context to build the proposal. And like, you know, at the end of the day, I could tell my team to just go build a proposal that says, hey, take what they're currently paying and increase it by 10%, right? That's like a I think a strategy that people have done before. Hey, it's a five percent increase a year over year. But what if I was much better what what if I was much more able to go to that customer with a proposal that was thoughtful about them, about their business, their growth, their patterns, their trajectories, right? Like that's what I think what we're talking about, where you could inject a quote unquote agent that does that, that's not again deterministic. That's like it's taking all those things and to build the best proposal it could for that customer based on the context it has. Jay Nathan: Yeah, I mean, think about it. There's all kinds of exceptions that happen during that process based on the help of the customer, the history of the account, know, all types of exceptions to the rule there. Even if you have, you know, think about you may want to actually provide options for renewal. You can renew for one year at this rate and, you know, two years at this rate or three years at another rate, right? So you get sort of like the multi-year discount kind of play you and I've built that before at a prior company. but the, thing is like, I think it's helpful to think of this, not as like a one-off optimization for each renewal, but almost like a process wide optimization. So do we know the health of the accounts, which group of those should we do manually versus do automatically? So you would sort of want to assess the current health of the account. by looking at the most recent call transcripts, what was the sentiment of those accounts, the conversations, the nature of the support cases that they've had. Support cases aren't necessarily bad, right? As you and I know, they're a sign of engagement. They're using the product, that's good. So all that kind of stuff can be taken into account and say, okay, this group, this chunk of upcoming renewals need to be touched manually. These absolutely don't. And we're gonna go try to do all of that autonomously, right? Jeff Breunsbach: Yeah. Jay Nathan: And then yes, we can be a little bit more personalized in each particular outreach as we as we do it as well Jeff Breunsbach: Yeah. That's fair. okay, cool. That's no, I think it's helpful con I think like your I think maybe the overarching thought for me is as I go continue to build something like this is the data. I think like I haven't thought enough about the maybe the long term vision, right? Like I think I could go build this system and probably deploy it soon to get my team what they need, maybe to operate. But I think to get to get to true I guess maybe to get the full value of AI and agents and like where them I guess where this is going in the long term. I think like the point that you're making is okay, Jeff, like you need to think about more of okay, how does more of this become context that is able to be called upon? And I think like that's the layer that to me is missing right now. Like i essentially like maybe like I've I've been able to go build a tool that can be useful for my team in the short term, but in order for us to really build automations and engine agents on top of that, like that's where This context layer needs to be thought out more thoughtfully. Jay Nathan: Yeah. I mean, what you're doing right now, I think is a logical first place that most teams are starting, right? Is there saying, look, it's easier for me to almost, you know, it create, create, use it, use a, use AI to create a static application that pulls together multiple data sets that are known, right? Cause I can build that fast. Jeff Breunsbach: Yeah. Jay Nathan: Code is the commodity, right? I don't have to wait on an engineer to build it. I don't wait, need to wait on a vendor to build it. There are still benefits to working with vendors. Don't get me wrong, but maybe not for this use case, as you know how I feel about this, right? So then the next step is, what do we actually, how do we want to change how we operate and what we do as a business now that we have these tools? And that's where you can start to think about, okay, what are the processes that we can automate now? And it might not be the existing processes. You might say, hey, now that we have all this data layer, We have agents available to us. What could we do that's completely different that we've never done before in terms of how we engage these customers? Like maybe you keep doing everything else the same, right? I mean, it's so it's just we got to think differently about this stuff when it comes to, you know, just want to use don't want to implement what you have today necessarily, right? Jeff Breunsbach: Yeah. the reason why I'm like s smiling right now too is like we have a head of data and AI on our team who's like got her PhD in I don't even know, some sort of data architecture or something and like in my mind I'm like I have not talked to her enough about this. Like she, you know, constantly is like trying she she right now is trying to pull all this data into like central repositories, like from all teams and making sure that we've got like a data strategy. And so like this is probably the thing I need to go talk to her about around is like the okay, how do we turn all this data into context that we can then access? so it's a good good reminder. Jay Nathan: Yeah, totally. And remember the other thing I was thinking about when you were talking to is LLMs as smart as they are, like Opus 5.0, Fable 5, Chad GBT 6.0, whatever. They're still dumb. They're still dumb. And the reason that they're dumb is they're educated on everything, right? So it's very easy for them to get confused and make up realities that don't exist because they have so much knowledge. So. Our job as we build agentic applications is to provide exactly the context that they need and no more. Right. And then even further down the road, like we will. I mean, the whole, the whole talk over the past couple of weeks has been open source models, which we can dig into what that means. but the whole, at some point down the road, we will all build custom models, right? We will either post train models with our specific data. We're sort of. We're not really post-training models, we're feeding it context to make it more efficient, the more efficient and accurate, but the better way to do this in the long run is to actually have your own privately trained model that knows your business context inside and out. And it only responds that way. Right. So it's going to be interesting to see where that that's the far end of the spectrum today for most companies, even like the best companies that we talk to aren't doing their own models yet. But I think that's where it's going to go. Jeff Breunsbach: Is that like do you think that's where I'm I'm naming like Google or Amazon, but like is that where you think that those companies are like I guess these like Fortune 500 companies that probably can invest and spend, like that's where their teams are probably already thinking or already on the edge of? Jay Nathan: Yeah, they're building the infrastructure for it right now. That's why they're investing billions in CapEx, hundreds of billions in CapEx and these because it's inference on models you own. Not everybody is going to use. Opus and Sonnet Claude's models or chat, Gbt's models, those are the frontier labs, but they're going to be there already are dozens and dozens and dozens of other options for models. You can host them yourself. You can post train them. You can fine tune them like that. That is going to happen. Right. And the big labs will still have plenty of business. I don't know if it'll justify the money that they're saying they're worth today and that they're raising and that they're spinning on CapEx, but the hyperscalers will have, we'll do a lot of hosting of these, these models in the long run for us. Confident in that. Jeff Breunsbach: Interesting. Yeah. well, where do you wanna go? Do you wanna talk about the open source models or you wanna talk through your the the call transcript stuff that we Jay Nathan: Yeah, we'll do the call transcript stuff. We can hit the open source stuff later. I mean, it's just it's an interesting topic because it's it's so in the news right now. There's a lot of conflating of multiple issues together on it. You hear talk of like Chinese models and open source. It's all being like conflated is one thing. If you're not careful, Anthropic just came out with a from with a letter from from their CEO, Dario. On did you see this on like sort of Setting the story straight on what their position is on open source models. Like I think the net of it is there's a lot of talk about banning open source AI, which would be horrible for not just for the tech industry, but also for the economy at this point, because so much is sitting on AI in terms of our economy right now, at least in US actually globally, probably true as well. All the growth in our economy is coming from AI right now. So anyway, we just leave it at that right now. If you hear that, go read about it. If you're listening to this and you don't know what I'm talking about, like we want to advocate for open source here. Open source has been the foundation of technology for the last 30 years in a lot of ways. And we need to make sure that that continues to be the case. Call your Senator. Jeff Breunsbach: Yeah. Well, the yeah, so the call transcript stuff, you know, I I think you've talked about it a lot and maybe I'm just starting to dabble, and so I'm kind of looking at you as my like sensei around like, hey, you know, what should I be thinking about here and doing? But I guess like where I've started to you know, I was I was on paternity leave for thirty days, I come back and I guess like where my mind has been is like I have not advanced my team's capabilities through technology enough, right? Like I Again, like we do a lot of manual stuff. I still have to tell our product team about, you know, certain feature requests and things that I just feel like at this point, not saying that they can be fully automated, but like I should be able to bubble up those insights for my team in order and then like have them press a button that says, sure, pr share this with the product team, right? Versus like them having to fill out stuff. so it's like a a very crude example, but and so I started thinking about it more. Jay Nathan: I think it's a great use case, by the way. It's simple, it's Jeff Breunsbach: Yeah. Jay Nathan: internal. Jeff Breunsbach: Yeah. And so so it got me thinking, like I know you've talked a lot about how you I think you were early on this train of like, okay, call transcripts are gold. We record most of all our calls with prospects and with customers and with partners, right? So I've got all this effectively you're building all this knowledge and context that's already text based that you could be doing something with. and so I'm kind of at that stage of like, okay, where would I start and like how would I think about doing this? But I guess to me it kind of feeds into earlier what we were talking about, where like there's a lot of of knowledge and context in these transcripts. It feels like I could be feeding that knowledge and transcript to almost the the data layer, the context that I'm trying to build. and so yeah, it's I guess like that's where I'm that's where I'm at. But I'm curious, like where have you guys taken this now? it feels like you are heavily investing in kind of building out a rag database of your calls and being able to essentially like store them. efficiently, make sure you can call on them where you need to, make sure you can push information in the right ways. So Jay Nathan: Yeah. So, for those who haven't heard this before, we, built all, we call it our call intelligence system. And it's actually now expanded to be our like company brain, but the call intelligence system. So, you know, rewind six, eight months ago when we started working on this, the car recording platform that we use, and I think you used to fathom is it didn't have an MCP server. Okay. And MCP is just a simple way for, for an agent like Claude to or an agent harness like Claude to interact with, you know, the APIs of a system like Fathom. So we record every call on Fathom, like day in, day out, dozens and dozens and dozens of calls, right? And to your point, BridgeCon, everything, Yep. Jeff Breunsbach: Do you even do it sorry, question. Do you do internal calls too? Do you guys retur record internal calls? Cool. Jay Nathan: And I'll tell you sort of how we categorize those in a second. So before they had an MCP server, They had just released their APIs and we're like, great. Now we finally have access to this data. So we started extracting calls every 10 minutes and loading them into a Postgres database in the cloud. You can do this in any database. doesn't have to be Postgres. And so basically we started creating a repository on top of that repository. So we did a couple of things. So we pulled out the raw data and then we also pulled out some key information on every call. who the participants were, who the call was with, if it was an external party, the duration of the call, the summary of the call, we went ahead and pulled that, the AI summary, because it started being generated, we're using those tokens in the Fathom platform, might as well get some value out of that, right? The full raw transcript sits in there, and some other characteristics, like the date of the call, the time of call, the duration, all that kind of stuff. then we put that into a structured table. Just the table, right? In the database. And then what we did on top of it was we used a very lightweight model called Haiku. It's an anthropic model. It's very cheap to use. And we created a call classifier. You could call it an agent. really not even an agent. It's just a skill, essentially, that runs in the process of loading these calls and basically gives us a sensitivity rating on that call. Is it something that should be? open and available to the whole team. We want as much of our data to be available to everybody as possible. Or is it something that's sensitive and should be closed or restricted? So that's the very simple classification we have today. Recently, we also layered in a sentiment classification, which is interesting. It's very cool. So we now with every call, we sort of give it a sensitivity, not a sensitive, I'm sorry, a sentiment rating. So positive, neutral, negative. Very simple. And we have a whole rubric and a whole skill realm now. So then what we did, so we had that database in the cloud. We built an MCP server that sits on top of it. And that was very simple to do. But the MCP server allows us to connect it to Claude. If you use ShadGPT, you could do the same thing. If you use Grok, you do the same thing, Gemini, same thing. So that MCP layer. calls into the APIs that we expose that expose that call data that we organized and structured the way we wanted to. So now with that layer, we have the MCP server. We can talk to that data from Claude and we can do it very efficiently, right? So it's not like pulling one call out of the time. It's actually got, we actually designed that MCP server to be efficient, right? To give us the tools is what they're called. to be able to go call in and grab a bunch of data at once, grab one call at a time, whatever the prompt calls for. So what I would suggest to you, first get that substrate layer in place. And I told you, we're to give you that. Connect it to Claude and then go use cowork to build an agent. The agent that is, okay, of all these calls, I want to start extracting product feedback items. And then you're going to start building that agent. You're going to coach that prompt, tune that prompt to give you that right, the right set of things out of those calls in the right categories. That's how I would start. I would use Claude as a prototyping tool. Does that make sense? Jeff Breunsbach: yes, it does so far. and I'm following you and I think Jay Nathan: By the way, you don't have to build that database to do the prototyping, right? You can just go pull the last 200 calls, put them in a folder structure, connect cowork to it, and just start running the prompts, right? Jeff Breunsbach: Well, so this is what I was gonna mention is I've I've somewhat done that already. The only thing that it's or like the only thing is I've not stored it. So what I I have in cowork today that runs is there's two scheduled processes that run from cowork at about nine a.m. every morning. And it goes through our calls from yesterday. And I've just like you said, I've trained it on product feedback and I've trained it on I called it like positive customer feedback, where like A customer saying, Hey, junction's awesome. Hey, I heard about you from another customer. Hey, what you know, just like unprompted feedback from customers. So I have these two scheduled things, and all it does is just it's connected to my my Fathom MCP. but again, to your point, like it it doesn't all it does right now is just call that directly from Fathom. and so there's not like this kind of data store. I haven't like layered on, I think some of the other pieces that you talked about, but but you can already see I I think like the the reason I'm chuckling is like you're talking about the MVP version of this, and like I think that Like what I've built is our little MVP. And you can even see how people are like, this is cool. Like our product team was like, where did you get this from? And I'm like, I just summarized this from calls that happened yesterday. And then, like, there's a little customer quotes channel now that is like pinging every day with like quotes from customers, and people are kind of like liking them. And it's just it's become like a positive motivator for the team. Like, especially in our sales cycle, it's pretty interesting. There's a bunch of customers or prospects who like, Hey, I heard about you from X, or I've heard about this person say they love Junction. And it's like, what a cool, again, like positive way. But again, I think like th those are two simple use cases. I just stood up in cowork using the MCP. and like you said, I've I've trained it a little bit, but there's not I I don't even think I have like an MD file or anything that's just running on a schedule, or maybe it created one automatically. I haven't even looked. But but yeah, anyways, that's that's what I've done so far. Jay Nathan: Yeah, that's perfect. mean, I think, this is, is, you know, Claude is really good for that. My gripe with Claude is it doesn't give me a way to build enterprise agents, agents that will survive if we disable your Claude account, right? Now Jeff Breunsbach: Yeah. Jay Nathan: there are ways to do that in the Anthropic Claude platform, but that's not what we're talking about right now. And by the way, I think, you know, there are thousand agent builders out there. Every model. company has an agent builder, go to platform.claw.com, you'll find the ability to create enterprise agents, but then you're locked into the anthropic ecosystem, right? You will not be able to choose an open source model in that agent builder, right? For example, if you wanted to run that, you couldn't do that, at least to my knowledge today. So, but yes, but it's a fantastic MVP prototyping tool, right? Because you can get stuff done very quickly. In fact, When I was building the first version of our company brain, I used cowork to go build our ontology, go build the first set of markdown files that, that make sure that they were producing the prompts that I was writing were actually producing the kind of output that I wanted for every customer account. For example, the history, the summaries, the, links to other resources that are attached to that record. So yes, you should absolutely use do what you've done is like the perfect first step. Now you got to make it enterprise grade and something that actually is repeatable and runs and doesn't depend on you as a human to babysit it, nurture it, all that kind of stuff. It's actually a enterprise system next. Jeff Breunsbach: Yeah. Well also it requires my computer to be on to run because of co work. so like my I think my team figured that out pretty quickly when I was gone for thirty days, all of a sudden they like, Where did these these messages stop, you know, sending? where'd that happen? You know, what happened to that? So Jay Nathan: Yeah. With cloud, to be fair, I mean, I think you can use a cloud server or a cloud. They let you put those, those tasks in the cloud now and run Jeff Breunsbach: Got it. Okay. Jay Nathan: there. But you still, you still want this to be on, you know, some kind of like company infrastructure that runs reliably and is part of the the fabric of the organization. Jeff Breunsbach: Yeah. I think another thing that just maybe clicked for me too that you just said is like I could be going to do the same thing you mentioned with cowork, because it's connected to a bunch of my tools already. Like I could go I could be going to build this context layer that you mentioned about each of our customers. Like I could be going to pull specific examples, like, hey, let's go build five customer files. Like you said, like almost these markdown files of customers. And then Jay Nathan: you Jeff Breunsbach: like, can I use that to as like the beginnings of like, okay, how would I go start to shape what this data looks like? And even trying to like even just understand what is it what does it understand today about our customers, right? Like in the tools that I'm already connected to, can it just pull this stuff in and and give me like context in the way? so I think it's another good like early MVP use case. Like I've maybe like something that I've recognized that I do is I I tend to jump to like version two. I'm like, okay, let me just go build this whole thing versus like the you know, I I don't come from a product background by nature, and so I think like my I'm like, let me go build, you know, version two that is like fully s spec'd and has all these features versus like, Hey, I have cowork, I have all access to all this stuff right now. Like the V P version is like the great place to start and iterate from. Jay Nathan: Yeah. Yeah. I mean, get the, the, get the smallest valuable unit up first and running and then you keep building around it. But I think that the problem that I'm seeing folks run into is that they're, just doing all of this in Claude and it's just not an enterprise. It's not an enterprise grade platform. So Jeff Breunsbach: Yeah. Well, and we mentioned this word earlier. I'm curious, just maybe for the last couple of minutes. Like you kind of mentioned the word harness earlier, and I've been researching a little bit more to understand the flexibility. I guess flexibility is what people need to start thinking about for of like all of these models are pushing the frontier, all of these models are coming out with different their different versions of what good is and what it's good at and like the context that it's bringing. And so Like I've recognized myself that I do a bunch of stuff in Claude and like I wonder if like I should actually have a harness that allows me to to flip between models. Like should I be looking at at Codecs, right? Like we have a we I have open AI, I have a license to open AI, like should I be I guess like being able to to go to both. so I've been been hearing a lot about that. But I guess how d how have you thought about that problem? Jay Nathan: So Claude is a harness. Claude Jeff Breunsbach: Okay. Jay Nathan: is a harness that gets you access to Anthropix models, right? Chat GPT is a harness that gets you access to GPT 5.5, 6.0, which is their models. So you have to think of these tools as a layer above the. the actual intelligence layer. And they're trying to layer in things like in Claude, you've got cowork, you've got, now you've got Claude design, right? There's a Claude application for life sciences research, right? That's the harness above the model. You have cowork, which is a harness. So, Jeff Breunsbach: Yeah, yeah. Jay Nathan: like they are building a layer above their raw models. to get us hooked into using their raw models. Cause that's how they're charging us is for tokens, right? And they're trying to give you all the tools that you need to be able to use their tokens, right? So in their models, all the models are great. Like the Frontier Lab model is fantastic. The open source models are catching up very quickly. Distillation, this and that. You can, we can talk about that some other time, but they're catching up very quickly. So. But what we need is an enterprise harness for agents and an enterprise harness makes an agent work across your team, not just for an individual. It gives you company wide, give you access to company wide context, not just what you feed into it. Claude is really good at saying, hey, attach files, like tell me what you want and I'm going to give you a better answer. But then you have to feed it context every time, right? And so what we're talking about Jeff Breunsbach: Yeah. Jay Nathan: is building a enterprise layer, enterprise wide. layer of context, feeding that into a enterprise layer that allows me to deploy agents across teams and across individuals. And then to basically share the knowledge that comes in. Do you know how many times this like people, even in your organization, you don't have a huge org yet, right? Think about like we work with, with companies that have hundreds of CSMs and hundreds of people in finance, right? Do you know how many times the same crap gets put through an LLM? over and over and over, like burning tokens from the same question over and over and over that doesn't need to be answered again by just a different person on a different account. That's what we're talking about, right? Like taking the best of what everybody's doing with AI and codifying it in one place. It doesn't mean everybody doesn't get access to cloud still, but like, for God's sake, share something across the organization that you can get that out of. Jeff Breunsbach: Yeah. I love that point because I actually have thought about that a lot. we have, you know, Claude Coer hooked up to like our notion in our Slack. And I kind of think about like that's that's helpful. but I'm like, I wonder how many questions are being asked. Like a CSM asking, okay, has this question been answered before? That's a a common use case that our team uses right now. It's like, Hey, can you go search in Slack? I need to figure out if like what are the the what are the laws and regulations around New York, New Jersey and Rhode Island for lab testing. That's a common question we have and we have to go like answer. And like again, like think about how many times A, we've answered it and B like you know, we need to be creating like almost like artifacts after that that allow us to answer that more qu more quickly or like with you know yes, like hey we've already we've already answered this and here's the answer. Right. Like here's we don't need to go searching for it. Jay Nathan: Yep. Yep. Don't go search the call transcript again for it. Right. You w so this actually gets, so in your business, you need a company brain that's constantly harvesting all of the knowledge that is being shared on calls that in public databases that tells you what those regulations are. And that's basically storing in a knowledge base or the brain, those regulations, right? for each state, for each municipality, however far down it goes, right? You're actually building that recursively in a loop all the time. And then at some point, you know, as you're building knowledge base like that, you want somebody to check it, right? Just make a hundred percent sure that it's true, but one person needs to do that, right? And validate all the data and they don't need to do the primary research. They just need to do the validation. And that's the human in the loop kind of process. Jeff Breunsbach: I guess this also makes me think about I guess maybe like the first use case that anybody thinks about is like the support use case of like I type in a question and then it it kind of goes and finds the answer, right? Like a and or it suggests an article, right? Like a hey, here's an article that could answer your question. And like to me it's like that version, but at a a broader sense of like, we should be able to answer these things based on this context. And again, if we're capturing the context and the knowledge correctly, like we should be able to answer these questions. and if If there's not currently an answer, then we should we should be able to capture what the answer is so that in the future if the question's asked again, like anyways, it feeds itself. this is cool. Okay. I I I don't know if people enjoy these. We can we can let the, you know, listeners decide, but I think when you're I think like when you're describing this stuff to me as a since I'm a a newbie, like I think these are like the best episodes. Like learning about harnesses, learning about enterprise great agents. I think talking through you like your whole idea around like data and context layer, I think this has been super enlightening for me. and I think this is when we get some of the best episodes because I feel like this is like tactical, practical stuff that people need to be thinking about on the front lines. Jay Nathan: Yeah. It helps me too because I'm trying to it. Some of this stuff is somewhat technical and I'm not saying I'm the most technical person, but I'm trying to find simpler ways to explain this stuff too, because we're this is where we're like my company. We are. We do software implementations in different types, right? Pendo being one, but we are. We are an agent deployment company now, like every every consulting. software consulting firm has to become an agent deployment company. That's what FDEs do. And so we need simpler ways to explain this stuff because if you're an executive at these companies, you're expecting business results and outcomes from all this work, just AI. AI for AI sake was six months ago. Those days are gone. Jeff Breunsbach: Yeah. Jay Nathan: It's ROI now, as we always knew it would be. anyway, yeah, it's helpful. Jeff Breunsbach: awesome. Well, we'll get this episode out. appreciate the time and we'll talk to you next week. Jay Nathan: Yep, sounds good. Jeff Breunsbach: All right, later.