I did not get into technology for a career. I got into it because I wanted to know how things worked. And in the early 90s, if you were a kid with a computer, the things you wanted to understand were games.

Type "Open Door"

If you grew up on Sierra games, you know the drill. King's Quest. Space Quest. Police Quest. Leisure Suit Larry, if your parents weren't paying attention. These games didn't hand you anything. You typed commands into a parser and hoped the game understood you.

"Look at tree." "Climb tree." "Take egg."

That parser was brutal. It wanted exact words in an exact order. Type the wrong verb and you got nothing. Type the right verb at the wrong time and you died. Sierra loved killing you.

Here's the thing nobody realized at the time: that parser was teaching us syntax. It was teaching us that computers are literal. That the machine does exactly what you tell it, not what you meant. That precision matters and vagueness fails.

That is programming. That is the whole job. The parser was a compiler with a sense of humor.

Before the Game Even Started

Sierra games taught you more before you ever saw the title screen. To play a DOS game in the early 90s, you had to earn it.

You edited CONFIG.SYS and AUTOEXEC.BAT by hand. You learned the difference between conventional memory, extended memory, and expanded memory because Space Quest IV would not run without enough of the right kind. You made boot disks. You figured out IRQ settings so your Sound Blaster would make noise. You memorized DOS commands because there was no other way to move around your own machine.

None of that felt like learning. It felt like the price of admission. But it built something real: a mental model of how a computer actually works. Files, memory, drivers, hardware. You knew what was under the hood because you had to reach in and touch it just to play a game.

Then Came the BBS

Somewhere in there, I set up a BBS in my house. One phone line, a modem, and a piece of software that turned my computer into a place other people could visit.

If you never experienced a BBS, here is the short version. People dialed your phone number with their modem. One at a time, because you had one line. They left messages, played door games, uploaded and downloaded files.

TradeWars 2002 was the big one for me. If you know, you know. A space trading game rendered entirely in ANSI text, played in daily turns, one caller at a time. You hauled cargo between ports, built up your ship, planted colonies, and schemed against everyone else on the board. Somebody would blow up your fighters overnight and you would spend the whole school day plotting revenge. Alliances formed. Alliances got betrayed. All of it playing out over weeks on a single phone line in my house.

Running the TradeWars game was its own education too. As the sysop I managed the game settings, reset the universe when it got stale, and watched how a handful of rules could create an entire economy and a social scene around it. That is systems thinking. I just thought it was fun.

Running a BBS meant you were not just a user anymore. You were the operator. You configured the software. You managed the file areas. You dealt with the kid who kept tying up the line. You learned what happens when your system goes down and people notice.

That was my first taste of running infrastructure. I did not know to call it that. But it was the same job I do today, just smaller. Something you built, that other people depend on, that has to work.

Why That Era Made Programmers

The early 90s had a specific magic to it, and it was not nostalgia. It was friction.

Computers back then were transparent by necessity. There was no app store. There was no "it just works." Everything you did required understanding a layer below the thing you actually wanted. Playing a game required understanding DOS. Running a BBS required understanding modems and serial ports. Copying a game from a friend required understanding disks and file systems.

The gap between "using a computer" and "programming a computer" was tiny. You were already in the terminal. You were already editing config files. Writing a batch file was a small step. Writing a QBasic program was one more. The machine invited you in because it had no way to keep you out.

Games were the motivation. Curiosity was the fuel. Friction was the teacher.

What's Out There for Kids Today

So here is the question I get, usually from parents: computers are sealed boxes now, phones even more so, so where does a kid get that same experience?

The good news is the on-ramps still exist. They just look different.

Minecraft is the BBS of this generation. Kids run their own servers. They install mods. They write command blocks and redstone logic, which is genuinely circuit design whether they know it or not. A kid managing a Minecraft server for their friends is doing exactly what I did with my BBS. Infrastructure, users, uptime, drama and all.

Roblox is where kids ship products. Say what you want about the platform, but kids are building actual games in Lua, publishing them, and watching real people play them. That feedback loop of build, ship, see people use it, fix what broke, is the whole job compressed into something a ten-year-old can do.

