E74: Your Agent Isn't Broken. Its Foundation Is. | Jonathan Moss, EVP Growth & Partnerships @ Experity

AI is not something that you add into an existing process because then all you're typically doing is you're just adding one extra step or one extra layer, but you're not really solving the business outcome or the root problem.

That's Jonathan Moss, with 20 years experience building go-to-market systems at Verizon, T-Mobile, and OYO. Now he runs growth at Experity, which is HIPAA-regulated health tech, and he's been a key figure in building the AI infrastructure that enables the entire company.

The workflow now is powered not by an individual, it's powered by all the systems and infrastructure.

In today's episode, we dig into what it took to build it, but we cover a lot more ground as well. The 6 layers under every agent he runs, the hard lessons he's learned about going AI first, and the near miss that almost locked the company's AI brain inside a vendor's product.

If you're not thinking about the system that you're building, you're not going to be able to scale it.

Most AI efforts in go-to-market teams turn into a soup of disconnected tools. Jonathan shares what the alternative looks like. Welcome to the Revenue Leadership Podcast.

Today's guest is Jonathan Moss, who is the EVP of Growth and Partnerships at Experity, and he spent 20 years building GTM systems at Verizon, T-Mobile, Oil Reef Booster, and then joined Experity in 2024 to run growth and rev ops. He's also the co-dean of the AI in GTM School at Pavilion and leads the revenue operation practice for the Growth Institute. That's part of Winning by Design. And he shares his learnings in the GTM AI podcast and on Substack, which are both great reads, highly recommend. And so we're going to talk about all things AI and how J Moss has built it. We're going to talk about some like specific workflows, unpack the problem, the redesign, lessons learned. And also get into org charting architecture and really understand how to build an org from the bottoms up that is AI native, whether you are transforming a legacy org or building something from scratch. So really excited for this one and appreciate you joining. I want to dive right in. And, you know, you've said that, which is a common observation, I think, that a lot of companies are Their AI strategy or their GTM AI transformation is like a bunch of disconnected pilots. It's like random trials and tests and stuff just like thrown into a soup that then when you zoom out has like little to no ROI. And everybody was quoting that like McKinsey survey or whatever it was, like 90% of implementations have no ROI. I don't know if it's that extreme now, But it's directionally very accurate. And so I would love to understand like how you've seen, maybe start with like the problem and how companies are getting it wrong. And then the approach that you guys have taken it, because Experity is not a, like a little startup that's built AI from scratch. Like you've gone through this transformation and done it with a lot of success. So maybe talk problem and then approach, and then we'll unpack a ton of stuff from there.

Yeah, and I think I'll start at the system level and then get into how to implement. So I think a lot of times what happens is people start with the tool or they start with some AI use case instead of the business outcome. But even when they start with the business outcome, a lot of times you can ultimately build around a workflow or something like that. And I'll talk about, that's definitely the place to start, but you have to think about this as a system. And I don't think many people think about it as a system. They think about it as like, I'm accomplishing this one thing. And so the way we've kind of thought about it, or I've kind of thought about it and broke it down, is there's multiple layers to the system. So the first one is you've got to have the data. So data in the data lake, quantitative and qualitative. So you've got to have that to be able to power this whole thing. And then we've built what we call the brain, which is basically this kind of semantic layer of Uh, policies, IP, our own IP, all of our decisions, things like that. So you gotta have this, this layer that understands who your company is and how it operates. Then you have your intelligence layer. And when I think about that, it's like the models. So simply it's the models, Claude, OpenAI, et cetera. You've gotta be able to then orchestrate this across multiple teams, multiple workflows, multiple agents. So how do you do that? Then you have your agents that are actually your teams that they are specialized. And then you have the interface, which is where you work. Is it Teams? Is Is it Slack? Is it Salesforce? Is it, you know, conversational UI that you created? So I think the first thing is if you're not thinking about the system that you're building, you're not going to be able to scale it. You may be able to accomplish a small business outcome on a workflow, which is definitely the place you start, and I'll talk a little bit about that. But ultimately the broader piece of this is you have to have the system underneath or otherwise it won't scale beyond Maybe a few workflows as a team, et cetera. So I think that's the important first thing that we, and I actually made this mistake when I first started. I started at the agent and interface. And every time I started working to build the system, I kept running into things. Why does it not have contacts? Why can't it work across multiple systems, you know, multiple tools? Why can't it do this? And it just led me to build all the way down to the bottom, which is a lesson learned for me. I should actually started at the bottom with the data and then the system started building up. And so I think that's thing one.

Can I pause you there?

Yeah, yeah, for sure.

So fundamentally, I very much agree. And, you know, I've talked a lot about building this, this like company meta harness. And so you and I see the world very similarly, but like I was just talking to a guy who runs AI transformation for a big public company today. And so there's like 50 cooks in the kitchen, all this stuff happening. And so I think sometimes for those organizations, Actually starting with the system and trying to fix fundamentals doesn't work because there's too many people that are squabbling over who owns it, what's allowed, what's the approach versus you and I, I think came into this the same way. It's like, hey, let's just get a couple interesting use cases up and running, build some value, demonstrate and build momentum. And then you have enough credibility to say, Okay, I can't do the next thing without the infrastructure being there. So I actually think, and, and, and, you know, because you and I were both early, that was the only way to do it. Nobody understood the systems engineering of AI enough back then to do it properly. But I actually don't mind people, you got to fix the data first, but maybe we don't need to fix all of the orchestration, all of the— the agentic coordination before you like spin up a couple good use cases that maybe don't touch 6 different systems, but produce real value. How do you respond to that? Especially for the people listening who are like in larger companies and maybe like need to build some momentum.

Yeah, yeah, for sure. And super valid point. And thanks for that because ultimately the next phase I was going to go is to the workflow because I agree with you, but I think What I would say is you should work these in parallel. They're not sequential because to exactly to your point, the system is going to be a long pole in the tent, but you have to have that thinking and understanding of this is what my like long-term goal is from a strategy perspective. And I need to start engaging in the conversations and trying to figure out where things are gonna break now as I'm building out these like individual workflows, which is where you do also start. So I think it's a parallel path. It's not a sequential one. And I think the problem is, is a lot of people maybe even think that it's a sequential one. So they start with the workflows, but they don't think about the system, or they don't think about the system at all. And then to your point, we're like, back early, we didn't think about it because it was, all this was new. But now I think you've got to think about this as you start building out your kind of getting momentum, getting your use cases and workflows down.

I think that's the right framing. Okay. So we're talking about system and use cases in parallel. And one of the things that I think is also useful about trying to build some of those workflows is it tells you where the system's broken. And I think what you're advocating is really smart is like, as you build workflow, think about system. Because oftentimes the workflow or the agent doesn't work because it doesn't have the right context or it can't reconcile identity across systems or doesn't have access. So. Um, that makes a lot of sense. So then, so completely agree. The layers you mentioned were data, brain, intelligence, orchestration, agents, interface, and agents is workflow. Is that where you would put like, like the workflow building?

Yeah, I would have, yeah, I'd have agents and then the orchestration if you needed multi-agents and in the, in the work, uh, the workflow piece.

Absolutely.

