MVPs are Easy, Agents at Scale are Hard: What We’ve Learned Building Atlas

So hi, hi everyone. I'm Shantan and over the past one year I've helped build the platform on which Atlas agents run and with me I have Jake who is the principal product manager and Jake has helped customize and implement and deploy these agents into various various customer instances and So we're gonna get into Quite a bit of a discussion today and we're gonna leave plenty of time for questions So feel free to drop those in Slido But I'll walk through the agenda and we'll set a little bit of context for the discussion today we're gonna go through how we've Thought about building and implementing agents and for specific Categories from fit identifying if you have the right idea for what you want to deploy into an agent to actually building Deploying and constantly iterating on those agents, but first I know this is the last session of a long two-day Pulse here and I know folks are still trickling in so I want to do like a very quick icebreaker So get everyone's body moving just a little bit. So I want everyone to stand up if You or your company is planning to deploy a customer facing agent of any type planning to All right, so good good group. All right stretch it out a little bit if you need to I know everyone's getting a little tired here.

All right, sit down, please Let's do one more stand up if your company has deployed a customer facing agent to date All right, so about half of you stood up so good mix of folks So I'm curious as we get into questions to hear what you've learned and and other other things that you want to learn about today But I also have one more question stand up if this feels like you some days This boulder of AI constantly coming at you and you don't really know how to how to escape it. Yeah We'll try and sprinkle in a couple Indiana Jones references throughout the the conversation here today So the reality today is Everyone's facing the same thing that boulder coming at them is really bucketed Into three areas that I think we've heard throughout the the course of the conversation but also the course that we've we've engaged with our customers is Every team is expecting expected to do more with less no surprise and There's constantly being improvements in all of these models and it's hard to keep pace It's a dizzying pace that we're all expected to keep up with and AI adoption is rising. We're seeing token usage going up Considerably across the board within our internal organizations with customers within every publication that you can see but what seems to be missing is the ROI the actual outcomes from those those agents from the usage of AI and that's what we want to get into more today and These days you have a range of options when you pick the AI solutions you want to implement right you have co-pilots Have MCPs and then you have these autonomous agents and agentic systems and it's important that you choose the right tool as part of a strategy and Right now the industry is sort of moving from these co-pilot like agents to a more co-worker like agents and these are Autonomous systems that are able to take a job entirely off of your hands and involve humans only as needed and so the Advantage with co-pilots is that they were relatively easier to build and they were also safer to deploy because there was always a human in the loop but again the human remained the bottleneck and Another issue with these co-pilot like agents was that the ROI that Jake just talked about was harder to prove But when you now come to these autonomous agents They are much harder to build and especially if you're building a customer facing agents. There's a higher risk involved in building them but the advantage is that it unlocks almost an entirely new level of value and very importantly that value is measurable because the agent owns the entire job and the job and the value of the agent is the value of the function right it's easier to prove the ROI as well and When I talk about autonomous agents in this session today I'm talking about agents that directly interact with your customers for example agents that can completely handle your renewal process or Onboard customers or drive adoption autonomously with minimal human involvement And Given this investment and risk involved I think we should the first question to ask is is this a part we want to go down on right?

do we want to make this investment and There's especially in CS. There's a it sort of comes down to three primary factors The first factor is do you have a segment which is valuable enough to make this investment in but also the risk to reward ratio is it good enough within that segment and the ICP sort of for this kind of agent would be if you have a huge volume of customers each with a pretty low ACV Right and you want to drive GRR or manage that segment with smaller headcount. So because this kind of volume just simply does not scale with humans and The risk of a single mistake is small because of the lower ACV But we've seen that this is not the only archetype of customer That autonomous agents work for we've seen customers with relatively lower With a relatively smaller long tail and higher ACV But again this they are understaffed and they don't see how they can drive up GRR without the use of agents. They are also implementing autonomous agents the second thing is that You need to have a very clear workflow that you want the agent to Implement and you need to have data which is clean enough to back that up and a good proxy to know That you are ready is if you have a fairly mature Digital program already in place that means you have the underlying infrastructure to deploy agents, right?