Scratch is the new QBasic. Drag-and-drop blocks instead of typed syntax, which purists complain about, and the purists are wrong. It teaches logic, loops, events, and variables. The syntax can come later. The thinking is the hard part.

Raspberry Pi is the new bare machine. Forty bucks gets a kid a computer that is transparent again. Linux, a terminal, GPIO pins you can wire things to. It brings back the friction on purpose, and friction is where the learning lives.

And AI is the new parser. Kids today are learning to talk to machines through prompts the way we learned through "look at tree." The lesson is the same one Sierra taught us: be precise, understand what the machine actually did, and don't trust output you can't explain. AI can generate code faster than any of us ever typed it. Someone still has to understand what got built. That was true in 1992 and it is more true now.

The Fundamentals Didn't Change

The frameworks change every couple of years. The fundamentals do not. What made a kid into a programmer in 1992 is the same thing that does it in 2026: curiosity, a machine that lets you poke at it, and something you care about enough to fight through the frustration.

For me it was a Sierra parser that killed me a hundred times and a phone line that tied up the house every night. For a kid today it might be a Minecraft server or a Raspberry Pi in a shoebox.

The tools are different. The discovery is the same. Give a kid a machine, give them a reason to care, and get out of the way. The only way to learn is to try.

HubSpot just learned an expensive lesson about trust. It took them four days.

On July 1, HubSpot quietly updated its terms of service. Buried in the fine print was a big change: data from your CRM could be pooled into a shared commercial dataset and used to enrich other customers' records. Business contact info. Company data. Email engagement signals like opens, clicks, and bounces. Even data you imported and cleaned yourself.

Here's the part that set people off. Everyone was opted in by default. If you didn't want your data feeding the pool, you had to find the setting and turn it off yourself.

The backlash was immediate. By July 5, HubSpot published a post titled "We Got This Wrong. And We Are Fixing It." They killed the terms change and promised that any future data sharing would be fully opt-in.

Credit where it's due. They owned the mistake publicly and reversed fast. That's more than most companies do.

But if you run a business, or you market for one, there are lessons here worth sitting with. Because this story is bigger than HubSpot.

What HubSpot Was Actually Trying to Do

The plan wasn't evil. It was strategic.

HubSpot was building a product called Contact Discovery, set to launch in August. The idea: let sales teams find and verify new contacts without leaving HubSpot. To power it, they needed a massive, constantly refreshed contact database.

And they were sitting on one. Hundreds of thousands of live CRMs, updated every day by real businesses doing real work. Your data entry. Your list cleaning. Your bounce handling. Pool all of that together and you have one of the freshest B2B datasets on earth.

The problem was never the product. It was the mechanism. Instead of asking customers to contribute, HubSpot changed the terms and flipped everyone's switch to ON.

That's not consent. That's a bet that you won't notice.

This Model Isn't New

Here's what most of the coverage missed. Plenty of companies already do this. They just do it out in the open.

ZoomInfo built its entire business on a contribute-to-access model. You get access to their database, and in exchange, their software reads contact data from your email. Apollo, Lusha, Seamless, and a dozen other tools run some version of crowdsourced contact data. It's the standard playbook in the sales data world.

The difference is that those are data companies. When you sign up for ZoomInfo, you know the deal. You're trading your data for theirs.

A CRM is different. A CRM is supposed to be a system of record that you own. You bought the software. You built the database. You paid your team to maintain it. When the vendor decides your database is now an input to a product they sell to everyone else, including your competitors, that's not a feature. That's a fundamental change to the relationship.

HubSpot tried to make that change with a terms update over a holiday week. Customers noticed. Good.

Why This Will Happen Again

Don't mistake this reversal for the end of the story. HubSpot said they still believe in a shared, continuously improving dataset. They're just going to relaunch it with clearer opt-in.

And the pressure that pushed them here isn't going away.