Um, and then so As you think about systematically, ultimately you want to run in parallel some things that you can get measurable ROI on, that you can implement, that are actually solving problems. And you mentioned it kind of when you took it away, which is start with like the, I call it the business outcome or the business constraint, not specifically what is the AI use case, because AI is just an element of the solution and the workflow. You don't need to start and say, hey, what would I need AI AI-ify things, right? And so you gotta, what is the business outcome that you're trying to achieve and how impactful is that? Then what you have to really do is map the underlying workflow. So think about your handoffs, your exceptions, the data that's required, all the different things that go into the workflow. Baseline what happens today. Where does context drop? Where do meetings, you know, you and I were chatting earlier before we started recording about meetings. Where all do I have to have meetings because that's where information's locked or context is locked or whatever, you know, decisions have to be made. So think about all of the time, quality, cost, outcomes, et cetera, that are part of this workflow. And then you have to think about redesigning the work. So I think this is important. AI is not something that you add into an existing process because then all you're typically doing is you're just adding one extra step or one extra layer, but you're not really solving the business outcome or the root problem. It may make it better and it may seem to make it better, but ultimately AI is really designed for you to kind of redesign the entire work. So what do I remove? What do I automate? What do I augment? Things of that nature is kind of how you think. And then once you deploy it, make sure that you've got good change management around workflow adoption. Make sure you have good measurements around what is it that you're tracking and how is this workflow working? And then have a learning loop where you can make those corrections. You know, it's almost like deploying a product in a way, right? You're deploying this kind of These are products from the same workflow, right? Yeah. And you need this dynamic feedback from the user and you need to make the tweaks and the enhancements to the workflow until you get it right. And then you can start scaling and deploying it. And so I think that's kind of how I, how we think about how to, how to deploy AI and think about these kind of measurable ROI workflows.

I think you've used the language like RevOps is transforming into revenue product, which, which is essentially what we're doing. You're, you're finding, you're looking at user behavior, you're understanding jobs to be done and requirements, building a PRD, redesigning a thing, and then testing and iterating. Like, you know, build your MVP, put it into the market, get user feedback, iterate and loop. And we're all there now. We're all product thinkers. Yeah, we have, you have to be.

And that, and honestly, we should have been doing this a long time ago because if you really think about RevOps and you really think about, you know, we've all had this, you know, a go-to-market tech stack. Well, that's really a product, you know, because a lot of, sometimes products, when you build a product, you're using third-party integrations because you don't, you know, build everything. So it's really, you are managing a product, um, and we have to think about it that way. And I also think that our organizational structure and, and, you know, we don't have to pivot there yet if you don't want to, but our organizational structure has to think about changing because we've created silos in go-to-market. You have marketing, you have sales, you have, you know, customer success, et cetera. And RevOps kind of did the same thing. They said, okay, well, if you've got these functional orgs, then I'm gonna have marketing ops, I'm gonna have sales ops, I'm gonna have customer success ops. And so, and so if you, you don't think about, you know, when you think about a product, you're thinking about what is the workflow I'm building? What is the capability and outcome I'm building towards? And it's not specialty. Like you don't have someone that, you know, only builds this portion of the product and this portion of the product, this portion of the product in a full like workflow as you're thinking about it. And so I think about, Um, I think about, you're exactly right. We have to start thinking about go-to-market and the system becoming more product-oriented, product-led, et cetera. You're in back-to-back meetings all day.

You're trying to stay present, but you're also worried you'll forget the decision, the action item, the important next step. And that's where Granola comes in. Granola is an AI-powered notepad for meetings. You jot down rough notes like you always do, and in the background, Granola transcribes and turns them into clear, useful notes when the meeting ends. No bots joining your calls, no distractions, just a clean notepad that helps you focus. Use code THEREVENUE for 3 months of Granola for free. So you can head on over to granola.ai/therevenue to learn more. Again, that is THEREVENUE for 3 months of Granola for free. Check it out at granola.ai/therevenue.

This episode of the Revenue Leadership Podcast is brought to you by Chris at Work. Your revenue team runs on 25 or more disconnected applications, sourcing in one, scoring in another, sequencing in a third. Cris@Work makes that a single AI-native platform, system of record, system of work, and system of intelligence as one. And at roughly one-third of what your stack costs today. Book your demo now at crisatwork.ai/pavilion to get 15x qualified pipeline. That's kris@work.ai/pavilion to learn more. kris@work.ai/pavilion to learn more.

All right. I'm going to bookmark the org structure thing because that, that is a really great topic. So, um, I want to zoom back to mapping the underlying workflow. And I think one of the interesting challenges here is like, how do you make it machine readable? If you actually want AI to play a meaningful part, then the things that happen by humans need to be machine readable and adaptable. And so maybe like if you can give a practical example of something that you've had to rebuild that's had a really good impact at Experity, like how have you had to do that workflow mapping and what were the technical foundations you had to build to then be able to redesign things?

Yeah, so I would say, I'll use this kind of GTM Intelligence Center, 'cause I think it's one that most everyone, it's not specific to a function. So typically, how do you get your dashboards? How do you get your data? How do you make decisions, get insights, et cetera? In normal, you would ask maybe RevOps. If you don't have your own dashboard or information that gets it to you, then they would have to prioritize it. They would then pull the data. They would visualize it for you, build you a dashboard. They may even analyze it and try to answer your question, right? So this is a very linear flow that's very people heavy and requires, you know, people expertise, et cetera. But ultimately, they're also not the domain experts, right? So they're not sales, they're not marketing, they're not customer success. And so instead of, you know, that being the workflow, intake, prioritization, build, deploy, et cetera, instead what we did was we said, okay, what are the, like, how should this workflow work? What's the outcome? The outcome that we're looking for is that anyone in the organization can understand where we're at, the trends, get insights, understand their component of their business and what's important to flag. This shouldn't be a RevOps in the middle of this. So instead, the outcome should be that the work is actually decentralized, federated down to the lowest common denominator of the user. So what does that mean? What do we have to do? So number one is we had to get all of our data In the right place. So we had to have it, you know, we had to pull it together and ensure that it was in our data warehouse. We had to ensure that we had, it had the right context because as you know, not every field, you know, if you could enter a field in your CRM, but if there's no business context behind that, then, you know, AI or whoever will make that judgment call, right? And it's going to be wrong. So you've got to have that context.

And that's the semantic layer work that you were talking about. Explain to the model how the data or field relates back to the business so that when the user asks the question, it can understand the connection between those things.

100%.

Yep.

And then we had to put the intelligence on it. So the LLMs, et cetera, on top of the semantic layer. And then we had to give the user a way to interact with it, right? So they could ask a question, it could build their charts, it could do whatever. And so what's interesting is really testing this, you know, we're able to build like 3-year trends of visual, get insights recommendations in less than 30 minutes, which is super impactful for anyone to be able to do. And so when I think about the workflow that changed was the workflow now is powered not by an individual, it's powered by all the systems and infrastructure. And the one thing that from a change perspective that we have to think about, I think is important is When you talk about the data, and you mentioned it earlier, you know, around ensuring having your data in order, you know, we use data all day, every day. So I don't know a go-to-market person, an individual that doesn't use data, and they know the nuances. So I think in this process, the paradigm had to shift, which is I'm teaching the system. If the system gives me a bad output and I know that it's a bad output, I'm actually teaching it that it is a bad output and what is the actual You know, what is that output should look like, or what is the context that's missing? And then that goes back into the brain, therefore it doesn't make that mistake again. And that was a paradigm shift we had to go through because most people were like, oh, this output's bad, so I'm just gonna take the information, I'm gonna go somewhere else, and I'm gonna do the way that I've been doing it. Yeah. You know what I'm saying? And it's like, no, no, no, I need you to teach the system that it's bad, why it's bad, so that way it doesn't do it again. And you don't have to take the output, but that was like a paradigm shift that had to happen in order from the operators or the users that was part of this like process change too. It's like, hey, you get the information, you don't need us, but we need you to teach the system if you find these like red flags or things that are issues in the output that you're getting.

