Ask the Cam team: live Q&A and build session

Share with

Description

Most Salesforce teams have tried AI on their own work by now. The harder question is how to hand an agent an actual ticket and get back something you can trust, without spending the time you saved checking and fixing it.

In this session, Max Vickers and Sam Youatt, engineers on the team behind Cam, the Gearset Agent, answer questions from Salesforce teams live. They also build changes that attendees suggested when they registered, from tricky flows to Jira tickets that had been sitting untouched for months.

What you’ll learn:

  • How Cam differs from Claude Code, and why that matters when you’re working in a Salesforce org.
  • How Cam handles a change to an existing feature branch, including updating a pull request that’s already open.
  • How to approach testing a flow by permission set group, and whether you need a test user in every environment.
  • What Cam can do today, and where its limits are.
  • How Cam uses credits, and how that sits alongside any Claude spend your team already has.
  • The architecture behind Cam, and what the team is building next.

Learn more:

Relevant videos:

Transcript

And thank you, Charlotte. And, yeah. Hi, everyone. My name is Max. Just wanna first and foremost thank you for joining.

A little bit about myself. I'm a sales engineer here at Gearset. So, I spend most of my week showing teams how CAM fits into how they already work. And today is gonna be a little bit different of a flavor from our usual webinars because I have a couple special guests with me, some folks who actually day to day work with CAM, build CAM.

So, Sam, James, would love to kick it over to you just for a a brief introduction, let folks know who you are.

Yeah. Thanks, Max. Happy to be here with everybody today. As Charlotte mentioned, I'm one of the software engineers here at Gearset.

I've been here about four years now. And for the past sort of eighteen months, I've been working on Gearset's new kind of AgenTek products. So I started with org intelligence and now these days working on CAM. So, yeah, excited to show you what we've been working on.

James.

Yes, Sam. And...

Yeah. Hello, everyone. I am James. I've been an engineer...

Engineering lead for the past two years. Been here for quite a while. And, yeah, I've been working with Sam on same things that he said. So, yeah, we've been working on CAM, worked on org intelligence.

Yeah. Really excited to chat to you and see what what questions you've got for us.

Absolutely. Thanks to both of you.

Yeah. So quick housekeeping. One thing to call out as we go. We want this to be interactive. So drop questions in the chat as we go.

We'll do our best. I know Charlotte, Ellis are keeping track of those on the side. And what we've kept and intentionally aligned for the second half of the session is for your questions that some of you, thankfully, sent in beforehand. We're gonna get the opportunity to talk to Sam, James, myself, and team, about, you know, some of the questions that you sent in in advance.

But we encourage you, as we walk through, some of those aspects today, any questions that come up, feel free to post those in the chat, and we'll be sure, again, to have about twenty minutes at the end today to make sure you get to talk to the CAM team and understand truly the inner workings of the platform. Now that being said, before, we get to the fun stuff and see CAM in action, I really wanted to start off today, and I believe, Charlotte, you might have a poll ready for us. So understanding, you know, AI and its involvement in how your team's development workflow goes today. A lot of times we hear from teams, you know, I work with Cloud, Copilot, ChatGPT, or something else.

And so what I want to do is just ask that everyone kinda share, you know, what's currently involved in the process today, and and that... That'll give us some good direction as far as what to capture.

And we'll give just a few more moment... Moments for those polls to close.

See Jira Robo in there. Awesome. Thanks, Igor.

We'll let this roll till about 01:15, Mark, just to give everyone, the time to response...

Respond.

Awesome. Awesome.

So I'm seeing a lot of Claude, a lot of Copilot, lot of ChatGPT, and even some some other things as well. So appreciate, again, you folks, sharing those aspects in the chat.

Absolutely. Okay. So thanks everyone, for kinda going through that. I'll go ahead, and end the poll, right now.

And long story long, essentially, you know, the results, of that poll really lines up with the questions that we get the most. So understanding that all of these things are likely currently involved in the process. Well, the question that then always follows off the back of that is in...

That you asked as we registered is if my team's already using Cloud Code or a Copilot, what does CAM actually do differently? So rather than tell you, we're gonna show you today on a real ticket. A lot of what makes CAM different isn't in the UI. It's what's happening underneath and under the hood.

So as we go, I'll take a few short tangents to show you what's going on under the hood and where there's that's a little bit different from a general purpose AI tool. Now when you folks had registered, you told us what you wanted to see. And so that small time consuming, ticket, fixing existing bugs, flow, and Apex changes, well as a lot of that impact analysis. So we'll build one ticket live with you and then show you a couple more that we ran ahead of time.

And after that, as we said, I really wanna make sure that we get to that. The floor is yours. We'll get to talk to the CAM team, and ask any other additional questions that we might have.

Now that being said, we can get straight into the fun stuff, and I will begin sharing my screen.

And this is where our first introduction to our virtual teammate, Cam, comes into play. Now you'll notice, within Cam's UI, directly integrated are my Jira projects and my Jira tickets that I am working from. We can scroll through the list down below and pick up any one of these tickets at any given point in time.

