Agentic AI with Vercel: Saltbox One
Chapters15
Introduces the session, how to participate, and what to expect from the guest and topics.
Saltbox One demonstrates agentic AI on Vercel, using AI SDK v6, the AI gateway, and sandboxed deploys to tame Salesforce with live, auditable user-driven actions.
Summary
Shane Smith of Saltbox Management shares how Saltbox One runs on Vercel to deliver an agentic AI experience for Salesforce customers. The architecture stacks a Next.js frontend with edge/server capabilities, an AI SDK (v6) to manage the agent loop, and an agnostic AI gateway to plug in models as needed. A core insight is that Saltbox deliberately avoids locking into a single model, instead routing based on question complexity to the right processor. The session highlights the power of the Verscell sandbox for ephemeral, browser-based development and Salesforce CLI deployments, enabling real-time interactions and background tasks. Saltbox also emphasizes user-based permissions for actions, with an extra Salesforce-specific approval layer to keep changes auditable. The demo showcases concrete use cases like building a Salesforce screen flow, generating user stories from meetings, and producing architectural reviews with mermaid diagrams. Finally, Shane reflects on best practices and four key learnings: leverage a gateway, streaming alone isn’t enough, use sandboxes for real deployments, and choose the right platform to focus on product features rather than infrastructure.
Key Takeaways
- Use a gateway to plug in multiple models; Saltbox’s setup routes tasks to the most suitable model for the job rather than locking to one option.
- Saltbox One supports streaming responses and persistent background tasks, enabling both real-time interaction and long-running workflows (e.g., B2B storefront setup) in Salesforce.
- Sandboxing is central: Saltbox uses Verscell sandboxes and the Salesforce CLI to deploy and validate changes in isolated environments, plus an in-memory sandbox per conversation for file handling.
- Saltbox combines Vercel, the AI gateway, and VZero context to generate code (Apex, LWC, flows) and maintain a seamless, contextual agent experience across Salesforce and Confluence/Jira workflows.
- Actions are auditable and user-based: changes are performed under the user’s identity with optional read/write toggles in Salesforce, plus human-in-the-loop approval screens.
- Pricing is still evolving, but Saltbox is starting with a user-seat model with usage limits, anticipating token-based adjustments as needs scale.
- Key architecture lessons include careful model routing, model-agnostic design, and leveraging platform capabilities (sandboxing, context passing) to keep the focus on product features.
Who Is This For?
Senior Salesforce developers, platform engineers, and product teams exploring agentic AI on Vercel who want practical patterns for model routing, sandbox-based deployments, and auditable actions.
Notable Quotes
""use a gateway. Stop arguing about those models. Start choosing the right models for the right tool and the right occasion.""
—Saltbox argues for model-agnostic routing via the gateway to maximize flexibility.
""Streaming is just the start. But really you need kind of that persistent background running capability as well.""
—Real-time feedback is important, but long-running tasks must persist beyond the initial reply.
""The two official tools is when you're spinning up a scratch or we always spin up a Verscell sandbox and we spin up that scratch or using the SF CLI.""
—Demonstrates how sandboxing and the Salesforce CLI are used together for deployments.
""We are still in the process of finalizing [pricing]… user-based seating with limits on conversations and data interactions.""
—Pricing model under discussion, starting with per-user seats.
""If you want to follow up or learn more about Saltbox, LinkedIn is the best route for me.""
—Call to action for audience engagement and follow-up.
Questions This Video Answers
- How does Saltbox One route complex Salesforce questions to the right AI model?
- What are the best practices for sandbox-based deployments with Verscell and Salesforce CLI?
- What does a typical agentic Salesforce workflow look like, from meeting notes to user stories?
- How can I implement auditable, user-based permissions for AI-driven actions in Salesforce?
- What pricing models are viable for agentic AI platforms on Vercel in enterprise environments?
Saltbox OneVercelAI SDKAI gatewaySalesforce automationSandboxingSalesforce CLIConfluence/Jira integrationMermaid diagramsApex and LWC generation
Full Transcript
Hi, welcome everyone to another Verscell community session. Uh my name is Jacob Paris. I'll be your host today. We do these sessions to highlight cool projects from community, from customers, and just anyone building cool stuff on Versel. Uh we're streaming this live2x and LinkedIn, but if you want to participate in the chat, come to community.comlive and you'll be able to see the session at the top of the page. At the end, we'll have some time for questions and answers. So feel free to drop any questions in the live chat along the way. I'd like to introduce our guest.
We have Shane Smith from Saltbox Management. Hi. Hey Shane. How you doing today? Doing great. How are you doing? I'm doing pretty well there. Um, yeah. So, you've uh you've got a demo for us. Do I've got some uh some content to walk through and a little bit of context and then a live demo at the end. Awesome. Uh I can help you share your screen here if you'd like to get started. Sounds perfect. Okay, as that's pulling up, I'll just start with a quick background here. Uh so my name as uh Jacob said is Shane Smith.
I'm the CTO at Saltbox Management. Uh Saltbox is a services firm. We actually spend uh most of our time implementing Salesforce technologies for our customers and over the last couple of years we have been building a product for ourselves and as we've been doing that we are uh going to the point where we're starting to roll it out into our customers and to the world of larger uh standpoint. So today I'm going to be talking about how we did that uh specifically with uh Forcel and some of the the different technologies that Forcell uh gives us.
As you kind of see on the screen here, we're going to be talking about the AI gateway as well. So getting a little bit into uh the problem statement here, we have a set of customers who uh are using Salesforce and especially in this agentic world uh these users are wanting to engage with Salesforce in a more natural uh natural language way. And so on the first uh use case here, the problem statement we're trying to solve is for the business users. They want to be able to talk to their ecosystem of Salesforce products with plain language and really get uh through the the questions they have quicker.
And on the second one, we are trying to solve for the builders, the people who are actually configuring and building customizations inside of Salesforce, which largely is us. That's where we started on this journey is we wanted to make building inside of Salesforce easier uh with agents. And so those are the two problem statements that we're trying to solve for ourselves and for our users. And the the context behind this is you know doing this is actually pretty challenging. I mean it's why people hire services firms like us and others uh because understanding the context of Salesforce understanding the company and the the context of what project they're trying to do uh and trying to move that into a production uh scalable code with best practices is really difficult.
And so you can't just go out onto you know any LLM and just ask a question about Salesforce. it probably will get you something but it won't get you something that is production ready. And so that that was the uh the goal that we were trying to achieve. So as we're going down this path, you know, we have a relatively small product team that we're trying to build this pretty ambitious product. And so we wanted to focus on the product and not so much on the infrastructure. We wanted the infrastructure to just work and give us the capabilities we need.
Uh and so that's that was kind of our challenge and our bet was that we could uh build this uh scalable platform on the Verscell uh infrastructure and enable us to to go and do that. So I'm going to talk a little bit about how we actually manage to do that. We kind of have three levels uh when it comes to kind of our highle architecture. At the very top level we've got an Nex.js JS application um that sits in the kind of the forward- facing UI uh capability and that has you know all the the normal streaming uh UI capabilities you would expect in an agent uh in this day and age and then the second layer of that we have our you know edge and server uh capability here we use the AI SDK uh specifically version six now uh to control the agent and have the agentic loop and uh all the tooling that is built built into that.
Uh if you're not familiar with this SDK and you're getting into the agent world, I'd highly recommend going in uh using that. It gives you the ability to uh use any LLM uh across the board kind of agnostically and provides kind of the framework and scaffolding you need to uh build the agent loop and and really give it some powerful tools uh through that process. And the third layer here is the actual AI. So plugging into whatever model we want and that was really what we were uh deciding when we first uh went down this path is we wanted to understand you know what was the right model to use and our verdict was that there isn't always one right model to use in every situation.
And so we wanted to build it in a way that is agnostic that we could plug and play the right model for the right situation as uh new models come out plug those in as well without uh huge uh scaffolding changes behind the scenes. Uh so we chose the AI uh gateway for that and I'll talk a little more about that in a moment. Then we have kind of our our background or backing services as you can kind of see at the bottom that support the rest of the infrastructure. So kind of going into the AI gateway a little bit more here.
You can kind of see on the lefth hand side is just a pseudo skip script here of you know what this would look like. But you essentially have one line that says I'm going to plug into the gateway and once you have that you have the gateway and you can essentially use whatever model you'd like. Uh so in a lot of cases we use opus 4.6 fix, but in some cases we use sonnet and uh you know GPTs and some gro in in different situations. And that's really one of the powerful things about the gateway is that you can use whatever model you want.
You're not locked in. You're able to have that flexibility. And what this allowed us to do is have some pretty uh intuitive based routing here around complexity and types of questions. And so we have this classifier in here that allows us to determine, you know, how complex is that question the user is asking. Are they asking for a simple response to a hello message or are they asking something more complex like trying to build an entire flow for the user? Depending on that, we might route it to different models. And that allows us to uh have fast responses, choose the right uh level of complexity on the model we we provide it and give the right response to the user.
And you know in today's age uh kind of around the experience on the agent there's really two different capabilities that most users expect nowadays and that is something that's streaming back to the user. So you can see what's happening in real time but also what actually happens when you have a really complex request that might take more than a couple of minutes or tens of minutes or hours. And so where we started out from a product perspective is on the streaming side. So that's really where AIS SDK shines. You know, it starts kind of on the streaming side.
On the left hand side, you can kind of see a sample question here. Generate user stories from a meeting. That was one of our uh first use cases as we were building this tool is is taking all the context and providing user stories for our developers. But as we started to get into more complex requirements like spinning up an entire B2B storefront in Salesforce or designing an experience cloud site with custom pages, those take quite a bit longer than a few minutes uh that can be streamed to a browser. And so as we started to mature in the Verscell platform, we started to have this single experience that the user has in the UI but be able to both stream and spin up background processes depending on the complexity.
And that's all supported inside of the Verscell infrastructure uh both on the actual platform itself, but also using some capabilities around sandboxes and and a few others that I'll talk about in a moment. So from a tool perspective, you know, this is I think one of the superpowers of using something like AI SDK is you you have uh really just a framework that you can plug into. So we started out with just a few tools and then over time have uh built more and more tools in these categories that allow us to really have hands to interact with the user and uh and Salesforce environments as well.
So you can kind of see we've got uh document generation, we've got search, we've got stories, integrations and uh primarily this Salesforce uh capability here which allows us to understand the environment, validate it, query it and make deployments into uh those environments as well. Uh so really brings to life this agent uh outside of just going straight to an LLM. So getting into kind of the the agent has hands, right? How does that actually work? Well, inside of uh the Verscell ecosystem, this is actually one of the the newer capabilities that they've been rolling out is this ability to have a sandbox.
So if you think about uh you know if you're familiar with Salesforce and you think about how do you interact with Salesforce a lot of times developers and kind of the technical side of the house they will use Salesforce's CLI and that allows them to at a terminal level interact with Salesforce spin up uh sandboxes spin up uh B2B commerce storefronts do deployments and that makes it really easy to interact with Salesforce but that's really difficult in an ephemeral browser right you log into uh just any site and you have to log in every single time and it makes it difficult to interact with Salesforce.
And so we uh started to leverage this Purcell sandbox capability where we could actually allow the user to authenticate to their environment, spin up a sandbox that allow would allow us to actually interact with a file system uh and would allow us to actually deploy our uh code that we're making or files that we're trying to do into that sandbox and then use the SS CLI in that sandbox to push uh those files into Salesforce. uh and this is maybe a use case specifically in the Salesforce ecosystem because they have these uh these concepts of scratch orgs and uh sandboxes but I think as we get more and more into kind of the coding side of the agentic ecosystem this idea behind sandboxes is absolutely critical because it requires uh or it provides us the ability to have this file structure that uh you know agents and LLMs are traditionally built on.
So I think it's it gives you a lot of flexibility uh when it comes to uh what you actually can do. And then kind of uh wrapping up kind of the pillars here that we have been building on. Uh Vzero is has been a a huge uh capability for our team, right? We we actually use it on two different sides. We use it from a product perspective as we're building our product Softbox one, but we also use it as a services side when we were building uh Salesforce. And so what we've actually done is we've plugged the two of them together where if you're in S1 and you have the context of what you're trying to do, you have all the Salesforce information, uh you have the ability to actually go and gather all that about your Salesforce or we have a tightly coupled integration with Vzero where you actually can pass over that information uh to VZ as context and that allows Vzero to actually help you generate code.
Uh so it's not just for React but uh given the right context and the information there you can do things like Apex and LWC's and flows and so we've been able to kind of couple those together and uh create a really uh nice uh seamless integration there. So if we had to kind of pause and say what would we tell another team these are kind of my four learnings here. One is use a gateway. Stop arguing about those models. Uh start choosing the right models for the right tool and the right occasion. Uh gives you a lot of flexibility and capability there.
Streaming is just the start. That's where a lot of these applications start that are uh kind of you know more startup uh applications in the agentic world. But really you need kind of that persistent background running capability as well. And so kind of that's the ceiling of where you're going to. Third is that sandboxes I was just talking about here. Uh making it real, giving the the CLI um access to your agents and that that really gives you a lot of superpowers there. And then the last one is find the right platform. So for us that was building on uh Verscell and allows us to not focus on the infrastructure and allows us to focus on the features uh and the capabilities that we're trying to roll out in Saltbox One uh at scale.
So with that, I'm going to jump a little bit into the uh demo here and uh go through kind of a a conversational uh you know Salesforce experience, talk a little about the story generation and kind of see the the agent in uh motion here. So give me one moment as I switch over to that screen here. Okay, cool. So jumping into softbox one here. This is uh one of our demo orgs here. But you can see that you've presented on the lefth hand side with uh what we call our projects. And our projects give us different uh contexts.
And then in the center we have our new conversation pane here. So we can kind of focus in on here. We can see all of our different uh projects. As we scroll down, this allows us to load in the right uh context into the conversation. We have our tools across the bottom here which are where all of our integrations are passed into. And then uh down below we actually have uh the ability to add context. We actually can drop in a meeting in here, a user story, an artifact, a Salesforce or something specific in that Salesforce or that allows us to have a really uh rich conversation like that.
Uh so I'm actually going to start with a uh more complex one to begin with and then we're going to switch over as that's running to uh something a little bit uh or something I've actually ran ahead of time so we can talk through that. So in this example here we want to create a screen flow in Salesforce that allows us to uh enter case comments and we want that to be able to give us confirmation screen. Uh so not a super complex requirement, but it does uh require that you know flow and that you know how to configure that and you know how to get there and you know how to debug it.
And so we're going to allow our agent to actually go and work on that as we go and talk about some of the other conversations. Uh and before I hop away, you can kind of see it's retrieving some of the context files. Uh that's some of the the secret sauce uh with Softbox One is we have a lot of information about Salesforce and how to do it and the playbooks to make it actually work uh correctly here. Uh, and you can actually see that it was pretty quick in how it came back and said, "Hey, good news.
I've checked your instance. There are no automations on the case common right now. And so we're clear to go. It's going to ask me a couple of follow-up questions here." Uh, and I'll say yes, you can use the default or and I'll let that go. Uh, it'll start to put together a plan here. Uh, but as that's doing that, I'm going to actually hop over into uh, a different uh, conversation here. So this is actually one of the uh most frequently used uh capabilities we have in our projects for our customers is the ability to uh take a meeting.
So in this case I have a demo brand called HOL. I recorded a meeting where we talked about some new requirements about uh building out in the Salesforce uh capability and I am asking it a little bit about you know our org. I wanted to do it based on what's in there today and I wanted to do it based on uh what the out- of- the-box Salesforce functionality is. So on the surface a pretty uh straightforward request but as you think about it it actually is it's pretty complex uh because it is asking for the details of your environment and you have to know what's out of the box and what is custom to make the right decisions.
Uh so in this case we asked that question and you can kind of see it come back with you know here are the meeting uh requirements that came out of that discussion and here's what you have today. Here's your data model put together a nice mermaid diagram for us to to look at and confirm this is what it is today and then it actually starts to go into uh recommendations here. So here's how you know S1 would approach it. It would break it out into these phases. It would start with phase one as a data model store from visibility subscriptions and then kind of give you some recommendations and some key questions and I'm able to go back and forth with it.
And so I've given it kind of this response of you know here is the answers to these questions and at the end of the day it's given me this nice document that's broken out the requirements into uh those phases with a lot of detail and I can take this and turn it into code. I can turn it into user stories or uh any other uh requirements. So that's kind of one of the superpowers of softbox one is we have built this from a services standpoint. Uh so we know how to implement Salesforce. We know the best practices.
We know how to approach it and all that's baked into kind of this agentic context that we have given Softbox One. So, as we uh hop back over to our original conversation here, we can see that we've uh said yes to the default org. It's gone through all that context I just talked about, figured out how to best do this, and we can see that it has uh created this nice little card for us to review. Now, this card here is our way of controlling what the agent can do. So, you want the agent to go and put together this plan, but you don't want it to run by itself.
We still want the human in the loop here. And so we've gone ahead and put together this component where you can see exactly what it's going to deploy and how it's going to deploy. And what you're able to do is go ahead and click approve and execute. And what that will do, and of course I'm doing a demo, so it's it's going to not work. But what you can do is you can actually uh go and deploy that. Uh you can click retry after you've gone back and forth with the agent and resolve that issue.
Uh, and if it's deployed, you actually can revert back uh to the previous version if you didn't like that version. Uh, one last uh, use case I'm going to pop up on the screen here before we do one more uh, live one is just a quick review of the architecture of your org. So, this is a really common question that we get asked all the time is help us understand the architecture or help us understand the technical debt that's in there. How do we get ready to actually uh go down this agentic path uh in the Salesforce environment?
Those are all really uh simple questions but really in-depth questions as well. And so what you can do is you can ask a question like this and have it actually go through your license environment uh key findings, put together uh what your object model may look like across opportunities. And then again, one of the things that we're going to always do in our responses is start to flag things that you may need to review. So in this case uh we have documentation data looks like undocumented fields across all of our objects. We got a lot of custom fields.
It looks like uh recommendations on how to approach it. Next steps on what we actually can dive into. So in in this case I could go ahead and you know say you know I want to go and do that and what it will actually do is start to narrow down its focus specifically around the B2B commerce uh flow and how everything starts to interact together. It's going to go ahead and make queries into the environment, uh, look at all the the ecosystem around it, and then pull together kind of a synthesis of the response, and you can continue having that conversation.
Now, as that agents, uh, go ahead and and running across, I'm going to do one more use case here, uh, just to kind of show one last example. So, if we hop back over into a new conversation, what I can do is go ahead and drop in a confluence page that uh I have that was actually uh the output of one of our previous conversations. And this has that full long detail of exactly what that solution will look like. And I can quickly go ahead and say I want to, you know, create user stories for phase one in this document.
And again, one what this is really special is that it's pulling together not only the context of this document but of your project, your Salesforce environment, our best practices, Salesforce ecosystem, and deciding what is the best way I should break up this phase one into manageable user stories. Write the uh initial statement of as a user I would like to with a few bullets of what the acceptance criteria actually is. This gives you a really nice starting place for those user stories. And once those user stories are actually generated, then you can kind of go into extra levels of detail in the back and forth with the agent if you'd like to kind of refine what those look like.
So now that uh that one is running, I'll hop back over to our previous conversation where we just finished our audit. We went through a couple of uh queries, pulled together kind of the B2B audit flow here. Uh you can see we've uh pulled together a pretty good assessment of what that looks like and kind of a recommendations on what the technical debt is or what we should actually go back and prioritize on. So you can kind of start to see how all of this uh pins together uh as I hop back over into my example here.
Um looks like my screen is frozen. Screen one second here. Um here we go. Uh so you can kind of see in our last example we pulled together these user stories and you can see these user stories are pulled up on uh the lefth hand side with the details on the right hand side and this gives us the ability to you know integrate into ASA or Jira and allows a kind of full development life cycle of uh what this looks like. So that's a a quick overview of uh Saltbox one, how we use uh the Verscell ecosystem, how we use things like the sandboxing capability, the gateway capability uh and uh v0ero to pull together an application like this and really focus on the features and functionality for our customers and uh not so much on the infrastructure behind it.
So with that, Jacob, was there any questions that we want to hop into? Yeah. Yeah. Thanks for thanks for giving the cool demo. I had a a few questions here. Um first off, I was curious how the agents permissions work. Uh does does S1 have its own permissions like when you set up the app, it gets certain access to Salesforce, Confluence, and so on or is it based on the person who's asking the questions? because that's that's the sort of a tricky thing to do once you have all these kind of enterprise SSO integrations here.
So I'm just curious what decision you landed on for that. Yeah, we we actually went back and forth a little bit on this as we were thinking of that same question and where we landed was userbased permissions. So when the user comes in uh they have the ability to authenticate as their user and so any action they do in Salesforce or any of the other applications is their specific user with either their OOTH or their uh API key depending on the the platform that we're supporting and this gives us the uh the control of your user was the one that performed it.
Uh but then on certain platforms like Salesforce we actually we actually have another layer of protection as well which is each time you connect a Salesforce instance it starts as a readonly connection and then you have the ability to flip it to a right uh permission and once you do that you'll always still see that approval screen for any changes that are going to be done in your Salesforce environment. Okay. So on the Salesforce side for like auditability um any any of the actions that the user did they they clicked um uh so when you had a right action it popped up the approval the user explicitly had to say accept and continue uh to get the agent to do it on Salesforce it would show as being done by the user.
Exactly. Okay. Perfect. Perfect. I was also curious how how how does the agent use sandboxes? um itself like or do did you have certain tool calls that um implicitly invoke a sandbox as like an implementation detail of themselves or does the agent have sandbox tools and it knows there's certain things it must do in a sandbox that that's where it has its uh CLI or APIs and so on. I'm curious how you set that up. Yeah, we've actually got two main uh tools that use the official Verscell sandbox and I'll talk about a a separate sandbox in a moment.
So the the two official tools is when you're spinning up a scratch or we always spin up a Verscell sandbox and we spin up that scratch or using the SF CLI. The second use case is when you're interacting with Salesforce to do a validation or a deployment of something new into an environment. That's always done with a Verscell sandbox with the Salesforce CLI. That's the easiest way in our opinion to do deployments and do other activities is to use the CLI. And the Verscell sandbox makes it really easy for us to install that and and continue on with uh the existing sandboxes.
So we have those two using the official Versell sandbox and then we actually have a uh smaller in-memory sandbox that every conversation has as they have uh each turn on the agent that we use to pull together all the files and allow the agent to kind of understand what's in that uh in-memory sandbox. So kind of two different versions of that. Okay. Okay. Um are you doing any sort of like um network restrictions on the sandbox to limit what it has access to? Um was what sort of security profile look like on the Yeah. The versel sandbox side.
Yes. Yes. Yeah. The versell sandbox. I mean they they get spun up pretty blank. So we load in the files that we need to and allow it to just have access to that. Uh so it's not like our codebase by any means. It's like S1 will go and actually take uh whatever it's gone gone and put together the plan essentially. So let's take the flow example I showed. It would take those files. It would create the uh directory it needs uh that Salesforce is expecting when it does deployments. It would put those files into that directory and it would then go and deploy from there.
So really it's uh pretty uh limited in what it has just what we give it at the right time. Um we have a question from YouTube. What's the pricing model setup? Um how how do you how do you handle pricing? Is it usage based, seat based or so box? Yeah, it's a great question. Uh so we are still in the process of finalizing that as we're rolling this out to our customers and and trying to figure out the right way to doing that. We are we're currently at a user based uh or a user seat uh based pricing uh with kind of limits inside of that tier of how many conversations you can have, how much data, how many interactions.
Um so that's kind of where we're starting. But as uh everyone is experienced in this ecosystem, things change quite frequently and and quickly when it comes to token based uh tools. And so that's that's where we're starting is kind of that that threshold of the user base seats. Yeah. Yeah. It's I think it's really really hard to find the the perfect model that kind of scales with your usage with your customers and with your own expenses as well. So here's on that. Um let's see another question here. Uh how do you decide what questions to route to each model?
Um so there were certain things you were routing to opus. There were certain things you were routing to sonnet. How do you decide what those are? use like an eval system to kind of data back it or just kind of testing manually and seeing hey sonnet is good enough for these classes. What was your approach there? Yeah, it's it is a it's an ever evolving uh answer to that question. Where we're at right now is we have a deterministic uh classifier on the initial questions that helps us to understand uh based on what the user asks how complex is that question.
Do they say things like plan? and do they say things like investigate? Um, so using that because those are those are quick and free, right? You can able you're able to kind of pick those up uh pretty quickly. So we start that with kind of a you know reject uh or deterministic based approach. If we don't find a match there, then we uh lean into on a LM classifier and we go and say, okay, based on what's in here, if it's over a certain threshold of words and etc. let's pass it over to uh an LLM to actually classify how complex it is.
That model's pretty quick, about 300 milliseconds to kind of do that classification of that type. Um and then it will help us route it to the right model, whether that's opus on or another one. Um, and then we kind of have a fall back to if things get too complex and the user uh, you know, asks the same question again or or there's other rules we have in there, then it will fall back to our most powerful model uh, for a minute threshold in order for the user to be able to um, have the right responses in their their questions.
Okay. And and you're just using uh, Haiku at the moment for that classifier for the for the routing model. Yep. For the one. Yeah. Cool. Cool. All right. Um, so yeah, you're also a part of the VZero ambassador program. Um, how has that helped you? Uh, would would you recommend it? Have you gotten value out of uh that program so far uh in building this? Yeah, definitely. Um, I'd highly recommend it if you guys are if anyone listening is interested in kind of being closer to the community. Um I've done a couple of events now um for uh people in different areas that did one a couple months ago or maybe one month ago out at um Mexico to actually do an on-site and kind of walk through like Vzero with a bunch of people there.
Um personally I get a lot out of the Vzero um ambassador program because I get access to uh the product team members but also other people who are just as dedicated in the the space as I am. So kind of bouncing ideas off of each other. has been really valuable. Cool. Cool. So, yeah, if you if you have access to um uh the product people directly, I'm sure you you send a lot of feedback that way. Anything you want to uh ask for feedback out here in public to really put them on the spot and get the pressure going or I I'll be nice.
I I think uh maybe the the biggest one and I' we've talked about this is like just bringing more uh capabilities into v 0ero uh when it comes to uh what developers are used to from a an IDE local environment perspective. uh you know we've over the last couple of months got uh sandboxing capability inside of vzero and the ability to kind of you know spin that up and have like an actual environment there and that's a huge step in the right direction and I think as we continue going down that path uh that will that will continue to get better.
So I think just continue going down that path would would be my uh my shout out. Amazing. Yeah, it's been a long ongoing process. It used to be this very very minimal little browser IDE and now it's kind of full VS Code Monaco integration. It's um get gets better and better uh every every month. That's right. All right. Well, I think that's all we have for questions here. So, uh yeah, I just want to thank you for coming on and doing such a great demo here. Um where where can people find you if they want to um follow up or learn more about Soapbox?
Where where Yeah, I'm most active on LinkedIn. So, if you want to go ahead and connect with me, put put a message in there so you watch the the session, I'll I'll know who you are and happy to connect with you and answer any questions or connect that way. Amazing. Yeah, we'll drop a link to your uh LinkedIn in the chat here. So, yeah. Anyway, uh thank you. Thank you so much for coming on. All right, thank you. All right. Uh yeah, thank you everyone else for joining. Um, we will have another community session coming up soon here in Let me check the calendar.
Um, I'm supposed to do this ahead of time. Oh, uh, it's coming up on Thursday. Um, but it's not actually added to our calendar yet. So, yeah, come back in a couple days. Uh, we have another we have another session going. Until then, we'll see you all in the community. Have a good day, everyone.
More from Vercel
Get daily recaps from
Vercel
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.









