Description
Agents are quickly becoming a key part of how we do business. But how can we include them in our source control? This session demystifies Agentforce DevOps and will empower you to get Agents into your source control.
Mike Reynolds – Sr Technical Product Marketing Manager, Salesforce. Mike is a tenured Salesforce professional with 20+ certifications. He lives in Chicago with his kids and cats.
Transcript
It's supposed to start three minutes ago, so we're good. Oh, hey look, it's, DevOps at Agent Force or DevOps and Agent Force.
All right. You all ready to go?
Okay. Good deal.
I do. It is just me between you and Happy Hour. I should go faster.
So my name is Mike Reynolds and I work for Salesforce, specifically Slack which I know you're all thinking Slack and DevOps obviously, right? So thank you for carrying along with me.
I actually do wanna start with gratitude. Events like this would be terrible if it were not for the people who make them great which is you. So, thank you very much. I appreciate that you are trying to make yourself more knowledgeable and then going back into your company and then making your company better because that's really what it's all about.
Wouldn't be a Salesforce presentation if I didn't say please don't make any purchasing decisions based on anything that I will demo in a little bit because that is not generally available. Please make all of your purchasing decisions based on general available products and features. Okay, so I sat down and I said, okay, well, if we're gonna figure out agent metadata, what makes it good? Because I could just say, look, there's like three folders.
We're gonna track everything that's in those folders. There you go. Boom. Done. Thanks for attending my TED Talk.
Go to the happy hour. But that's gonna miss the point because really the people that are truly exceptional at DevOps in the Salesforce space, what makes them exceptional is they know where everything is. So what we're gonna do is actually get into the metadata, talk about what's in it so that you know where's the setting that does this? You'll know where it is.
We're gonna talk about dependencies and then we're gonna talk about employee agents because they're the best agents. And I'm not saying that just because I work for Slack and all your employee agents should live in Slack. I'm saying that because employee agents are in Slack and I think Slack's super cool.
You're supposed to laugh at my jokes.
Okay, thank you. Appreciate that. All right, Agent Force. You all know what Agent Force is, I'm not gonna talk about this. What I do wanna do is bring you to the screen on the left.
For the most part, we're dealing with three buckets of metadata.
I've got an agent, Agents have topics. Topics have actions.
If it were that easy, it would be great.
It's almost that easy, right?
We do start out with the agent. The agent is really pretty simple, right? Of course, it's not called agent.
The folder we're gonna track is called GenAI planners, right? And it's the top of the pyramid, right, when you look at the dependency but it's also the simplest, right? So, if this is a legit file, I didn't have to trim any of this to get it in the screenshot. So this is the whole thing.
Of note, you've got a description, pretty straightforward. And then immediately I reference Gen AI functions.
Well guess what? That's a topic.
And then I get all the way down to Gen AI Plugins and guess what? Those are actions. And so at the top level, my agent is directly referencing a topic and an action.
Even though we don't add actions to agents, we add actions to topics and topics to agents, guess what? It shows up here in the metadata. So, am I deploying these things piecemeal?
Probably not, right? You're gonna wanna package when you go deploying anything agentic.
Also, bring it all the way down to the bottom, the planner type. Fun fact about AI Copilot React, that's what all of them are. Maybe there'll be something new, but right now that's literally the only acceptable value.
So the next one, Gen AI Plugins. This is where it starts to get fun.
So the Gen AI Plugins is gonna be your topic. Topics of course contain actions, right? So I should expect to see some references in that. But there's a whole lot more inside a topic than what's inside an agent, right. Like when we looked at the agent metadata, the agent metadata is really pretty boring. It just references other stuff. There's nothing interesting here, right.
But Gen AI Plugins on the other hand, there's all sorts of stuff in here, right? Now, I did trim this file down to get it to fit on the page.
You've got an utterance, right? The utterance is actually when you're building your topic, you get to say, well, an example of this would be this, right? So you would use this topic when the user says this. That's an utterance and it lives right here. That is its structure. They'll all be like that.
You've got can escalate.
So does this agent have the ability to actually hand this conversation off that's controlled by that Boolean? It's got a description, a dev name, that makes sense. Then you've got JIT and AI functions, those are our actions, we'll get to those in a minute.
And then down you've got instructions.
Now instructions we all understand, I can give you an instruction, you would have lots of these. These are the statements that generally speaking, I wanna always start out with the word always or never, right?
And any of your early agents use a lot of always statements and a lot of never statements. That's gonna get you really far. And then down at the bottom, language, a label, and a plugin type. This one is clear that it's a topic. And then the scope is defined here, right, because scope is too topic.
So pretty straightforward still and then it gets more Salesforcey. So Gen AI functions, right? The Gen AI function is gonna be your action, is more complex.
This, I want you to think about it in the same way that you think about deploying a lightning web component. This is a bundle.
I will never ever push this without its bundle, just push the bundle, okay? So the first thing is, it's not a single file, right? We have a file with two folders, each containing a file and then a meta. And it is this bundle that makes the action.
Well, why does it work that way? Well, if you think about the screen, right? I like to think of the screen and then try to figure out what the screen lined up to and the actual metadata.
You have this bit at the top of the action, so I kinda set its name and what it does. And then you've got a column on the left, it's all your inputs, and a column on the right, it's all your outputs. That's essentially what we're looking at here. I have an input section, an output section, and then I have the bit at the top which is gonna be in the meta file.
So let's look at the meta file. It's pretty straightforward, very boring, right. Nothing here is particularly interesting. Although, you do have that process indicator message and whether or not it's is include in process indicator, right?
That is, is there literally a message being displayed in the log in the middle of what's happening? Do I post a message there? If it is, it's that message, right? So, that's where this is.
Otherwise, this is a really boring file. When you get into these schema files, this is where it gets a little entertaining.
If you think about that screen where you say, here's the input for this action and then how you control that input, you give each input what? A title, a description, it has a type, you can specify PII, and then if we are requiring the end user to provide us with that data, right? That's all specified per item and then essentially your input and output files look the same.
What I would like to draw your attention to is this little line right there. Lightning is PII. Anybody ever seen this before?
So, you can specify this in code. I can do it right here. I can type on this. I can change that to true.
Anyone know where that's located in the UI?
I made people uncomfortable by asking that question.
It's not. So, best I can tell, if everyone, and I mean everyone, went through and actually used field metadata and specified the simple things like, yeah, this field, it holds PII, then we could trust you. But you people don't do that, right? So, we basically had to teach agents how to identify it on their own. In code, you can be explicit.
You can be like, hey, this is PII. I want you to treat it as PII. I want you to be careful with that, which brings me to this very important point. You have to get it right.
Don't rely on the agent. The agent is going to look at it and then decide is this PII or not, which means set up your permissions well. Don't give the agent access to something that you don't think the agent should have access to, right? That's simple to say, maybe a little bit more complex to do. So square out your permissions.
Before I go any farther, does anyone have a question about the agents in the code? Yeah.
Yeah. So, it's a really good question.
The way that I would think about this is the same way that we think about it for any other human user, right?
But I can treat agents like modules or blocks of code. But I still wanna think about their access in the same way that I would if you were a real person and I was teaching you to do a function. So, if you're a real person and I'm going to teach you how to, let's say your only job is to manage everybody's branches because nobody does that well, right? Everybody names them the wrong thing and, oh, you know what?
Also, nobody updates their stories in Asana or in Jira. So your job is gonna be to go into Asana and every time a story is created and added to a sprint, I want you to create a channel in Slack. And then I want you to summarize the work to be done and put that in a canvas. And And then I want you to add the project manager, the BA, and the QA and the dev.
I want you to put them in the channel. And then, I want you to build a branch and make sure that everybody has access to the branch, right? And then maybe merge that branch at the right time for the QA engineer, stuff like that. Just like the stuff that nobody actually wants to do that we all do kind of poorly unless you have somebody literally standing there going, no, no, no, no, we have a git ignore, you can't push that file, right?
I teach you to do that. I can build a very, very narrow set of access for you.
And in that example I just gave, no Salesforce access is needed except for the Apex that is gonna run the thing.
So we wanna think about the jobs to be done and design access to the specific jobs to be done even though I might only give that access to one user which is the user that is my agent.
That's the right way to do it. We previously would not have thought about it that way. We probably wouldn't have said, well, I'm not gonna build a permission set for one thing.
But here we really do, we wanna do that.
Does that help?
Cool.
All right, so big dependencies, clearly we can reference all sorts of different things. You can reference Apex classes and then you can open tickets with support and say that agent force is broken because there's a whole action that's missing only to have one of your colleagues point out that you forgot to put the Apex in the permission set, right? So check the permissions. That totally didn't happen to me by the way this morning, that was yesterday.
Connections, connections is a big one. You will add your connections. Essentially, where am I going to deploy this agent? You do all that later, right? It's not in the metadata that you can access or control today. So remember, you're doing that as a post deployment step.
Anybody thought about the bring your own LLM?
You're always gonna bring it, right? You're not actually deploying that into your environment. When you think about LLMs, I have a model that's super cool, uses a hugging face LLM.
That model's like thirteen point five gigabytes. I'm not putting that model in my Salesforce instance that is the worst place on earth to put it, right? We're gonna access that model through Salesforce using Apex, using named credentials, those types of things we already know how to track that, right?
Follow all the best practices you already have. This is really straightforward, right? Don't think that it's different just because it's an agent. You still have to test the thing. You still have to work with it. Follow your regular processes. We put those in place for a reason, right?
I think get everything turned on before you deploy.
You can get the code that will be produced by turning these features on and you can put it in your source control. I will show you why we didn't spend a lot of time talking about that, but you can do it. Don't, just go turn the features on then manage your deployment.
And then we talked about this before, the PII line, you can specify if you are writing your YAML because you've got open API, you can actually specify PII is true. This is the other time and place that you can actually do this. If you don't know what this means, don't worry about it.
All right, employee agents.
So, employee agents are the greatest agents because they're in Slack. But before we get there, does anyone not have Agent Force in their own developer edition?
Then scan the QR code.
So, I would encourage you to use this. I would also encourage you to go to slack. Dev and sign up for the developer program. When you sign up for the developer program, you get an enterprise grid issue of Slack and you can have sandboxes in Slack.
I say that and sometimes people are like, you can have sandboxes in Slack? Yeah, it's enterprise technology. Of course, we have sandboxes, right? So, if you actually wanna build it and test it and see if you can do it, it's free.
Well, no, for testing, you can play. You can join slack. Dev and you get an enterprise grid for free. And the enterprise grid comes with, like if you personally, you can sign up for this and then you get all the slack you want, right?
And Slack is free until you want features beyond the basics and then you have to pay for it, right? But sign up for that, it's well worth it. The three things I would point to you on Trailhead, we just started getting Slack modules on Trailhead. I'm personally really jazzed about this.
I would go check these out, specifically the one that talks about how to actually connect your agent force in your Slack. It's good, it explains everything. It's a bit of a process right now. By the end of the summer, we've literally got a button.
You click the button, they're all connected.
So if you wanna go through it now, you can, but by the end of the summer, done.
And then there's a ton of reasons, right? There's a lot of reasons and I think the biggest one and the one that matters the most is that in Salesforce land, I ignore a lot of employees because you're not a Salesforce user, right? My entire HR team, sorry.
I don't want your data, I don't want your problems, I don't want any of your stuff. You are an absolute risk to me. But in Slack, Yeah, absolutely I want you. Because I can build an integration that makes no sense for Salesforce, but makes a lot of sense for Slack.
Like you need to request PTO? I can give you a button for that. You need to ask HR something? You have a benefits question?
Cool, I can connect you with those people.
Slack fits in this neat little spot where all of the people that served around my Salesforce org. I can actually interact with them in a meaningful way. My favorite example of this is with a finance team. I always had, I had a huge team and we sent emails to finance and those emails lived in a queue.
I can eliminate that entire process by having my finance team use Slack, having my Salesforce team use Slack, having the record in Slack, and having functions in Slack that helps finance do their job. And all of a sudden everybody's happy. And we're all working together, we're actually collaborating. So I can do a whole lot more when I consider Slack as a tool that's in my tool belt, right?
So I can actually show you some of this.
This is a Git repo that is definitely not gonna be interesting at all to anybody unless the agent that I described a minute ago, the agent that manages your entire git processes and then manages your Asana processes so that it kind of just does everything for you.
Don't look at that, it's not worth it. It's not open source and just totally sitting there, right?
Okay, so, let's look at Slack.
So everybody's seen this, right? It's very straightforward, it's Slack, it's fun, it's great. I can talk to this agent, right? And the agent will tell me things, right? If I asked it about Tableau for some reason.
And the agent will come back and it will tell me, well, here's some information about this. And if this is my Datanet account, it makes sense that I would have some collaboration happening but this sort of misses the boat, right? I'm still looking at Salesforce to be able to facilitate this. And so, instead of going to Salesforce and swivel sharing, what I really wanna do is just put my Salesforce right here. Because when I put my Salesforce here, all of a sudden now my agent makes a lot of sense.
Because this conversation and the collaboration is happening directly on my record. And of course, I can make this flip the other way, right? You don't necessarily need to display chatter, I could display Slack there, right? This is all GA this summer, right?
This is called Salesforce Channels and it just gives you the ability to put your Salesforce over here. So now when I'm going to do things, if I need to edit this record, I can edit the record. Or if I needed to add, I forgot a contact role on this, we'll just go pop a contact role in. They're not an influencer, they're a technical evaluator.
I forget their name, maybe it was Maria or something. Mark, yeah, definitely, need to add Mark.
The ability to do everything that we could do in Salesforce, I can do in Slack. And when we think about what can I do, what can I build if I actually don't have to swivel chair?
If my finance team has a concern with this account, with this opportunity, we can all look at it even if they're not in Salesforce because they're here. And I can let them see this. They don't need to edit it, but they can see it. And now all of a sudden, we can actually have a meaningful, informed, collaborative experience even though they're not Salesforce users.
There's no me exporting a report that just has the one thing in it so that they can see it. I can literally just put it here and then they can see it and we can do stuff, right? And then you can build agents that are managing a ton of things for you that I don't want to do so that I can spend time doing the stuff I do want to do. This is the vision for an employee agent.
It's the idea that I can bring the agent and the Salesforce and then the non Salesforce users in one spot so that we can all get work done.
This to me blows my mind. This is like the greatest thing I've seen since before SafeFlow.
I think there's a hand back.
This is using CRM based data.
So, very forward looking statement. I can get that Data Cloud data and get it to appear here. The big concern there is how I build the UI because I'm relying on Salesforce to give me a lot of the structure.
So, I have to, that's kind of like a product gap that we have to figure out but that is on our roadmap. It's to be able to display as a blend and I mean, and you can do it. You can do it today because you can create your own Bolt solutions. So I can create a completely custom based code based application that is going in using data cloud, pulling everything in.
So you could do it today, but it wouldn't be as easy as setting this up. This gets, I mean, this is really easy to set. So there's that. That is it.
That is my whole presentation. But we do have time, I have just a few minutes for questions if anybody else has questions.
And I can't see hands because these light those two lights are like right.
Yeah.
Yeah, like barely.
I got you.
So I have the ability to limit what you can do because I know who you are and I know what you can do in Salesforce and I can harmonize those. Actually, I can't unharmonize them.
So if you're restricted from seeing a data point in Salesforce, I can make it so that you do not see the data point in Slack even if I in the same view can see that data point. Because I'm using the same architecture, the same rules, the same structure, the same everything.
I can also choose to configure a guest user access using the model that I have for experience and take the exact same thing and move it over, right? So we, like I can use the established rules and structures and bring them in to Salesforce channels. Yes user you.
Correct, yeah, right. And then of course I could have multiple of those, right? Because there is the idea of a guest user that is in finance that I might have a certain set of access for. That would be very different from the guest user that is, I don't know, in some other team, right, in a warehousing team. That they're looking at transactional stuff or they're being alerted that something has happened. That's one of the demos that I think is really fun is where I have a warehouse person who's trying to manage literally I have pallets of stuff.
They're managing requests for incoming and outgoing movement of things without a Salesforce license.
Because what they're working on is in their inventory management system. But the impacts of what they do in Slack, interacting through the API with their inventory management system, is then through agents going back into Salesforce and updating Salesforce information in real time. And so Slack replaces the inventory management UI.
Keep all the functions, but then bringing agents in, I now get to go back to Salesforce.
And so I can eliminate one of the big hurdles and then I can also bring in other people into the conversation and then we're all collaborating.
But only the person with the right access gets to change things in the IMS, right? And that's a real use case by a very large bookseller, right? Where they manage that type of complexity in a really easy way where they're collaborating about it, right? Because if you get a pallet of an item that needs to get split and they're trying to figure out where that went, the inventory management system's like, yeah, here's a pallet, it's got five fifty books on it. I need seventy two there, I need forty seven there, I need this many there.
Like that gets tricky unless you really simplify it, which we can do as well.
Also, that was excellent timing on my laptop battery dying.
It's brilliant. So that is it. I was in the way between you and happy hour so I can be done.
Thank you all much.
I can hang around and ask a couple of questions.