Now wanted to root this in a real example for you folks. And so I wanna pan to my ticket here, MP318. And the ticket at a base level is customer success, as we can see the Jira description here, wants to start tracking renewal readiness.

It's the kind of thing that sits in the backlog not because it's hard, but because it's truly mundane. 18 fields, three objects, and over 50 access settings to get right. And it's easy to get wrong.

This org already has a field that nobody can see because a permission got missed. One team told us a bigger job like this took them about five hours by hand and about ninety minutes when using CAM. So I've now assigned it to CAM, and on its way to planning implementation, this is where the difference between CAM and general purpose AI tools really starts to show. So while it works, let me go ahead and show you what's taking place under the hood or tell you what's taking place under the hood rather.

And can everybody still see my screen? Should be some slides now.

Awesome.

So as we think about what's taking place within cam, the first thing is truly those skills. If you've used a Claude or a Copilot on Salesforce, you've probably noticed they're a little bit better at things like Apex than at anything declarative. And that really makes sense because they've learned from huge amounts of public code, and there's far more code out there than declarative metadata. But so much of what we do in Salesforce isn't necessarily just Apex. Salesforce spent years making things declarative, so you build them by clicking in the UI. Nobody builds a flow by typing out its XML by hand, so there's very little out there for a general tool to learn from. That's where our skills come into play.

They're built in practitioner knowledge, so CAM works like an admin or developer word across flows, permission sets, tests, triggers, really the lot.

And they're built on more than ten years of Gearset doing Salesforce DevOps.

The other part is who maintains them. Teams that wire up Cloud themselves end up writing their own skills, standards files, which is definitely that right instinct. But then 10 people might have 10 different setups, 10 different versions of good, and someone has to keep them working through every Salesforce release and every model change. With CAM, that's ours and maybe even James and Sam's full time job and not yours. And if your team has its own way of doing things like naming conventions, you can add those as a standards file in your repo, and CAM follows them. If you don't, default... By default, it will use our best practices.

Secondarily, while it's planning, Cam is actually reading this org. You're naming conventions, how your metadata depends on each other, your full permission model. So the plan comes back with how it fits your org as if... As it's already built, not a generic best guess. And here's a really critical aspect.

The understanding of your org doesn't come from the AI guessing. It comes from the same dependency analysis Gearset has used for years in comparisons and deployments.

The thing that tells you you've missed a field before deployment fails, that's still deterministic. It gives the same answer every time. CAM is sitting on top of that, so the AI is working from facts about your org.

Compare that with connecting an AI tool to your org repo. That tells you what your team did, not what you've necessarily decided you should do. So it's gonna copy whatever pattern you use most, maybe even the ones you're actively trying to move away from.

This is also where that impact analysis comes from, which a few of you had asked about. Hold that thought, though, because we will see that in real, in this real example.

And lastly, where this all runs. When someone connects an AI tool to their org themselves, it access that with their permissions on their laptop with whatever that laptop can reach. Doing that safely means building a properly sandbox setup, and, honestly, most teams have it.

CAM doesn't run on anyone's laptop. It's hosted by Gearset and sandboxed, and every action it takes is locked. So there's a full audit trail.

It sits on the same security foundations as the rest of Gearset, your data and metadata encrypted in transit and at rest with twenty four seven intrusion detection. Gearset doesn't use your data to train AI models and doesn't let the AI providers we use train on it either. And nothing CAM builds skips your process. Every change still goes through your pipeline with your reviews and your sign off. So wanna give a brief pause there. I feel as though I'm stealing a bit of Sam and James' thunder as you've actually had your hands on on with this. Anything you'd add or anything that I've left out, I'd love to, you know, hear perhaps how the skills are actually built perhaps.

Yeah. Absolutely. I guess the first thing to call out is that these models do a pretty damn good job at...

As, like, general purpose agents. It's kind of in the harness in those skills that you build where you get to specialize them for certain domains. Salesforce is one of those domains where there's definitely room we found for specializing that harness and those skills. So the harness itself is how we get that context layer into CAM.

So what's present in your org, your permission data model, that's all the context layer. And then those skills, like Max said, is how you figure out what these Salesforce best practices mean to the model. Max called it out a little bit earlier that those skills need to evolve over time as the models change. If you go to, like, a newer generation of model, it might need less steering in some areas, more steering in others.

It might be that now you're using a better model, you can handle a larger task, but that requires a slightly different workflow. So when we're developing CAM, we have what we call, like, an eval suite where we're constantly testing the newest models, including, like, cheaper models because it might be...

Can get more bang for your buck with a cheaper model, but you need it to perform well. And so that's kind of what the evals are doing here. And that's work that...

It's great to have someone else do so that you can just turn cam on every day and know that the cam you're working with today is the best that you can currently get.

Absolutely.

Thank you there, Sam. And, you know, just understanding this, we wanna help contact...

Folks contextualize this as we walk through CAM. So rather than talk about it as we have been to this point and appreciate, the questions that we can see flooding in. I wanna come back to the ticket that we just assigned to Cam. And one of these key aspects that we're talking about and some of the things that are taking place on the back end is that Cam is going to come back with four questions rather than guessing anything that's going to be just introduced.

