CJ Brewer, Co-founder at Swirls AI and VP Ops at CipherStash

Hey everyone. My name is CJ. I'm really looking forward to presenting here at Builders Day 2026. Um yeah, let's jump right on into it. So, today um we're going to be talking a little bit about how businesses use agentic systems in their day-to-day operations. And I labeled this could this just be a markdown file? Um I've seen especially recently with all of the like personal AI agents coming out um a lot of people banking on them to run business operations, which is great and honestly I use it myself for like my personal assistant. Um but when you when your business needs to rely on these systems that are being created, uh we need to think a little more systematically about how we define these systems.

So, I believe the answer to that is declare a declaration of agents um for real business operations. So, let's jump on into it. So, as I said, my name is CJ Brewer. I'm the VP of operations over at Cypher Stash, a data security company. And I also co-founded my own company called Swirls, which I've been working on on the side. Um and I've been working with companies for the past 10 plus years um to build like software uh in really in the consulting space. So, local small to medium-sized businesses here in Colorado.

Um whether it was like my friends and family or a small business that I run into on the street. And more recently uh it's ever since the GPT-3 models came out, people really started to understand what you could do with these AI systems. So, they started asking me to implement AI into their existing applications.

And I have a lot of opinions about how that should work, especially given um how many times I've done it. So, bear with me as I kind of dive into my learnings uh today. As I mentioned, uh customers wanted AI inside of their processes. They wanted to leverage this decision-making power to automate business processes.

And I found myself really going into existing applications, mostly like Next.js or like TanStack startup apps, and implementing the AI SDK built by Vercel or some of the other ones as well. But that was like kind of my go-to. Um into these applications to provide an agentic layer for these applications.

And I noticed a pattern every single time I went and did that. Um it wasn't just implementing like chat interfaces. It was actually implementing in workflows into these existing applications to do particular processes that just so happened to have AI decision-making inside of that workflow.

What was also interesting was I was connecting a lot of different systems together. So whether that was like a CRM, uh something like like Adio or Salesforce or HubSpot, um financial systems like Stripe, and I was piecing a lot of them together and using AI in those workflows to do like business decisions.

Um so the patterns kept coming up over and over and over again about how I was building the same architectural uh designs into existing business systems. And more recently, I have been noticing people are using and really adopting these personal assistants. Things like Grok Bot or some of the routine and schedule features of Claude and ChatGPT uh in order to manage business operations, which I'll be honest, like I use Grok Bot myself to manage a uh like my calendar, manage my emails, and I think that's totally fine for like an individual who isn't collaborating with other people inside of a company.

But, what happens when you want that system do operations for your business? And this is where I continue to have conversations with these small to medium-sized businesses. That is people keep coming to me and saying, "Well, I can just do it all of this in Grok Bot." But, they have a team of about 10 people. And a pattern that I've been seeing recently, especially over the last like month or so, just kind of crazy to think about. Um how how far we've come from the initial like GPT models.

Uh is they define things inside their personal Grok Bot in like a business process to like go post on LinkedIn every Wednesday when like ingest [snorts] the things I've been working on and create a LinkedIn post. If that person's out of office or there something goes wrong with the LinkedIn API, and they need like their team members to debug it, like good luck.

It's uh it's a pretty challenging feat to actually pull off operationalizing these processes that you want to run. So, I believe there is a better way of doing this, specifically for your business.

I've already touched on this a little bit, but I really want to hyperfocus on this failure case, because it is the reason that we need to be thinking about declarative systems over using things like Grok Bot and these routines that get scheduled on the markdown file. And we need to really think about it from an engineering perspective. Like we you think about um if I have a process that's going out and connecting my CRM to my internal application, which is the example that I have described here. We need a way to be able to monitor and modify that process across the team.

Because if let's say the CRM API breaks or something in my internal application breaks, or we even have like a network blip. Uh where some internet route is uh not available at that particular point in time. Which happens often, more often than not than you would think. Um what's interesting is you need to be able to debug these these issues. Uh I think Claude and ChatGPT have a little better configuration over how these schedules are working.

But I've again been seeing a lot of people building these business operations into Grok Bot and things like Muse. And it's just extremely challenging to debug things when when something goes wrong.

So again, this is where I think declared workflows is actually the future when it comes to implementing AI for small to medium-sized businesses. Um and really any business uh for that matter. You get a few benefits when you have declared workflows. And it depends on the framework you're using. Um you might have uh things like Vercel Eve.

Obviously, I'm a little opinionated with the uh the Swirls platform. But there's a lot of uh declarative workflow engines out there, even when going back to things like n8n. Um but the the premise that all of these frameworks are built on is you have a typed input, so you can understand exactly what is going into the system.