Contact data is getting cheap. Tools like Clay and Apollo are driving the price of raw B2B data toward zero. When the data itself is nearly free, the only lasting advantage is a dataset that gets better as more people use it. That's a network effect, and every software vendor with a large customer base is thinking about how to build one.

Which means every vendor with access to your data is looking at it and wondering what else it could be worth.

Your CRM. Your email platform. Your field service software. Your review management tool. All of them are sitting on customer data that you created. Expect more of them to ask for it. Some will ask nicely. Some will bury it in an update to the terms.

What This Means If You Run a Contracting Business

I work with home service contractors every day. HVAC, plumbing, electrical, roofing. And I'll tell you what I tell them.

Your customer list is one of the most valuable things your business owns. It took years to build. It's full of people who already trust you, already paid you, and will call you again if you stay in front of them. No lead vendor can sell you anything close to it.

Most contractors are not reading terms of service updates. They're running crews, quoting jobs, and answering phones. That's exactly why this matters. The businesses least equipped to catch a quiet policy change are often the ones with the most to lose from it.

So here's the practical advice:

Know where your customer data lives. Every tool that touches your customer list is a potential leak point. Make a list. It's shorter than you think.

Ask your vendors the direct question. Is my data used to enrich, train, or improve anything outside my account? A good vendor answers in one sentence. A bad one sends you to a policy page.

Watch for opt-out defaults. Any time a vendor makes data sharing the default and puts the off switch on you, that tells you something about how they see the relationship.

Work with partners who read the fine print for you. A good digital partner absorbs this risk. They watch the terms changes, they lock down the settings, and they flag the problems before you ever hear about them on the news. If your vendor hands that job back to you, that's a red flag.

The Bottom Line

HubSpot's reversal proves something encouraging. Customers still have power. Enough noise in four days killed a plan that took months to build.

But the direction of the industry is clear. Your data is the product now, and every vendor wants a piece of it. Opt-out is not consent. Defaults are not choices. And the businesses that protect their customer data today will be glad they did.

Real businesses are built on real relationships. Guard the list.

---

Sources and further reading:

• HubSpot Scraps Opt-Out Data Sharing Plan Days After Announcing It (CMSWire)
• HubSpot Spent 20 Years Selling Trust. It Took Four Days of Fine Print to Put It on the Line. (The State of Brand)
• HubSpot Data Pooling: What Changes on 4 August 2026 (Value Gravity)

If you've sat through a pitch meeting or skimmed any product strategy deck lately, you've heard the word "moat." It's everywhere. Network effects are a moat. Switching costs are a moat. Proprietary data is a moat. Your brand is a moat. Somebody on a panel is, right now, explaining why their AI wrapper has a "durable moat."

I use the word too. It's useful shorthand. But the constant repetition has started to make it feel like something you say to sound smart rather than something you actually have to earn. So let me push on it, and then tell you what our moat at Red Barn Media Group really is, because I think it's the least glamorous and most defensible kind there is.

The word is new. The idea is ancient.

Warren Buffett popularized "moat" as an investing concept decades ago, and he didn't invent the underlying idea either. He just named something businesses have always known: the question isn't whether you can win a customer today, it's whether you can keep them tomorrow when somebody bigger, cheaper, or louder shows up.

That's the whole concept. A moat is just the answer to "why won't this be easy to copy?"

Medieval guilds had moats; they controlled who was allowed to learn the trade. The railroad barons had moats; they owned the land the tracks ran on. The local hardware store that's survived three Home Depots opening nearby has a moat, even if the owner would never use the word. He knows every contractor in town by name and what they're building this season.

So when software people talk about moats like it's a recent discovery, it's a little funny. We've dressed up a very old survival instinct in venture capital clothing.

Why software made everyone moat-obsessed

Software made the moat conversation more urgent for a real reason, not just a fashionable one.

In traditional business, a lot of your moat came free from physical reality. Distance protected you. Shipping product and building stores is expensive, so a competitor couldn't appear in your market overnight. Geography did the defending for you.

Software deleted that. When your product is a URL, distance is zero. A competitor in another country reaches your customer as easily as you do. Distribution is nearly free. Copying features is fast. The cost of serving one more user rounds to nothing, for you and for the person trying to eat your lunch.