What did you build this on?

So number one is we have Snowflake as our kind of data layer. The brain is basically a bunch of our code, internal context, things like that. It's all mainly stored in GitHub as a repo, but it runs and runtime. So, and our runtime is ran on AWS. And so we have what's called Agent Core. It has capabilities for orchestration and observability, et cetera. And then the user interfaces, we have a chat user interface that we built that's just kind of like a simple UX/UI that's plugged in, or you can use it in Teams or other places that you work today. So that's kind of the structure in a very simple term.

You built the brain. The harness that pulls all the data, calls the right model, and does the intelligence work.

Yeah.

And I think that's an actual important point. You built it. I think that's the one, this whole build-buy thing has transitioned a lot. And I think the harness that you're mentioning here, you have to build this. You should not give that to anyone else because all of that is your secret. It's how your business logic works, how your processes work. It's your company contacts and information. It's IP. It's all those things. And one of the the decisions that was almost about to be made was we were about to put all of this into a third party. And I was like, whoa, whoa, whoa, before we do that, how are you going to port it over to something else? Now you're going to be locked into this third party forever. Number one, that, which is very big time risk, especially with things are moving. But number two is now that third party has all of that information. Why do you want them to have that information? So I think that's important. There are certain things a part of this that you definitely buy, But I think the brain, as I call it, harness those, some of those capabilities, those are all proprietary to you. I think those are the places that you spend time building. Yeah.

If you have the technical capabilities internal to do so, which is definitely not the norm in my experience. And I think you can, I agree with you. Like I've written extensively about like, you should be building your own intelligence. I think that, I think you can build a, you can buy a platform to build your intelligence within it. Like Vasco came up on my last podcast because we were talking about this exact topic. Like how do you create the right harness to give you the right answers? Because so much of the time, if you just MCP your Claude code instance or your Claude desktop instance into a bunch of things and ask it questions, it lies to you. It just, it fills in the gaps, it makes things up. It's trying to give you an answer that you'll say thank you for. Like that's the RL. It's not RL to be totally accurate because the user doesn't know enough to have that right feedback loop. And so like, I think you can use a platform like a Vasco or some of these harnesses, as long as you can see the intelligence within it and you can like still take it out and you're not like locking away your business logic and all of this stuff. forever, but because it is that compounding asset that is the brain of your company.

Yeah, 100%. I think that the portability is the most important factor if you're going to do it. Is it portable and how easy is it to, because you may, to your point, you may outgrow it, you may get too deep in, or you may eventually have the expertise that can build it. So I think that portability is definitely the most important piece.

What was, so I think that's a good example of like, a bunch of these layers. You talked about how you, where you had to put the data and how you had to do it. And the semantic layer, the brain and the workflows and interface. How much data work was there to like data work plus translation layer, like semantic layer that you needed before you could get accurate answers out of this thing?

Yeah. So I think the biggest thing here was we didn't, bite off more than we could chew. So what I meant by, what I mean by that is we started and said, okay, where do we, you know, at the end of the day, we work with the data every day and we know where there are a ton of gaps. So, and so do I, you know, so does everyone across the organization. They have their own, like, hey, here's, I have gaps here, so I have to do this, et cetera. So the key for us was start with high impactful workflows where we knew what data we had. And that it was good enough, or we knew what the gaps were so we could actually, again, fill in those gaps with that context and that information in the brain. And so that's kind of where we started. And going back to the point I was making about the user then providing the inputs, that was the key to make the data better. So it was like every time we use, so it's almost like today when you use a CRM, a lot of times, every time someone uses a CRM, the data gets worse. But in this scenario, what we wanted and the way way we thought about it was as they use it and correct it, I need the data to get better. So as I'm using the system, the data is getting better. And that was kind of the way that we went about approaching it. And so we approached it on high-impact workflows that we knew we had data and/or we knew what the context was missing that we needed to fill in. And then over time, our data got better and better because we had 2 components. We had a user component that was making it better. And then we still were working on the data as an ongoing thing. Like, hey, let's make sure that we fix this. Let's make sure we map these relationships, these tables are correct, and we're building that semantic layer, et cetera. So it was kind of like a two-pronged approach, if you will. And that's kind of how we continue to iterate over time for it to get better and better and better.

And so that structural work was done with your data team? Did you bring in an outside vendor?

It was done with our data team and with the help, honestly, of our vendor partner that we use for our data warehouse. So they have a lot of resources that helped us out with understanding more about how to do it, why to do it, how to approach it, et cetera. But we did have some expertise internally as well. But we obviously, and I think that's important, if you've got a data lake or you got a third-party vendor that you use, you know, leverage them for their expertise and help too.

And so that was the Snowflake team or that was like a Snowflake team?

Yeah, Snowflake team.

Yeah. Oh, shout out Snowflake. That's high quality customer support.

It was, it was 100% high quality customer support.

So yeah, that's half the battle now with some of these programs is like, can you get the right FDE from this partner to actually like stitch it all together?

Yeah.

Yeah.

So one of the questions I get asked a lot is like, how do I get people to agree to do this work? How do I get the data team to spend the time on go-to-market data? Because oftentimes they're getting pulled into product stuff or there's a lot of mouths to feed if you're a data team like that. They're the hottest of commodities today. And so did you have to do much to convince folks that this was a high priority area? Because it seems like you got this done earlier than many. Any approach, any like advice to people trying to build organizational momentum around this topic?

So I'll tell you what I tried and failed that may work other places, and then I'll tell you what we did. How about that?

Yeah, that's great.

What we tried and failed was exactly what you just said, which was we tried to make it, help them make it a priority. And the way we tried to do it was, look, at the end of the day, the revenue organization is driving the growth, right? If you think about the revenue that feeds all of us and keeps this business alive, we've got expansion, you've got retention, and you've got acquisition. So without those 3 things, which all fall on the revenue team and go-to-market, you know, without those 3 things, we don't have a data team, we don't have a product, we don't have anything, right? So we should think about how to prioritize the needs because ultimately what this does is it allows us to make the right coordinated turns. It lets us make the right initiatives to get past the green if we're behind. It allows us to understand the green shoots for us to then double down there because we have a channel working or a motion working or something like that for us to continue to drive and grow the revenue. So if we need an ROI, this is the easiest ROI to get. So that was the pitch. I thought it was convincing. You can tell me that it's not, but I thought it was convincing and it was like, this, this makes complete sense in my brain. Why, why do you not see that? So we got a little bit of momentum by doing that, but it wasn't enough to, you know, slow and seder. So what did we do? We convinced and decided to actually allocate some of our budgeted headcount to the data team. And that's actually what ended up solving it, was saying, looking at the org, looking how important this is and saying, okay, in our planning, in our budget, we're actually gonna allocate, you know, 2, 3 FTEs of the overall revenue organization to this because it's so important. And, and we understand, you know, just like I pitched to you again, uh, you know, you can gimme feedback on the Shark Tank if you invest or not, but ultimately, uh, that was kind of what, what actually happened in the solution was we gave budgeted headcount.

So, for them to hire net new.

Yes. For them to hire net new people that were specifically focused on our domain and, and that we used specifically for that and nothing else. And, and sure, they could have flex labor, but that was ultimately the, the solution. It wasn't the great pitch that I thought we had.

