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.

Client OS Demo

So here is the opening screen of Client OS, and what we do is we create an instance for each one of the brands that we work with so that each brand has its own brand definition, its own data connections, and each store is completely separate from other stores.

And now for every brand, we create a brand definition, and this brand definition gets really detailed.

Now, if you see here, as I scroll, there's lots and lots of different, uh, types of data about the brand that we're putting in there.

You know, things like what should subject lines be like?

How do we capitalize things?

What are words that we

use?

What are words that we don't use?

What sort of tone do we have?

You know, all sorts of

good information.

And this is a lot of information to consume.

So once we put it in there, we actually have tools that we've built where we can review that information and we can also export it to Klaviyo because Klaviyo has new features

that have brand in them.

So in case you don't want to use

Client OS to edit your Klaviyo,

You can actually use it to create the brand voice for your Klaviyo.

And then because this,

brand definition is so detailed, we actually allow people to download it or export it to a PDF

that gives them a brief summary, which, you know, one-pager of the brand.

Which we give to brand owners first to review and go, yep, that's, that's on the mark.

they have any feedback on that top level, we'll go ahead and incorporate that in.

But then we also give a PDF with all the detail that they can go through line item by line item and make sure that this lengthy brand definition actually maps to their expectation of the brand.

So we actually have, uh, brand owners go through and redline this for us, and then we go ahead and update the brand from there.

So the brand definition here is, is the brain of client OS for each of the brands.

And then we have the arms and legs, which is the data section.

So data is really all the connections to all the different tools that the brand is using, which is going to include Shopify, Klaviyo, GitHub,

Google Docs and other pieces of information and systems that we're talking to.

And we give little, you know, green lights here saying, yeah, everything's good, because every once in a while things will change and need to be updated.

So you have this dashboard view to come in and make sure that all of your connectors are working properly.

One of the things we found really valuable with Client OS was automating tasks that we ran all the time manually.

For example, for all of our stores, every month we used to run a 404 report or a page not found report.

And we would then go ahead and manually verify that that page was still rendering a 404.

And if it was, we would create a redirect and put that into the Shopify settings.

But now we've automated that process with Client OS.

It, it goes out and pulls the report for a page not found.

And then it comes up with a list of these reports on a frequency that we can set.

We can set it to be every week or every month or whatever frequency we want., and then we use AI to determine which page in the Shopify store

is going to be the best landing for that redirect.

And we put a confidence behind that,

recommendation.

And then we have a setting that says, all right, everything, you know, over the— a confidence threshold, automatically apply the redirect.

Anything below that threshold, go ahead and create a Notion task.— and assign it to our person is then going to go and evaluate, is that the right landing page recommendation?

Or they can change it and they can do that right here in the tool

where if they like the, uh, recommended one, they can just create the redirect.

If they don't like it, they can change it out to be whatever URL they want and then go ahead and have that redirect created.

So this tool has, you know, saved us hours every month for all of our clients of manual work.

Automated it as much as possible, but still had that threshold, that confidence threshold in place so that a human can come in when necessary and make a decision on the recommendation.

Another automation that we've done is ADA compliance checking,

We had a process where every couple months we would go into our clients' stores and check all of their pages for ADA compliance again.

We always do that when we build a store, but things change over time as you add to your store and bring products in and do

merchandising and campaigns.

So we'd go in every couple months and run a check on all of the pages, and then, you know, all the errors we found— we would then go ahead and automate those.

But now we've automated the checking part of the ADA compliance, and now we actually run it more frequently, right?

So we can, we can run it every single month if we want,

and we are in some of our stores.

This one's actually set for every 3 months.

And what we do is we go in and we check for all the errors and warning for ADA compliance.

However, I don't trust AI to make the changes, right?

I, I still want developers going in there, and this is based on us actually seeing what AI can do and not do.

Um, for any of you that worked in ADA compliance, sometimes it'll be things like the structure of your nav menu needs to be, uh, updated to bring ADA compliance rules into place.

Well, I don't want AI going and touching code that is as delicate as the nav structure.