So in a world where the old physical moats evaporated, software people had to get deliberate about manufacturing new ones. That's the obsession. SaaS founders talk about moats constantly because SaaS is born without one. You have to go build it on purpose.

The moats everyone lists (and why most are shakier than they sound)

The standard menu goes like this:

Network effects. Your product gets better as more people use it. Real, powerful, and rare. A lot of companies claim it when what they have is just "a lot of users," which isn't the same thing.

Switching costs. Once a customer's data and workflows live in your tool, leaving hurts. Legitimate, but it cuts both ways. Customers resent feeling trapped, and "we're annoying to leave" isn't "we're worth staying for."

Proprietary data. The current favorite, especially with AI in the mix. But data is only a moat if it's hard to get, genuinely useful, and yours to use. A lot of "proprietary data" is none of the three.

Brand. Slow to build, hard to fake, underrated. But brand without substance is a logo, and customers figure that out fast.

Economies of scale. Works great until someone burns money to undercut you, which in software happens roughly every Tuesday.

These are real categories. But notice how many are things you assert rather than things you can prove. That's the buzzword trap: "moat" becomes a word you reach for to make a weakness sound like a strategy.

The real test

Here's the test I apply, to us and to everyone throwing the word around: a real moat is something your competitor can fully understand and still not replicate.

If knowing your secret lets someone copy it, it was never a moat. It was a head start. The hardware store's relationships, the guild's controlled training, our accumulated judgment: you can explain all of them out loud and your competitor is still stuck, because the barrier isn't knowing, it's doing the years.

So use the word "moat" if you want. I will. Just make sure you can finish the sentence honestly: "...and the reason a smarter, richer competitor can't copy this is _______."

If you can't fill in that blank with something real, you don't have a moat. You have a buzzword.

For about twenty years, schema markup did one thing. It answered a question.

What is this page about?

You marked up a product so Google could show the price. You marked up an article so it could show the author and the date. You marked up your business so the hours showed up in the little box on the right. That was the whole game. Schema was a description layer. You told the machine what was already sitting on your page, and the machine displayed it a little better.

That era is ending. Not because describing things stopped mattering. It still matters. But a second question is showing up right behind the first one, and it changes everything.

What can a machine actually do here?

The agent doesn't browse your site. It uses it.

Think about how a homeowner books a service call today. They land on a contractor's site. They scan for a button that says "Schedule" or "Book Now." They pick a service. They squint at a calendar. They pick a slot. They fill out a form. They hit confirm. Every single step is a human looking at a screen that was built for human eyes.

Now picture an AI agent doing the same job for that homeowner.

The agent doesn't want your hero image. It doesn't care about your nav menu or your carousel of five-star reviews. It wants three things, and only three things:

1. What services do you offer?
2. When are you available?
3. How do I lock one in?

If that agent has to crawl your page and guess which button is the real submit button, the whole thing is held together with tape. It breaks the moment you redesign your site. It breaks if you move a form field. It breaks if a plugin updates.

So the web is starting to do something smarter. Instead of making agents guess, sites are starting to just tell them. Here is what you can do. Here is exactly how to do it.

That's the leap. Your website stops being a place to look at and becomes a set of things you can do. Your sitemap of pages picks up a shadow. A sitemap of actions.

The funny part: this vocabulary has been sitting there for years

Here's what I love about this. The tools for it already exist. They've existed for a long time. Almost nobody used them.

Schema.org, the same vocabulary you've been using to get rich snippets, baked in something called Actions years ago. ReserveAction. BuyAction. ScheduleAction. OrderAction. These were built to describe not what a thing is, but what you can do to it.

And they basically sat in a drawer. Unused. Because there was no reason to use them. A search engine showing a blue link had no need to know your booking endpoint. Why would it? It just needed to show the link and let the human do the rest.

Now the human isn't doing the rest. The agent is. And suddenly that dusty old vocabulary is the most important thing on your site.