A human stays in control, and nothing changes until you've agreed to the plan. The first question being asked here. It's a really good one. The ticket says sales should be able to see these fields.

Sounds very simple, but Cam has actually spotted that our sales profile can see accounts but can't open success plans or churn risk assessments at all. So if I'd done this by hand and just set the fields to read only for sales, half of them would still be invisible. It's also noticed a sales permission set that exists in the org but not in our repo, which is exactly kind of thing that catches teams out.

And it's the recommended option, as we see here, that actually works.

The second question Cam asked. The ticket says nobody else needs access, and Cam's checking whether that includes admins. This is how fields go missing. This org already has a churn risk flag on account that a flow sets automatically, but nobody, not even admins, can see it because no one was ever given that access. We'll look at that here shortly in a minute, but for now, I'm going to go again with Cam's recommended approach.

Our third question that Cam runs by us, and I really do like this one. Cam's found the org already has leftover renewal fields on the account. They're not in our repo, and there's no data in them. Instead of quietly creating duplicates, it's asking, and I'll create the fields the ticket asked for and flag the old ones for cleanup. But that's a decision I wouldn't have even have known I needed to make had I have done this by hand.

And last, it's proposed picklist values rather than guessing silently and made them restricted so people can't add their own.

It's also checked throughout this planning, as we can see here. What else touches these fields before changing anything? One of you asked about impact analysis when you registered, and this is where that shows up. These questions are CAM's impact analysis at work. They're specific to how the org is built because before planning anything, CAM has looked at what already touches these fields, who can actually see the objects, permission sets that only exist in the org, and leftover fields nobody knew were there.

So that being said, and I've already promised this, let's take a look at what's going on under the hood.

Remember that churn risk flag that I had mentioned? Well, let's take a quick look because this is the kind of thing that cam checks under the hood. I asked org intelligence, which is ultimately the engine driving, cam here, a simple question on what references this field.

One flow uses it, as I can see here, when a customer's health score drops below a threshold. It ticks this flag so the account team can act on it.

We can also see that every profile I checked, even admin, has view access turned off.

But every profile, even admin, again, has that switched off. So I ask the next obvious question here.

Do any permission sets give access to account churn risk?

And the answer is no. No permission sets, no groups, nothing. And the flow sets it, and nobody can see it, not even those admins.

That's the same understanding of the org cam was working from when it asked me about sales and admin access a minute ago. It's why it didn't just follow the ticket to the letter. Org Intelligence lets you see it for yourself while also tracking different dependencies, permission considerations, the lot.

Now after this is done, this is the plan that Cam will have come back with. We get the opportunity to sift through this.

But notice, first and foremost, Cam is following our team standards, the naming, the description... A description on every field, how the lookups behave without me having to spell any of that out in the ticket. That's the skills and standards we talked about on the slides.

Second, the access is least privileged, and it explains every decision, who gets edit, who gets read only, and what's deliberately being left alone. And third, as we look down below, it's written down an assumption rather than hiding it. Our customer success permission set doesn't actually give access to accounts, so it's flagged that CS users need that from their profile. And it's checked that the fields will actually show up.

None of our account pages use dynamic forms, so adding the fields to the layouts will work. That's normally something you would find out after you deploy.

Now happy with that?

I move forward, and I approve.

Now once I approved, Cam is going to take everything into consideration, everything we've talked about, and actually runs the build.

If we fast forward, we can then see what cam is actually built. All 28 changes, that's 18 new fields, plus updates to two profiles, the permission set, and even seven layouts down below.

And instead of reading XML, you can actually see the change, here.

The renewal readiness section on the success plan layout highlighted in green, we get that visual representation, all the while ensuring that our code quality checks have passed. Validation against the org has succeeded with auto fix switched on at the top. So if anything with those checks flagged and comes up as an issue, it goes back to CAM to fix before it reaches me. It's also reviewed its own work. After building, it checked that every field has exactly the right access for each profile and permission set, counted the fields on every layout so nothing was missed, and matched its new lookups to how this org already sets them up.

Now, Sam, why don't you just give a brief pause there, kick it over to you? We talked about there CAM checking its own work. I'm wondering if you could, whether it's Sam, James, elaborate a little bit on what some of those deterministic checks are.

Cool. Thanks, Max. Yeah. So we do a bunch of checks in CAM to make sure that all the metadata is up to up to Salesforce's standards and your standards, of course. So we have things like using code analysis on things like Apex through things like PMD. We also do validation... The validation validation of the method for XML directly.

This is a bunch of the things we have through problem analyzers and different things in our deployment engine that we already needed to make sure that, you know, your deployments... To make sure that your deployments succeeded. So, yeah, all of our preexisting knowledge in our, like, battle hardened engine, like, we've taken a bunch of that... Those learnings and and applied them here.

And, yeah, at the end, if there is anything that is best, like, we do go through and do, another review round with the agent just to, yeah, make sure that everything is is TCTP.

Awesome. Thanks, James. Sam, anything to add there?

Nope. This has been one of James' areas of specialty. So Awesome. He's coming off better than me.