And finally, this is a significant investment and this is a longish investment And you should be ready to spend multiple cycles iterating this agent. It's not a Build and I'm done kind of a situation at all with autonomous agents So probably the biggest lesson that we've we've learned with deploying these these agents is You should start as modestly as you possibly can you can have the biggest roadmap the grandest ideas but the MVP can be so small and so contained because getting yourself live is a huge Milestone that you and your team and your partners achieve that you can then iterate on you've gone through Security and you've gone through any technical issues. You've gone through data concerns. You've gone through Scoping with multiple teammates and all of this Gives you kind of this huge corpus of what could be the requirements that you want to build out that you can build into a roadmap But the wise idea is to smart start small and iterate from there Because many people who have these grand ideas might try and take that big swing and never get anything off the ground So that's really the guidance that we've been giving with many of our customers and that's where we're seeing a lot of success so as you think about defining your MVP there's a few sections that you'll you'll see here as we thought about really launching our our fleet of agents We had four in mind and we decided ultimately to start with renewals Because that's really closest to that revenue component of engagement with customers But additionally we're working actively on adoption and considering things like expansion and onboarding directly after that But as you think about the selection criteria for this you need things like a clear trigger understand Who's going to be engaged how they're going to be engaged?

What quality of data that you might need are do I have the right contact to reach out to it the the right accounts? you also need to be able to identify where they're bottlenecks in your existing processes and Use the agents to fill or address those bottlenecks because that's really where there's friction that can be solved for and if it can't be Measured then it's probably not something that you really want to Build an agent on because then you're not going to be able to report that back to your executive team And they're not going to continue to fund projects like this So as we thought about MVP selection criteria, Jonathan mentioned this earlier We thought it makes a lot of sense to find accounts that are relatively low risk so lower a site ACV your lower ARR things where you can start with Templates where possible and then eventually allow the agent to have more and more control over how it responds to your customers how it engages with your your customers and start to define what a happy path and That unhappy path looks like so you can also give that guidance as you think about Agents and how we're thinking about that that Modest start is really the onboarding of a new hire in your company Right once you get them plugged into your systems that first day or that first week is really a syllabus week, right? You're getting them their computer. They're getting them access to the right systems You might give them a job or two and say hey like you're taking over this book of business I want you to start reviewing these emails That's how you might think about the approach with an agent and then eventually as you realize they're more competent They can do the job.

Well, that's where you start to expand the functionality and the work that you're handing them and more trust You're providing to them So the common challenges that we've seen across discussing with dozens of customers and working very closely with some some select design partners are threefold Every single customer has top-down mandates where they're expected to go in and deploy AI or agentic functionality that solves a specific reason or a specific need Typically that need is aligned to some sort of GRR or revenue based metric The other thing that we've seen across the board is most teams that we're working with are using their scale their digital segment Teams who are already stretched incredibly thin and don't have capacity for more work So that's where you can start to identify What's low-hanging fruit that we can tackle and new things we can do to support our customers throughout the lifecycle? Throughout the journey that our team that's already stretched through thin may not be able to handle themselves So where we think about scaling headcount, but don't have the the capacity to do that That's also where we might want to insert an agent in this in this flow And where we've also seen the the journey well developed with many of these customers is a lot of them is cut as John to Mention a few minutes ago have developed mature CS digital processes where there are manual bottlenecks where teams have to jump in and engage with customers at Different points in the customer lifecycle the last thing that we've seen relatively across the entire board is there's a some sort of offshoring or Outsourcing model within these businesses Where it's you know low cost resources that are doing some things that are repeatable tasks that are very easily to To be trained across the the different teams that we're engaging with that's something that we can take and just develop directly into an agent Now this is something that we've done with all of our customers And I'd suggest you all do this if you're considering Developing an agent or just want to go through a thought exercise is create a value statement with with the folks that you're working with So start to identify what that pain is that you're looking to solve If you can identify what that root cause or root causes are associated of the pain Name the business consequence if you can't solve for the pain itself and then time travel a bit and say okay 18 months or 24 months from now What does this future state look like and what are the leading and lagging? Indicators to get me to that point where I can actually develop this and start to measure Consistently are we reaching those steps to achieve those desired outcomes? So Now let's say you decided that you do want to build autonomous agents and then we'll now talk about what it takes to build these agents and The hardest thing about autonomous agents is that That that last mile gap between a good demo and production It's very high and because these are high stakes that gap has to be fixed before you go to production and So there are some reasons as to why that happens right in a demo In a few weeks you can get to an 80 90 percent done agent and you get excited and you think you're good to go But that last 10 percent the last mile really has You know You'll see you'll see that that last mile never ends right?