So. Not uncommon. And actually, this is something I've done myself, being like, hey, like, I will give up headcount if you allocate it to this team and it's dedicated. Like, when we raised our Series C, the first role that I put into the new headcount plan was an applied AI leader for sales. And ultimately, we put that headcount in the data and biz ops team, but that was like, I was like, this is what I'm carving out above anything else because it's so important. And the right place for it to live in the org chart ended up being somewhere else, which is fine. Like, I just needed the work to get done. And I've seen this in other places. So I think that's probably a pattern that is replicable. As funny as that is.

I wish I had a better answer, but that's what happened.

I think it's a great answer because it's actually useful because I see, I've had conversations recently on this topic. It's like, oh yeah, like we want to do this, but the data team like is telling me it's 6 weeks and it won't get picked up for another whatever. And it's like our brains don't compute that. Because our brains are like, but this is the money. Like, this is where the money comes from that powers everything else that we want to do as a business. But if you're just not, if you don't live as close to revenue and GTM, sometimes like all those other things feel just as important because you're just another stakeholder. Like, yeah, you're the money stakeholder, but to them, you know, like, why are you any more important than the VP of product or the CFO or the whatever, they're all important people in the business. And so I think your approach is reasonably, is a reasonable takeaway. Oh yes.

If it was much easier, man, we'd all be doing it, I guess, huh?

Yeah, exactly. So I want to talk orchestration because I think this is a topic that I've started to talk and write about a lot more, this sort of like Meta harness, company brain. I use the word company brain in a different way than you, but this is a, like, especially for companies that are more successful with their AI initiatives are now all feeling the sprawl. It's like, oh geez, like actually RevOps was building stuff and growth marketing and some of the sales leaders built their own things and then the data team and then there's a central applied AI organization. And so now you have this sprawl of agents and some people might be like hosting it on their own, you know, Vercel account, just like with their company credit card in it. And some people are building something that is like more, you know, well-structured. You've got like Ramp that wrote that whole thing about Glass and like Cursor has a cool platform for it. But I think the common experience is for the sprawl to happen and then for it to not really talk to one another. But then they, some of these agents are all actually trying to talk to the same places in an uncoordinated fashion and like tripping over one another and sometimes sending like a customer, like multiples of, of duplicative emails. And so how have you solved this orchestration problem? And like, what, what was the strategy? What were the tools to get this all to work harmoniously?

It's valuable when it's connected into what you're, you know, you're talking about the harness and the brain because you actually can get better outputs and better outcomes. And that's actually what the user wants, whether you're in sales, marketing, whatever. All what you're trying to do is solve, get to an outcome and a job to be done. And so having that connection piece is, is, is super powerful.

The second thing is, so you didn't have like different teams just building like randomly on their own?

If we did, it wasn't enough to like know that it was happening or impact because the other side of their own Claude instance and like maybe a couple skills.

Yeah. Yeah. Yeah.

Maybe. Yeah.

Yeah.

Because the other side of this was that we made a decision to give everyone, I think this is also where constraints happen, give everyone access to AI capabilities and tools that were connected. And so I think a lot of times some people, at least the ones I talked to or such, and we did this at the beginning, we only had a set group or a set number of people that had it. And what we learned was, A, it pissed a bunch of people off. B, um, you know, this kind of, oh, well, hey, I used, I used, you kept hearing other tools being used and you're like, what are you using that for? And so we kind of went through this a little bit, um, at the very beginning. And so we knew that it had to be, you know, number one, we had to give access to people. So I think number one is access. Number two, it has to be connected. So we have all the tools that we give people that connected to the right places. And what's cool about, um, this agent core with AWS is that, um, you know, regardless of where you're at, you can build these agents pretty easily. 'Cause I mean, as you know, you're in it, the agent is the easiest thing to build of all this.

Yeah.

Um, and if you know how to build one, it's like the easiest piece to be. So you can spin up a ton of agents, um, and really good if you got the right framework, if they can be connected to the tools and, and context, et cetera. And so we started building these agents and then we started showcasing what was being built. So we ran these, Like weekly, and we still have these weekly, like, show us what you did with AI this week, or these kind of open shows where people will come and they'll showcase what they did, how they did it, et cetera. And so we had this kind of centralized building of agents, and then we started to work these bottom up to your, to your point, bottoms up. Hey, instead of like going to some other tool, just build an agent here and here's how easy it can be, but it's gonna be connected, et cetera. So I think That approach really kind of helped us not have a bunch of this sprawl. And I'm sure we had some of this, to your point, at the very beginning when people didn't have access, because we were forcing them to go do something because they wanted to use AI, they wanted to do it, but they didn't have the ability to. And so I think that all has, to my knowledge, maybe they're still in these pockets, who knows, but ultimately now it's well more connected. It's, you know, decentralized building and centralized building, and it's all connected internally too. So it makes, it makes life for everyone a lot easier and they get the best output.

And so is Agent Core like a user experience that I can go into and like it walks me through how to build an agent, or are they, are they like accessing Agent Core through their own Claude code instance? Like how?

Yeah, you, you, you can access it through your own Claude, your own Codex, your own, your own instance. So the in— The interface is, is multichannel, if you will. It's like headless. But the back, yeah, it's headless, but the backend is all connected to kind of AWS and Agentcore, which was really helpful for us, obviously, for obvious reasons. Um, you know, is to have that kind of next level where the agents live, how they orchestrate, all connected, um, with multiple interfaces.

Okay. That's cool.

And I would imagine, 'cause you guys are regulated industry, like your experience is— Very regulated. Yeah.

Okay.

We're in health tech. So yeah, HIPAA, you know, PHI, all this stuff.

So.

And so it's at the agent core level where you would put in all of the governance and permissions and tell people like what they can and can't access. And like you're able to manage all that at the, at the, with this one surface.

That's right. That's right. Yeah. Yeah. With this one, with, yes, with one surface, not to be interchanged with the interface that people use, but the surface layer under it, to your point, is where we can manage all of this stuff. And I think what you just said actually is probably for the audience too, probably one of the reasons why we didn't have a lot of sprawl is because people, you know, because we're regulated, because we're in healthcare, people understand that, you know, doing this is like eliminating your job basically. So that probably had some things to do with why it wasn't just going crazy too. So there's probably a little bit, you know, unique variables to our situation too.

Especially because you guys are regulated, the progress you've made with AI is even more impressive. Like that, I see so many companies. I spoke in an event a couple days ago, Winning by Design thing, and somebody piped up and was like, well, what about regulated? And you can't do this, you can't do that. And I'm pretty honest with these things. I'm like, I don't know. I sold restaurants. We are very much not doing what you're doing. And And I've heard this feedback previously, like, oh, well, you can't do that because it's, we're in finance, we're in finance tech. And, but you can, it just takes a different level of, I think, coordination that you guys have done. Yeah.

And I would say 2 things to that. So one is the great thing about go-to-market is that you're not really using any data in this sense, unless it's coming from like a customer success call where someone brings it up because it's regulated. So like, So the, the end go-to-market, the likelihood of you using data that's non-HIPAA compliant or PHI or stuff is, is super small. But to your point, the problem is in this industry, people think about everything as regulated and they put it all in the same bucket. So that was the, that was the part it took us time to unravel a little bit was the thinking around it. And then AWS again, um, is, you know, allows us to like have these controls and these walled gardens to make sure that we stay with inside of compli— the So that has been really, that infrastructure level has been super critical for us to be able to do it and feel confident to do it.