Awesome. Awesome. Awesome. Well, thanks for that, James. Really appreciate it.

Okay. So as we hop back to the story, really, the the last thing to do at this stage is raising the pull request, and that's truly just one click of the button as you can see here.

And when we raise that pull request, what we are then able to see is that this is injected directly into our pipeline. So from here, raising the poll requested, the validation has succeeded. It's up against my integration environment. And we can also see that our automated code review scan from Gearset has also passed, in which case we could dive directly into the pipeline.

And wanna bring it back out to this because as we think about involving AI and agentic, development into our workflows, it still is going to funnel through that same governed process that is Gearset, where you see all of our merge checks take place, the metadata validation, as well as those different testing pieces that may be applicable.

Now what we will have always available to us is the ability to see on the Git side and as we create a pull request from CAM, the level of description and what your reviewer ultimately gets on the pull request, a proper write up of why the change was made, what changed, and where it went beyond the ticket, like giving admins access with the reason why.

And, again, here is our change back in the pipeline sitting in integration next to everyone else's work, same checks as any other PR, no conflicts, metadata validation passed, and the automated code review found nothing.

Nothing Cam's bill... Builds is going to skip your your process. One of you asked about deployments with AI, which is obviously gonna be the focal point of today, and this is truly it. CAM does the build. Your pipeline still decides what gets deployed.

Now as we take a look here, we wanted to make sure to walk through one of those realistic tickets, with you folks live. But as we think about it, that was a pretty safe or albeit mundane change, and work can reach CAM in other ways as well. So based off of what some of you folks told us when you registered, we ran a couple more ahead of time, and one starts from something that's already broken in production and the other from a ticket that turned out to be a little bit bigger than it looked. The first ticket, as we just walked through, started with someone writing down what they wanted. A lot of time, though, work starts because something broke, and a few of you asked about fixing those existing bugs. So this one starts with an error.

Cam doesn't only wait for tickets. Down here, it's already picked up what's going wrong in production from observability.

And as we then dive into observability, this is really the full picture of every flow and Apex error in production called out on the top and actually ranked down below calling out how many people they're hitting and how often.

The top list of this list is Apex. Those matter, and Cam can fix them too.

But remember, what we said on the skill side, Apex is where those general tools are already the strongest, where teams actually get stuck are on things like flows.

So I'm gonna go down to my re... Process failed payments flow. And the reason for that is this is one that I know that I care about more than anything above it. It's one of our business critical flows. When it fails, payments that should be retired just retried, just aren't, and that's money we're not collecting. So ranking aside, this is the one I want to actually go in and fix first.

You see here. Here's the error as Salesforce reported it, the flow, the step that failed, and ultimately, the error message. Normally, that's an email sitting in someone's inbox.

Here it is, grouped, counted, and ranked.

Now while Cam goes in and and and builds this fix, let's talk about what's actually happening. Fix it from Cam gives Cam the error itself, which flow, which step, what Salesforce said. But CAM doesn't stop at this one email. It looks at every time this has happened across users and environments, so it's fixing the pattern. Not just this one failure. And at this stage, it's only investigating. Nothing gets changed until I give it that word.

Now what we can see immediately as Cam has now worked through the steps, here's what it's come back with. The error on the screen, the ultimate root cause, but then we get a really clear picture as to some of the insights as it relates to when this issue was first seen, so August 29. So it's not new.

Additionally, what we can see is within the last thirty days, the flow has logged this error 432 times across many users. So that's gonna give us the really clear picture of how many things are certainly unhandled.

But instead of guessing and giving from a vague message, Cam looked at the other errors this same flow is throwing, as you can see here. And one of them gives the game away. A required name field is missing on the same step.

When we look up to the top here, we can see ultimately how the flow works and get that level of information as well.

Its fix ultimately at... When this is all said and done is to set the name in the flow or switch the field to an auto number. And before suggesting that, it checked everything, and we can just go in and actually kick off this build directly into CAM.

So as we think about it there, we are talking about the different ways in which CAM gets work into the pipeline. And simply by utilizing and having that all encompassing view of how our production org is performing, Cam has those insights to then directly connect and introduce these fixes immediately into the pipeline.

As we get to this stage, similar to what we walked through earlier on in the conversation with our live ticket, when this work is complete, we can envision going through those same clarifying questions, approval of build plan steps, in which case we would get back once again to that opened PR where we get the analysis of what Cam has built.

Now we're opening up at the bottom of this chat, but you can see, as we scroll to the top, the conversation that got us to this point.

It started with the smallest change, just setting the name, and before building, it actually caught a problem with its own fix. The flow doesn't load payments name, so the new formula would have failed.

It adds that and leaves everything else alone and continues going through its other additional steps.

Now as we think about this at a high level, once again, all of this being done while code quality checks are being met, standards are followed.

But this is really a habit I would encourage every team to get into. The ticket's done from what I had originally tasked him with.

But I asked a follow-up question. And based off the context of the org and what you've already built, are there any other metadata adjustments you'd recommend?