Here's what it actually looks like. Say you're an HVAC contractor and you offer a furnace tune-up. Today your schema probably looks something like this:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Furnace Tune-Up",
  "provider": {
    "@type": "HVACBusiness",
    "name": "Green Mountain Heating & Air"
  },
  "areaServed": "Burlington, VT"
}

That's fine. That's a description. It tells a machine this page is about a furnace tune-up offered by a company in Burlington. A search engine can read that and show it. Good.

Now here's the same thing, but built for an agent that needs to actually do something:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Furnace Tune-Up",
  "provider": {
    "@type": "HVACBusiness",
    "name": "Green Mountain Heating & Air"
  },
  "areaServed": "Burlington, VT",
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "USD"
  },
  "potentialAction": {
    "@type": "ScheduleAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://greenmountainhvac.com/book?service=furnace-tuneup",
      "actionPlatform": "https://schema.org/DigitalPlatform"
    },
    "result": {
      "@type": "Reservation"
    }
  }
}

Read that second one carefully. It's not saying "this page is about a furnace tune-up." It's saying "this thing is bookable, it costs $149, here is exactly where the booking happens, and here is what you get back when you do it."

That's not a label anymore. That's a lever. The agent can pull it.

And notice what just happened to your pricing

Look at that block again. There's a number in it. $149.

For twenty years that price tag, if you even put one in your markup, was decoration. A nice-to-have. Maybe it showed up under your search result and made the listing look a little more complete. It was a string of text a human glanced at and then ignored or didn't.

That's over too. In the agentic web, the price isn't decoration. It's an input. The agent reads it, compares it, and decides on it. Your Offer and your price and your priceCurrency aren't there to look nice in a snippet anymore. They're the numbers a machine uses to make a buying decision on a real person's behalf.

Sit with what that means. When a homeowner tells their agent "find me a furnace tune-up under $200 this week," the agent isn't reading your headline. It's reading your Offer. If your price is wrong, stale, or missing, you don't show up in that comparison. Not because you ranked badly. Because you never gave the machine a number to work with. You weren't even in the room.

This is the part a lot of people are going to get burned on. Plenty of contractors keep their real pricing vague on purpose. "Call for a quote." That worked fine when a human was on the other end, because a human would call. An agent won't call. An agent that hits a wall where the price should be just moves on to the contractor who put a real number there.

I'm not saying publish every price for every job. Some work genuinely needs a site visit before anyone can quote it honestly, and pretending otherwise is its own kind of BS. But for the stuff that has a real, knowable price, a tune-up, a service call fee, a standard install, that number needs to be in your structured data, accurate, and current. Treat it like the working part of the machine it's about to become. Because a wrong price an agent acts on isn't a typo anymore. It's a transaction.

A whole new stack is getting built on top of this right now

If it were just the old schema vocabulary waking up, that'd be interesting enough. But in 2026 there's a whole layer of new standards getting built to make these actions executable, not just declarable.

I'm not going to pretend I have a crystal ball on which one wins. Nobody does yet. That uncertainty is part of the story. But here's the short version of what's in play:

WebMCP, proposed by Google and Microsoft and now being worked on at the W3C, lets a website register actual tools an agent can call. "Check availability." "Add to cart." "Start a booking." The agent calls the tool directly instead of reverse-engineering your buttons.

NLWeb, from Microsoft, turns your site into something an agent can just ask questions of through a standard endpoint. The thing I find telling: it's built on top of existing schema and feeds. By the same guy who shaped Schema.org and RSS in the first place. He's not throwing out the old work. He's building on it.

Commerce protocols from Google and Shopify and OpenAI are turning checkout itself from a page you look at into a protocol a machine can run, with the payment piece handled by its own emerging standards.

Different approaches. No clear winner yet. But every single one of them assumes the same thing underneath. Clean, accurate, structured data.

And that's the whole point I keep coming back to.

This is the fundamentals argument all over again

I've said this for years and I'll say it again here because it's never been more true. The flashy stuff on top changes every couple of years. The fundamentals don't.