So this is the harness concept because your harness is basically this, whatever you've built in Agent Core that says, you know, these users can access this data. It's like, 'cause you know, it's all in Snowflake, but you're saying, okay, these users get access to these tables that are non-sensitive. HIPAA PHI data and they can do these things. And do you, in that experience, is there like agent management where you've given them the ability to like build or run evals, or you can like monitor what agents are doing what, so you can like help improve them over time? Like what else is in the harness of that?

Yes. So it has governance, to your point, and it has the ability to kind of see and measure outputs, has the evals where it's natively built in. It has that kind of its own capability to do evals. We've got the permissions. So exactly to your point, what permissions should the individual have? That's the user. So it allows us to do all of these things, which again, If we didn't have, we wouldn't be able to do everything that I'm mentioning. And I will still say we still have a lot of work to do. So while it sounds great, I mean, we still have access controls that we have to go through IT. We still run into a lot of the things that enterprise scale companies would do that we're, you know, so I wish we had everything that my personal system has. We do not. So I'm not here to also say it's like sunshine and rainbows because there are issues. But ultimately I do feel like we have made really good progress, you know, in where we're at. And I think that AWS and Agent Core has been a really big internal seller for us to be able to do more because of all the options that they offer.

So. Yeah, yeah, that makes sense. And I think these are good takeaways for folks. Like if I framed it up, you know, once you get to a maturity level where you've got some stuff happening here and there and you've got, you know, like a bunch of successful agents and workflows and you've built some things into your GTM stack. And you're starting to, this is like the next layer of sophistication, I would say. And so if we go back, like I gave the SaaStr talk, I think I sent you the deck beforehand for feedback actually. And so, you know, level 1 is like people just using chat as a replacement for Google searching. And then you've got like level 2 is sort of, yeah, you've got some successful agents. You're now running some good AI workflows and level 3 is AI as infrastructure. And this is AI as infrastructure. This is now you're building things that then people can build within so that it can be more productive than if they were just like vibe coding it themselves, because you don't need to do all the MCPs and integration work yourself. You don't have to like make your governance basically just like you building a monster skill file. This I think is very much like the level 3 sophistication of like, you've now built the infrastructure that people can build on and go faster and be more successful and ultimately gives you the platform to get to level 4, which is that like recursive self-improving loop where if everything is in one set of infrastructure, now you can have agents watching the agents and building agents and improving other agents. And, you know, maybe not in regulated, you have the agents just like doing their own thing recursively, but You have an inspection agent, like you and I were texting about GrokBot and it's like I have a setup GrokBot that also monitors all of the other bots that I've built that can then look for opportunities for improvement. And so you're starting, like I only did that just because it's cool and interesting and I'm trying to learn some of these things on my own and we'll talk about personal AI, in a bit. But I think like we're, the best companies are getting here like sort of now where there's like glimmers of the recursive. Have you guys experimented with any of that? Like agents watching things yet?

No, not fully. We have, we've been trying to kind of think about how can it watch, you know, different code. It's more prevalent in our engineering than anywhere. I'll say that. Yeah. But not outside of that. So there's some things going on there and like to your point on on, you know, Grokbot, you know, trying to get— I have one to kind of go in and like poke at all the things I've built, all the apps and things, and like poke around in there to see if it would gimme any feedback or if things were messed up. So I think that's kind of the next step of how do we take this to go to market. But we have not done that yet on the level 4, as you're mentioning. And one thing I'll just say for the audience is, you know, you're also, and you probably know this, but I think disclaimer, you're talking to 2 folks that have been like on the bleeding edge and speed of this. So I will say internally, we have people still at all of those levels. We still have people that use AI that think it's a better search mechanism than anything else. And then we have people that are utilizing infrastructure and building agents in it. We have a large spectrum across the thing. So, so don't think like, oh shit, I'm behind, or, or, oh my gosh, just like, no, you know, this is a journey. And I think just people are on different, different phases of that journey.

Let's talk about org chart and org structure. So there's sort of 2 flavors of this that I want to unpack. One is how have you built it and who's doing the work and how have you coordinated with these other functions to understand what projects to take on and where does this mandate live? And I think it's also worth tying into this topic, Your opinion that the revenue leader of the future might not just come from sales and there's like a different type of person that has to think about system design. And so not only the design of the org, but, and this might not have to be the CRO is this thing, but like these new types of leaders that are the system designers. But let's just start with like org design. So you made the point, you know, RevOps was traditionally built into these silos. You had marketing ops, you had sales ops, you had CS ops, and now that's not as relevant. Maybe just expand on that point. Like why don't you think that this is necessarily the org chart? And then I'd like to zoom out and talk about like, where does AI transformation live? But let's start with the, like, non-function-separated RevOps teams first.

Yeah, for sure. So I think of, we've talked a lot about this GTM being more of a system, right? And this will kind of lead into, and then also we think about running revenue and even RevOps more like a product. Well, if you think about what modern product development is today, is it's done in very small pods, right? So you've got like a team of like 3 or 4 people and there's a lot of, you know, I think McKinsey has something out there. You can go find this, but you can kind of see this like modern software development as these pods where you have like a product manager, you may have a business SME, you have a developer, and really if you need something else like data and stuff like that, you have them as a component of it. They work in these pods. And so I think of it as the same way, and that's how we're transitioning, which is it's less about the function and it's more about the outcome, the workflow, the job to be done. And that could be, and if you think about go-to-market, go-to-market in almost every single workflow, there's very few workflows that just, that do not require more than one function. And so when you think about that, you don't need, you do need some expertise in saying, hey, Like, where would, how does sales fit into this workflow and what do they need from it or journey? Same thing with customer success, but you have that expertise in the organization. And so what way we've thought about it is we've, we thought about how do we build these pods? So we have someone that's like a product manager, someone that's an engineer that can build, someone that's a process-oriented SME, if you will, across go-to-market, which is your traditional ops person, if you will. And how do we have data as part of this?

Yeah.

And their goal is to tackle different things. So you've got like an acquisition pod, you've got an expansion pod, you've got a retention pod, you've got a value realization pod, which is really like what happens between someone committing and someone getting implemented, you know, implemented and adopting and utilizing the software. And so they're focused on, irregardless of the function, like it could, it may need some product, it may need finance, it may need legal, but we, this is what RevOps did already, except we just did it manually and in these like small little functional teams. And so now you've got this pod that's working in cycles. So they're constantly working and trying to ship and trying to build, and they're staying close to the stakeholders because to your point, what's important is what outcome is the stakeholder trying to drive for the business that they have friction or they're not getting the full, you know, You know, realization of, et cetera. And these pods are meant to build out the capabilities for them to be able to accomplish that. And that those stakeholders prioritize, and it's almost just like a roadmap. So you have prioritization, you have a roadmap, you're shipping, whether, and that shipping can be, you know, something you built or it could be just shipping a new process. It could be shipping whatever, but ultimately it's shipping that capability cross-functionally versus relying on these kind of siloed teams and handoffs. Because even RevOps is siloed when you think about it, if you're set up like marketing, sales, and customer success. You're just focused on your own little domain and function. And yeah, you may say, hey, you know, sales ops, I need your help here or there. And then you kind of like pass the buck. No, I want you to own the journey, own the thing you're doing or building from end to end, solve it, ship it, make sure that it's working. And then what's next on the list and let's continue to go. So I think that's how, in my mind, the org starts to shift and change and is changing. And we've kind of seen some good success with it.

And so, uh, in your new role, do you still have the whole RevOps function under your, like, under your scope?