Before answering, you can see that it went through, multiple steps, looked at how this org already does things, the permissions, the layouts, and the error logging subflow the other flows use, including reading a flow that uses it. Then it came back with two questions in which I gave it direction. Should payments be marked as reprocessed so the running flow doesn't create duplicates? Yes. And which team should get access? I said no access change... To changes for now.

So at this stage, it's fixed the misleading labels and made the flow safe to rerun and added error handling using that same error logging subflow rather than inventing its own.

These red paths that we're able to see visually on the side here mean every failure now gets logged instead of lost. And after renaming things, it checked. Nothing still pointed to the old names. We can dive in on a node by node basis. But as you saw within the chat perhaps, we were able to really clearly understand and point out that Cam explains the trade offs of the decision it's made. It's deliberately left out one step with the error handling.

So if marking the payment fails, the whole run rolls back. You never end up with payments that have been billed but are still marked failed. That's the kind of judgment we'd truly be looking for from someone on your team. And, again, we see the pull request validated against the environment, validated against the org, code review passed, and once again injected right back into that same pipeline.

So I wanna give a brief pause there before we go into that last, sort of example, the more complex change that grew in nature and grew in volume.

Sam, James, just as we think about the error details, how CAM identifies the root cause, is there any, inner workings or under the hood mechanics you might be able to elaborate upon?

Yeah. Absolutely. I think this is one of the cases where it starts to show off why an integrated plat...

Platform like Gearset starts to differentiate itself. We have this concept of observability anyway, which is kind of our ingestion engine for Salesforce errors that are coming in as well as hitting a number of the Salesforce governance limits in the org. And then with that information, we already do sort of trend analysis. We'll show you in a dashboard what's been going on, what...

If there's any new flows, errors, and how many people it's affecting. But then we can use that information to try and figure out the rough impact of these things and then give you this short list of things that are worth your attention. Now that's great for people already, but when that serves as, like, a source of data for Cam to pull in, it starts to feel a lot more proactive. Cam already knows about these things going on.

You can start pull these in more easily and get those fixes in faster than if it was up to someone on your team to triage and then ultimately do the fix, and it gives you kind of control and flexibility over how you want those to work in your team, whether it's one that you just want Cam to do the triage for you or whether you're happy for it to pick up those tasks and get them done as quickly as possible off your plate, really.

Awesome. Thank you so much for, providing that additional color, and greatly appreciate it.

Okay.

So now as we take a look and start to dive into our last example, the last one that we're gonna showcase today really sounds like an afternoon's work. When a success plan milestone goes overdue, tell the CSM and raise a churn risk. We go in and identify where that ticket's at. That is now going to be MP319, where once again, as we've seen a few times today, we directly feed that ticket to camp.

Now before asking us anything as we've seen before, Cam has looked and is continuing to look at how this org works, the flows on milestones, and the churn risk, and how the org currently notifies people, whether there's even a CSM field at all as well. So as we fast forward to that chat, again, going through all those appropriate steps, we can see that this investigation started at a very early stage.

Cam immediately came back with four specific questions. It recommended ticking the account's churn churn risk flag, but that's the flag nobody can see from earlier. So I said assessment only. And it caught a trap at high risk. An existing automation creates a second task so the CSM would get two notifications for every missed milestone. So I went with Medium in that regard.

But this is where it gets interesting because this is how real work goes. As we scroll down, we can see that the code quality checks have passed.

But Cam did flag that if several milestones, go overdue in the same overnight run, the account could duplicate assessments. I asked it to actually close that gap. So this is that work, the scope growing in the midst of while we're working on something. It moved the logic into Bulk Safe Apex and spotted that overnight job runs as a system user without our customer success permissions, so it designed and tested for exactly that.

You'll then notice a second follow-up that I've introduced.

So as we scroll down, I asked for more on the basis of CAM, the way the requirements really change. If it keeps happening, escalate to high, CAM found another trap. The existing task automation only fires when an assessment is created, not when it's raised. So escalations in this sense essentially would have been silent. It asked how I wanted to handle that and laid out every case in one table as you can see below.

And its own review caught one more thing, before any of this ran. The overnight job couldn't actually edit assessments it didn't own. It fixed that with a tightly scoped change and added a test to prove it. We can see the culmination of all of the thorough steps that Cam has introduced in the effort to actually introduce this PR.

As we think about this change list as well, really two bullet paints came from a new picklist value, a flow, an Apex service, a test factory, and two test classes, all following our standards, and it's already validated the pull request as we've seen be a common theme with each avenue of work within CAM with 100% code coverage. None of this was especially hard code, so to say. What made it complex was everything around it, and that's the part you want caught before you deploy, not after. So once again, we have a pull request fulfilling a 100% test coverage as you can see here and going through all of our effective gates and governance levels that our team will have to follow within the pipeline.

So that being said, we've talked a lot today, and we wanted to ensure that based off the responses we received, we showed you realistic realistic examples that really dive into some of the pains or questions that you might be having overall. Wanna first open it back up to to Sam, and James to see if they had anything to add in relation to how Cam is best positioned to assist with more complex work. But then as promised and the idea behind this entire session, we want you folks, to be able to ask the questions that you need the answers to, and we do have, some of those, from the responses generated as well. So, Sam, James, before we get to that opened up q and a, anything you'd like to add in relation to complex changes?

