Hey, Scott Austin here.
Here are two things about AI that are both true, and that almost nobody says together.
The first is that AI is powerful. Not the chat window version, but the version where it's wired into your systems and working on your brand while you sleep. That's real. It exists. I use it every day with my clients.
The second is that getting there is hard. Not conceptually hard, the ideas are simple. Hard in the way that anything real is hard. It takes an enormous investment of time. It breaks frequently. It requires a level of detail and discipline that has nothing to do with AI and everything to do with knowing your business and tools cold. We have already put over a full-time month of senior development into what I'm going to show you today, and we're nowhere near done.
You mostly hear the first half of the power of AI. The demos, the YouTube videos, the posts about how AI is going to run your store for you. What you don't hear is the second half, which is what it actually costs in time, money, and brain bandwidth to make any of it work.
So today I want to give you both halves. I'm going to show you a real tool that we are running. And I'm going to share with you about how hard it was to build and how much of it still needs a human. For those listening to the audio version of the podcast, there's a link in the show notes to the video if you want to see the demo.
The tool is called Client OS. We built it at JadePuma and use it for our clients' brands.
What Client OS is
At its core, Client OS is a tool that sits in the middle of a client's Shopify brand and connects to all the tools that the brand uses.
It connects to Shopify. It connects to Google Drive, where documents and assets are stored. It connects to Klaviyo for email and SMS. It connects to Notion, which we use for project management. It connects to GitHub, where the theme code lives. And it connects to a few more places depending on the client.
So the first thing to understand is that Client OS is a connector. It's the tool that can see across all of these systems at once. And that alone is useful, because normally that context is scattered. The brand voice is in a Google Doc, the products are in Shopify, the campaigns are in Klaviyo, the code is in GitHub, and no single tool can see all of it together. But Client OS can see it all.
The second thing Client OS connects to is AI. We wanted Client OS to be agnostic about AI providers. So we didn't build it inside anybody else's toolset, like Claude Co-Work or ChatGPT Work. We built our own. It's our own codebase, running on our own servers.
That makes it more work, obviously. It would have been faster to pick a platform and live inside it. But building inside somebody else's toolset means you inherit their choices. You get the models they support, the pace they move at, the pricing they set, and the direction they decide to go. And in a field moving this fast, that's a lot of your future handed to someone else.
Owning the codebase means we're not locked in to one AI provider. And that's what lets us do the next part, which is that we don't connect to one AI model. We connect to whatever model is a good fit for a given task, by API.
Quick definition, an API is how one piece of software talks directly to another piece of software, without a person in the middle. Every one of the connections I mentioned earlier, Shopify, Klaviyo, Notion, all of them, work this way. And so does the connection to the AI models.
So Client OS calls whichever model suits the job. Some tasks want a model that's strong at long, careful reasoning. Some tasks want a model that's fast and cheap because we're going to run it a thousand times. Some tasks want a model that's good with images. Client OS routes each task to the right AI model, rather than forcing everything through a single choice. And when a better model shows up next month, or a cheaper model, we point at it. That only works because nothing in here is tied to a single provider.
And that distinction changes the economics. When you use a chat interface, you pay a monthly subscription and the cost of what you're doing is invisible to you. With the API, you pay for every token consumed. Every word going in, every word coming out. So a task that runs across five hundred products has a real, countable dollar cost, and a sloppy prompt that stuffs in twice the context it needs costs twice as much.
Which is why we built token tracking into every screen in Client OS. Wherever you are in the tool, you can see what the work is costing. Not an estimate at the end of the month, but the cost of the task as you are working on it. That keeps us honest, it keeps us efficient, and it means when a client asks what it costs to do something, we have a real number instead of a guess.
There's one more consequence of owning the codebase. We have to write our own skills.
A skill is the recipe that Client OS follows to perform a task. It's the step by step of how this particular job gets done. What to look at first, what to check, what rules apply, what to do when something is missing, when to stop and ask a human. Every task I'm going to show you today has a skill behind it that we wrote.
Skill isn't a term we invented, by the way. If you've poked around any of the AI platforms you may have run into the same idea under a different name. Claude calls them Skills too. In ChatGPT the closest thing is a Custom GPT, and in Google's Gemini it's called a Gem. Same basic notion in each case, which is a reusable set of instructions for a particular kind of work, so you're not explaining the job from scratch every time.
Now, having to write all of our own skills is work. But it's the good kind of work, because it means we can get very specific. We automate things exactly the way we want them done to our standard, instead of accepting somebody else's idea of how the process should go. If a client has an unusual way of handling a thing, we can encode that. If we learn a better way to do a task, we change the recipe and every future run does it the new way.
That's the plumbing. Now let me show you some of it.
Demo: one tool, many clients
https://client-os.jadepuma.com/
First thing you see when I open Client OS is a list of clients.
Because JadePuma works with a lot of Shopify brands, and every one of them is different. Different voice, different customer, different catalog, different systems. So Client OS was built from the start to handle all of them, and to keep them completely separate.
[Screen: switch between two clients]
Watch what happens when I switch from this client to this one. Everything changes. Different brand definition. Different connections. Different tasks running on different schedules. Different history. This client's work has no idea the other client exists, and that's on purpose.
Each brand gets its own space, and nothing in one space touches another. That matters for the obvious reason, which is that a client's data is theirs and it stays in their space. But it matters for a second reason too, and this one is specific to working with AI.
If you blur two brands together, the AI will blur them together in the output. It'll start writing this brand in that brand's voice, because both are sitting in front of it. So the separation isn't only about privacy and good practice. It's about quality. A brand definition is only useful if it's the only brand definition in the room.
So one tool, many clients, each one walled off. That's the container. Now let me show you what goes inside it.
Demo: the brand definition
https://client-os.jadepuma.com/clients/healing-home-foods-shopify-app-datify/brand
This is the brand section for one of our clients. And I want you to just watch me scroll for a second, because the length is the point.
[Scroll slowly through the entries]
This isn't a paragraph that says "our brand is fun and approachable." This is dozens and dozens of individual entries. The specific words this brand uses and the words it avoids. How it talks about price. How it handles a frustrated customer. Sentence length. Whether it uses contractions. What each product category means and how it differs from the others. Who the customer really is, in plain terms, not a persona nobody believes.
Every one of these entries is a decision we've made and written down. And the reason we go to this much detail is simple. The model is not the hard part anymore. The models are good. The hard part is context. It's telling the model precisely enough who this brand is and what good looks like for them. Get this right and the output is genuinely on brand. Get it vague and you get content that sounds like every other store on the internet, and you can feel it immediately.
So a lot of the work here is not AI work at all. It's the unglamorous work of defining a brand well enough that a machine can act on it.
Now, when you have dozens and dozens of entries like this, a real problem shows up. They start to contradict each other. One entry says keep it short and punchy, another example three screens down is long and flowery. One says avoid exclamation points, another uses them. As a human, you'll never catch all of those by eye.
[Screen: run the brand review tool]
So we built an AI tool that reads the entire brand section and looks for inconsistencies. Let me run it. What it comes back with is a list of places where the brand is arguing with itself. Here it's flagged that our tone guidance and one of our example sentences don't match. Here it's caught two entries that give different rules for the same thing.
And this is a nice example of using AI on the thing AI is good at. It's not writing here. It's reviewing. It's holding all of these entries in its head at once and finding the conflicts, which is exactly the kind of tedious, detailed check that humans are bad at and machines are good at.
Demo: the connections
https://client-os.jadepuma.com/clients/healing-home-foods-shopify-app-datify/data
Last thing I'll show you here is the data tab. This is where you can see all of the connections for this client at a glance. Shopify, connected. Google Drive, connected. Klaviyo, connected. Notion, connected. GitHub, connected. Each one showing its status. This tab is how we know the plumbing is healthy, because when one of these connections breaks, and they do break, everything downstream stops working. So we watch it.
Demo: recurring maintenance
Now let me show you the part I find genuinely valuable, maybe more than the content creation. The recurring maintenance. These are the boring, repeated tasks that keep a store healthy and that get skipped because nobody has time.
https://client-os.jadepuma.com/clients/emerson-knives/redirects
Here's the first one. Every week, Client OS handles redirects for 404s.
Here's the second one. Once a month, Client OS scans the whole site to recheck ADA accessibility compliance.
https://client-os.jadepuma.com/clients/reptichip/ada
It goes through the site looking for accessibility issues. And if it finds any, it creates a task in Notion and routes it straight to our accessibility expert. So this isn't the AI silently fixing accessibility. It's the AI doing the tireless monthly scanning, catching the issues, and then getting them in front of the right person.
And I want to explain that choice, because it's a good illustration of where I draw the line.
Take a common accessibility fix. You've got a navigation menu that doesn't work properly for screen readers or for keyboard users. Fixing that means editing the structure of the nav. The markup, the nesting, the way the menu handles focus and keyboard input. That's nuanced development work. It's the kind of thing where a change that looks right can behave wrong in ways you only find by testing it properly.
I don't trust AI to execute that reliably today. And more to the point, look at what we'd be risking. The main nav is on every page of the store. It's how every customer finds anything. If an AI edit breaks it, it isn't broken for one person on one page. It's broken for everybody, everywhere, on the thing they need most, and possibly for hours before anyone notices.
So the math is simple. High volume of tedious checking, low risk if the AI is wrong, that's a good fit for automation. Small number of nuanced changes, catastrophic if the AI is wrong, that goes to a human. Scanning is the first kind of work. Rewriting the nav is the second.
The machine does the watching. The human does the fixing.
Alright. Beyond the scheduled maintenance, here are some of the tasks we run through Client OS today.
Demo: evaluate a page or email for brand compliance
One. We review existing content for brand compliance. We point it at Klaviyo emails and at web pages, and it checks them against that big brand definition I showed you. And it doesn't just say pass or fail. It gives us actionable edits. Change this line, it drifts from the voice. This subject line is off tone. Here's a version that fits. So we can go implement the fixes.
Demo: understand customer sentiment
https://client-os.jadepuma.com/clients/the-healing-hedge-witch/chat?session=gq1oCVkSTSCnpwiHBPpB
Two. This one I really like. We have it read through the comments customers leave in reviews, and pull the customers' own words back into the brand guidelines. Because the way a brand describes itself and the way its customers describe it are often different, and the customers are usually right. So the brand definition doesn't just sit there. It gets better over time by learning the language real customers use.
Demo: mock-ups
https://client-os.jadepuma.com/clients/the-healing-hedge-witch/chat?session=XsyvjJZAlFIvMsrxSfzu
Three. We use it to produce mock-ups for pages, so we can look at a layout and a direction before anyone builds anything.
Demo: build a page
https://client-os.jadepuma.com/clients/neural-balance/chat?session=jHboe9KAkMHmZleriq4c
What's coming next
Everything I've shown you so far is running today. Let's see where this is going, because we've got integrations in the works that open up a lot more.
The first is ads. We're connecting Client OS to the ad platforms, so it can see the ad accounts the way it already sees the store and the email. Once it can read and write there, the same brand definition that shapes your product copy can shape your ad copy, and it can review your ads for brand compliance the same way it reviews your emails today.
The second is social. Same idea. Connect to the social accounts so the brand can post and stay consistent across the places customers see it, all working from that one shared definition of the brand.
The third is Google Analytics, and this one is a different kind of connection. Everything else I've described is about doing things. Analytics is about knowing whether the things worked. Once Client OS can see the analytics, it can look at what it created and tell you how it performed.
And the fourth is the one that ties it all together. We're connecting Client OS to our own marketing calendar app. Because once you're touching the store, email, ads, social, and analytics, the question stops being can you create each piece, and becomes can you coordinate all of them on a schedule. The calendar is the backbone for that. It's the thing that says this campaign runs these dates, and here's everything that needs to go out, and here's when.
The future we're working toward
Here's the scenario we're building toward.
Imagine you want to run a campaign. Today, a campaign is a dozen separate jobs handed to a dozen different tools and people. Somebody comes up with the idea. Somebody builds the landing page. Somebody writes the emails. Somebody makes the ads. Somebody does the social posts. Somebody sets up the discount. And somebody has to coordinate all of it so it goes live together and on time.
The scenario we're working on is Client OS doing that whole chain, end to end.
It comes up with the campaign idea, the offer, and the dates, working from the brand and from what's worked before. It creates the landing page. It writes the emails and gets them ready in Klaviyo. It creates the ads. It creates the social posts. It sets up the discount in Shopify. And then it runs the whole thing on a schedule, according to the marketing calendar, so every piece fires at the right time.
And when the campaign is over, it reads the analytics and tells you how it went. Which is what makes the next campaign better, because now "what's worked before" isn't a hunch, it's a record.
One campaign, one brand, every channel, coordinated. That's the goal.
Now, I want to be honest about how this works, because it's not the AI going off and doing all of that unsupervised while you sleep. It's the AI assembling the whole campaign and then bringing it to a human for the checkpoints spelled out in the skills. You approve the idea and the offer. You review the landing page and the copy before it publishes. You sign off before the discount goes live. The machine does the tireless assembly, the human keeps the judgment. What changes is that instead of a dozen disconnected jobs, you're reviewing one coordinated campaign that already knows your brand.
That's the direction. And to make that landing page step work properly, there's something else we think we'll need to build, which is our own language model.
We don't start every store from scratch. We use one theme on every store. And we've built our own Shopify app that adds our custom sections to that theme, which is what gives it the extra functionality we want. So across all our clients, we're working with a known, consistent set of building blocks. It makes us faster and experts in the theme.
The problem is that Client OS doesn't inherently know any of that. If I ask it to build a landing page, it needs to know which sections exist, what each one does, what settings each one has, when you'd reach for one over another, and how they're meant to be combined. Right now that knowledge lives with our developers.
So we'll be building a model that details every section in the theme and in our app, and Client OS will reference it whenever it builds anything in Shopify. That's the vocabulary. Instead of describing a page in vague terms and hoping, we'd be able to say build this page, and the tool knows exactly which sections we have to work with and how to assemble them properly.
There's one more piece of the future I want to mention. Right now, Client OS is a JadePuma tool. We use it on behalf of our clients. Where we're headed is opening it up so our clients can use it too.
If everyone working on a brand work through Client OS, they're all working from the same brand definition. The same voice, the same rules, the same standards, whether it's us building a landing page or their marketing person writing a social post. And it improves for everyone, because when their team learns something about the brand, it goes into the definition and every future task uses it.
Now the hard part
I've shown you a lot of what's possible today, and I've just told you where we're headed. Now I want to be straight with you about how hard this is, because I don't want anyone walking away thinking they can wire this up over a weekend.
Client OS is built by our best app developer. Not a side project, not something squeezed in between other work, our strongest developer. And yes, he uses AI to build it. The AI helps a lot. But it still takes an enormous amount of time and knowledge.
And a good chunk of that month is the two choices I told you about up front. Owning the codebase instead of living inside somebody else's platform is more work. Writing every skill ourselves instead of taking a process off the shelf is more work. We think both are worth it, but I don't want to pretend they're free.
I want that number to sit with you, because it's the honest counterweight to everything I just showed you. A month of a senior developer's time, with AI assistance, to get to what you've seen. That's the real price of this stuff.
Now, the reason it's worth it for us is that we amortize it across every client brand we work with. We build a capability once and it serves all of them. That math works for an agency. It would not work for a single store, and that's worth being clear about. If you're one brand looking at this thinking you should build your own, the numbers are very different for you than they are for us.
And building it is only the start. Two ongoing difficulties are worth knowing about, because they never go away.
The first is that the connections themselves are hard. Every one of those platforms has its own API, its own authentication, its own rate limits, and its own quirks. Getting them to talk to each other reliably is real engineering work. And it breaks. APIs change, tokens expire, a platform updates something and a thing that worked yesterday stops working today. That data tab I showed you exists precisely because this stuff needs watching. It's not build it once and walk away.
The second is wiring it all together, and this is exactly why that end-to-end campaign vision is hard. Routing tasks to the right model, feeding each one the right context but not too much, keeping the cost reasonable at volume, and handling the case where a call fails or comes back with garbage. That's a lot of moving parts on a single task. Now chain a dozen of them into one campaign, where the landing page depends on the offer and the emails depend on the page, and a failure at step three quietly breaks everything after it. The more of them you string together, the more careful you have to be.
And underneath all of it is the thing I keep coming back to. Knowing which tasks are a good fit for this and which ones aren't. That's the nav menu decision, over and over, on every task we consider automating. Part of doing this well is knowing where that line is.
So where does that leave a store owner
Here's what I want you to take away.
What's possible today is real. You just watched it. A tool that connects across all your systems, understands your brand in real detail, checks itself for contradictions, runs maintenance on a schedule, and helps create content and code. That exists and it works.
But it is not a button you press. The value doesn't come from the AI. The AI is the easy part now. The value comes from all the work around it. The connections, the brand definition, the guardrails, the verification, and the judgment about what to use it for. That's where the difficulty lives, and that's where the results come from.
If you're a store owner of a small or medium brand, I don't think the lesson is go build this yourself. For most of you, that would be a poor use of your time. So here's what I think the lesson is instead. You should be looking to your agency to bring this to you.
And yes, I hear it. That is a wildly convenient conclusion for a guy who runs an agency to reach at the end of a podcast about his agency's tool. I'm sorry, there's no version of this where I say it and it doesn't sound self-serving. So take it for what it's worth, and let me at least show you the math behind it.
That's the deal with an agency. You're not just buying hands to do the work. You're buying expertise and tooling that you couldn't justify building on your own. The economics only work because the agency amortizes the investment across all the brands it serves. That's exactly the math I described a few minutes ago. A month of senior development is unaffordable for one store and completely reasonable across a roster of them.
And I should say there are real exceptions. Some small brands will build their own, and they should. If you've got a technical founder, or somebody on the team who genuinely enjoys this and has the time, you can absolutely do a version of it yourself. Just go in knowing what it costs, so it's a real decision and not an accident.
For everyone else, it's fair to expect this from whoever you work with. Ask them what they're building. Ask how they're using AI on your brand, and what the guardrails are, and what they'd never let it touch. Ask whether your brand is defined anywhere in enough detail that a tool or a new hire could act on it, or whether it's living in one person's head. Those are reasonable questions, and the answers will tell you a lot.
Here's the last thing I want to say, and it's the thing I most want growing brands to hear.
There's a lot of hype right now about how easy AI makes everything. That hype is wrong. Not about the results, the results are real. It's wrong about the effort. Most of what I showed you today is too complex and too distracting for a store owner to take on themselves.
And you already have enough jobs. You're doing merchandising, and customer service, and inventory, and hiring, and cash flow, and product development. You do not need another hat.
What you need is a technology partner who is already wearing that one. Someone whose job is to keep up with this so you don't have to, and to point it at your brand. That's what this should look like for you. Not you building your own AI solutions. Someone bringing it to you.
Thanks for listening.