It's bad data that you only said that only surfaces in production customers behave in ways or you encounter scenarios that you did not expect to encounter and Every possible edge case that you have thought of and did not think of you will hit it in production. So you need systems that are robust and are able to handle these scenarios or at least fail gracefully and unless you have these mechanisms implemented deploying a customer-facing agent is going to be a challenge and So the most widespread customer-facing agents that we see are what you see in support But CS is structurally more different and more complex from support So CS has long running workflows spanning months That we initiate and we are also responsible for the closure of those workflows so we initiate the renewal conversation and We have to close it as opposed to support where the customer initiates a very contained request and you are closing it then but you have to take this workflow to completion in CS and It also has to operate in a much larger context and with more nuance Right. So a renewal process is a lot more complex than completing one support Right and that is where the challenge lies for autonomous CS agents And it all comes down to balancing predictability autonomy and reliability Predictability is can you predict what the agent is going to do and can you ensure it does it consistently? and so this comes down to You choosing a model The simplest solution that can solve the task is what you should always aim for there's multiple moving Agentic components in a CS workflow and you always want to reduce each one to its simplest possible form Right.

So if a deterministic Tool can get the job done always favor the deterministic tool Do not agent do not use agents if you can afford to not use them and also a Few short learning goes a long way with LLMs. So providing templates providing examples of what a good response looks like and Giving detailed instructions and the right context matters a lot When it comes to autonomy again, the idea is to introduce autonomy in small closed contained loops, right? So for example If You're let's take an example of a respondent like a customer has responded and you want the agent to handle the responses a very good practice is figure out what are the key use cases and then give specific instructions for each of those use cases as opposed to having the agent figure out a Solution from scratch, right? So break down any complex problem into smaller components and build agents that work in small closed loops and For reliability again, this is very important when you're operating at scale because AI will break down at scale There will be errors right and what you need for this is a set of guardrails That the that you ensure that the agent never violates right you know, for example, if you're running a renewal workflow, it can never give a discount of more than 10% right or Let's say never reach out to a person who has Opted out of your lists.

These are things you cannot rely on AI you'd want to put guardrails in place and Similarly, you want to identify what are the critical failures that can happen within your workflow? You need to implement evals to measure these critical failures and only launch once you are satisfied with the error levels and you have to continually monitor and reduce these errors and Keep updating your eval. So implementing this guardrails and eval framework is critical for any production grade agents that you deploy So with this in mind, I'm gonna talk you through how we had designed our agents within Atlas, right? so at the highest level we created this abstraction of an agent an entity that executes your AI playbooks and the playbook is what contains the process Now the agent we it's modeled around a user, right?

It has its own mailbox It can access its system through a through an agent user like it can access gainsite Salesforce any other system with the right set of permissions Just like a user would have it has its own set of composable skills So how to generate quotes how to create a timeline entry like these skills are available and composable and we also Let you configure what data and what set of knowledge it can access to complete its job so agent has all of this skill set and an identity and the playbook is where your actual workflow resides and as I said a CS workflow starts with you initiating a conversation Solving the customer request and then also nudging the customer until the workflow gets completed So the playbook primarily contains within Atlas an outreach strategy Where you can define how you want the agent to reach out with what messaging what's the cadence and who to reach out to? And then we also have an inbound strategy Which is further broken down into various reply categories and instructions for each reply category, right? This forms the meat of the playbook how you reach out and how you respond to at least the most common use cases and Then we have guardrails and evals and execute it and half of and handoff which are key scaffolding within the platform So you can define guardrails as to what the agent Absolutely cannot do and these guardrails are checked before every action the agent performs Similarly, we have a very robust eval Framework implemented within the platform. So all the critical failure modes you identify you codify them They are checked prior to the action getting performed if that eval fails It is redirected back into the agent to fix whatever error had failed and Then if after enough retries, it does not get fixed Then we hand it off to a human if the failure is critical and again, this scaffolding is very important for reliability Finally, we have exit criteria and handoff Exit criteria determine when the agent should stop That particular workflow it could be like a success scenario where the person actually renewed or It could be that you exhausted your contact sequence or it could be that you got a P0 support ticket and you want them to want the agent to stop interacting and you want to hand off to happen so all of these exit criteria are checked every time the agent wakes up and any of these criteria are met the agent stops executing and Finally the handoff itself is configurable and when the handoff happens completely flexible So you can choose to hand off via CTA within Gainsite.