You can still leverage AI processing, so AI decision-making for being able to um leverage the power of AI to like make decisions on humans' behalf based on prompting. Uh you can have rules and reviews. So this is where human reviews come into play, which I think is a really important feature that a lot of tools like Grok Bot and Muse don't have out of the box without having to do like very manual intervention.

Um having manual reviews built into the workflow framework really enable uh much more trust in the systems that are being built and deployed into everyday business processes. And of course, we have allowed actions. So being able to connect tools uh into these workflows and having that declared alongside the workflow also really helps out security. So, security teams are able to actually audit exactly what is this workflow doing to manage my business processes.

The workflow is just a piece of the puzzle. The you also need a declared runtime in order to run these systems. So, things like keeping track of the state, enforcing the human approval gates, and also the observability side of things. So, it's to limit query on exactly what happened through that process so that you as a operations expert who knows the business context more than better than anyone else does can understand what the system is doing, modify it if needed, and also be able to improve it over time. Let's take a little example.

Let's say I have a cleaning company and I have a request that comes in to dispatch a cleaning crew. Um maybe that the prompt is something like clean the shop before opening tomorrow. And that job gets defined inside my CRM through some plumbing that I've put together. That could probably also be a workflow, by the way.

Uh but let's focus on actually dispatching a crew to actually go do the cleaning. So, we have inside of our database or CRM or whatever different systems we have that are defining how my business operates. We have a a set of crews and we have a job that needs to be completed at a particular point in time.

Inside of a declared system, you can actually outline exactly what that state looks like. So, I think this is a another really good benefit of declared systems. As a human, you can actually go view what is going on and what is running when one of these jobs comes in. I challenge you to go do that with Rockbot. It's quite interesting to pull out all the details of exactly what's happening behind the scenes.

But back to our use case here. So, a job comes in to clean the shop before opening tomorrow. We have a workflow defined. We have some AI processing in there because again, one of the main reasons that we want declarative workflows is to leverage AI in a responsible way. So, we have an AI node that actually does the processing to feed in the data from how many crews are available, what is the actual job that needs to be happening, and the AI AI can do the decision-making of what crew gets assigned to that job.

That job will be pushed through the system. And there'll probably be some human approval there to say, is so the AI said, this is the crew that I want to assign to this job. A human can go in there and say, yep, that looks great, approve, and that crew gets notified, and they are off on their way and performing the cleaning the very next day.

It's a very kind of straightforward use case, but I think it's very indicative of how you can look at a very simple task that's declared inside of a workflow that you could you could go offload off into something like Rockbot. But if you ever need to modify that or say you want to remove the human in the loop component, you can actually audit all of that from a declared workflow.

Let's take a look at what a declarative workflow actually looks like. So, as I said earlier, AI and decision-making is still extremely important in why we're using these declared systems to implement into businesses because people want to use AI to automate like tedious tasks that have been previously taken a lot of human hours.

So, here we have a node inside of a workflow that is using what model, so defines what model. So, the Google Gemini Flash model. Obviously, that's a pretty old one, but it's also really cheap. We can define the prompt that is being used to actually process this request. And we can also define the inputs that it uses, that are dynamic every single workflow run.

There's a few things to note about why I would be be interested in using a declared system here. Let's start with that model key. When you can declare the system and you have a runtime that can actually support multi uh multi-model um systems, you can determine exactly what model you want to use for any particular job.

So, there's a few benefits to that. Number one, you can test out the the new models on the block, but also it's about cost control. As I said, Google Gemini 2.5 Flash, it's not the most robust and intelligent model on the block, but it's extremely cheap. And for doing something as uh trivial as this, it does a pretty good job of making the correct decision again and again, because again, we understand a strongly typed input with a static prompt, and the output that it gives is pretty uh it's pretty deterministic um every single time those inputs go through.

We don't need something like uh Fable 5 to determine what crew should be assigned our job uh when a cleaning uh cleaning request comes in. So, that's one uh one very helpful uh component to the puzzle. And the second here is the prompt. We Let's say um the output of this node isn't exactly what we thought it would be. And we have that because we have observability, which I'll get into here in a few slides.

We can use the data based on how these workflows are running to modify our prompts, to change our agent behavior. Because the agents and the models are only as good as the prompts and the context that we give it. And I think that's a very important uh component. Um again, I'll get into that in a sec. Won't go and dive too much into it.

