The CASS Framework: Building Blocks for Scalable AI Agents

Eva Živanović, Notion's first hire outside the founders, explains the CASS framework for building scalable AI agents: Capabilities, Archetypes, Solutions, Systems. She walks through how Slack Q&A bots at Aduro work, why incremental capability upgrades benefit all agents, and how consultants can shift from product builders to client advisors.
Chapters
The people who think that AI is most valuable to them by eliminating jobs just clearly don't understand the leverage to the equation. Welcome to the Notion State of Mind podcast. I'm your co-founder, joined by my co-founder and co-host and now coworker, uh, Iva Zivanović. Did I say your name right?
Absolutely not.
Close enough.
Zivanović.
Zivanović.
Is that how it is?
Sure. Let's go with that.
Can you, for the sake of the listeners, can you say your name?
It's Eva Živanović. Actually, no, I Americanized my name for you guys. That's horrible. It's Eva Živanović.
That sounded the same, but we'll take it. Eva Živanović. Sorry to any Slovenians, uh, if I butchered your language, but I'm trying. Today we're joined by Ava, super excited to have you on the call. And we're going to talk about your strong opinion on some frameworks on Notion and consulting that you have. But before that, just want to introduce you and talk about you because you are, I don't know, Notion state, Notion stater number one.
Yeah, you're the first team member to join the team outside of Josh and I. I was trying to look for a cooler name than NotionStater.
We'll work on that. Um, but yeah, you were the first one on the team, kind of have seen us grow up through the years and have seen the team evolve, the market evolve, the product evolve. Um, so yeah, I would love, uh, to give you a minute to kind of introduce yourself and how you found out about us and why you've decided to stick around for so long.
Yeah, so I joined NotionState about 2 and a half years ago. A little bit over 2.5 years ago, it's gonna be 3 years in November. Josh and I came together as typical Notioners come together through geeking out over Notion. So at the time, Notion was releasing Notion Formulas 2.0, and I really wanted to dive into the product a little bit more. I wanted to understand a little bit more about what the changes are and how they apply to building formulas and how that applies to the products that we're building. At the time, I was still consulting as a solo. Consultants and I was building some builds on my own. And I'm the type of person that really likes to dive into the work to learn more about the functionality. And so I did a Twitter campaign where for 30 days I posted a new formula every day and Josh found me. He DM'd me at the time and so we started geeking out over Notion. And then he told me that he was looking for someone that could potentially join the team that could help with some of the consulting work. And at the time I didn't really understand what consulting was really, uh, to me it was more about notion building. And so I had a conversation with Josh, I had a conversation with Bryan, and to me what really stood out was just the way that you guys thought about not just the product but the way that you think about the world, the team. So it's really more about the culture. That's really what drew me in the most, and I just got a really good vibe from you guys at the very beginning. And I felt that this is very much aligned with what I want to do in and how I want to develop my career. And I felt our values were very much aligned. And so I decided to, yeah, join Notion State. And it's a really interesting experience because we started very differently to where we are today. So we started with smaller projects and I think our perspective changed a lot over the past 2 to 3 years and how we think about Notion and how we think about consulting in the Notion space. And so it's been really interesting to see how that developed, um, over the span of a few years and how I developed in that, uh, space as well, along with the team that we've built so far.
Yeah, not only have you seen it develop, you've helped develop it. Absolutely. Your imprint is on everything that we've done and delivered to the organization. I still remember back in November of, I guess it was '24, when Josh and I were talking, I think we need another person, and Josh goes, You know, there's this, there's this person on Twitter that did a really cool formula. I think we should hire. And I'm like, I don't think that should be the barometer of who we hire, but we got on the phone. You were awesome. And I think we hired you that day or maybe the next day. And then we started working together. It was super fast and very organic and it just worked out really well.
And I think it's also because Josh and I, I feel like I sit somewhere in between Josh Yuan and Bryan Yu, where I'm very much a product person, but I'm also very much a consultant. And at the time I was more a product person, I was more knowledgeable on the product side, and I feel like that's what stood out to Josh at the time. And then over time I kind of developed more of the, of the consulting skills when I was working together with you, Bryan. I still appreciate the fact that I have access to both of you and just be able to brainstorm on both sides of the work that we do.
Yeah, I think that's awesome. I think something that's so cool about your trajectory at Notion State was like, as you mentioned, you came in very product heavy. You, you kind of came in wanting to be technical. And I remember having many conversations where you wanted to focus only on automations and you didn't, you didn't want to manage programs and you were very focused on more of the builder mindset. And something that I was very intentional about pushing you towards and both selfishly and because I think I thought that you would be good at it was like I think you can manage crazy programs and, and now today, 3 years later, you are managing the biggest programs at Notion State. I think under, under you specifically, I think you have probably close to 4,000 or 5,000 users that are projects that you're either supporting or leading. Um, and it's been really cool to see, I guess, just to, to ask what has changed over the past 2 years to help you get to the point where you feel comfortable working on those sorts of engagements?
Yeah, so for me, I wasn't necessarily super confident in my client management skills at the time. It's not that I wasn't necessarily good at them, it's just that I had to build confidence to become the, the professional that I am today, or to have the confidence that I have today to manage large programs. I started with product knowledge, and that's where I felt I was strongest, and I typically do lean more on the skills that I do have, but I'm also very open to opportunities to develop in Areas where other people feel like I might be good at, but I just don't see it yet. And I, I feel like that's been a really good trajectory for me at Notion State because I wasn't able to see everything the way that you Bryan and you Josh saw for me at the time. And so I'm very open to opportunities to develop in those areas. And the way that I view these types of opportunities is I can do anything that I set my mind I need the right level of support and I need to have someone to be able to brainstorm, to be able to, you know, get feedback and ultimately work together to get to the state where we have a win-win situation where I am where I want to be and you guys also get value from my development. And so for me, it was really just mostly about confidence and not believing at the time that I could manage large programs and also not being sure that that's something that I would enjoy, which has turned out to be a Very untrue. It's, I really, really, it's probably the part that I enjoy most about the work that I do.
Hmm.
What would you say to people? So there's, there's a lot of growing supply of people who are Notion consultants or like, you know, certified as a Notion consultant, but they start from the same kind of background and interest of being a really, you know, a product expert. They love Notion. Usually that's what gets people into the ecosystem is they love the software. As you've kind of gone through your trajectory of starting in that direction and then growing in confidence towards becoming a good consultant and caring about something more holistic than just the product. How would you encourage, or what would you tell those people that are in the ecosystem that are— they love the product, but they're maybe trying to figure out how to become a better consultant?
I think ultimately it comes down to how driven you are to, to be a consultant, because these are two very different skill sets, right? And not everyone needs to be a consultant to fit in the model of like Notion, uh, consultancies, right? So we have builders and we have consultants. And in my mind, a builder is very much a product person and a consultant is someone who handles client relationships well. Still needs to have good foundation of Notion knowledge. But to me, it's more about how willing are you to grow in the areas that you want to pursue. Because if you're driven. If you're motivated, Notion State, for example, will give you the opportunity to develop the way that you want to develop. And then finding an agency or a consultancy that is going to help you reach those goals is, in my mind, what's critical. So having internal drivers and motivators to get you to where you want to be and finding a good environment to develop in, to me, is like a, it's a win-win situation.
What changed? I mean, Bryan talked about early days, he was trying to, you know, uh, kind of encourage you or push you towards, for example, uh, the idea of recording Looms, like not something that was super interesting to you in the beginning, but now it's like, that's your bread and butter is you're really good at Looms. Well, sorry, we don't use Loom anymore. I don't wanna shout out a product that we don't support anymore. Back in the day it was Looms. Um, what changed? What was the mindset when it's like, yeah, I, I don't feel like this is my area, this isn't my expertise. Like what made you think, oh, you know what, I'm actually gonna go after this even though it's uncomfortable. What was the driver there?
I think for me it was just a characteristic that I have. I will put myself in situations that I'm not comfortable with, with the intention of getting better at them. Really what changed was just the repetition, I had more exposure to it, I did more of it. And then ultimately that really ties into how I manage relationships today as well. I have weekly office hours with over, you know, 200 people and it feels very much like recording a Loom these days. But at the time, recording a Loom was super scary and it's just like putting yourself in the position where it feels uncomfortable in smaller risk situations where you have a little bit more, space to make mistakes. And then ultimately also recognizing that a mistake is not really that problematic. I can make a mistake even if I say something on office hours that I can always correct it. I can always spin it in a way that's funny, that's, you know, engaging. And I'm just— I feel it's very similar to language where if you're not scared of doing it and not scared of speaking, people will understand what you're saying. And ultimately you're going to get your messages across. It's just about stepping out of your comfort zone to get there.
Yeah. Yeah.
Well said.
I think honestly, at the end of the day, it builds trust with people when they, you know, when you can admit that you had, that you made a mistake and just, and just make up for it. It actually, I think, creates a, a better net positive experience with the people knowing like, okay, I can trust this person. They're human, that they understand that they're human. They're not trying to be something that they're not and that we can work through, you know, snags that will inevitably happen. So that's, that's great.
I think it also makes you very approachable in a relationship, right? It ultimately what I thought a good consultant was, was like this professional that never makes mistakes. I think finding balance between being a human, being a person, being approachable, and then being a professional at the same time creates a really interesting relationship where the client can really lean onto you for professional opinions and to help drive the direction of their Notion solutions and ultimately Regardless of the work that you do, be the partner that they need you to be, but also be the person that they can come to when they feel like, you know, they want to share a win or they want to present a challenge that they want to chat about with you, or ultimately just tell you about the weekend or maybe a PTO that they've just come out of. So it creates a better relationship, in my opinion, if you have the balance between the two. And that's, for me, that was really like a shift in how I approach relationships. And I think I relaxed a little bit and it just created— I love my clients and I feel like we have really good relationships and that's really what, what had to click for me to be able to get there.
Yeah. Well, the, the professional relationship always needs— while it always needs to have some component of it, the best part of client management is the friendships that come out of them. Uh, and I, and I think that that's like one of the coolest things that I've seen for you, but also even with me at Notion State, it's like having a number of clients where for sure send Christmas cards to, right? And it's just a cool thing to be a part of. And it's something that takes time to cultivate and things like making mistakes on Looms or sending a bunch of Looms or being there for them when they have those moments. And that's a really, really cool part of it.
Yeah. Yeah. Fully aligned. If I'm very, for me, it was super interesting to see how a relationship evolved into something that I'm very excited about. Not that I wasn't excited before. I was always excited about, you know, the things that we were doing and the relationships that we were building, but, you know, Now on a Monday, I get up and I'm excited about a weekly call that I have with a client and then just, you know, getting the opportunity to touch base and then chat about the next steps that we're going to take. So I think it creates a really safe environment for both sides.
That's awesome. I guess to kind of take us to where the core focus of this podcast is, a really cool part of, I think, the consultant's journey or from getting into consulting and becoming more of a thought leader in the consulting space is being able to take your experiences and start to turn them into frameworks. And you've created an incredible framework for Notion State. You call it the CAST framework. Tell us a little bit about what the CAST framework is, but more importantly, tell us why you felt the need to build this.
Because I wanted to, to coin a term. No, kidding. Uh, also, but one thing that I'm very conscious of in the world of AI and where AI is going and how fast it's evolving is that IT teams are very overwhelmed right now. Governance is really hard. Features are just launching and launching and launching. And we've had conversations with our clients where they actually, you know, were very transparent about the fact that it's really difficult to create one scalable solutions, solutions that will potentially work across platforms and build governance around it so that on the one side it can enable their teams, but at the same time that the solutions that the company is building follow a specific security framework, they follow specific framework that allows them to scale the solutions that they build. And so that's something I've been reflecting on a lot. And we also work with AI quite a bit, and I wanted to be very intentional with not creating additional problems for the organization, not creating things that they will ultimately talk about as like an additional thing that they need to manage. And this is how the CAST framework really came to, came to mind, where I wanted to build a framework that that not only is easy to manage, but is designed in a way that allows us to build AI solutions and agents in a way that we start with more granular components and then we build solutions out of those components. And then as we learn more about AI, as we learn more about agents in general, the solutions that we build, we can improve the component and with that cascade upgrades and improvements to all agents that use those components. And the CAST framework is really, is built out of 4 layers. The most granular component is capabilities. So capabilities are essentially skills or prompts or functionality that an agent or an AI solution can have. Out of those capabilities, we can build something I'm calling agent archetypes. So that's the, the A in the CAST framework. Archetypes are types of agents. So a knowledge agent is an archetype, or a project generator or checklist generator is an archetype. A Slack Q&A bot is an archetype. And by taking those capabilities and really being intentional with how we build capabilities and what type of functionality we build, we can take those to build archetypes. And once we have a good framework for building the archetype, deploying the archetype, testing and measuring success of that archetype, we can deploy a solution. So individual instances of those archetypes and ultimately connect those solutions into a system of agents that work together through an orchestration layer. So it's a really interesting concept. It requires you to be very intentional with how you build to make sure that it is designed in a way that if you improve a capability, it really cascades through all layers. But it's something that we're being very conscious of in our deployments.
I think it's awesome. I think it's a really cool framework to be able to think through. It's like Notion is blocks and they're like Legos and you build houses with them, right? And you kind of are applying that same philosophy here to use capabilities are your blocks and then archetypes are collections of those blocks, systems are collections of the archetypes, so on and so forth. At what point in time did you decide, okay, you found a framework here? Did you start with the framework or did you start with a bunch of agents where you found yourself doing the same thing over and over again, just in different flavors?
Well, the idea actually came from a knowledge sharing session that we had at Notion State where I believe one of the pods was using something they're calling external prompts where within the agent itself, they were just referencing external prompts. And what that essentially triggered in me was like, well, this is essentially building blocks that we can leverage to build types of agents. So it's not just a one-off solution that we are doing for this specific agent. It's something that we can really turn into a repeatable framework. And at the same time, I know that Notion is positioning agents as team members, and it really had me thinking that we should be thinking about agents as team members. And when you look at a team, they have soft skills, they have hard skills. So that's a capability, right? We have profiles of people. We have an IT person, or we have a consultant, we have a builder. That's an archetype. Individual solutions that we're using in the framework are essentially individual people within a team. And then a system of people is a team, right? It's a team of people working together that have a set of capabilities and skills to be able to perform a specific job, right? And so really taking those two concepts and connecting them together into something that made sense in my mind and that felt like a good way to think about deployments is really what's, what triggered me to start thinking about this more intentionally and then documenting it as I thought through it.
This whole thing being about boiling things down to primitives and kind of the atomic level, I suppose. We've kind of seen this emerge in other areas of work and thought leadership. Uh, the archetype piece is really interesting because a big part of the conversation right now is what happens to our jobs? How do they evolve? People are kind of boiling down jobs into almost their most basic primitive components. That don't really have a job description anymore. As you build out these archetypes, I imagine the first run is recreating the system that we already know, recreating basically existing job descriptions. But are you seeing the archetype shift, especially as you kind of think about the parallel between a person and an agent? You know, you've got skills beneath it and then you're building up an archetype, which is like the job description, and then the solution, which is like the actual person in the job. How do you see the landscape changing? Not just in, in agents and AI, but just in general. Like, I wonder if you have any thoughts since you're thinking in this lane about how jobs are going to change given how we're able to break these down into primitives.
That's a really great question. The way that I think about it is like the agent ultimately becomes the first level of work, whether that be support or it be, um, responses, it'd be like the admin work, the office work. And so in my mind, We're not— people are not going to lose jobs if they can understand how AI is going to influence their work because we deployed 3 instances of a Slack Q&A agent at Adoro and it was really interesting to see how the team is now adapting to this. So instead of being that first line of support, now they're managing the agent. So really it's delegation of work, right? And so it's management. And I think this is where people will need to adjust slightly to, like, it's essentially like a team member that they have to manage, right? So they have to give it feedback. They have to say, this is good, this is bad, right? They have to make sure that the responses that the agent is giving are accurate. And if not, to essentially report it back either to us or to the agent so that we can log that feedback. So it's really just about thinking of agents or AI in general as the first line of support, the first, like the entry level job that can drive a ton of value. Like one of the most successful agents that we deployed at Aduro is essentially autonomously solving 70% of questions, if not more. The quality of responses is like 90% and above. That's really like our most successful agent. People are engaging with it. They're learning how to engage with agents to the— how we engage with agents as well. And so it's been really interesting to see the shift in the company as well, to see how they are viewing that and that engagement and how they are responding to AI solutions, but nobody lost their job, right? It's just making their jobs easier and making their jobs slightly different. And then to me, I think people just need to acknowledge that fact. It's going to be different. You're not going to lose your job if you acknowledge that it's going to be different and understand how that is going to influence the way that you do work today.
Yeah, it's interesting. You got me thinking that like, you know, this is just a generalization, but the people who think that AI is most valuable to them by eliminating jobs, just clearly don't understand the leverage to the equation. You know, it's like you already onboarded 100 people that you're talking about laying off. You've already built in culture, you've already built in reporting lines and politics, and you just want to cut all that away when you could give them the tools to leverage their work to absolutely dominate your corner of the market. Yeah, so thinking about it in that way, I think is really healthy.
Another thing added on top of that, Ava, you said this also, I've heard this in a couple other sense as well, is like every agent that is created requires a manager. Eventually it's going to stop working or eventually it's going to need fine tuning. So the idea of an agent replacing a person is wrong. It's definitely augmenting or like thinking about as a part of the team. I think it's really interesting to think through. It's like when you deploy these agents now as a Notion consultant deploying agents, it's very important to find somebody at the organization that's responsible for owning this agent beyond. I think that's a new nuance to the role and the job.
Jumping into maybe some more of the details of the CAS framework and how it actually helps you do your job, or even for the clients that you work with. What's an example of, you know, you've got the capabilities that are kind of meant to be the granular things that if you level them up, it kind of disperses and levels everything else up downstream. You talk about Slack Q&A bots and things like that. To give people a picture of how this works and how this framework helps you do the agent management. Do you have an example of maybe one of those capabilities that leveled up and it, it kind of went downstream and helped you cascade the value creation that you have without having to go into every single piece?
Yeah, so I can talk about examples from the Aduro build. So essentially we've deployed 3 solutions that fit the Slack Q&A archetype. And the first one that we built was essentially, it was, it was the first time that we were really developing a framework for how we want to build knowledge and Q&A agents. And we started with what is the basic functionality that we want this agent to have, right? So the IT agent was the first one and we talked about, so we want this agent to be able to consume the historical information from Slack, right? Because this is a lot, a lot of times this is where the knowledge lives, right? People have repetitive questions. The IT team responded to those questions. And so there's such important context in those threads, in those conversations. So I wanted to find a way to import that data into the agents and make it as a knowledge base instead of waiting for the IT team to actually build a knowledge base from the ground up. So that's an example of a capability. Another capability was to be able to interpret the questions that the user has and then confidently respond to those questions, right? And so the way that we typically structure these knowledge agents is we said, what is the confidence level that says the agent will very likely respond with an answer that is accurate? And we found a good threshold is somewhere, somewhere around 70%. And so from that, we have two playbooks, right? We have two capabilities. If it's over 70% confident, it will respond to the question. It will, you know, cite the resources. It will give the, the person everything that they need to unblock them. If it's less than 70%, then we need an escalation path, and that's another capability. And then some of the later agents, we've also built additional capabilities like knowledge gap logging. If the confidence is 70% and the agent has escalated, then we're potentially also have a knowledge gap where we don't have those questions answered. And so we potentially wanna build a resource around it so that the agent, the next time it runs, it has that context. And so knowledge gap logging is another capability. And then finally, things like opening tickets, triage, things like that, uh, that are more action-oriented to be able to collect feature requests, collect bugs, and then ultimately create a backlog of things that we need to work through to, to support the teams. These are all capabilities, and we started with a smaller set of capabilities. And then the more we learned about how people are engaging with this, what are the things that they potentially need, we started adding additional capabilities. And with every new solution that we've deployed, we integrated those capabilities into the functionality. And the more that we learn, the more we can then say from these learnings, we need to improve this capability And considering that all of these agents are built on the same capability, we're essentially cascading these updates across all of the solutions that we've deployed. And it creates a, a really interesting plug and play situation where we can very easily say for this archetype, for this solution, it makes sense to take these capabilities and we're creating a pool or a portfolio of capabilities. And not every solution of the same archetype will need all of those capabilities, but we're creating repeatable capabilities that we can use depending on what the solution needs to be. And by updating one playbook or one capability, we're really just creating such a scalable way to drive further value and just better quality of the output across all of these different deployed solutions.
It's fascinating. It almost feels like what we're doing is, uh, an experiment in granularizing, if that's a word, the human brain. You know, it's like if you could just take tiny little slices of every tiny little skill that somebody has, and the more granular it is, if you can kind of like collect them and then draw on them in the same way that our brain probably has some sort of orchestration layer to call on each of these little things, we're really creating like a neural network. If anything, it is a network, you know, it's more of a graph model and it's kind of like the brain in a sense. And so the more tiny little slices you can get, you know. And you increase those skills, uh, the more they bubble up to the surface.
Yeah, that's exactly it.
And I think what's so neat, and I mean, this is exactly, Josh, what you were just saying, but it's like, you're making custom agent creation plug and play as opposed to every time doing the same thing or like having to build from scratch. And I think what's really interesting to think about in this zone is when you think of each one of those agents that you created, those 3 different Slack agents, those were 3 different people or 3 different teams of people that were responsible for responding to those, but what they were doing were the same thing. They needed to know where the knowledge base was or have the knowledge and they needed to answer it. And then if they didn't know the answer, they needed to find the answer. And the idea of what you're building is you just need one thing that's able to do that and you can use it across all three of those different execution patterns.
And what's really interesting as well is one thing I'm very conscious of is AI solutions cost money. And so something I'm very conscious of is like, how do we measure value? How do we prove value? How do we report on what the agent is doing and how efficient it is at what it's doing? So what's really interesting to then observe is once you have an archetype and you know how to measure success, it's really interesting to see the same solution being deployed in multiple instances and then back kind of analyzing what makes this agent successful, but this agent not successful, right? If they're the same archetype, they have the same capabilities. Why is this one so good and this one could potentially improve? And something that I've found is that we're then starting to answer very functional questions. So we're answering business questions. I'll give a quick example. The agent that we just deployed had fantastic documentation. We specifically designed documentation with AI in mind to be able to make it super accessible to AI. We answered all the FAQs before we deployed the agent. And the questions that people have are very repetitive, right? And so we know that this archetype will always perform really well in this situation. But then potentially another agent is performing still well, but it's not performing as well as the other two. And we found that there's more nuance in the question that people ask. And so this then creates a really interesting path for us to guide our clients to say, like, we can very confidently say that if we deploy this solution, it's going to perform really fantastic. It's going to be a great ROI for you. But if we want to deploy this for this instance or this use case, Well, why not consider a different path because this might be less successful because of X, Y, Z. So I think it also makes us better consultants with the framework because we can learn collectively across different archetypes instead of just assuming that one solution that was working well means that the agent as an archetype is working well. Yeah.
Having the proof points, uh, one increases your confidence, which increases the client's trust in you. So it's like a healthy cycle there. As you were, one of the pieces you were just touching on that was being able to actually communicate this to the client and have a conversation with them to get them to understand. What have been the pros and the challenges to using this framework and getting clients to adopt it?
Well, we haven't had any necessarily like challenges. The challenges that I found were more around governance. Some teams are more open to governance and actually want governance. Some teams want to be more open and then provide access to agent building to anyone in the organization that wants to build agents. The companies that are more oriented towards governance in general and that want to have structure in place will be very open to the Paas framework. Those that want a little bit more freedom in agent builders are going to be less open to the framework. And it's really hard to govern if everyone is building their own solutions. And so that's what, to me, that's the biggest challenge. We have either power users that we can train, or if our team is building, it's super successful. It's been, the feedback has been amazing, but that's not going to work well when everyone is building their own agents in their own respective ways.
There's almost a parallel to Notion and everyone wants autonomy, but we'll see where, where it ends up, you know, over time.
And a pattern that I've noticed, depending on the path that the client takes is if individuals are building, a lot of times what they're building is individual agents. If power users are building and Notion State is building, we're building for the company and departments and larger organizations within an organization. And it's just something to be very conscious of. I will always be biased and always say that we should build less, but build for more people. But also some companies do want that autonomy and promote people learning and adopting AI through that pillar as well. So. I think it's just a matter of recognizing what the client needs and what is the best fit for them and just guiding them and still helping them establish some type of governance to help them manage the solutions down the line.
I have like 30 more questions, but I acknowledge we're at time though, so I don't think we're going to get through them. Ava, is there anything else that's top of mind for you that you also want to talk about on this or touch on before we close things up?
The last thought that I want to put out in the world is that I really see AI solutions in general as something that we need to talk about from the perspective of value to cost. A lot of times when companies are investing in AI, they're seeing it as pure cost, and a lot of times it's because they don't necessarily know what the projection is going to be. They don't know how to measure that projection, how to estimate projection. But ultimately, something that we're very conscious of and having those conversations with clients is really understanding what is the value that this solution is going to drive for you for the investment? And I'm intentionally saying investment because it is an investment, not a cost, if the solution is working well and if the build is well thought out. And so I encourage companies and decision makers that are watching this podcast to really think about AI solutions in that respect, as opposed to just cost, an additional software cost that is going to come to the company if they lean a little bit more into AI. I typically recommend defining what are the top 3 to 5 use cases that can drive value across the organization and then defining what the path to that success looks like, how we will measure that success, and then ultimately making that investment, piloted. And then after you've seen the results, making a decision on what the next step should be instead of just immediately saying no because it's an additional cost that is going to come to the organization.
That's a great way to wrap this up. I mean, Ava, Thank you. What you're doing is you're creating clarity in a world where there's just so much ambiguity and the models like Anthropic and ChatGPT and even Notion, they just let all of these organizations swim in ambiguity with regards to this is just going to cause value or drive value. And what you're doing with this framework and the governance that you're putting around it is putting a lot more predictability and clarity into it, which in turn drives a lot more value and return and further investment. Into it. So thank you so much for one, being a part of our team and two, being thoughtful and building frameworks like these to help our team members and our clients organize around how they build and deploy in AI.
And thank you guys for the opportunity to be able to do that. I, I was just reflecting on it yesterday. 15 years ago, I was working at McDonald's. 10 years ago, I was a physical therapist. And today I'm leading some of the largest programs at Notion State deploying very cool solutions, working with fantastic clients. Uh, it's something I'm very grateful for and something that I'm very excited about because seeing the trajectory over the past 2 and a half years, I can't even imagine where we're gonna be in, in 2 and a half years from now. So thank you both.
Love that. That's my favorite part about doing this. Likewise.
More from Bryan

Bolt-On or Built-In // AI-native services, scaling, and the people who make it work