I think the main thing I wanted to call out around it is how that, like, saw that feedback loop of Camzone work where it can run those pull request validations where it's got those quality gates. It's in the more complex work where those start to feel really useful.

Because for smaller changes, it could be quite often that, like, it will just work first try, or it might be that you could take a look at it and be confident that it's But then as you kind of go back and forth on these large scope things, giving CAM a way to verify its own work saves you a lot of hassle, and it saves you finding all of these problems when you deploy it to a sandbox to test it and go, god, it's forgotten about this. So pushing those as far left as possible and making sure that Cam's doing those for you is, a thing we think is is pretty cool.

Awesome.

Thanks for that.

Cool, folks. Well, you know, hopefully, what we've walked through today has gotten the gears turning as far as where Cam could essentially assist as part of that development or AI workflow. And, really, that's what we wanted to show you. So we spent that first half on what Cam can do and answered a few of the questions you had sent in along the way.

But, really, the point of today is within the name. We've got two people, two experts right in front of us who built CAM. So let's open it up. Obviously, you know, I'm sure, some questions came through in in your mind as the the demonstration was being walked through, but we can also, look at the responses that were sent in ahead of time if need be.

But that being said, Charlotte, Ellis, are folks able to unmute and ask questions, or are we are we just primarily gonna be working from the chat today?

I think I can unmute people, but that... They probably need to request it in the chat. So it's up to what people prefer. We've had a few Max, we've paced one in our chat for you about multiple user stories if you want. It's quite a long question, so I won't I won't read the whole thing out.

If you wanna take that one, or we can start off with some of your questions that you have in your slide here, whichever you prefer.

Yeah. Absolutely. I think, Sam, James, if you're happy with it, I'll kinda read off the question as it goes. We can have a good conversation about this first initial one to kick us off.

And then encourage you as more ideas come to mind, send them in the chat. But then we'll also aim to tackle some of those questions that were sent in ahead of time that are on the screen. So, Sam, James, I I guess to start, question from the chat. The solution of creating fields and fixing bugs, these are very discrete changes.

But in our daily work, user stories are ambiguous and broad in requirements.

Requires a lot of context, question and answer, and things of that nature, but ultimately relies on the human or humans to get that collective answer to the question. Think teams, Slack channels, etcetera.

It also needs an agent to define, multiple development steps, AI agent to test the solution with Playwright or UI.

So I guess just in the overarching sentiment of that question, is there anything that you would add about, you know, a vague Jira ticket and what that means from a CAM perspective? Is there any limitation with vague tickets, or is that the intent behind it?

The first thing to call out is that a better defined Jira ticket is obviously is grounded, and, like, everyone wants their tickets to be better defined. But, CAM having access to the org and particularly, like, org intelligence and that observability there as well means that there's...

We've seen a higher chance of success rate from vague tickets than we have with other solutions just because you can kind of use CAM to do some of that legwork for you. You can do a little bit of that pruning yourself if you wanted to. You could go from a vague ticket to exploring a bit of the org, especially if it's bit that you're new to or if it's like a new teammate, and some of what's already in that org then can help you narrow down whether those tickets are useful or not. I mentioned in the chat to someone else that we've recently supported some MCP integrations into CAM.

So, for example, Jira and Linear. If you have tickets in those, you can kind of use the MCP to be a little bit more free form with CAM. You can kind of bring in a few, maybe explore the org that way, and then post details back to the ticket. You might even be able to do some of that, improving those ticket descriptions right there with CAM.

So, yeah, it's definitely still good to have better tickets. I think we all know that, but you could definitely use count to try and make some of your tickets... Existing tickets better.

And on the topic about how would it handle if you give it 10, a 100 user stories, There's also a flow from the assigned work view. There's the Kanban view. We didn't get to touch on a huge amount today, but you can sort of bulk assign CAM to a bunch of different tickets. The other option is that you coming out very soon, hopefully, within the next week or two, is letting CAM pick up work off the Jira backlog more autonomously. I think that's another one where it might be interesting to work with some customers on how we can tackle that problem of, like, vague ticket descriptions, and maybe there's more room here for camp to do a better job of pruning that backlog for you so you don't have to do so much of it.

And I think the only thing I'd add, that brilliant response by Sam, is when you have these, like, vague requirements, you can have a lot of back and forth of, like, there's a lot of nuance in an org. The orgs can be very old, have lots of different parts to it that you don't... Didn't even... Don't really understand how they interact. And so by having... Like, by using CAM, even at the early stages, you can really start to understand, oh, maybe a few of these things that I would have discussed for maybe ten, twenty minutes, and then a few people would have a back and forth. Actually, it's just, like, not a problem at all, and you can you can sort of sort of sort of of sort of sort of thinking that way because you have the full context of the org and sort of the changes that have been made and how everything's been structured.

Yeah. Thank you.

Awesome.

Awesome. Thank you there. One thing... So I'm just looking at the chat, to make sure we haven't missed anything in chat replies, or left anything.