Today? No, that role changed a few months ago, but, uh, but building it out over the last 2 and a half years is kind of what led us to this point.

So, so is that how the team is structured? It's, it's like acquisition pod, value realization pod, retention.

Yeah, it started. Yeah. So it started to transform into that. So obviously there was some talent talent things, there were some things we had to do. So, this has been kind of like an over-a-year evolution into how do we get to this point? So, it's less about functional silos and more about the, as I mentioned, the job to be done, et cetera. So, it's a transition. We're not fully there yet, but that's the goal. And we've got some pods working now today.

Okay, cool. What was the talent transformation? Like, what skills were no longer in demand versus what did you have to go bring in net new? And what do you think are— skills that we should be building these teams around today?

Yeah, so I think number one is a foundational knowledge of revenue architecture, just how that goes. So one of the things that we've taught is how do you think about revenue, recurring businesses, et cetera? So just having kind of that framework and understanding, I think number one is super important. The second thing is we look for more generalists than specialists. So previously we were hiring specialists because you had to know marketing ops, right? Not everyone knows marketing ops. You had to know sales ops. And so in this, it's more, I understand the foundation of go-to-market and I understand operations and how things should work. I may not have 100% domain expertise, but also we have like marketing ops agents that can help or other things that can help with some of these elements. And then we hire people that are really focused on, that are curious and they can basically showcase that they can actually build and do things in AI and not just like—

Interesting.

Yeah, agency. There you go. That's, yeah, the agency. Because ultimately this is not, you know, if you're at level 1, you just talked about the levels. If you're at level 1, you're just using search, probably not the best fit because that's not what we're looking for. So you've got to have kind of the agency and think about systems thinking, et cetera. So those are like more of the qualities that we're looking for today. And you find that some of these qualities people have in RevOps today and some that they don't. And so that's kind of how we, and sometimes we find them that they're, you know, in some other organization, product, or engineering or something, but they may not have the go-to-market expertise, but you can kind of lean into that if you're teaching revenue architecture and other things, you can do that as well. So that's kind of how we think about the talent versus the specialty, more general. And then to your point, the agency and things of that nature.

And then how much specialization do you still need to keep in the team? Like I think about marketing ops being the function that like needs more specialization because you have to figure out Like, you just like pixel stuff, like you, this like nitty-gritty, how does it show up? How does it flow into the data? How do you instrument this like workflow? Like, where do you want like a handful of people who still do have that like technical expertise or what's the balance?

This is a great point. There are still elements of it that you want to have someone that has the— so for example, we use, for better or worse, um, and sorry, I'm going to say this, we use Pardot and Pardot is not the easiest thing to use. So there is some, there's some specialty that you still need to have. But what I, what I will say is we actually started contracting that agency.

Oh.

Um, so, and so, and so if we needed something that was more specialized like that, we would find it either through an agency that we use that we have, you know, RevOps flex labor in, or we found it on things like Upwork or other places. So because what we wanted to hire for was the other capabilities that I mentioned, and if we need specialties, we can contract that for the amount of time that we need it because we also don't need it all the time. We need it in some element, you know, maybe 10 hours a week, maybe we need some weeks we need it 40 hours a week. So that's kind of how we thought about it as part of this Like, let's talk leadership skills.

What does this new RevOps leader need to look like? What does the new like revenue need to look— revenue leader need to look like? Oftentimes I think about, you know, building these org charts, like building a basketball team where like you don't want 5 centers, you don't want 5 point guards, like you need sort of the diversity. So like, do you think everybody now needs to be like super AI-pilled? Like you need a CRO and a VP of sales a head of RevOps, like everybody needs to be super AI-centric systems thinking. Can you get away with like it being more of a partnership and there being more sort of like traditional skill sets? Like how do you think about the leadership skill set today?

So the concept, I feel like the talent that needs to be leading revenue in today's world, either if it's one person, needs to understand P&L. So they need to know how to operate the business top and bottom line. The second thing is I do think they need agency because you can't not do it yourself and learn how to do it, build your own stuff, et cetera. So I think there has to be, you don't have to be, you know, a full-blown systems engineer, but you have to know how the system, you know, how AI works, what you can use it for, and be able to at least build some things yourself.

Yeah.

So I think number 3 is you have to understand revenue from end to end because I do, I do still run across CROs a lot of times and you may, you may as well, but they're like, I'm like, oh cool. So you own the whole revenue? They're like, no, I have sales and marketing. I'm like, that, that, that's not like, that's not in my mind a CRO. A CRO should own the whole end-to-end revenue and the system underneath it if they have that type of capability. So not only knowing how revenue works on both sides, but also how does the system underneath work from end to end? And so I think like that is the talent profile. Now, if you have a CRO, if that's what the CRO looks like in the future, great. That's great. If that's not how we see the CRO evolving, then I honestly think you need someone with more of a growth mind and RevOps mind that sits in the C-suite or that has at least has a seat at a table if it's not a C-level. I mean, you think about, you usually have a CPO and a CTO, right? They have different parts of the product. And so I think about almost this in the same way. If you have a CRO that may be responsible for the outcome and the people, et cetera, you may need someone that's responsible for the system that, but that person cannot be layered down. They need to be at the table when strategy's being decided, when all the things. So I think like in my mind, regardless of title, regardless of where it sits, I think those are the capabilities that someone has to have to be very successful in running kind of revenue at an organization. So that's my view of it. And I think as we get more and more AI agents running a lot of this and doing it, I think it becomes even more critical. So I think we're kind of becoming at that inflection point, if you will, in my mind that this is a transition that we'll have All right, let's talk personal AI stack because I wanted to make sure we could fit this in because you've built some cool stuff.

Maybe just share a little bit about like, what have you built yourself and what does it help you do? And then I'd love to unpack like how you built it and we talk, we got a lot of, this could be a whole 90 minutes, but we'll try to do it in 15.

Yeah, yeah, for sure. So kind of my journey with this was, I started building agents. So I started at the wrong layer, as we kind of mentioned earlier. And so I started building agents and it was cool, but I was like, oh, this is not as great as I thought it would be. I can prompt really well, maybe chat or something like that, and get similar outputs with connectors and things. So I started with thinking that I needed to build all these agents. So I have 121 agents. They don't all get used every day, but I have 121 agents and they're built different hierarchy teams. So I have engineering, I have product, I have sales, I have marketing, I have customer success, RevOps enablement. I have, um, a GTM panel, which by the way, um, you know, not just 'cause I'm on here, but, you know, Kyle Norton is on my GTM panel. So, uh, you know, we should, we, we, we should probably see how accurate it is or not. Uh, I've got a GTM panel. I have a personal board of directors. panel that helps me with things. And so I've kind of built these teams thinking about like, what are some of the things that I need? Um, you know, what, what do I do and what are some things that I need feedback and stuff on or people to help build? So I have these, I have these agents. Um, my interface, I'll go through my stack, my interface.

And when you say I have an agent, just like, is it fair to say like that's Skillfile?

So I look at agents. So that's actually a good question. So I actually have 57 Skillfiles. So I'm looking at my architecture over here so I can give you the exact numbers. So to me, the difference is a skill file is kind of a repeatable process, something that I do on an ongoing basis that I have a desired outcome, et cetera. And it just kind of, it can be used by any of the agents. The agent is more of a an expert at a domain, if you will. So a skill can be a repeatable type of workflow type thing if you want. The agent is more like, I've got a marketing ops agent or I've got a revenue data analyst agent. So, and they could use a skill, like the skill may be, hey, um, here's what I want. You know, when you look at Google Analytics and pull the information, here are all the things that you do, here's how you do it, here's the workflow, et cetera. I don't want that stored in the, in each individual agent, 'cause I may, I may have multiple agents that are working on that, that same, that can use that same skill. So ultimately I see them as different, different things and that's kind of how I view the world.