Just quite yet. Another really cool thing about using declarative systems, and again, this is uh an example using uh that dispatch uh workflow that I was talking about. We can choose how we want the requests to flow through our workflow. So, right here, we're really declaring how the workflow works. So, we have a choose crew, which is the node that we just defined using AI.

Uh the AI node to run it through the Gemini processing to understand what uh what crew is the best one for the job. And we can define like a check choice. So, this is the human approval gate. We might say, "Okay, like yeah, like that that's a really good crew for this job. I want to approve that."

And once the approval goes through, then the booking decision happens. So, there's a few things going on here. And I think it's really important to highlight the importance of the runtime when choosing your declarative system. Number one, this needs to be highly [snorts] durable. So, if there are any failures that happen in the runtime or any something goes wrong with the APIs, it knows the state of where it left off, and it can also pick up uh at any point in time based on any type of pause. So, that human approval here in this specific example, that could be sitting around for a few days. If you don't have a runtime that can actually manage those human approvals and be able to pick up the workflow and actually go reserve the

slot uh once the human has taken action, the workflow is essentially useless. So, there's a a healthy balance of the declared workflow system and the runtime that actually makes it a reality. But, circling back to uh the this this flow definition, um it really just gives you control over how these systems are processing your data.

Another reason that we want to lean into declared workflows is the ability to have these workflows in our source control. So, these workflows can actually live directly inside of your the source code for like your applications. And you can commit them into get. Uh you can version control them. You can have like QA environments to be able to test them. And you as a developer or simply a systems operation manager can view the history of how this workflow's changed over time using just out of the box dev tooling with get.

You can also point fingers at your coworkers like, "Why did you turn uh the human review off for this particular workflow?" Um it gives you just that auditability over behavior changes over time. This is an interesting piece of the puzzle as well and really leans more into the the runtimes of how these workflows are processed. Uh but it also does come back to the declarative nature of workflows as well. So, you can in a really good systems, you can have they they really expose uh aspects of the runtime directly into how these workflows are processed. So, things like failure policies. You can say, "I want this workflow if you in if this piece in the node fails, like you're hitting some external API and

let's say it's offline for a few hours. You can define that that failure threshold to say, "I want you to retry this every few minutes uh over the next few hours and if it still fails over 2 hours, then fully fail the workflow." But you can define like how the runtime actually manages failed state, which is a really important piece when building business systems that your company's going to rely on.

Now, I said we'd get back to observability and now is the time to visit that. So, again, I think this is more on the runtime side of things rather than the the workflow declaration side. But really adopting things like open telemetry to understand exactly the state and inputs and outputs of your workflow in a digestible trace, I think is extremely important. Number one, you would need to make sure that the systems are doing what they're supposed to be doing. Number two, when something fails, you're able to diagnose that extremely.

Um, and number three, you want to be able to feed these into kind of self-improving uh system like things like uh Lang LangSmith or Neat Logs as another company that's popping up that's um taking traces of how agents behave so that you can make better decisions and modify your prompts, modify the context that these LLMs are handling to be able to optimize your system for uh the best business efficiency possible.

So, why does all this matter? At the end of the day, small businesses and really any business for that matter should be able to depend on these agentic systems. And they should be able to leverage AI to implement uh like better decision-making and automated decision-making into their everyday business processes. But doing that in something like a Grok Bot or a Muse leaves a little to be desired when it comes to being able to operate that over time and across team members.

So, having business rules defined inside of a declarative system, I believe is how businesses and people are going to be able to adopt AI um in a much more efficient, cost-effective, and performant manner. To kind of finalize things here, uh do want to talk a little bit about Swirls.

So, these all of these principles and opinions is what built and really constructed Swirls. So, we actually built our own DSL. Uh thank you to the Prisma team for giving us a little inspiration to doing so. Um, having a declarative language purpose-built for workflows and agentic systems has been kind of a game-changer for small to medium-size businesses that we've worked with.

And as I've mentioned before, the workflows in the declared systems are only as good as the managed runtime. So, the Swirls platform actually runs those systems for you. And we provide SDKs to be able to directly integrate those into your existing applications. Obviously, I'm a little biased with Swirls, but frameworks like Vercel's Eve or the TypeScript framework with Mastra do a really good job of achieving the same outcomes.

It's all about choosing the software that's right for you. But having those declared systems in source control that your entire team can manage and operate over time is again how we're going to be able to leverage these on a more responsible manner. And really use AI inside of the SMB SMB space, but also just really any company in any size for that matter.

Thank you for listening to my talk. My name's CJ. If you are interested in any of this, feel free to reach out to me on LinkedIn or Twitter. And again, thank you so much for the Prisma team for having me. Looking forward to the next one. >> [music]