Especially on the main nav, or if it makes a mistake, all of a sudden your, your main nav breaks.

So we're using Client OS to check for errors and report them, and then it goes ahead and creates a Notion task about each of those errors and assigns it to our ADA expert.

So those are some of the automated tasks that we do with client OS, and we have a lot more of those in the backlog.

But let's, you know, shift gears a little bit and start looking at some of the ways that we're using AI to help create and evaluate the content on— on our site.

So here in this conversation, it started off with, you know, this is an existing store that had an existing site set up, and we went in and created a brand definition and then started evaluating the site for compliance with the brand.

So in this chat here, I just said, hey, evaluate this page for a campaign that we're doing and tell me if it conforms to our brand guidelines or not.

And it came back and said, you know, overall score, 6 out of 10.

And 6 out of 10 is really low, right?

When we create content from scratch from ClientOS, it's about a 10 out of 10 most of the times because it's so good at following rules.

So it gave us an overall score of 6 out of 10 and then, you know, told us what was good and then gave us recommendations on where things were not in compliance.

And then I could ask it to, you know,, you know, go ahead and edit the page and update it with its recommendations.

And then, you know, we worked on it, you know, back and forth a few times and then got that page up to be brand compliant.

So we, we're doing this, you know, we can do it page by page.

We also do email by email inside of Klaviyo when we take over an existing store and bring it into Client OS.—

And because we have the ability to evaluate any page on the website, another powerful thing that I really enjoy doing inside of Client OS— if we just give it a task to go ahead and look at the customer reviews, right?

I love looking at customer reviews to understand the way that customers are speaking about the brand.

What are they liking about the brand?

And more importantly, what words did they use to describe the brand?

So we just ask it to do a sentiment analysis and come back with the pros and cons of the brand and the actual words that get used.

So then the AI goes off, looks at all the customer reviews, and comes back with recommendations on what words we should be using and how we should be describing the brand in the way that the customers are describing it themselves.

And then we can take that and we can go and update our brand guidelines based on that.

So, you know, we establish really rich brand guidelines, but every so often we go in and check in with our customers by looking at their reviews that they leave and make sure that our language is the language that you're— they're using.

So we're always in sync.

Yeah, another thing we use Client OS for is creating mockups.

Now I say mockups here, now that could be at the page level or at the image level.

even at the image level, we rarely use images that come straight out of Client OS.

I find that AI, all of the tools just aren't good enough to give me a brand-worthy image without serious work on it, right?

And by serious work, I mean, you know, going back and forth multiple times and iterating on the image that it generates.

Even though we give strong brand guidelines to ClientOS, AI is still—

in my experience, doesn't follow the rules as well on images as it does on text, right?

So we do use it for idea generation.

So on this one here, we're saying, hey, give me some homepage banner ideas for this brand, right?

And it, you know, gave me ideas first, and then I said, all right, let's go ahead and, you know, mock it up and show me some examples of it.

So it started, you know, we agreed on what the concepts of them would be, and then it gave me, you know, its imagery that it's thinking of.

To map to our brand.

And if, you know, if you were to look at this brand, you'd go, yeah, it's, it's close, but it's nowhere near perfect to the way we represent our brand.

But what we do is we take these ideas and mockups, work with the brand owner, come up with the one that they like, and then we take it to our graphics team who will make the image using AI or not using AI.

But it's great for us to ideate on a bunch of different alternatives and then pick the one we like to go double down on outside of this tool.

And now upping the complexity level a little bit on what we're doing with client OS.

In this example, what we're doing is we're actually designing a landing page.

So it gives us a mockup.

Again, we talk about ideas back and forth, but then we say, all right, this is great.

We like what we're talking about here.

Now go build that., right?

And it actually goes into Klaviyo, creates a page, creates a template in the theme, assigns that template to the page,

and then looks at all the sections that are available in that store, figures out which ones most closely match the design that we're making, puts those sections in place, and then fills in the content.

So this is super powerful.

Still a work in progress.

We're working on the skills to make this even better all the time, but it's already started accelerating the time it takes for us to get from idea to a draft page in place for the store to work with.

 

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.