But the instantiation of the agent is like basically like one chat. Like you said, you use Telegram. So it'd be like one Telegram channel is that agent and that agent knows that it can access multiple skill files and has a job and connections. Would that be how you would define what like that agent is?

Yes. With one difference. Telegram. So if I think about the interface of Telegram, it actually, it uses a one agent to your point that is a smart routing agent. So the smart routing agent is the one that it selects which agents to use based upon what I am asking.

And this is OpenClaw behind it?

No, it's actually just, it's actually all code that I have either written or got from open source. Okay. All right. So this was kind of pre-OpenClaw. I did not ever, as you and I were chatting, this was not, you know, so I never kind of moved to OpenClaw because I actually asked my, you know, it's going to sound, you know, I don't know, we're getting a little sci-fi here. I asked my CTO agent and my systems architect agent to review all of OpenClaw and tell me, should I port everything over and just use it? Or are there certain things that I should actually build into our system? And it actually recommended some cool things.

We do this all the time.

Do you really?

Okay.

All right, cool.

All right.

So you've just made me feel better.

No. Yeah. Like, 'cause so I'm set up on OpenClaw, uh, and, uh, but I'm transitioning a lot of stuff to GroqBot and, and in OpenClaw, like I'll see something cool. Like people are like, oh, Hermes agent, Or, or some of these like other ones or, or like Gary Tan will post a thing about GBrain and I'll like be like, hey, read this GitHub repo. Like, should we add this? And then it'll come back and be like, no, you like, it overlaps with whatever. 'Cause like, yeah, I was trying to figure out like where I was trying to figure out memory. Like how do you figure out memory in OpenCLaw? So is it, do you use GBrain? Do you use like Toby's QMD stuff? Is there other things? Now I'm sure mine is like a bit of a soup because I'll be like putting, I'll be like shooting in ideas and then OpenClaw's like deciding what to build. But so I feel like I'm right there with you.

Yep. So that's exactly what mine is. So, you know, 'cause I had the same issue. So I have a memory, I have a bunch of different components of memory and they're all either A, you know, I took some from OpenClaw. I've had some from other open source things that I've found on like X or other places or just searched Like what's the best memory, et cetera. And then the system just builds it and uses some of this code. So it's kind of like, to your point, it's a soup of things, you know, and that comes with its own challenges. Like I then had to, you know, I realized that the system wasn't working all the time, so I had to set up like a watchdog that can tell me what's broken through the night or et cetera. So, but yeah, so same kind of thing. So it's basically homegrown, if you will, to some degree. But it's a mix of things that I have, um, or things that are open source and just the conversations and things of like, hey, I need to solve this problem. You know, I ran into these things. How would you best solve it given the system that we have built? And, you know, and then it makes some recommendations and then I test those and go from there.

And so you just run off one master channel interface and then the agent selection's happening behind the scenes.

That's right.

And you don't have the— okay, interesting. I've always kept all like different channels just to keep my, like, just to keep me organized. And so like I have a, even like I separated podcast production from podcast outreach because having them, having it go back and forth in the same channel, I found personally confusing because, you know, like I have a bunch of crons set setup that looks at like, all right, 48 hours before, have I created the docket? Have I shared the docket? If I haven't, and now one of the reasons I'm moving everything over to GrokBot is it just does the job so much more cleanly without me— I find my crons just stop firing for some reason in OpenClaw and I have to go in and be like, hey, I'm recording with Jonathan Moss. 18 hours. Like, what's going on? Where's this docket? And the, like, I'm just all day going to bet on Cursor. And I've, so I have a Cursor, I have a Groq bot setup agent and the setup agent is walking me through how to grab everything from my OpenClaw instance. Because a bunch of it is in the skill files, like everything I build is always instructed right back to the GitHub repo with these skill files. So I can use multiple experiences with the same tools and skills, but then there's some stuff like the crons have to be built in the OpenClaw tooling. And so in that virtual machine, but then the virtual computer getting like logging into stuff, GroqBot has just really solved that in a pretty cool way. So I have the Groq setup bot. just like telling me how to port into OpenCLAW. I'll just like scoop it all over and turn it all off.

So 2 things you mentioned, I completely agree. And this is kind of why I started using GraviBot. So one is I probably should have set up multiple threads because you're exactly right. If it's a simple type of thing in Telegram, it's cool. But once I can't do deep stuff there with all these agents, because to your point, it just gets confusing because it's in the same thread. And that, so that was always a challenge. And so typically for I would, I would, you know, use, um, you know, either the app on my, wherever I was at, my phone, iPad, or, or whatever.

Right.

Um, my computer, uh, for those types of things. And it was a restriction that I had, so I just kind of lived with it. But then when Grok had these separate channels, I was like, oh, this is so— this is the first thing that hooked me. And the second thing that hooked me was its ability to do all of these things. Because you're right, I mean, I'm like, I'm like, now I have 52 cron jobs and at least 4 of them broke. break every day almost. And I'm like, what the hell is going on? And so I spend, I spend like my first 15 minutes at, you know, sending it over and saying, fix these. I thought we just fixed these last week. Why are they still not working?

Yeah.

You know, why do they break again? You know, so it's kind of like if, if, if GroqBot can solve that where I don't have to worry about these, you know, cron jobs firing and stuff, then like, dude, I'm all in to move it to, you know, to the, some of the stuff there too. So.

My GroqBot crons have fired correctly every So like not everything has been moved over, but my experience so far has been really good that it's become like more and more my main place to go. And so now I'm spinning up like all the rest of the channels and it's going to be interesting. Like the, I think the thing that GrokBot has done so well is also the the cloud computer interface. So you can click in and write, just enter in the password and hand it back. Because my OpenClaw is built in this virtual machine, you have to VNC, you have to do this thing where it creates a link and then I log into the thing and then I go do a whatever. It's a nightmare. And I haven't wanted to just give it all my passwords. For good reason.

Yeah.

But with what I'm doing with like 1Password is there's a GrokBot vault and then it'll, and so, 'cause like I have an email address for, I call it Kai, K-A-I. It's like my digital chief of staff. Kai has its own email so it can create its own logins and it could have passwords for those logins. And 1Password has like done a pretty good job I'm like thinking through this like agent password management piece. So I feel like it's going to be pretty interesting. And now everybody's talking about Instinct on X, like that's like the new normie, like Open Claude. I was like, oh damn, I'm just moving things over. I can't have more like AI FOMO that there's some cooler thing out there.

Right. I mean, it went from, what was it? Context to Loops to Graph. We got all these things that are, it's moving so fast, man. To your point, it's really hard to keep up with Even those that are in it all the time, it's hard to keep up with. Yeah, I agree with you. I think I'm really loving GrokBot so far and kind of going from there. So we'll see how it goes.

And so then where are your agents doing the work? Have you given them, like, how have you given them access to the right places? Like, you're, again, you're in this like regulated market, so I'm assuming it's not, it doesn't have control over your like work account and it's like writing, or it's like it's not into Snowflake or whatever. Like, what, how is it doing the work? Does it have its own Google Suite ID or like what's the plan? What's the approach?