It can create a task within Salesforce It can simply CCU on an email. It can do all of these things. It's completely configurable. How the handoff happens So let's talk about a little bit of what we need before we we build let's talk about the the journey here I'm gonna have to turn this way so I can actually see what's on the writing But as we go through this this journey, you know The slide will build but the first thing that we want to think about is who are we reaching out to who's our segment?

Followed by that. What's the current workflow that we're using to engage with this Set of customers in this particular journey whether it's their onboarding journey their renewal journey adoption journey in a specific cohort From there we say okay What what systems are we using to engage with that customer? But what systems are we also using to update information to pull fields to capture that that detail in one place? All of this kind of builds as we we think through it into an overarching set of requirements So think about this almost as like a separate tab on a spreadsheet that you might be building and What's the contact strategy?

Who are we going to reach out to when what happens if we don't have the the right contact? What order should we proceed to? What's gonna trigger our outreach at what point should we be reaching out to someone should it be a time-based outreach? Are they 150 days from renewal?

Is it someone who's just had a specific dip in adoption? Do you want to make that very rigid is that something that should be? much more Much more specific or can you give some flexibility to the agent as we think through this? Chauncey mentioned these earlier but guardrails.

So what should the agent never do? What are the boundaries that it cannot cross? All of these are things that you're continuously Iterating and updating and building with with your team Things that are either obvious that you just want to say like never reach out to this customer. This is a federally based customer I should not touch the customers that are fed I shouldn't touch customers that are in the immediate in the region over a certain ARR threshold It's hard to build out all of these rules with consistency if you're trying to build it in a CSP or Salesforce or something Like that.

So that's where you need the LLMs to give it that natural language engagement as you're building in the guardrails Additionally, what's the handoff design at what point we've reached our guardrails that that boundary that we hit What are we doing from there? We now need to trigger an action or take some action who's responsible for that action? Where are we taking that action? Are we pushing back to gain site?

Is it going into Salesforce? Are we sending an email to a teammate with a specific set of instructions or details? All of those things need to be defined in this process So it's clear not only what should the agent be doing but who takes the ball when we've reached our boundaries Additionally as I mentioned earlier, we need to be able to measure success So across the the entirety of this agent similarly to how you might have MBOs for for your team What are those things that we're looking at? Are we trying to move the needle on adoption or retention or a renewal rate?