All these new protocols, the ones getting all the attention right now, are sitting on top of structured data. If your site is modeled well, if your entities are clean and accurate and actually reflect your business, you're most of the way ready. You barely have to do anything.

If you treated schema as a rich-snippet trick, something you bolted on to game your way into a better-looking search result, you've got nothing for an agent to stand on. The house of cards doesn't fall down dramatically. It's worse than that. It just quietly does nothing while your competitor's site gets used.

This is the same thing I say about every shortcut in this industry. Fake reviews. Private blog networks. Inflated metrics. Anything built to fool an algorithm instead of serve a customer. It works right up until it doesn't, and when it stops working it costs you more than it ever paid. The agentic web is just the newest version of the same lesson. The boring, real work is what holds up. Everything else is borrowed time.

The hard part isn't the markup. It's understanding your own business.

Here's where this gets real for contractors and for anybody running an actual business instead of a marketing demo.

The markup is the easy part. Copying that JSON block up there is the easy part. Anybody can do that.

The hard part is mapping what your customer actually does. Walk through it. A homeowner's furnace dies in January. What are the real steps? They need to find you. They need to know you handle emergencies. They need to book. Maybe they need to reschedule. They need a quote. They need to know when the tech is coming.

Every one of those steps is a real-world action. And every one of them has to be made legible to a machine that has no eyes and no common sense. It can't infer. It can't squint at your page and figure it out like a person would. You have to tell it, cleanly and explicitly, exactly what it can do and how.

That's not keyword work. That's not even really SEO in the old sense. That's understanding how your business actually runs, step by step, and being able to describe it to a machine. Which, if I'm honest, is the whole job and always has been. The markup just makes you prove you actually understand the process.

What this means for you, plainly

For most of the time I've been doing this, the goal was visibility. Be found. Be ranked. Be shown. Get cited.

That still matters. But there's a second thing now, and it's a different axis entirely. Call it actionability. Can an agent actually use you?

Because here's the uncomfortable truth. A page can rank perfectly, look beautiful, and load fast, and still be a complete dead end to an agent. Because it never said what you can do with it. In the old web, a great-looking inert page was still useful, a human could figure it out. In the agentic web, an inert page is just a wall.

The contractors and businesses that win the next decade won't be the ones with the most pages an agent can read. They'll be the ones with the most actions an agent can complete.

Book the appointment. Get the quote. Reschedule the visit. Buy the part. Each one of those, exposed cleanly, as a thing a machine can actually do.

So here's my advice, and it's the same advice I'd give about anything.

Don't chase the protocol wars. Don't wait for a winner to be declared. Get your fundamentals right. Model your business honestly in your structured data. Map the real actions a customer takes and make every one of them clean and explicit. Do that, and whichever standard wins, you're ready.

Keep it simple. Make it work. And build it on something real.

The vocabulary's been waiting in the drawer for years. The agents finally showed up to use it. The only question is whether your site has anything for them to do.

For two years now, the marketing industry has been pitching contractors a new acronym every six months.

AEO. GEO. AI Optimization. LLMS files. Special schema. Content chunking. AI-friendly rewrites.

A new shortcut. A new service tier. A new invoice line item.

This week, Google published an official guide called Optimizing your website for generative AI features on Google Search. It went live on May 15, 2026, on the Search Central blog.

I will save you the click. Here it is, in their own words:

“Is SEO still relevant for generative AI search? In short, yes!”

That is not a tease. The rest of the guide spends most of its time telling site owners that the things being sold to them as “AI SEO” do not actually do anything. Same playbook. Same fundamentals. Same work.

What Google says you can ignore

The guide has a section called “Mythbusting generative AI search.” These are the tactics Google is officially telling you to skip:

• llms.txt files and other “special” markup. You do not need AI text files, machine readable files, or any special markup to appear in AI features. Google may crawl those files. That does not mean it treats them as special.
• Chunking your content. No need to break pages into tiny pieces for AI to understand them. Google’s systems handle nuance across multiple topics on one page.
• Rewriting content just for AI. AI understands synonyms. You do not have to capture every long-tail variation or write in some special “AI-friendly” way.
• Seeking inauthentic mentions. Buying blog mentions, fake reviews, paid forum posts, and any other manufactured “AI citation” play. Google says quality is what gets cited and that spam systems block the rest.
• Over-doing structured data. There is no special schema just for AI Overviews. Existing structured data is still useful for rich results. That is it.

