How to build a brand OS: a step-by-step guide

This guide is based on “Building a Brand OS,” a talk Fletcher Richman, co-founder and CEO of type.com, gave to an EcommerceFuel think tank of seven- and eight-figure brand owners on September 23, 2026. Every figure is a slide from his deck. Watch the talk

Most ecommerce brands already use AI. Marketing has ChatGPT open all day, someone in ops built a clever Claude project, and finance tested a reporting prompt. The company as a whole still isn't getting much out of it.

Fletcher has spent the past year talking with brands of every size, from Bombas, Coach, and True Classic to one- and two-person startups. He keeps hearing the same problem. Each person uses AI in their own way, with their own data and context. Ask for yesterday's revenue and you get one number on Monday and a different one on Tuesday. And the strongest AI users build up methods that nobody else on the team can reuse.

A brand OS fixes this. It gives the whole company one place for its data, one shared understanding of how the business works, and one set of agents and automations everyone can use.

Every brand Fletcher has worked with ended up with the same three layers. Skip the data layer and AI guesses. Skip the knowledge layer and AI sounds like it has never heard of your company. Skip the collaboration layer and all of it stays stuck on one person's laptop.

The 11 steps below follow the talk in order, plus what Fletcher recommended when attendees asked questions.

AI with no data is guessing. For a typical direct-to-consumer brand, four areas matter most. You'll have other sources too, but almost every question your team asks AI depends on these.

Connecting them is only half the work. Agree on definitions and reconcile the numbers, so that “revenue” means the same thing no matter which source the AI checks.

Before AI, a data warehouse was nice to have. Now it's close to essential for most brands. When data is spread across a dozen tools, any AI your team uses has to pull a bit from each one, and nothing is the single source of truth.

Fletcher's rule of thumb (type.com doesn't sell a data warehouse): under $5M in revenue and Shopify-only, Shopify can be your source of truth for now. Over $5M, or selling on more than one channel, evaluate a shared data platform.

He recommends three: Polar Analytics is a managed, Shopify-led warehouse and the lowest-touch option for teams with few engineers. Google BigQuery is his default: it works well out of the box, you own all your data, and most of the seven- and eight-figure brands type.com works with use it. Snowflake is a strong choice if it's already in your stack or your engineers prefer it.

An attendee asked whether plain Postgres or MySQL would do. It can, at a certain scale. Warehouses are built to take messy data from many sources and run lots of queries on it, so the answer depends on how many rows you have and how varied they are.

The knowledge layer didn't exist before AI. It answers one question: what does the system understand about your business? Fletcher's analogy is that a fresh chat with Claude or ChatGPT is a PhD-level hire who knows nothing about your company. The knowledge layer is the onboarding.

Start with static context, the part of your business that changes about once a month or once a quarter. Three rules apply. Write the files yourself; brainstorm with AI if you like, but the CEO or COO should be confident every line is right. Keep them short, because they load into a lot of AI requests. And review them monthly.

According to Fletcher, these four files make a model feel less like someone who's never heard of your company and more like someone who has been onboarded for four to eight weeks.

Dynamic context changes every day. The wiki lets future AI requests skip the raw pile: ask “what did we decide in yesterday's launch meeting?” and the agent goes through a tidy index instead of every meeting ever recorded. That saves tokens and makes answers faster. If the four context files are a new hire's first month, the wiki is their next two years.

Keep both folders somewhere in the cloud that the whole team and their AI tools can reach, not on someone's laptop. Fletcher sees four options: a type.com Space, a private GitHub repo for more technical teams, Notion, or Google Drive, which he finds messy for this job.

For permissions, start with public information only: shared inboxes, public Slack channels, shared Drive folders, and public meeting notes. Leave personal email and private notes out of the first version. Once that works, give sensitive teams such as finance their own /raw and /wiki with separate access.

Some large brands build a semantic layer, a custom set of definitions on top of the warehouse. Fletcher thinks that's overkill unless you're a nine-figure brand with plenty of resources. Shared skills do the same job for a fraction of the cost.

A skill is a set of instructions, and often code, that an agent follows every time someone asks a certain kind of question. Start with revenue, because “how are we doing?” is the first question everyone wants answered reliably. If you sell on only one channel, skills 01 and 02 can be one skill.

Unlike the context files, you don't need to write skills by hand. Work with an agent to draft them.

Will a skill give the same answer every time? It will if it runs code. Because step 1 gave the agent a data source, a good skill doesn't just read instructions; it runs SQL or a Python script against your warehouse. Ask for “revenue for the last seven days in Europe” and everyone gets the same number. Fletcher's caveat: skills won't fix messy data, and brands with years of history and many revenue sources may need cleanup first.

After the first four, keep adding skills. The goal is that what your best people know how to do stops living only in their heads and becomes something the whole team can run.

Governance matters more than it sounds. An experimental skill can be open to everyone. Your ROAS definition shouldn't be, or the company ends up reporting different numbers again.

Automations run on a schedule and post wherever your team works. Apps are dashboards and custom tools built for your business. Shared memory captures decisions and lessons as work happens; Fletcher says it “kind of creates itself” once the other three are running.

Fletcher defines an agent as one department (marketing, finance, operations) with access to that department's data, available wherever the team works: Slack, email, or Teams. Pointing an agent at a department works better than giving it a persona.

Wherever you build these, they can't live on one person's machine. Some brands with engineering teams build their own internal agent platform. Others use a shared AI workspace such as type.com.

Starting with agents across the whole company is overwhelming. Across type.com customers and the other brands Fletcher has talked to, three first workflows come up most often and pay off fastest. This is the first, and it's an automation.

It sounds simple, but for most brands it's the first real aha moment. It runs on your data layer and revenue skills, so the number is accurate, and the whole team sees the same thing every day. Run it daily for the people closest to the numbers and weekly, on Monday, for everyone else.

The second first workflow is an agent. Paid media generates more data than one person can review, and Fletcher says models are surprisingly good at finding ideas a human would miss.

The third first workflow is an app. AI is very good at writing code, so you can build a landing page for every ad variation, launch, or product test instead of a handful a quarter.

The brands doing this best have their agent write Shopify Liquid templates and push them straight to the store, so pages map to real product and inventory data. Some type.com customers now run hundreds or thousands of pages, each matched to the creative from their paid media agent. The details depend on your stack, including whether you're headless.

After the first workflows, you could build almost anything: inventory tools, ad generation apps, customer service agents. Brands often get stuck choosing. Pick by payoff, then go from baseline to small test to measure to scale.

If you're not sure where the opportunities are, point an AI at your Slack and email history and ask where the biggest revenue upside is. Often the problem isn't what AI can do. It's knowing what's possible.

In the Q&A, one attendee asked what to do about an employee who refuses to use AI at all. Fletcher passed on advice from a recent founder roundtable: going forward, make excitement about and familiarity with these tools part of the interview process.

A shared brand OS also lowers the bar for everyone else. People who never open an AI tool still get the daily report in Slack or email, and they can ask the department agent a question where they already work.

Power users don't have to give anything up. Another attendee asked whether this replaces Claude. It doesn't: the knowledge and skills stay shared, and people keep working from Claude. With type.com, the MCP server and CLI let someone build an automation from Claude that the whole team can then use. A one-off personal automation can stay in your own Claude; a shared one, like inventory alerts, belongs where everyone can see it.

And if your whole team already lives in GitHub? Claude plus GitHub can carry the context. You still need to choose how to run the automations, agents, and apps; a repository alone does not provide the shared operating layer.

Each layer has a clear finish line. Don't move on until the one below it works.