All of those things are things that we want to build in and I'd recommend having kind of that North Star metric But similar other metrics underneath can be other ones that you're looking at consistently The leading and lagging outcomes are ones that I'd recommend that we take a look at too And in addition to that through each step, what is Good look like how should the agent be evaluating itself to make sure it's moving with consistency Through the right steps in the journey to engage with the customer deliver outcomes make sure that we're reaching the right engagement with that that individual customer and that series of customers that you might be Be reaching to and finally this is kind of round out rounds out the The requirements, but as you think about building this out, you also need to put your team together So who are the stakeholders who owns this who's going to be training your team who's going to be engaging With the agent at some points who's going to have those specific touch points with the agent and who's going to have the authority to make Decisions make go and no-go calls decide what to expand where to expand in the process So all of this is kind of our journey map and how we think about Those steps in building out the agent and if you were to put that into a spreadsheet One by one you could probably pop that in the cloud and build out a pretty decent demo to share with the team But as Sean Tann mentioned like taking that big step from Demo to production is a whole nother level where our team has been getting very involved with our customers and learning as we're going So next year this slide might you know have another dozen notes on that on the the slide itself Now let's get into how we actually think about deploying this and the stakes are are very high Why is that we're engaging with customers from day one? every Engagement every mistake every little change is is visible So the recommendation that we had earlier to start small allows you to contain the risk if there's an email that went out That's now that's a bad email or you accidentally use the wrong field It's easy to catch that in uat but production data and uat data are not always the same So you're going to catch things along the way so starting with that that small MVP really allows you to make sure that you're building effectively and Not exposing too much to your customers as you're going live There's also that that data issue that I mentioned things that might be hiding under the surface are going to be exposed at scale when you start to launch this these agents and those handoffs between the agent and The humans that are working on on these accounts in your company They might not have the best handoff you want to make sure it's fluid So are we giving the right information are we giving it into the right channels are those teammates enabled on what's what's to come next? If you have a bad handoff it actually creates more work for your team Than if you just handed the ball directly to the team in the first place so making sure you think about those handoffs Effectively in the first place is a really important component Now here's how we think about rolling this out and we've done this with you know customers who are in the audience and who are speaking on stage with info blocks and part source and Okta name of name a few we think about rolling us out with that contained day one scope So right now we're thinking about with our renewals agent Let's just start with outbound any inbound response we get the agent will classify It will push information back into a system and it will make a handoff that could be in an email and share the right Information with the right team as quickly as possible From there we also have thought about you know how how early do we bring in the the human element? Well in this early stage as we we roll out that day one approach We want to make sure that happens almost immediately because we're gonna get very quick feedback That goes back into the development loop that we can iterate on very quickly And we haven't reached a lot of customers in case there's something glaring that we didn't catch early on So as we think about rolling that out We also want to just validate that things are working that the pipes are are turned on and everything's working as we expect Then we go into the stabilized mode.

We say okay. Everything's working is expected. How do we then expand from there? Now let's have the agent take on more responsibility.

Can they reply to customers? Let's set what those reply categories look like the instructions for the agent. Let's make sure they have clear guardrails So as they're reaching those guardrails, they're including the right people at the right time But it's happening later than it did at that day one moment We also think about not only engaging with one person but multiple contacts which has its host of Excitement and challenges along the way and not only multiple contacts But reaching multiple contacts throughout the the journey to make sure that they're not only being reached to once For some critical adoption moment or milestone or an onboarding engagement But throughout the most critical points in whatever journey that they're on and then finally we think about scaling once we've hit those guardrails will have checkpoints along the way and make sure that we're Ready to move on we're ready to expand the scope of what we're looking to do. This could mean expanding the segmentation Reaching new customers in different countries with different language requirements different cultural expectations When should the agents inbox?

Email land in an inbox How should you be responding to customers in specific ways and adding more and more autonomy? to the agent as we've built out that trust in those first couple phases and One thing that's really important is bringing your team along for the ride So you might build the most incredible agent, but if your team doesn't know that that agents doing work on your behalf Then they might do duplicate work the customer might get confused you might have adoption challenges Escalations you might have a churn risk because there's overlap in what you're expecting to do with your customers and your agents So bring your CSM's your renewal managers your adoption leaders along for the ride have them involved in building out the requirements going through you a T Testing and make sure there's an enablement plan for them even if it's as simple as a quick demo and a two-pager that walks them through what we've done to build the agent and what they should expect along the journey and Finally within the team the project team that's actually building it we find it critical first and foremost to have someone Sponsoring the project someone who's willing to to sign up with you know within the c-suite Or an executive to go to bat for the team and identify You know what's working what's not really go through a pilot and beyond stage to make sure that you're really engaged With the right stakeholders to move the project forward if there's ever any blockers and also make sure that within the project team There's people with clear ownership of the project of the goals so if there's ever decisions that need to be made they can be made quickly and and effectively and again Deployment is by no means the end of the story. It's really the beginning and Especially in when when working with autonomous agents iteration is not at all optional. It's because again one of the limitations of current AI at least as of 28th May is that AI is currently not capable of learning on the job, right and you cannot expect to build an agent that's gonna be able to tackle the full range of the curve balls that are expected in this kind of a setting in one go and Also, the technology itself is changing so rapidly that if you take out four to six months to build something out It's very possible that you are building on outdated technology So keeping your iteration loop small and fast and committing to that loop is very important next and typically This learning loop again.