If your marketing vendor has pitched any of these as the new must-have for AI search, you now have Google’s own public documentation saying it does not matter.

What still works

Same things that worked last year. Same things that worked five years ago.

• Unique, non-commodity content. Google’s example, almost word for word, is the difference between “7 Tips for First-Time Homebuyers” and “Why We Waived the Inspection & Saved Money.” One is recycled common knowledge. The other is real, lived, expert-led experience. For contractors, this is your home turf. The install nobody else would touch. The repair that turned out to be three problems stacked. The truck-roll that saved a homeowner ten grand. That is the content that earns visibility in AI search.
• Clear technical structure. Pages have to be crawlable, indexable, and eligible to appear in Search. Site has to work on mobile. It has to load. The main content has to be easy to find.
• Good page experience. Easy to read. Easy to use. Not buried under junk.
• Real local and business signals. Google Business Profile. Merchant Center. Accurate, consistent business details. The unglamorous infrastructure that has always mattered.

That is the whole list.

Why this matters for contractors

Here is the part I care about most.

Contractors have been getting pitched “AI optimization packages” for over a year now. Some of those pitches come with five-figure monthly fees. Most of them are either repackaging things that were already part of basic SEO, or selling tactics that Google is now publicly saying do not work.

If a vendor is asking you to pay extra for:

• An llms.txt file on your site
• “AI-ready content rewrites”
• A “GEO audit”
• “AI citation building”
• Special schema markup just for AI Overviews

Ask hard questions. Google’s official position, in a public document updated this week, is that none of that is required to show up in AI Overviews or AI Mode.

What is required is the work. Useful content from people who actually do the job. A site that loads. A real business with real signals.

The takeaway

Nothing changed.

The interface changed. AI Overviews show up. AI Mode exists. Citations are surfaced differently. The way clicks come in is shifting, and the traffic data is real.

But the work that earns visibility? Same work as always.

Earn it with content real people actually want. Build it on a site that works. Run a business that deserves to be recommended.

That is what we have been telling our contractor clients since AI Overviews launched two years ago. Now it is in Google’s own documentation.

Keep it simple. Make it look beautiful. Have it work.

The shortcuts never worked. They just took longer to fail.

Last month Google Labs open sourced the format that powers their Stitch tool. It is called DESIGN.md. A single Markdown file. YAML at the top with your design tokens. Prose underneath explaining the why. Drop it in your project root and your AI coding agent reads it before it writes a line of UI.

If that pattern sounds familiar, it should.

CLAUDE.md does the same thing for code. AGENTS.md does it for general agent behavior. README.md has done it for humans reading your repo for thirty years. Now DESIGN.md does it for visual identity.

You are going to see a lot more of these. Buckle up.

The Pattern

The shape is always the same. Plain text file. Lives in your project root. Versioned in Git. Readable by a human. Parseable by a machine. No platform, no plugin, no lock in.

You can already see where this is headed. SECURITY.md for your security posture. DATA.md for your schema and naming conventions. BRAND.md, TONE.md, VOICE.md for marketing. Whatever the next agent needs to know about your business, somebody is going to write it down in a Markdown file and check it into the repo.

This is good. This is how it should work.

Autonomous Does Not Mean Omniscient

Here is the part people keep missing about AI agents.

Autonomous and smart are not the same thing. An agent can run on its own. That does not mean it knows what you want. It does not know your brand. It does not know your tolerances. It does not know that your contractor client's customers are mostly homeowners over fifty who will not tap a button smaller than their thumb. It does not know that your manufacturer partner has spent twenty years building a quiet, engineered brand and would rather die than ship a screen with a gradient on it.

It cannot know any of that. Not until you tell it.