Question from Joseph, on the chat here, Sam and James. Does CAM have any kind of persistent memory? If it does something that I like and I tell it to remember that, will CAM be able to remember that?

It's probably a good question for me because I've been looking at this stuff.

So at the moment, it doesn't have explicit assessment memory, but we have been trying a bunch of different approaches for this.

This is a much more challenging problem than I expected because you have things like you want people on your team to have ways of updating their agent that could be bad in the long run. And actually, like, in a team based system, you want everyone to be making PRs in a similar way. You want all the benefits to be within the team. You don't just want one person to be building all this new cool stuff, then no one else getting value from that.

And so, yeah, this is actually one of the things that I'm focusing on at the moment, and we'll have more to more to give in this in this area in the next few weeks. But, yeah, I think we're definitely more focused on making it a team based system. So I think any kind of persistent memory that we do add will be more in terms of improving the the experience of building and deploying with CAM for your team, and then the user, like, the user level interactions may come later depending on the outcome of that.

Thank you so much for that detailed response there, James.

Okay. So taking a look, I feel as though we have most of the chats answered in some capacity. I know Charlotte and Ellis are are are marking them down. So if there's anything that we miss, we'll be sure to to get the appropriate answers there.

Now as we take a look on the screen...

And, Sam, James, apologies. Gonna put you a little bit on the spot here. But one that I get asked immensely from time to time...

And we tried to showcase a lot of that today and to some of the differences of what CAM and Claude code, what those differences are. But from a base level and from your two's perspective, if if someone comes up to you and says, hey. How is CAM ultimately different from Claude code? Is there any level of detail that you might be able to provide on that topic?

I can go here.

So, yeah, I think I I think Scott did ask a sort of similar question here a bit earlier. And, yeah, I think at its core, I like to... So this is in the message, but, yeah, we're not really trying to joust or fight with Claude. We we want, like, our aim is to work with it. So we don't think they can... Like, does exactly the same things as Claude, and we don't want it to. Claude is a very generalist product trying to appease to many, many different groups and get as much market share as it possibly can in every area of of the world, which is cool. But that's not really not really our job, I guess that... So, yeah, we're more focused on, you know...

We have things like pipelines. We've done Salesforce DevOps for a long time, and as people have been using us with big big teams, small teams, different kinds of shapes and sizes of people, there are lots of different ways that people work. And, yeah, we're focused on making sure that that experience is really as as good as possible. There's always that question of things like ROI.

So even if you're using Cloud in a big team and you feel really productive, it's very difficult to actually map that to, okay. But did that actually give me PRs? Are people actually just chatting in their separate chats and then going back and forth when they actually bring it to other people and and test it? All this kind of stuff.

And in addition to that, you've got the governance layer. You know, you're... You're probably already...

We already understand how to hook up to orgs. We already understand how to hook up to your Jira instances, all of these other connections, and we already have good governance around around pipelines and all of our other products.

In addition, you know, all of our other products, as Sam Sam mentioned earlier, as they start to interlink, it's really... You can really start to feel the power when you see things like the observability hook where a flow error that's just been deployed to production can actually trigger, and Cam can say, oh, this has just occurred. Do you want me to just fix it? And, like, you ship that through the pipeline, and you can see why it failed and do root cause analysis on it. And, really, as we go through and build more and more into CAM, this will become more and more of a... Of an obvious thing.

And at the end of it all, we have, like, Salesforce expert... Expertise across all the different facets of building metadata and through all the products and how they interact. And managing all of that is even with with Claude. For this specific use case would be, yeah, a lot of a lot of extra work.

And, yeah, I think that's I think that's my main take. Sam can probably fill in some gaps.

I think that all sounds pretty good. The only thing I would add is, like James mentioned, that we constantly think of ways that we can improve this. Right? This is the worst that CAM is ever gonna be.

And as we add more of the products integrations and as we find more cases that users have told us where they want improvements, we like shipping faster, Gearset. We want you guys to ship fast with your Salesforce changes, but we like shipping fast as well. It's fun. So we love all this customer feedback, and we just enjoy making this product better and better.

And it puts a smile on our face every time it does a cool thing that we didn't think it was gonna be able to do last week.

Awesome. Thanks to both of you. Okay. So we have some more questions here. We have about eleven minutes.

So what I wanna do is kind of steal the ball here for a second. I wanna definitely talk about number two, because that's a question that comes up a lot. So does Cam use credits separately from clogged credits? So I'll address that shortly.

But what I would encourage you, just to ensure that we get to what's most important to you folks, if we could take a look on the remaining questions on the screen, so three through six. As I talk through, you know, how CAM and credits ultimately work, could folks just post in the chat which question that's currently on the screen is maybe most pertinent to them? And then we'll aim for that to be the the last question that we answer and ultimately, cover it.

Sound good?

K.

That being said, want to address question two here, pretty specifically. So as we think about CAM, its credits, and the usage of Cloud credits, ultimately, CAM runs on Gearset AI credits that come with your agent license. So it's separate from any cloud subscription that you may have. Today, you can't bring your own tokens. Each seat adds a monthly allowance to a pool the whole team shares, and it resets on the first.