You've already established your evals you have your guardrail setup, but again in production They are going to fail right and you need humans in the loop who are Looking at all these failed events and also a sample of the succeeded events and they're annotating where the agent failed and why and then Periodically you need to synthesize these failures investigate the root cause as to which evals are failing and why and fix and repeat this cycle and So I know that this is a very tedious process but again what I expect is that a Big chunk of this loop will be automated you will have platforms that will be able to investigate fixes and Deploy those fixes even now some teams for example are able to fix bugs without an engineer getting involved So that loop is starting to happen right? But it is very important that you develop this muscle of capturing this list of failures and the reasons Right because this is excellent fodder for that eventual system to Sort of auto fix your agents, right? So you need to develop this muscle and train your CSMs and your users to hide whenever they see issues with how the agent behaved They should flag it tag it and that resource is going to be very valuable in the future and this whole iteration group is going to get much easier is my expectation going forward and again, finally the key takeaways are Autonomous agents help unlock an order of magnitude higher value and measurable value right and it is a sizable investment and it carries some risk and But if you pass the readiness check and you choose to invest in this you are going to see much higher returns than with co-pilot like agents and Iterate build in short continuous cycles and invest in that learning setup and framework is One very important tip and finally again, it's high investment high risk, but worth the reward Not only are you going to see significant outcomes and impact Because it is customer facing agents if they are done, right? they're also sending a signal to the market to your customers that you are ahead in AI and in today's world that means a lot and it's a very strong signal that you're sending to your customers and if you look and because of the complexity in building deploying and iterating it sort of It is one of the reasons that informed our strategy of forward deployed teams and Forward deployed motion and now the idea of AI enabled services because it takes a lot and it's a continuous process And that is where delivery model also reflects for Atlas reflects that reality.

So yeah. Thank you. Thanks All Right, we've got some time for questions here, so Where are most companies deploying agents at scale most companies say they use agents? But I find they are simple co-pilot chats or shared locally on machines Are we trending towards an industry standard custom agent orchestrate orchestration layer?

I? I Mean that the most common agent that we're seeing is an enterprise support agent I think most of the most of the tools that you're using today like that's pretty well solved and shaunton mentioned that You know that that's a an easier use case because a lot of information is in Support documentation and can be be found relatively easily and it's also inbound What we're not seeing a lot of quite yet is the outbound agent Because it's harder it takes time to figure out how do you reach out to the right people at the right time in the most meaningful? way Anything you dad and again are we trending towards an industry standard custom agent orchestration layer again? You see that there's a Very high number of agent builders in the market right now.

There is a bit of a standard protocol MCP also sort of Structurally aligns with how agents are built in general and you see all of these builders and Again in general Software is becoming cheap right and It's all going to become infrastructure. You know the agent builders the LLMs etc. It's building this muscle of creating a new kind of software and getting agents that actually work effectively and I think it's a little Less to over time the platform differentiation is not going to matter It's just about the best practices of building reliable agents and and so that's where it's heading towards It's all going to become infrastructure Commoditized layer LLMs agent building all of that How do you know if you have enough clean data for agents You want to take it? So again, a very good proxy is that if you have a fairly mature digital process already in place that means you have all the data and We see a few tricky Data areas that are typically the problem contact Management is always a problem contact data in general is always messy a lot of custom companies do not have the right granularity of usage data brought in right and If you have these two and and if they are clean enough to run your digital programs on I think you have the right foundation and again a lot of Subjective context that something like a staircase is able to generate etc all of those things you can plug in later But clean enough contact data Fairly reliable usage data.