Most of the complaints I hear about AI output come back to the same thing. The agent did exactly what it was asked to do. It just was not asked the right way. It did not have the context. So it guessed. And the guess looked generic, because the average of everything on the internet is generic.

The fix is not a better model. The fix is better inputs.

Constraints, Guardrails, Variables

That is what these Markdown files actually are. Constraints. Guardrails. Variables. The three things every good engineer and every good designer has always used to make sure the output is not a coin flip.

A DESIGN.md file says: these are your colors, these are your type sizes, this is the why behind them, here is what you do not do. That is a guardrail. It does not slow the agent down. It points it in the right direction so the work it produces is actually useful.

CLAUDE.md does the same thing for code. Here are the conventions we use. Here is the framework we have picked. Here is what we do not want, even if you have seen other people do it. Same pattern. Same purpose.

This is not gatekeeping the AI. This is operating it the way it was meant to be operated.

Now Think About Your Own Business

Here is where I want you to stop reading for a second.

Think about your business. Your craft. The thing you do every day that you are good at. Now ask yourself: what are the rules of how it works that you have never written down?

Every business has them. They live in the head of the founder. They get repeated in the meeting the new hire missed. They show up the moment somebody does it wrong and gets corrected. Tribal knowledge. Unwritten. The stuff "we just kind of know."

That is your DESIGN.md. That is your CLAUDE.md. That is your AGENTS.md. You just have not written it yet.

If you run an HVAC shop, your rules might be: we run service calls in these zip codes and not those. We do not sell on price. We answer the phone in two rings during business hours and within fifteen minutes after hours. We do not install equipment we cannot service ourselves. Our techs wear shoe covers, every time, no exceptions. Those are guardrails. They are why your customers trust you. Right now they live in your head.

If you run a manufacturing brand, your rules are the ones your dealers are quietly bending in ten directions right now. Logos in the wrong colors. Co-op ads that look nothing like your brand. Product photos shot in somebody's garage under fluorescent lights. You have a PDF brand book somewhere. Nobody reads it because nobody can search it, version it, or hand it to an agent.

If you run an agency, your rules are the ones the new project manager learns the hard way. What clients you take. What you charge. What stack you build on. What you say no to. What "done" actually means.

None of that is in a Markdown file yet. It probably should be.

My Version of This

At Red Barn we have been doing this in pieces for years. Our tech stack is documented. Our design system is documented. The way we build SEO for a contractor is documented, because we have done it hundreds of times and the process is the process.

Now we are writing it for the agents. Same content, slightly different format. Tokens at the top. Prose underneath. The why next to the what. So when an AI helps us build a contractor's site, it does not start from the average of the internet. It starts from how we do it. Our colors. Our defaults. Our patterns. Our reasons.

That is the work. Not picking the model. Not chasing the new tool. Sitting down and writing down what we actually do, in a format that a human and a machine can both read.

Most businesses I see have not done this. The rules live in the founder's head and in the team's habits. It runs fine that way until you want to scale, or hire, or hand off, or use any tool that needs to be told what good looks like. Then the absence of written rules is the bottleneck.

AI is exposing this. AI is not the only reason to write your business down. It is just the loudest one.

What This Means If You Pay for Software

If you are a contractor, a manufacturer, or anybody buying digital work from an agency, here is the part to take with you.

The companies that get good output from AI are not the ones with the fanciest model. They are the ones with the best inputs. The clearest brand. The cleanest standards. The most explicit guardrails. If your vendor cannot tell you where their constraints live, where your tokens are defined, where the rules for your project are written down, your output is going to be generic no matter how powerful the model is.

Ask where the Markdown lives. Ask to see it. If the answer is "we just kind of know," you are paying for guesswork.

Where I Land

DESIGN.md is not a moment. It is a marker on a trend that started with README and is going to keep going. The shape of the future is small text files that tell agents what you actually want.

Autonomy without context is just expensive guessing. Constraints are not the enemy of speed. They are the reason speed is worth anything.

Write your business down. Version it. Hand it to the machine.

Simple. Beautiful. Works.