Yeah, so for on the business side of things, it does have its own permissions and its own ability to log in, or so like its own identity into certain things, um, depending upon your user permissions and the agent permissions. And so that's, that's why, um, you know, having that kind of capability in Agent Core is so critical, because otherwise you wouldn't be able to do a lot of the things because once you start seeing—

Oh, this is all built in Agent Core as well?

No, no, not my personal stuff. So not all this stuff.

Oh, okay. Yeah.

So we, we, since you went back to the Experity, so the Experity is all built in Agent Core. My stuff is all actually just built, I've it in my GitHub. I have my system is called Let's Cook. And so basically it's this system I've got, you know, I've got things like we built a brain. And so that's where I store all of the docs. So I've got like over thousands of docs in the brain. They're just markdown files that are structured that it can be referenced. And also the memory, you were talking about memory earlier. So the cool thing that I really, and I think I use a couple different open sources, a But ultimately I wanted it to constantly improve. Again, as I mentioned, like the system that improves over in the business side, I actually built it first on my personal, like how can you continuously improve through my work that I'm doing? What's the infrastructure that has to happen? How do you do it? And then we added in like LangTrace so I could track decisions. So what decisions were made where and when? And so there's there's like these little components that I never would've thought about until I started using it and we're like, why can't I know what decisions were made 3 weeks ago? Or, or why did I have to repeat myself multiple times? And I think that's something we mentioned earlier in the episode, which was you and I using it, we actually got into, well, this is breaking, or I want this, or why doesn't it work like this? And those questions kind of led to, here's a solution that, you know, someone else has built, or here's a solution that I can go back and forth with the system to build, um, and, and see if it works, you know, and still, still things happen, um, you know, like Cron jobs breaking, but, uh, but ultimately it gets, it gets better every day. Yeah. All of this is just on my own system, on my Mac mini. So I've got my Mac mini and I've got GitHub, and those are usually the, the places that ultimately a lot of this stuff is, is stored.

And the runtime is on the Mac mini?

Yeah, everything, everything runs through, uh, runs through the Mac mini, even if I'm using it on my laptop or my iPad or iPhone.

Okay, cool. What's the best thing, like the most valuable agent that you go back to the most?

Probably my chief of staff. They help me personally. So I have a personal OS. So all the things that are important to me personally, my kids' logins, my kids'— not login, my kids' stuff and schedules, like what's going on, my, you know, things I want to do or accomplish or whatever, travel. So it's got my stuff that can book me travel or it And like, uh, you know, match up my kids', uh, sports schedules with my work schedule and travel schedule and all these things. Um, and then I've got, then it's also have the business side of things where it knows me, knows my, you know, my memories, my domain expertise, et cetera. I had to set all this up, but I go back to it because it can help me either on business or personal. So even when I'm thinking, even when, even though it lives somewhere else, when I'm doing stuff at Experian, I'm like, Okay, I really need to think through how to do this. So I'll ask it and it'll go through all of like my, almost like my second brain. It'll then use the GTM panel. So I get advice from Kyle and others a lot on things GTM related. So I kind of have that going, but I always go back to it because the most, because I can use it for so many horizontal things versus very specific things. Hot tip.

If you use Robinhood for banking, you can spin up virtual cards that are like purpose-built for agents. So you can, 'cause like, I don't really want my agent to have my credit card. I don't know. I'm just not there yet.

You gotta draw the line somewhere, right?

Yeah, we're getting close. But you can create a virtual card for yourself, like in your Robinhood account and give it like a $500 limit or whatever, and there's some other like things built into it, but then just give that, give the card details to your, to your agent. So if you want it to actually go like purchase things, it can.

No shit.

Okay.

I'm gonna have to check this out. I saw, you know, last time I was on my Robinhood, it kept popping up this like, excuse me, this Agentic thing. Like, hey, have your agent, give your agents access. I thought it was just for trading. I didn't realize you could actually get spending money.

Oh, it might be purchases This is in the Robinhood banking app.

Like I have a— Oh, got it. Got it. Got it.

I created a Robinhood bank account because like you could buy like gold at this crazy like return and there's a bunch of stuff that's like pretty compelling in there. And also like as a tech person, I just like wanted to experience the Robinhood product. And yeah, so I was like, I was in there, I was like, oh dang, like, you know, I can, I can like give my agent a card now. And you can either set it up to like, you can, you have to approve every single one of them. I turned off the approvals but turned on the monthly limit.

So what do they, so I'm just curious, Ben, what have they bought for you? Do you like just ask it to buy things? Does it buy things that it thinks you need or want? Like, how can you, can you tell me a little bit how you get it set up?

Yeah, I'll just like say, hey, go buy this for me. Or like, hey, I'm looking for, 'cause like I wanted to buy, I've only done this successfully like with like one thing. I only set this up recently, but I was like, I need new of this, like one particular sock that I've bought a bunch of times. I was like, go rebuy my last thing and it successfully like went through the flow and it has all my like personal details. So, and that was like a light bulb moment. I was like, oh shit, like maybe, 'cause there's always, there's like stuff that I think about and I'm like, oh, I gotta like find it and add it to a cart. And like, I don't know, just like the minor crap. I would love to be able to give it, like Amazon should create Like, you should be able to create like agentic access to your Amazon account where, yeah, it can, you know, not shop through the visual interface, like the graphical interface, but like it should be able to purchase like through like agentic means. So I agree.

And, you know, they try to do this subscribe and save thing, and it's just all manual and it's frustrating because sometimes I don't need it. You know, I don't run out just on the subscription. So I either, either get more than I need sometimes, or I get, or I need it quicker.

Yeah.

And I, you know, there's this like interesting thing to your point where things are going. I do feel it would be amazing if it did, was able to shop because then, and it had access to my calendar and it had where I could Exactly. Voice, 'cause I use voice more than I use typing now and just tell it what I think I'm low on or whatever. And then it just goes and like carts things or buys things. You know, if I'm coming up on a trip, it may recommend some things. Hey, your kids need swimsuits for this trip 'cause you're going to the beach. I would love to have something like that that I don't have to think about much other than just, you know, just telling it to think about it for me. So, or to check in with me, hey, is your toilet paper running low? Do you need some more? Actually, you know what?

Yeah, I do.

Thank you. Can you order that for me?

Yeah. So virtual cards in Robinhood, this is probably the like most secure way I've like thought to do it so far.

Makes sense. And it makes sense that a bank, a financial institution would make you feel more comfortable about that than some tech, you know, some agent tech thing, right? I think that makes a ton of sense. And actually, that's kudos to Robinhood for leaning in there because that may actually be what gets people more safe and secure. It's like, oh, I already have, they already trust them with my money. If I'm trusting an agent that's using them for my money, then I have some protections and the same protections I have because my money sits there anyway. So yeah, makes complete sense.

Yeah. And mine's on a $500 limit. So like if it goes haywire one month, I'm not dying to waste $300 or something, but you know, it's spending limits for everybody. Well, this Awesome, J Moss. Like, we got through a bunch of cool stuff. I learned a ton. I think it's really gonna help people like structuring their thinking about like how to go tackle this whole problem set. And man, you guys are doing some cool stuff. So big kudos. So appreciate you joining. Appreciate it. And yeah, we'll get you back on soon.

It was fun, man. Thank you for having me. Appreciate it.

Leadership Podcast. If you enjoyed it, don't forget to subscribe, and you can find a link in the show notes. And be sure to leave a 5-star review, share it with your network, and please join me next Wednesday for another great conversation.