You can see exactly where it's going in the usage dashboard under some of your configuration of the agent. And if a team does use it all, access just pauses until it resets. There are no surprise charges, and you'll see a usage bar in the chat once you pass 80%. And with the latest update, in our testing cam uses two to three times fewer credits per task for the specifics of your team's allowance. Your account team can walk you through it. So just some some additional information as it pertains to the CAM credits conversation.

Okay. Okay. And it looks like we have two questions that are gonna be important to us.

Joseph did get it in first, so I must say, and it looks like we have a secondary point to number five. So, Sam, James, can Cam add changes to an existing feature branch and update its open PR?

Any color you can add there?

The short answer is yes. You can add changes to an existing feature branch.

Yeah. Yeah. It just it just works.

At least... Yeah. I'm pretty I'm pretty sure.

Yeah. That's it.

Slowly longer answer on that There you go.

As well is that there are more ideas we have for this area in terms of flexibility. And at the moment, my cam is fairly railroaded towards making, like, one PR, and that's great. And we've heard from a couple customers that they wanted to work on maybe multiple at a time or potentially work on work that is already in flight. So we're currently having a think about how Cam can be more flexible in those ways. So maybe let you bring in a branch halfway through a chat, or maybe you want to expand to a second branch in the same chat. So that's an area that we're actively working on at the moment. So if any of you are existing customers and want to give us feedback on those things, we would love to have a chat with you about those.

Absolutely. No. Thanks to the both of you. And I know we have some functionality that we've released around, including unreleased changes and things like that as we're committing. So, definitely, you know, from talking to to our experts here, definitely something that's, possible in coming down, the pipe and being refined. But, that provided the clarity you folks needed.

Okay. We do have seven minutes, and I said pick one. But, Brett, sign up question, I feel like we we must accommodate that. So let's definitely tackle that as well. And I know, Sam, James, not to put you on the spot, we've talked a little bit about what makes CAM ultimately different.

But, ultimately, if you speak about the architecture behind CAM and, you know, thinking about what's coming next. Now I know we can't promise anything road map wise, but from your experience, from your hands on with the tool every day, some things that we're maybe considering moving forward. If we could just give, Brett a little bit of insight as what the overall architecture, looks like from that perspective, as well as maybe some things we're thinking about, I think that would be a really great way to to wrap out today.

Yeah. Absolutely. Don't worry about putting us on the spot here, Max. That's that's the count team. It's in the name. Yeah.

So in terms of the architecture, there's kind of a few different pieces to this.

I suppose we'll start from what it looks like happens when you press send on, like, your first prompt in a chat. The first thing to call out, like Max said, is that each of these chats is kind of running sandbox from each other.

There's a couple of advantages to that. The first one is it means that we can host more chats more flexibly for people. We can kind of scale up and down to demands we need. But the other nice part is that it's not running, like, on your computer, which is good because means it that you don't have to serve your dev environment again.

I don't like setting up my dev environment when I get a new computer. So running those in the cloud is nice. It means that they can work in the background. You can have multiple working at once, and you don't really feel any of those constraints.

The second part of all of this, I suppose, the next layer is the harness itself. We have, like, our own harness. We're not really using any off the shelf ones. The main reasons for that is that it gives us more flexibility and power in terms of how we integrate with the rest of Gearset.

Gearset's a product that's already filled with really cool features and functionality, and a lot of these off the shelf harnesses don't have a nice way of working with all of that. So making our own harness kind of means that we can. We can bring in these kind of different life cycle things that happen, like the quality gates that run event at the end of every turn, whether that be things like PMD analysis, or that pull request validation loop. Those are things that are in Gearset that are much easier for us to plug in if we have our own harness.

The other one is it gives us more flexibility in terms of how we run the models and which models, how we route to the right models.

So it means that if a new model comes out and it's great, we can switch to a little bit more easily. We can optimize them more easily.

We can control how they kinda communicate with each other. A lot of the way that we've designed the harness is to try and make it as flexible as possible for us to bring in more functionality. Because when you give the agent more tools and you give it more context, you get a lot of, kind of emergent behaviors that are quite nice. And the more interconnected everything starts to become, the more powerful it almost always seems to become. So the harness that we developed is basically entirely around doing that and making it easy to plug in as many bits of Gearset as possible where it's useful.

Awesome.

Awesome. Awesome. Awesome. Thanks for that detailed response there, Sam.

So, folks, obviously, Ellis is posted. We have a a a few more minutes here, so so happy to answer any final questions as we wrap. But by and large, that's what we wanted to cover today. And we really appreciate you spending an hour with us and wanna extend from our team's perspective as well. Thanks to Sam and James for joining.

That being said, if you'd like to see Cam on one of your own tickets and things of that nature, we encourage you to set up a meeting with us, and we can walk through in a little bit more detail and maybe a little bit more specific to you and your day in the life, you know, what Cam could ultimately empower within your DevOps process. So save for any more questions. Once again, thank you everyone for joining. Thank you, Sam and James, for being here, and appreciate the good conversation today.

Thank you, everyone.

Thanks, guys.