I think works as a good foundation Yeah, and we've you know heard from some customers saying well, we don't have opportunities in Salesforce, but we use Salesforce It's like well You might not be ready for it if there's not a easy place that we can access if your finance team is gating that information from from you it's probably going to be pretty hard for us to get to To deploy an agent if half of your team is using one field for you know an opportunity Account value and the other half is using another field. It's hard to identify which field we should use right out of the box It's not impossible And you know contact data is often messy probably the most messy thing that Everyone CRM has today and that's something that we are planning to work on within the the agent functionality But what we're finding is it's not impossible to use it you know we The llms can get around like if you have you know the the wrong case capitalization for for contacts or if someone put do not contact in the name itself an LLM can pick up on that pretty easily and recognize that so those types of Examples wouldn't really deter you necessarily from from deploying an agent But where you're missing data or people are doing things so inconsistently That's a that's a challenge and also in general when it comes to process and data it comes down to the amount of institutional knowledge that is within your organization how much of information is learned on the job and not documented anywhere and there's ten different fields and Over time you learn which field it is that should be used so an employee In the first week of joining the company like you know how easy for him How easy is it for him to navigate your systems determines how good your data is for an agent? roughly What's the difference in the offering of Atlas staircase and Gainsite Co-pilot? Yeah, so you can think of Atlas as an autonomous agent So where the work is being done on the behalf of it of a teammate or someone who might be engaging with a customer whereas staircases your intelligence layer, it's grabbing all the engagements that you have with your customers and surfacing those up up with with with triggers for your team to then take action on and then what's happening within Gainsite is really where your teammate is orchestrating and Actioning on the work so certain staircase might surface up a signal that's then managed by a teammate in Gainsite Atlas is the agent that's actually maybe going to pick up on that CTA eventually or handle some of the the workflow itself Think the data hygiene questions been answered here, so we'll skip to the next one You mentioned we should expect to maintain and support AI agents How should we think about planning for admin ops capacity for this?

Feels like this should be part of the upfront investment planning so our agents don't get stale or outdated yes, so definitely Account for supporting and managing these agents and it's not like ops is not doing that already, right? you're also working in cycles there is certain agility and constant maintenance of any system and it's just that you need to think of an agent as a unit to right-size the project and ensure that you are staffing for maintenance and That is one of the reasons why we also don't recommend that you try to build multiple of these autonomous agents and deploy them in parallel stabilize one agent then move on to the next and Definitely staff for maintenance Yeah, I mean the I've talked to a lot of admins this week and there's a lot of people saying well Our agent's gonna take my job and I think it's gonna make the admin even more important because they have an understanding of Systems and know who to go to to actually execute on You know building out things like an agent or you know in a journey orchestrator example you know using the tools that exist today and using those wisely to create kind of the next iteration of what the workflow or the behavior might be that you want a Team to take or in this case an autonomous agent to take so the the staffing is really important And depending on if you were to use gain site like we have a forward deployed model Which is where our team our engineers our product team is involved But if you're handling this this yourself and have an internal team in-house The ops functionality is going to be even more critical and because you'll have some more overhead on your team To manage some of the the project and the requirements gathering and keeping things Constant as you're iterating and identifying new new requirements. I Think we've got time for one more here. Where are most companies deploying agents at scale?

We I think we How do you see Atlas relating to J.O. Will J.O. Become a genteck in the future? so There are definitely plans to introduce more agentic components into J.O.

and you know so one thing the introduction of this capability into J.O. Is going to do is it's gonna also make your J.O. Program much simpler and easier to configure But then again, we talked about the additional scaffolding layer, right? You need E-vals you need guardrails and and you need a feedback loop Serving back when you are doing very dynamic interactions tens of thousands of them J.O.

With agentic nodes gets you a decent amount of the way there, but a fully autonomous agent again, there's a reason we decided to build it outside of the Jio platform is we wanted to future proof it and and Build it for reliability Right when it comes to these kinds of stochastic workflows, but yes, J.O. Will definitely Get closer to this platform, but this platform is going to have certain components that Jio will likely never have All right, that concludes this session and that concludes this year's pulse. Thanks Jake and Shantan and thank you all for attending