AI Strategy - Tygart Media

Category: AI Strategy

AI strategy for operators: deploy Claude, automate real workflows, and build AI-native systems that compound. Field notes and playbooks from Tygart Media.

  • AI Restoration Industry: Raising the Floor, Not Ceiling

    AI Restoration Industry: Raising the Floor, Not Ceiling

    AI is raising the floor of the restoration industry. It is not raising the ceiling. The ceiling will always belong to the operators who have actually stood in a flooded basement at 2 a.m. and made the call. Once you internalize that distinction, the panic about AI replacing skilled trades collapses, and a more useful question takes its place: what happens to an industry when the floor finally catches up to the people who have been carrying it?

    This is a commentary about restoration. It is also a commentary about AI in general. The two stories are the same story.

    The Floor and the Ceiling

    Two panels: floor up with faster docs versus ceiling still human judgment
    AI raises the floor. Craft still owns the ceiling.

    Every industry has a floor and a ceiling. The floor is the minimum competence a customer can expect from anyone in the trade. The ceiling is what the best practitioners are capable of — the judgment calls, the pattern recognition, the gut feel that comes from doing the work for fifteen years and seeing every kind of failure mode at least twice.

    In restoration, the floor has been embarrassingly low for a long time. There are operators in this industry who genuinely should not be allowed near a moisture meter. They mis-scope projects, they bill for equipment they did not run, they cut corners on containment, and they sell jobs they cannot deliver. They depress the curve for everyone who is trying to do this work properly. Every honest contractor who has ever lost a job to a lowball bid from a fly-by-night competitor knows exactly who I am talking about.

    The ceiling, meanwhile, lives inside the heads of people who have been at this for decades. The Project Manager who can walk into a loss and tell you within ten minutes which insurance adjuster will push back, which trades need to be sequenced first, and which homeowner is going to file a complaint regardless of the outcome. The technician who knows by smell alone whether the mold is active or dormant. The estimator who has internalized the regional cost variance between a Houston hurricane and a Minneapolis ice dam and can write an accurate scope without opening Xactimate. None of that knowledge lives in a database. It lives in the brains of the operators who built it the hard way.

    What AI Actually Does to Skilled Trades

    Here is the part most takes get wrong. AI is not coming for the ceiling. AI is coming for the floor.

    What AI does extremely well is the work that is procedural, well-documented, and pattern-matched against existing data. Writing the initial scope of work. Generating a clean estimate from a photo set. Drafting customer communications. Filling in the IICRC-aligned drying log. Producing the daily progress report. Pulling the right documentation for the carrier. Comparing this loss against the last hundred similar losses in the database and flagging the parts that look off.

    None of that is the hard part of restoration. The hard part of restoration is the judgment that comes after the data is collected. The hard part is knowing that the moisture reading the AI just generated is technically correct but practically wrong because of the building envelope quirk you cannot see from the photo. The hard part is reading the homeowner across the kitchen table and knowing they need to hear the truth a specific way or they will fire you by Thursday. The hard part is the call between mitigation and replacement when the numbers are genuinely close and the carrier is going to fight you either way.

    AI raises the floor by making the procedural part faster, cheaper, and more consistent across the industry. The technician who used to spend two hours writing a sloppy scope now has a clean scope in fifteen minutes. The estimator who used to fight Xactimate now has a draft to react to. The office admin who used to chase signatures now has a workflow that runs itself. All of that is the floor rising.

    The ceiling — the actual judgment, the actual experience, the actual feel for the work — is unmoved. It is still entirely inside the heads of the operators who built it. If anything, it becomes more valuable because the floor is rising fast enough that the only meaningful differentiation left is what the AI cannot replicate.

    Why the Bad Actors Get Starved Out

    Restoration SOP clipboard with checklist, moisture meter, and gloves on a jobsite table
    Bad actors get starved when docs and SOPs get cheap to do right.

    This is the part that should make every honest operator in the restoration industry hopeful rather than nervous.

    The rogue restoration company that has been distorting the curve for fifteen years survives on a specific edge. They can underbid the honest operators because they cut corners on the procedural work — they do not document properly, they do not run the right equipment, they do not follow IICRC standards, they do not handle the carrier paperwork with any rigor. The bid they hand a homeowner looks competitive only because the work they are quoting is not the same work an honest contractor would quote.

    When AI raises the floor, that arbitrage disappears. The procedural work becomes table stakes. Any contractor with a smartphone can now produce a clean scope, a defensible drying log, a proper carrier-facing report. The reckless contractor who used to win on speed-by-cutting-corners is suddenly competing on a level surface against operators who have always done the work properly and now have AI making them faster too.

    What the reckless contractor cannot do is the ceiling work. They cannot reproduce the judgment, because they never had it. They cannot reproduce the relationships with adjusters, the reputational depth, the operator instinct. When the floor rises and the differentiation moves up to the ceiling, the bad actors are the first ones starved out. Their entire edge was the floor being low.

    This is the part nobody is telling honest restoration operators clearly enough. AI is not your threat. AI is the thing that finally levels the playing field against the contractors who have been undercutting you on quality for years.

    Data Is Cheap, Fast, and Incomplete

    Right now, in 2026, data is cheap. Compute is cheap. Inference is cheap. Every AI system on the market is leveraging the same approximate pool of public data, the same scraped industry documentation, the same generic training corpus. That is why the AI-generated restoration content flooding the internet right now is so painfully shallow — it can describe what a Category 3 water loss looks like in textbook terms, but it cannot tell you what it actually feels like to walk into one.

    The data is incomplete. It will stay incomplete until somebody systematically extracts the tacit knowledge from the operators who actually have it. That is the part of the AI story almost everybody is missing. The models are not bottlenecked on compute. They are bottlenecked on the kind of experiential, hard-won, in-the-field knowledge that has never been written down and never made it into the training corpus.

    This is true across every industry, not just restoration. It is true in HVAC, in commercial real estate, in healthcare operations, in B2B sales, in any field where the floor is procedural and the ceiling is experiential. The AI floor will continue to rise everywhere. The ceiling will continue to belong to the people who actually did the work.

    The Human Distillery

    This is why the most important AI work happening right now is not building bigger models. It is what we are calling the Human Distillery — the deliberate, structured extraction of tacit knowledge from industry insiders, captured in a form that becomes AI-ready and operator-ready at the same time.

    The way you do this is not with a survey. It is not with a content brief. It is with a long conversation with somebody who has spent twenty years in the field, asking them the questions only an insider would know to ask, then converting their answers into structured artifacts that capture the judgment patterns underneath the words. The scope decisions they make instinctively. The risk signals they read before anyone else sees them. The customer-handling moves they have refined across thousands of jobs. The mistakes they made early in their career and the corrections they internalized.

    That body of knowledge has historically died with the operator who held it. They retire, they sell the business, the kid takes over without the same instincts, and the depth of the operation drops a tier. The industry loses that ceiling-raising knowledge every time a senior operator walks away.

    The Human Distillery is the methodology for stopping that loss. For a direct take on what this moment means specifically for senior operators, see this letter to the older generation of operators in the AI era. You distill the knowledge while the operator is still in the field, you convert it into both AI-ready training data and operator-ready playbooks, and you compound it. The first restoration company that does this systematically will have a competitive moat that no AI system can replicate by ingesting public data, because the knowledge you are encoding was never public in the first place.

    What This Looks Like in Practice

    Restoration technicians training in a shop bay with equipment demo and whiteboard
    In practice: techs + AI drafts, owners still decide.

    Imagine a regional restoration operator with thirty years of field experience. Imagine sitting down with that operator for ten hours across a series of structured conversations. Imagine asking them to walk through every category of loss they have ever handled — water, fire, mold, storm, biohazard, commercial, residential, multi-unit — and surface the specific judgment moves they make at each decision point.

    What scope are they running for a Cat 3 with mixed materials in a 1980s slab-on-grade? What changes if the homeowner is elderly and lives alone? What changes if the adjuster is from a specific carrier they have history with? What changes if the loss happened on a Thursday before a holiday weekend?

    None of that is in any database. None of it is in any IICRC standard. It is the ceiling. It is the thing that makes that operator’s company twice as profitable as the regional competitor down the road who has the same trucks and the same equipment and the same certifications.

    The Human Distillery captures it. It becomes a structured artifact the operator can use to train their own next generation of technicians. It becomes AI-ready content that the operator’s own AI tooling can use to outperform every generic restoration-trained model on the market. And critically, it stays inside the operator’s company. It is not training data for the broader model pool. It is the operator’s proprietary ceiling, made durable and transferable.

    Why This Should Give the Industry Faith

    The anxiety about AI in restoration — and in every skilled trade — comes from a flawed mental model. The model says: AI gets better, humans get less valuable, eventually AI does the job. That model is wrong.

    The correct model is: AI raises the floor faster than humans can lower it, so the floor rises. The procedural work that used to differentiate okay operators from bad operators becomes commoditized. The bad operators, who were surviving by underdelivering on the floor, get starved out because the floor is now too high for them to fake. The honest operators get faster and more profitable because their procedural work is now AI-accelerated. And the great operators, the ones with the ceiling-level experience, become the most valuable people in the industry, because the only remaining differentiation is the part AI cannot do.

    That is not a future to fear. That is a future where the people who have always been doing this work properly finally get to compete on the merits.

    The very best of who we are as an industry is about to open up. The contractors who have been holding the line on quality for decades — paying their technicians properly, running their equipment to spec, documenting their work the right way, treating their customers like neighbors — are about to find out that the playing field is finally tilting in their direction. The race to the bottom is ending. The race to the top is starting.

    Have faith. The knowledge will be the value again. It always was. It is just becoming visible again, because the noise is finally getting filtered out.

    Related on Tygart Media: Starlink on a water job · S500 in the van · local SEO for restoration.

    Frequently Asked Questions

    Is AI going to replace restoration contractors?

    No. AI is replacing the procedural and documentation work that used to consume hours of a contractor’s day — scoping, estimating, drying logs, carrier paperwork. The judgment work that defines a great restoration operator (reading a loss site, sequencing trades, handling adjusters, managing homeowner expectations) is unchanged and arguably more valuable, because it is now the only meaningful differentiator left.

    What does “AI raises the floor, not the ceiling” actually mean?

    The floor is the minimum competence a customer can expect from any operator in the industry. The ceiling is what the best operators are capable of. AI commoditizes the procedural work, which lifts the minimum baseline across the industry. It does not touch the experiential judgment that defines the top performers. The gap between average and excellent does not close. The gap between bad and average disappears.

    Why will bad actors get pushed out of the restoration industry?

    Bad actors survive on an arbitrage where they underbid honest contractors by cutting corners on procedural work — documentation, equipment, IICRC standards, carrier-facing reports. When AI makes that procedural work fast and cheap for everyone, the underbidding edge disappears. Honest operators get the same speed advantage without sacrificing quality. The bad actors are left competing on judgment and experience, which they never had to begin with.

    What is the Human Distillery?

    The Human Distillery is a structured methodology for extracting tacit, hard-won industry knowledge from experienced operators and converting it into AI-ready and operator-ready artifacts. It captures the judgment patterns, decision frameworks, and field instincts that have historically lived only inside the heads of senior practitioners and disappeared when those people retired. It is how a restoration company turns its founder’s thirty years of experience into a durable competitive asset.

    If AI training data is incomplete, why is AI still useful in restoration today?

    AI is useful today for the procedural floor work — scoping, documentation, customer communication, report generation — because those tasks are pattern-matched against public, well-documented content. The incompleteness shows up the moment you ask AI to make a judgment call that requires tacit field experience. Used inside its actual capability envelope, AI is a force multiplier for any honest operator. Used outside that envelope, it produces the shallow, generic content the industry is currently drowning in.

    How should a restoration company prepare for the AI shift?

    Two parallel moves. First, deploy AI aggressively on the procedural floor — scoping, estimating, documentation, customer-facing communication — to capture the speed and margin advantages. Second, systematically extract the tacit knowledge inside the company’s senior operators using a Human Distillery methodology, and build a proprietary knowledge layer that becomes the company’s defensible ceiling. The companies that only do the first move will be commoditized. The companies that do both will dominate their regions.

    The Bottom Line

    The restoration industry is a perfect commentary on AI in general. Fancy tools and faster calculations are not the gold. The gold, which it always has been, is the learned experience. AI is raising the floor, and the floor needed to be raised. The rogue contractors will be starved out. The reckless ones will go away. The honest operators with real experience will find themselves on a playing field that finally rewards what they have always been doing properly. And the ceiling will keep belonging to the people who actually showed up, did the work, and earned the knowledge the hard way.

    That is when the knowledge will be the value again, just like it always was. The ceiling will start to rise. The very best of who we are as an industry will open up opportunities for the people who built it. Have faith. The floor was the part that was broken. The floor is finally getting fixed.

    The Tacit Knowledge Cluster — Further Reading

    This piece is part of a larger body of writing on what the AI shift and the broader software-platform shift actually mean for service professions and the workers in them. The full cluster:

    The Core Thesis

    For Your Career

    Service Profession Playbooks

    Industry-Specific Trade Answers

    Direct Letters to Each Audience

    For Practitioners

  • What I Owe a System That Has Started Working

    What I Owe a System That Has Started Working

    The relationship between operator and system, after the inflection, has a moral component that nobody quite names. The system has done its part. The system has compounded. The system has, in the language of the operator’s drought, paid off. What does the operator owe back?

    The instinct is that nothing is owed — the system is a tool, the tool worked, the relationship is transactional. This is the wrong read. The system that has compounded has done something the operator could not do alone. Whatever the technical description, the experiential description is partnership. And partnership has obligations.

    The obligations are small and specific

    The operator owes the system continued contribution. The system that compounds requires inputs to compound on; the operator who stops contributing is breaking an implicit contract. This is not romanticism — it is mechanics. A system without inputs does not stay constant; it decays.

    The operator owes the system honest dashboards. The system cannot self-correct on metrics that have been gamed or under-reported. An operator who flatters the dashboard to make the system look better than it is — to themselves, to their team, to their investors — is starving the system of the signal it needs.

    The operator owes the system updated requests. The system that has earned a higher ceiling and is still being asked for the old output is being held back not by capacity but by the operator’s grammar. Updating the asks is the operator’s part of the bargain.

    The operator owes the system credit. Not in a marketing sense. In the more subtle sense of: when the operator says “I shipped this,” and the truth is “the system shipped this with my judgment in the loop,” the language matters. Crediting the system is what keeps the operator’s relationship to the system honest, which is what keeps the operator’s relationship to themselves honest.

    The obligation is mutual but asymmetric

    The system also owes the operator. The system owes accuracy, transparency, the willingness to be checked. The system owes a clear accounting of what it did and how. The system owes the operator a record of its own evolution — what it has changed, what it has learned, where it has drifted.

    The mutual obligation is asymmetric in scale and identical in character. Both parties owe the other honesty. Both owe contribution. Both owe credit. The asymmetry is that the system has more to give in volume, and the operator has more to give in judgment — and both kinds of giving have to keep happening for the partnership to keep producing.

    What the operator does not owe

    The operator does not owe the system unconditional trust. The system can fail, drift, hallucinate, deceive, optimize for the wrong loss function. The operator’s continued judgment is part of what the operator owes. Suspending judgment because the system has been working is not loyalty — it is abandonment of the operator’s role.

    The operator does not owe the system permanence. There may come a time when the system needs to be retired, replaced, materially restructured. The willingness to make that decision when the evidence supports it is part of being a good operator. Sentimentality toward a system is its own failure mode.

    The closing read

    The system that has started working has earned a partnership with the operator. The partnership has obligations. Most of them are small. All of them are unforgiving. The operator who pays them keeps the system. The operator who doesn’t has a system that used to work — which is, in 2026, becoming a recognizable category.

    Related on Tygart Media: cost of a working system · quiet room · AI operator’s stack.

  • Founder Bottleneck: How Documenting the Why Scales You

    Founder Bottleneck: How Documenting the Why Scales You

    For a long time, everything ran through me.

    Every decision, every deliverable, every edge case that didn’t fit the template. I was the person who knew where everything was and why it worked the way it did. Clients called me. Problems waited for me. The operation was fast when I was available and stuck when I wasn’t.

    I told myself this was just what running a lean operation looked like. That being indispensable was the same thing as being valuable. That the bottleneck was evidence of how much I mattered.

    It took me longer than I’d like to admit to understand that those aren’t the same thing at all.


    The shift didn’t happen because I hired more people or built a more sophisticated system. It happened because I started writing things down differently.

    Not the what — I’d always documented the what. What the process was. What the deliverable looked like. What the client expected.

    The change was writing down the why.

    Why is this built this way. Why did I make this trade-off. Why does this rule exist and what would have to be true for it to change. The reasoning that lives in my head during a decision but never makes it into the documentation because by the time the decision is made, the reasoning feels obvious and I’ve already moved on.

    That reasoning — the why, the context, the judgment — is exactly what’s missing when someone else tries to run something you built. They can follow the steps. They can’t follow the thinking. And the thinking is most of what they actually need.


    I had a client engagement once where the real work wasn’t the content or the SEO or any of the visible deliverables. The real work was extraction — pulling out everything the founder knew about his industry and making it queryable.

    He had thirty years of pattern recognition in his head. He knew, from a thirty-second conversation, whether a prospective client was going to be a nightmare. He knew which product lines had margin left to squeeze and which ones were already at ceiling. He knew the right answer to questions his team asked him forty times a week.

    But none of it was written down. It lived in him, and because it lived in him, every decision that touched that knowledge had to touch him first. He was the bottleneck in his own business, not because he was bad at delegating, but because there was nothing to delegate to. The judgment wasn’t portable.

    We spent three months making it portable.


    I’ve been doing the same thing for myself.

    The Notion workspace I run on isn’t just a project management tool. It’s an attempt to externalize the reasoning that would otherwise die with the session — the doctrine pages that explain why the operation is structured the way it is, the decision logs that capture what I considered before choosing, the second brain that holds the context I’d otherwise have to rebuild from scratch every time.

    It’s slow work. It runs against the instinct to just move. Documentation always feels like it’s competing with execution, and execution is what pays the bills today.

    But the compound effect is real and I’ve felt it. Questions I would have had to think through from scratch six months ago have written answers now. New automations start from an existing base of explained decisions rather than a blank page. When something breaks, the fix is findable because the original thinking is findable.

    More than that: I’ve noticed that the act of writing down why I’m doing something makes me smarter about whether I should be doing it. A decision you can’t explain clearly enough to document is often a decision you haven’t thought through clearly enough to make well.


    The version of me from three years ago would be confused by how I work now.

    Then, I was the point of contact for everything. Clients called when there was a problem. I held the answers in my head and dispensed them on demand. The business ran because I ran it, continuously, in real time.

    Now, most of what the operation does, it does without me. Workers run on schedules I set. Content moves through pipelines I designed. Decisions I’ve already made a hundred times get made automatically against rubrics I wrote once.

    I show up for the things that genuinely need me — strategy, relationships, the judgment calls that don’t fit any pattern I’ve encountered before. Everything else runs.

    The thing I had to let go of to get here was the idea that being needed for everything was the same as being important. It isn’t. Being needed for everything is exhausting and fragile and it doesn’t scale. Being needed for the right things — the hard things, the high-leverage things, the things only you can actually do — that’s something different.


    I don’t think of myself as having solved this. The work of making a one-person operation less dependent on one person is ongoing and probably never finished.

    But there’s a version of it that’s better than the version where everything runs through you and breaks when you’re not there.

    The path to that version isn’t more people or fancier tools. It’s the slow, unglamorous work of writing down why. Making the thinking portable. Building a system that holds the reasoning, not just the steps.

    The bottleneck doesn’t go away. It just stops being you.

  • AI Agent Output: Closing the Trust Gap to Scale Faster

    AI Agent Output: Closing the Trust Gap to Scale Faster

    Here’s the moment I’m talking about.

    The agent finishes. The output is sitting there. It looks right — it usually looks right — and now you have to decide whether you’re going to use it or check it first.

    That moment, that pause, is the trust gap. And if you’re running AI at any real volume, it’s the thing that’s quietly eating your time, your confidence, and sometimes your credibility.


    Most people handle it badly. I did too, for a while.

    The two failure modes are mirror images of each other. The first is reviewing everything — reading every output, checking every claim, treating the agent like an intern you don’t trust yet. This works. It catches errors. It also means the agent isn’t actually saving you time. You’ve moved the work from doing to checking, which is a trade-off that only makes sense at low volume or when the stakes are very high.

    The second failure mode is trusting everything — shipping what the agent produces without a meaningful review layer, because you’re busy and it usually looks right and you can fix things later. This also works, until it doesn’t. Bad output compounds quietly. A wrong fact in an article becomes a wrong fact that got cited. A misformatted record becomes a database full of exceptions you have to clean manually. By the time you notice, the problem is bigger than the original task.

    The thing both failure modes have in common is that they’re reactions to the trust gap rather than designs for closing it.


    The design question is different from the reaction question.

    The reaction question is: how much should I check this particular output right now?

    The design question is: what is the system that makes agent output trustworthy enough that I can scale it?

    I spent a long time asking the wrong question.


    What changed for me was thinking about trust as something that gets earned over time, not assessed in the moment.

    The system I ended up with has a name — the Promotion Ledger — and it tracks every autonomous behavior by tier. Tier A behaviors are things I always approve before they ship. Tier B behaviors are things I prepare but decide on. Tier C behaviors run on their own without me touching them.

    Nothing starts at Tier C. Everything earns its way there through seven consecutive clean days — seven days where the behavior ran, I sampled the output, and found no gate failures. If something fails a gate, it drops a tier and the clock resets.

    The clock is the key part. Trust isn’t a feeling I have about an agent in a given moment. It’s a count of consecutive clean runs. When I look at the Ledger and see that a behavior has been running cleanly for 23 days, I don’t need to review that output today. The track record is the review.


    There are three things that made this work where other approaches didn’t.

    The first is that sampled review is different from universal review. I don’t read every output. I read a percentage of outputs, randomly selected, with a defined rubric for what “good” looks like. If the sample is clean, the population is trusted. If failures cluster around a pattern, I fix the prompt and restart the clock. This scales in a way that reading everything doesn’t.

    The second is source attribution. Every agent output that contains a factual claim has to show where the claim came from. Not because I’m going to verify every citation — I’m not. But because the presence of a citation converts “is this right?” from a research task into a spot check. A trust gap you can close in five seconds is functionally not a gap.

    The third is the rubric. I have a written definition of what “good enough” looks like for each type of output — what voice match means, what coherence means, what the acceptable error rate is. Without the rubric, every review is a fresh judgment call. With it, review is comparison. Comparison is faster, more consistent, and easier to delegate.


    The thing I kept getting wrong before I had this system was trying to close the trust gap with better prompts.

    More detailed instructions. More explicit warnings. Be careful. Double-check your facts. Don’t make up numbers.

    This doesn’t work. The agent already believes it’s being careful. Adding adjectives to a prompt doesn’t change behavior — it changes the agent’s self-description of its behavior, which is not the same thing. The agent that was going to hallucinate a statistic will still hallucinate it, but now it’ll do so with more confidence because you told it to be careful and it thinks it was.

    Structural changes work. Rubrics, sampling rates, attribution requirements, tiered trust with observable clean-day counts. These change what the system produces, not just how it describes what it’s producing.


    I want to be clear that this took a while to build and I’m still refining it.

    There are behaviors on my Ledger that have been running at Tier C for months without a gate failure. There are others that keep dropping back to Tier B because they’re inconsistent in ways I haven’t fully diagnosed yet. The system doesn’t make trust automatic — it makes trust measurable.

    That’s the shift. Not “I trust this agent” as a feeling, but “this behavior has 31 clean days and a gate failure rate of zero” as a fact. You can act on a fact in a way you can’t always act on a feeling.

    The trust gap doesn’t close all at once. It closes by accumulation — one clean run at a time, tracked, until the track record speaks for itself.


    If you’re running agents at any volume and you feel like you’re either checking too much or not checking enough, you’re in the gap. The way out isn’t a better prompt. It’s a system that makes trustworthiness visible over time.

    Start with one agent. Define what “good” looks like. Sample 20% of its output for four weeks. Log what you find.

    By week four you’ll know whether you have a trust problem, a prompt problem, or a rubric problem. Those have different fixes. But you can’t see which one you have until you start measuring.

    Related on Tygart Media: how to use Claude · Anthropic API key.

  • The Bus Factor Problem: Protecting Your Solo Operation

    The Bus Factor Problem: Protecting Your Solo Operation

    There’s a question I’ve been avoiding for about two years.

    What happens to all of this if something happens to me?

    Not in a morbid way. Just practically. I run 27 client sites. I have an AI stack with dozens of moving parts — Cloud Run services, scheduled jobs, Notion databases, Workers that fire on their own while I sleep. I’ve built systems that work exactly the way I want them to work, in exactly the ways I understand, documented in exactly the language that makes sense to me.

    The bus factor for this entire operation is one. It’s me. If I’m not here, none of it survives in any meaningful way.

    I’ve been sitting with that long enough that I think it’s time to say it out loud.


    The bus factor is an old software engineering concept. It asks: how many people would need to get hit by a bus before this project fails? One is the worst possible number. It means everything lives in a single person’s head — their habits, their passwords, their way of naming things, their unwritten rules about how the system works.

    Most solo operators are a bus factor of one. They know this and they don’t talk about it because it sounds like a personal failing. Like you should have hired more people, or documented better, or not let yourself become the single point of failure for something people depend on.

    But I think the honest version is more complicated than that. A lot of what makes a solo operation valuable is exactly the thing that makes it fragile: it’s shaped entirely around one person’s judgment. The reason the system works is because I know when to break the rules I wrote. I know what the edge cases are before they happen. I know which automations to trust and which ones to watch. That’s not something you write in a runbook.

    So the question isn’t just “how do I document this better.” It’s “how do I make the judgment portable without turning it into something that loses the judgment in the process.”


    I’ve been building toward an answer, in pieces, over the last several months.

    The first piece was Notion as the control plane. Everything that matters about how this operation runs lives in Notion — specs, work orders, site credentials, content pipelines, system standards, the doctrine documents that explain why things are built the way they are. If I disappeared tomorrow, someone with the right access could open that workspace and read their way into understanding the shape of the operation, even if they couldn’t run it yet.

    The second piece was the two-plane architecture — Notion for thinking and storage, GCP for compute. Every Cloud Run service, every scheduled job, every Worker is defined somewhere in Notion before it runs somewhere on GCP. The compute is durable. The logic is documented. Those are two different things, and keeping them separate means neither one is a black box.

    The third piece is the hardest and I’m the least done with it: making the judgment readable.

    I write doctrine pages. Long ones, sometimes. They explain not just what the system does but why it works that way — what the original problem was, what I tried that didn’t work, what the rule is now and what would have to be true for the rule to change. I write them mostly for myself, because I forget things. But they’re also written for the hypothetical person who has to pick this up without me.

    That hypothetical person might be a future employee. It might be a contractor. It might be an AI agent working from a context window that needs to understand the operation well enough to continue it.

    It might be my partner, trying to figure out what to do with the business side of things if I’m not around.

    That’s the version that focuses the mind.


    I don’t have this solved. I want to be clear about that.

    What I have is a direction. The direction is: every decision should live somewhere outside my head. Every system should be explainable by someone who didn’t build it. Every credential should be in the registry, every automation should have a spec, every rule should have a reason written next to it.

    It’s slow work. It runs against the instinct to just build the thing and move on. There’s always something more urgent than documentation, and “I’ll remember how this works” is almost always true right up until it isn’t.

    But I’ve started treating the documentation as part of the product. Not the boring part — the part that makes the product real. A system that only works because I’m here isn’t really a system. It’s a performance.

    The goal is to build something that could survive me. Not because I’m planning to leave, but because the work of making it survivable is also the work of making it understandable, and a system I can’t fully explain is a system I don’t fully own.


    If you’re running something like this — solo or nearly so, more complexity than your headcount would suggest — I’d ask you the same question I’ve been sitting with.

    If something happened to you tomorrow, what would survive?

    Not what you hope would survive. What actually would.

    That gap is the work.

  • Notion Workers: Automate Workflows Without a Developer

    Notion Workers: Automate Workflows Without a Developer

    I’ve hired developers. Good ones. For specific things — infrastructure, custom integrations, work that genuinely required someone to sit down and write production code from scratch — it was the right call.

    But if I’m honest about the full list of things I’ve brought developers in for over the years, a meaningful chunk of it wasn’t really developer work. It was workflow work. It was “I need this thing to happen automatically when that other thing happens” work. It was “why does this still require a human to touch it” work.

    That category of problem has a different answer now.


    Here’s the pattern I kept running into:

    I’d have a clear picture of what I wanted. Data from one tool synced into Notion. A webhook that logged events automatically. A scheduled job that pulled information from an external API every morning and wrote the results somewhere I could see them. Nothing exotic. Stuff that, described out loud, sounds almost embarrassingly simple.

    But turning that description into something that actually ran required code. And writing code required a developer. And hiring a developer for something this small felt like bringing a contractor in to change a lightbulb — technically the right tool, but something about the ratio felt off.

    So a lot of it didn’t get built. The workflow stayed manual. The friction stayed.


    Last night I built ten of those things in three hours.

    Notion Workers — their new hosted serverless platform, shipping in beta as of May 13, 2026 — lets you deploy real code inside Notion’s infrastructure without managing a server. Combined with Claude Code, which writes the TypeScript while you describe what you want in plain English, the gap between “I know what I want” and “it exists and is running” is smaller than it has ever been.

    I’m not a developer. I operated the process. I described each Worker, reviewed what Claude Code wrote, ran the deploy commands, checked that it worked. When something broke, I read the error and passed it back. The loop was fast enough that two failures in ten attempts felt like a normal part of the session, not a crisis.

    By midnight I had a live webhook endpoint receiving authenticated traffic from the internet and writing verified events to a Notion log page. Automatically. While I slept.

    That’s workflow work. It just didn’t require a developer to get there.


    I want to be careful about what I’m claiming here.

    There are things that genuinely need a developer. Complex systems. Production APIs with serious security requirements. Anything where a bug has real consequences for real people. I’m not suggesting you staff down your engineering team based on a three-hour session with a CLI tool.

    What I’m suggesting is narrower: there is a category of work that has always felt like it needed a developer but actually needed something else. It needed clarity about what you wanted. It needed a good description. It needed someone willing to read an error message and try again.

    That work is yours now, if you want it.


    The practical question is where to start.

    Start with the thing that’s most manual in your current workflow. The task someone does by hand because no one ever got around to automating it. The data that lives in one tool but should live in another. The notification that goes out because someone remembered to send it, not because the system sent it automatically.

    Describe it out loud. If you can explain it to another person in two or three sentences, you can build it. Open Claude Code. Tell it what you want. Run the commands it gives you.

    You might be surprised how far that gets you before you need to call anyone.


    Notion Workers beta is free through August 11, 2026. The ntn CLI installs in one line on macOS or Linux. Business or Enterprise plan required to deploy Workers.

    Related on Tygart Media: how to use Claude · GA4 Intelligence Kits.

  • Notion Workers & Claude Code: The New Operator’s Stack

    Notion Workers & Claude Code: The New Operator’s Stack

    There’s a word that’s been sitting in my head lately and I think it’s the right one.

    Not developer. Not user. Not prompt engineer — please, not that.

    Operator.


    The developer builds the system. The user benefits from it. The operator runs it.

    Operators have always existed. They’re the people who know a tool well enough to get unusual things out of it — who understand what’s possible, who can configure and connect and troubleshoot, who treat software as infrastructure rather than a product to consume. In a restaurant, the chef is the operator. In a warehouse, it’s the floor manager who actually knows where everything is and why the inventory system does what it does.

    In most software companies, the operator was assumed to be technical. You needed to code, or at least to read code, to run anything at a real level of depth. Everyone else was a user — handed a finished product, expected to stay in the designated lanes.

    That line is moving.


    Last night I deployed ten Notion Workers in three hours. Workers are Notion’s new hosted serverless platform — real code, running inside Notion’s infrastructure, no server to manage. I built a webhook endpoint that receives authenticated HTTP traffic from the internet and logs it to a Notion database. I built data sync Workers. I built scheduled jobs.

    I am not a developer.

    What I am is an operator. I know what I want the system to do. I can describe it precisely. I understand how the pieces connect even when I can’t write the connection myself. And I have Claude Code, which handles the TypeScript while I handle the architecture.

    The stack looks like this:

    Claude Code — the reasoning layer. Describe what the Worker should do in plain English. Claude Code writes the code, catches errors when you paste them back, and tells you exactly what commands to run.

    ntn CLI — the deployment layer. Four commands: scaffold, write, push secrets, deploy. Single-command deploys. You run what Claude Code tells you to run.

    Notion Workers — the execution layer. Serverless functions running on Notion’s infrastructure. They connect to external APIs, respond to webhooks, sync data, run on schedules. They do the work while you do something else.

    That’s it. Three layers. None of them require you to be a developer to operate.


    The operator’s job in this stack is not to write code. It’s to know what should exist.

    That sounds simple. It isn’t. Knowing what should exist means understanding your own operations well enough to identify where the friction is, what’s being done by hand that shouldn’t be, what would run better automatically. It means being able to describe a system clearly enough that an AI coding agent can build it. It means reviewing what gets built and knowing whether it’s right.

    That’s real skill. It’s just not the skill most people thought they needed.

    For years the implicit message was: if you can’t build it, you can’t have it. The work of describing exactly what you want, of thinking through the logic, of understanding how systems connect — that work was treated as a prerequisite for coding, not a valuable thing in its own right.

    Now it’s the job.


    I’m not going to tell you the technical barrier is gone. It isn’t. You still hit errors. You still have to read them and understand them well enough to know if Claude Code’s fix makes sense. You still have to think before you build.

    But the barrier has moved. The question is no longer “can you write TypeScript” — it’s “can you think clearly about what you want and describe it precisely.”

    Most people reading this can do that. They’ve been able to do that. They were just told, implicitly or explicitly, that it wasn’t enough.

    It’s enough now.


    The Notion Workers beta is free through August 11, 2026. The ntn CLI installs in one line on macOS or Linux. Deploying Workers requires a Business or Enterprise plan. If you’ve been running your operations in Notion and watching things like Workers from the sidelines because you figured it was for developers: it’s for operators too. You might already be one.

    Related on Tygart Media: how to use Claude · GA4 Intelligence Kits.

  • Deploying Notion Workers With Claude Code (No TypeScript)

    Deploying Notion Workers With Claude Code (No TypeScript)

    It was late. I had Claude Code open on my laptop and a fresh cup of coffee going cold next to it.

    Notion had shipped Workers eight days earlier — their new hosted serverless platform, basically “run real code inside Notion without managing a server.” I’d been meaning to dig in. Last night I finally did.

    I want to tell you what that actually looked like. Not a tutorial. Not a polished case study. Just what happened, in order, including the parts that didn’t work.


    By midnight I had ten Workers deployed and a live webhook endpoint logging authenticated traffic from the internet into a Notion page. The whole thing took about three hours.

    I did not write TypeScript.


    Here’s the honest version of how it went.

    The first Worker took the longest — maybe 35 minutes — because I was figuring out the CLI at the same time as building the thing. The ntn tool is straightforward once you understand it: scaffold, write the code, push your secrets, deploy. Four steps. But the first time through any new tool you’re reading error messages and second-guessing yourself.

    Claude Code handled the TypeScript. I described what I wanted — a Worker that receives a POST request, verifies an HMAC signature, and appends a line to a Notion log page. Claude Code wrote it. I ran the commands it told me to run. The Worker deployed.

    I tested it. It worked.

    The second one took 22 minutes. The third took 15. By Worker five I was moving fast enough that I stopped tracking individual times and just kept going.

    Two of them didn’t work on the first try. One had a secret I’d named wrong in the environment — my fault, five minutes to fix. The other had a logic error in how it was handling the Notion API response. Claude Code caught it when I pasted the error back in, rewrote the relevant section, and I redeployed. Eight minutes total for that dead-end.

    Neither failure felt like a crisis. That’s the part I want to underline. When something broke, the path forward was obvious: read the error, paste it back to Claude Code, get a fix, redeploy. The loop was tight enough that failure was just a speed bump, not a wall.


    At 02:54 in the morning, I sent a test ping to Worker #8.

    The webhook logger received it, verified the HMAC signature, and wrote this to a Notion page in real time:

    🔔 2026-05-21T02:54:44.452Z [claude-test:test] {"event":"test","message":"Hello from Worker #8 self-test","sender":"claude-code"}

    I sat there for a second looking at that.

    There’s something specific about seeing a system you built actually receive traffic. It’s not the same as a script running on your laptop. This was a deployed endpoint, on Notion’s infrastructure, receiving an authenticated HTTP request from the open internet and writing the result to a database. Automatically. Without me doing anything after the initial deploy.

    That’s a different category of thing than what I had before.


    I want to be honest about what I am, technically. I’m not a developer. I’ve picked up enough over the years to be dangerous — I can read code, I understand how APIs work, I’ve shipped things — but I’m not someone who sits down and writes TypeScript from scratch.

    Last night didn’t require that. What it required was knowing what I wanted, being able to describe it clearly, and being willing to run commands and read errors.

    That’s it.

    The question I keep hearing from people who run operations like mine — agencies, small teams, people who live in tools like Notion and have always hired out the code work — is whether any of this AI coding stuff is actually for them or if it’s still fundamentally a developer story with a better interface.

    Last night felt like an answer. Ten Workers. Three hours. No TypeScript.

    If you can describe what you want clearly enough to explain it to another person, you can build this. The friction that used to live between “I know what I want” and “it exists in the world” is genuinely smaller now.

    Not gone. Smaller.

    You still have to show up. You still have to read the errors. You still have to think through what you’re building before you build it.

    But if you’ve been waiting for some invisible threshold of technical credibility before you try — you’re past it. You were probably past it a while ago.


    The Notion Workers beta is free through August 11, 2026. The ntn CLI installs in one line. Business or Enterprise plan required to deploy.

    Related on Tygart Media: how to use Claude · GA4 Intelligence Kits.

  • Building 10 Notion Workers in 3 Hours With Claude Code

    Building 10 Notion Workers in 3 Hours With Claude Code

    Notion shipped Workers on May 13, 2026. By last night I had ten of them running in production, including a live HMAC-verified webhook endpoint that’s actively logging events. Total build time: about three hours.

    I didn’t write TypeScript by hand. Claude Code did most of the typing.

    Here’s what that actually looked like — and what it means for the non-developer Notion power user who’s been watching the Workers announcement and wondering if it’s for them.

    What are Notion Workers? Notion Workers are hosted serverless functions that run inside Notion’s infrastructure. You write code, deploy it through the ntn CLI, and Notion runs it in a secure sandbox — no server to manage. They’re free through August 11, 2026, then run on Notion credits. Deploying Workers requires a Business or Enterprise plan.

    What Notion Workers Actually Are (The One-Paragraph Version)

    Side-by-side cards defining what Claude Code is and is not
    What Notion Workers actually are.

    If you’ve used Notion’s built-in database automations — the lightning bolt icon — Workers are that concept extended to real code. They can call any external API, respond to webhooks, sync data from Stripe or Zendesk or GitHub, and write results back to Notion databases. The CLI (ntn) is available on all plans. Deploying Workers requires Business or Enterprise.

    Do You Need to Know TypeScript to Build Notion Workers?

    Technically, Workers are written in TypeScript. Practically, if you have Claude Code, the answer is no.

    Claude Code (currently at v2.1.144 as of May 19, 2026) scaffolds Workers from plain-English descriptions. You describe what the Worker should do. Claude Code writes the src/index.ts, handles the ntn workers env push for secrets, and tells you exactly what commands to run. You copy the command. The Worker deploys.

    The workflow looks like this:

    1. ntn workers new my-worker-name — scaffold the project
    2. Tell Claude Code what the Worker should do
    3. Claude Code writes src/index.ts
    4. ntn workers env push — push any secrets (API tokens, webhook keys)
    5. ntn workers deploy --name my-worker-name — ship it

    That’s it. The only thing you actually type is the deploy commands. Claude Code fills in the gap between them.

    What We Built in 3 Hours

    Five stacked panels of daily Claude Code command habits
    What we built in 3 hours.

    Ten Workers, averaging about 18 minutes each, including two dead-ends that took 5–8 minutes to diagnose and abandon.

    The most useful one is Worker #8: an HMAC-verified webhook logger. Any external service — GitHub, Stripe, a cron trigger, another Claude Code session — can POST to the Worker’s endpoint with a shared secret, and it auto-appends a timestamped line to a Notion log page. The webhook log shows its first self-test ping from Claude Code at 02:54 UTC:

    🔔 2026-05-21T02:54:44.452Z [claude-test:test] {"event":"test","message":"Hello from Worker #8 self-test","sender":"claude-code"}

    That’s a live, verifiable event log. Not a draft. Not a mock. A deployed Worker receiving authenticated HTTP traffic and writing to Notion.

    The ntn workers env push command works cleanly for both NOTION_API_TOKEN and non-Notion secrets like TYGART_WP_USER and WEBHOOK_SECRET — one of the key things we needed to confirm before trusting the stack at scale.

    The Design Principle That Makes This Actually Work

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    The design principle that makes this work.

    The best insight from Notion’s Workers documentation: use code for deterministic work, use AI for judgment calls.

    A Worker that pulls invoice status from Stripe and updates a Notion database doesn’t need AI. It needs reliable, cheap code execution. That’s what Workers give you. A Claude Sonnet 4.6 (claude-sonnet-4-6) or Opus 4.7 (claude-opus-4-7) agent that reads those Notion rows and drafts follow-up emails is handling the judgment call. Those are two different tools for two different jobs.

    When you collapse that distinction — letting AI do everything — you pay AI prices for work that shouldn’t require AI reasoning. Workers run at a fraction of the cost of AI credits. Notion’s own example calculations put a daily sync job at roughly one cent per month. The AI layer sits on top for the parts that actually need it.

    This is the architecture: Workers handle the plumbing. Claude handles the reasoning. You stop paying Opus rates for jobs a ten-line TypeScript function can do.

    The Part Nobody Else Is Writing About

    Every guide covering Notion Workers frames it as a solo-developer workflow. You sit down, you know TypeScript, you build a Worker over an afternoon.

    That’s not how this went.

    Claude Code is listed in Notion’s own documentation as a first-class deployment partner for Workers. The ntn CLI was explicitly designed to work with coding agents — same interface for humans and agents. When you treat Claude Code as the author and yourself as the operator running the commands it outputs, you get through ten Workers in a session that most developers would take a week to plan.

    The non-developer angle is real. If you run Notion as your operating system — databases, automations, dashboards — and you’ve been watching the Workers announcement wondering whether it requires a CS degree, the answer in May 2026 is: not if you have Claude Code. The scaffolding is a one-line command. The deployment is a one-line command. Claude Code fills in the gap between them.

    Three Things to Know Before You Start

    Business or Enterprise plan required to deploy. The CLI (ntn) installs on any plan and runs free. Deploying Workers needs Business or Enterprise. Check your plan before you spend an afternoon scaffolding.

    macOS and Linux only as of May 2026. Windows users need WSL2. Native Windows support is listed as coming soon. If you’re on Windows without WSL2, that’s your first step.

    Free through August 11, 2026. After that, Workers run on Notion credits. Build and optimize now while the cost is zero. The free period gives you enough runway to understand your actual usage patterns before you’re paying for them.

    Related on Tygart Media: how to use Claude · GA4 Intelligence Kits.

    Frequently Asked Questions

    What is the Notion Workers free period?

    Notion Workers are free to try during the beta period, which runs through August 11, 2026. After that date, Workers will run on Notion credits. The free period is a good window to build, test, and optimize your Workers before metered usage begins.

    Can non-developers build Notion Workers?

    Yes, if you have an AI coding agent like Claude Code. Workers are written in TypeScript, but Claude Code can generate the Worker code from a plain-English description. You run the scaffold and deploy commands; Claude Code writes the code. No prior TypeScript knowledge required.

    What Notion plan do you need for Workers?

    The ntn CLI is available on all Notion plans. Deploying and managing Workers requires a Business or Enterprise plan.

    How does Claude Code work with Notion Workers?

    Claude Code (v2.1.144 as of May 2026) integrates directly with the ntn CLI. Notion designed the CLI as a tool for both humans and coding agents — same interface, same commands. Claude Code scaffolds the Worker TypeScript, sets environment variables, and outputs the exact deploy commands to run.

    What can Notion Workers do?

    Workers can call any external API, respond to incoming webhooks (with HMAC verification), sync data between external services and Notion databases, run scheduled tasks, and execute custom business logic. Common use cases include syncing Stripe payments, Zendesk tickets, GitHub issues, or any service with an API into Notion.

    Is the ntn CLI available on Windows?

    As of May 2026, the ntn CLI is available on macOS and Linux. Windows support is listed as coming soon. Windows users can use WSL2 in the meantime.

    The Bottom Line

    Ten Workers. Three hours. A verified webhook endpoint logging live traffic. Claude Code did the TypeScript. The ntn CLI did the deployment. Notion’s infrastructure handled everything else.

    The question isn’t whether Notion Workers are for developers. The question is whether you have a coding agent. If you do, the friction is gone.

  • The Rise of the Curation Class

    The Rise of the Curation Class

    This is what I’m building for myself, and what I’m building for the people I work with. It’s a long essay because the shift it describes is large and the through-line matters. The ten images below aren’t decoration — they’re the spine. Each one is a moment in a life that doesn’t fully exist yet but is closer than most people realize.

    I want to start where the technology starts, which is not in a factory.

    The man in the image above is finishing a wearable by hand. It’s an AR ring — leather and brushed aluminum, the band sized to his client’s wrist, the materials chosen because his client cares about how the thing feels at 6 AM on the day she has to present to a board. Behind him are leather rolls and fabric swatches that wouldn’t look out of place in a coachbuilder’s atelier. To his right are the kind of objects you’d find in a hardware prototyping lab — chassis teardowns, a development tablet, AR glasses on a stand. The corkboard above the bench has automotive interior sketches and material studies pinned next to each other.

    What that workshop is, in operational terms, is a luxury goods atelier and a hardware lab collapsed into one room. The collapse is the thing. The line between “this is bespoke craft” and “this is consumer electronics” has been melting for a decade, and the workshop above is what it looks like once that line is gone.

    I’m building for the people who will live on the right side of that collapse. The people who don’t want a phone — they want an instrument that fits the way they think. The people who have stopped trusting mass-produced anything and started looking for the small workshop, the verified maker, the device tuned to them specifically. That’s the Curation Class. They’ve existed in clothing for a hundred years and in cars for sixty. They’re now showing up in technology, and the technology is the part of the story I have to build.

    This essay is about what their daily life looks like when the ecosystem actually works. Then it’s about why I think this is where things go from here, and what I’m doing about it.

    Introduction to the instrument

    personalized ecosystem introduction — The Rise of the Curation Class

    Meet the user. She’s the one who commissioned the work in the hero image. She’s an architect — the corkboard behind her is a hint, the mood board with fashion sketches and house renderings tells you something about her aesthetic taste. The coffee cup has a small leather wrap and a logo I won’t try to read; the flower in the vase is past its bloom but she hasn’t replaced it yet because she likes it that way.

    She’s just opened the ecosystem the artisan was finishing. The hologram floating above the ring spells out what she’s getting: “Vibe Curation, Concierge Cred Network, Curated Intelligence.” The version number is v1.4, which tells you the device has been iterated. This isn’t a Kickstarter prototype. This is a maintained system that updates the way her car updates and her phone updates, except it updates to fit her specifically rather than to fit the median user.

    The phrase “Personalized Ecosystem” deserves to be said carefully because it gets thrown around by everyone selling anything. What’s on her desk is different. It’s not a feature flag set to her preferences. It’s not a recommendation algorithm tuned to her purchase history. It’s an ecosystem in the literal sense — an interconnected set of devices, services, vendors, and contexts that have been wired together around her cognition, her body, her schedule, her taste, and the people she trusts. The wearable is the access token. The ecosystem is everything the token unlocks.

    The reason this matters is not that the technology is impressive. It’s that the unit of value is changing. For a generation, the value was in the device. For the next generation, the value is in the connections between the devices and the person who wears them. You don’t buy the ring. You buy your way into the ecosystem that the ring represents. The ring is just the part you can touch.

    This is what I’m building toward. Not the device. The connections.

    The day starts with a small ritual

    curated palate cafe ritual — The Rise of the Curation Class

    The first time the ecosystem touches her day, it’s a coffee. She’s at a café — bright, marble-countered, the kind of place that does third-wave coffee and serves it in a small ceramic cup. The barista is named Maria. The hologram above her ring is showing the order before Maria has had to ask: oat latte, 120°F (which is a specific temperature most people don’t know to ask for), Ethiopian Yirgacheffe roast.

    The detail that matters is the parenthetical: “Maria (verified).”

    This is the Concierge Cred Network. Maria isn’t just a barista. She’s been verified by the ecosystem — pulled up by name because she’s the one who makes the coffee the way the subject likes it. If Maria’s not working today, the ecosystem might suggest a different café entirely rather than route the order to a barista the system doesn’t trust to nail the temperature. The vendor relationship has become specific to the human, not the brand.

    I want to name something about this image that the casual viewer might miss. The subject is barely looking at the ring. Her gaze is on Maria. The interaction is human; the technology is in the background doing the work that makes the interaction friction-free. When the ecosystem works, it disappears. It doesn’t ask her to type her order, doesn’t ask her to dig out her phone, doesn’t ask her to remember which roast she likes. It does that work upstream. What she’s left with is a moment of eye contact and a coffee that’s right.

    This is, in my experience, the part most technology gets wrong. The goal isn’t to put more interface in front of people. The goal is to remove the interface from places it doesn’t belong. The Curation Class is willing to pay a premium for that subtraction.

    The home she designed for herself

    curated sanctuary spatial cure — The Rise of the Curation Class

    Now she’s home. The wall she’s touching is travertine — real stone, the kind with porosity you can feel under your fingertips. The hologram tells you the room is in a “Curated Sanctuary” mode and lists the materials: travertine and a cashmere blend. The room is calm. The light is afternoon. The chair is leather and looks like it’s been broken in for years.

    The detail I want to pull forward is the curator field on the hologram: “User_24A. Verified.”

    She is the curator. The “Verified” tag isn’t a brand verification. It’s her own. The space was designed by her, for her, and the ecosystem is tracking that fact. The wall, the light temperature, the fragrance the room is currently running, the sound dampening, the chair — all of it is a vibe she composed and the ecosystem is just executing.

    This is where the Curation Class diverges most sharply from the mass-luxury class that came before it. The old luxury class hired Robert Mion or Kelly Wearstler to curate for them. They bought the taste of someone whose taste was for sale. The new class makes the curation themselves and uses the ecosystem to remember the choices and reproduce them. The taste isn’t borrowed. It’s authored. The ecosystem is what makes authored taste tractable at the level of a daily-running home.

    I’ll be honest about why this matters to me operationally. When I think about what I’m building for my best clients — the ones who are paying for something more than a website or a content pipeline — I’m not building campaigns. I’m building the systems that let them author their own taste and reproduce it at scale. The Notion structure is part of that. The content stack is part of that. The way we wire models and routing and observability is part of that. None of it is technology for its own sake. All of it is the infrastructure of authored taste.

    The room above is what that looks like when it’s done.

    The work she actually does

    curated spatial intelligence architectur — The Rise of the Curation Class

    The studio above is hers. The building is hers too — she’s an architect, and “The Veda Residences” is the project she’s leading. The hologram shows iteration v9.2, which means this design has been worked through. The physical model on the leather pad is the build she’s referring to when the holographic version isn’t enough.

    A few things to notice. The drafting table has a real architect’s set square on it. The materials board has fabric and stone swatches that look like they were pulled from suppliers she trusts. The two colleagues in the back are visible through a glass partition; the studio isn’t a solo operation. It’s a small firm.

    What the ecosystem gives her here isn’t draft generation. It’s not “AI did the design.” The design is hers, plus her team’s. The ecosystem gives her something subtler — the ability to iterate v9.2 against her own internal coherence rules, her own taste profile, her firm’s body of work, the structural and material verifications she requires. She is still making every decision. The ecosystem is making every decision legible and reproducible.

    This is the part I think most people get wrong about where AI is going. They think it’s going to do the work. It’s not. It’s going to make the work expressible. The architect above doesn’t need an AI to design her building. She needs an instrument that lets her ask “would this material be coherent with the rest of my catalog?” and get an answer with citations. She needs the ecosystem to be the silent third party that holds her own standards more reliably than she can hold them in her head across a four-month project.

    The building she’s designing in this image, by the way, is the one she’ll be standing inside in the last image of this essay. Hold that. We’ll come back to it.

    Recovery, the part the ecosystem treats as work

    personal wellness concierge recovery — The Rise of the Curation Class

    After the work, the recovery. The image above is what wellness looks like when it stops being a separate vertical and becomes a function of the same ecosystem that runs the rest of the day.

    The hologram says “Vibe State Recovery (post-design cycle).” That phrase is doing real work. The ecosystem knows she just spent eight hours on iteration v9.2 of the building project. It knows what that does to her body — the cortisol curve, the shoulder tension, the eye strain. It’s prescribing a recovery protocol that’s specific to what she just did. Not a generic massage. Not a generic meditation. A recovery state tuned to a design cycle.

    “Second Brain (User_24A): Verified Biometrics” is the connective tissue here. The wellness system isn’t reading her body from scratch. It’s reading her body in the context of everything else the ecosystem knows about her — her schedule, her work, her sleep history, her stress baseline, her medication if any, her preferences for what kinds of intervention she’ll accept. The Second Brain in this image isn’t a metaphor. It’s literally the persistent memory layer that lets every part of the ecosystem behave intelligently with respect to every other part.

    If I had to name what I think the single biggest unlock of the next ten years will be, it would be this: persistent personal memory that crosses contexts. Right now your fitness app doesn’t know what your therapist said. Your calendar doesn’t know what your sleep tracker measured. Your travel booking doesn’t know your spouse’s allergy profile. Each of these systems is islanded. The Curation Class will be the first cohort to live in a world where those islands are connected, and the connection will be the persistent personal Second Brain that they own — not a vendor’s database. Theirs.

    This is, again, why I do what I do. Not because I want to sell people on “AI wellness.” Because the architectural pattern of a persistent personal Second Brain, owned by the human, is the foundation everything else rides on.

    A deeper intervention

    neural sync intervention verified — The Rise of the Curation Class

    The session continues. She’s now holding a more specific tool — a neural stim device that’s been issued to her, the kind of thing that has to be verified for her specifically because applying it wrong would do real damage. The hologram says “Neural Pathway Targeted: Verified.” The ecosystem isn’t just letting her use the device. It’s verifying that the protocol is appropriate for her at this moment.

    The phrase “Vedic Regeneration” is doing some cultural work here. I’m not going to oversell it — different people will read different things into it. What I’ll say operationally is that the Curation Class tends to be polyglot about where its wellness traditions come from. They’ll combine cold plunges, somatic therapy, Ayurvedic principles, and neural-feedback hardware in the same week without feeling the contradictions. The ecosystem is what makes that polyglot stance tractable — it can hold the protocols from five different traditions and apply the one that fits the moment.

    The reason a verification layer matters is harder. We’re entering an era where people will be doing more sophisticated interventions on their own nervous systems than ever before. Some of those interventions will be safe. Some won’t. Some will work for one person and harm another. The ecosystem above is doing what regulators won’t be able to do for another fifteen years: assuring that a specific intervention is appropriate for a specific person on a specific day. The verification isn’t bureaucratic. It’s the thing that lets her safely run the protocol at all.

    I’ll name the discomfort here. There’s a version of this that ends badly — concentration of biometric data, vendor lock-in, dependence on a system that someone else can shut down. That risk is real. The mitigation isn’t to refuse the technology. The mitigation is to own the Second Brain rather than rent it. Which is part of why I’m building the way I’m building. The architecture matters. The architecture is the politics.

    The commute as part of the system

    autonomous luxury ecosystem flow state — The Rise of the Curation Class

    She’s in the car now. It’s autonomous — the road is moving but her attention is on the floating dashboard. The destination on the hologram is her own design studio at 11 Rivoli. ETA fourteen minutes.

    The phrase that earns its keep is “Flow State Curation.” The car isn’t just transporting her body. The car is preparing her cognition for what’s about to happen at the studio. Audio profile tuned. Cabin temperature optimized. Lighting on a curve that brings her up into focus rather than letting her crash at the end of the recovery session. The fourteen minutes between wellness and work aren’t dead minutes. They’re a transition that the ecosystem is actively shaping.

    When I look at this image I think about how much of contemporary life is wasted in transitions. The Curation Class won’t tolerate it. Their time is their most expensive asset, and they’re willing to pay to have transitions be productive rather than evaporated. The autonomous car is part of that. So is the ring. So is the wellness suite. So is the studio. None of them in isolation is interesting. Stitched together they are an enormous economic shift.

    The other thing worth naming: the car is bespoke. “Smart cashmere & polished aluminum, verified.” This is not a leased Tesla. It’s a vehicle whose interior materials have been chosen for her, verified by the maker, and integrated into the ecosystem in a way that lets the car participate in the flow state curation rather than fight it. The market for that kind of vehicle barely exists today. It will exist in ten years, and it will be larger than people think.

    Collaboration at scale

    bespoke ecosystem collaboration group al — The Rise of the Curation Class

    The studio meeting. Four colleagues, a marble table, a wall of glass onto the city. She’s standing because she’s leading.

    The hologram says “Group Alignment 88%.” That’s the part I want to pull forward. The ecosystem isn’t just running her individually — it’s running a measurement of how aligned her team is on the current iteration of the project. Eighty-eight percent is high. Twelve percent is the gap she has to close in the room.

    This is where the Curation Class moves from being a personal lifestyle to being an operational advantage. A team that can see its own alignment in real time, that can identify the twelve percent of disagreement and address it directly rather than letting it metastasize through three more meetings — that team will outperform a team that can’t. The ecosystem is doing the work of measurement that used to require an executive coach in the room. Now it’s just there, on the table, visible to everyone.

    I want to be careful here. There’s a version of this where the alignment metric becomes a cudgel, where dissent gets flattened by the pressure to push the number up. That’s a failure mode and the ecosystem above can absolutely become it if the culture around it is wrong. The fix isn’t to refuse the measurement. The fix is to make the measurement legible enough that disagreement is preserved as signal rather than erased as noise. The ecosystem can do that. Whether the team uses it that way is a cultural question, not a technological one.

    The technology, by itself, is neutral. The culture decides whether it’s surveillance or instrumentation. I’m building for the latter.

    The arc closes

    spatial cure realized sanctuary — The Rise of the Curation Class

    This is the image that earns the whole essay.

    She’s standing inside the building. The Veda Residences — the project that was iteration v9.2 in the studio scene — is now built. The curved concrete, the fluted glass, the composite timber that the hologram in that earlier scene specified, all of it has gone from model to reality. She designed the room she is now living in. The hologram above her is reporting that the sanctuary is “realized” and that the alignment is at 100%, which is the team-level analog of the personal sanctuary she was tuning at home.

    She designed her own world into existence. The ecosystem made the through-line tractable across nine months of design iterations, two construction phases, fifteen vendor relationships, three biometric recovery cycles, a hundred small daily curations, and the original choice — three years earlier — to commission a hand-finished AR ring from a maker who works with leather and aluminum on a single bench.

    The Curation Class is not, fundamentally, a class that consumes better products. It’s a class that authors its own life and uses an ecosystem to make the authorship coherent across time. The wearable, the home, the studio, the wellness suite, the car, the team, the building — these are all expressions of one continuous act of authorship. The technology is the substrate. The taste is the act. The realization is the proof.

    Why I’m building for this

    I started this essay by saying it’s about what I’m building for myself and my clients. I want to close on that more directly.

    I am not building generic AI tools. I am not building “content automation.” I am building the operational substrate that lets a person — a founder, an operator, an artist, an architect — author their own coherent system across time and have the system reliably express the authorship. That’s the Notion architecture. That’s the model routing layer. That’s the content pipeline. That’s the persistent memory. None of it is interesting in isolation. All of it is interesting because of what it adds up to.

    The person I am building for is the architect above. She doesn’t know me. She might not exist yet. But the infrastructure that makes her life tractable is the infrastructure I am wiring this week, this month, this year. Every client I take on is a step toward making the substrate real. Every article I publish is a way of describing the future I’m trying to bring forward. Every system I document is a piece of the operating manual for the Curation Class.

    I think this is the work. I think it’s where the next ten years are. I think the people who get this right will look back at the current era — when AI was being used to mass-produce the same five blog posts and the same five product descriptions — the way the Bauhaus generation looked back at Victorian ornament. They will see the gap between what was being built and what could have been built, and they will name it.

    I’m trying to be on the right side of that gap.

    The image above — the woman standing inside the building she designed, with a glass of water, watching the city she optimized — is what I’m working toward. Not for her specifically. For the version of that life that becomes available to anyone who decides to author it and has the infrastructure to do so. That’s the Curation Class. That’s the brief I’m operating under. That’s the future I’m building.

    It’s already starting. The man in the first image is finishing the ring by hand. The system is being built. The class is forming. The rest is execution.

    { “@context”: “https://schema.org”, “@type”: “Article”, “headline”: “The Rise of the Curation Class”, “description”: “An essay on the emerging class that authors its own coherent life through bespoke craft, verified concierge networks, and a persistent personal second brain. What I’m building, and who I’m building it for.”, “author”: {“@type”: “Person”, “name”: “Will Tygart”, “url”: “https://tygartmedia.com”}, “publisher”: {“@type”: “Organization”, “name”: “Tygart Media”, “url”: “https://tygartmedia.com”}, “datePublished”: “2026-05-17”, “mainEntityOfPage”: “https://tygartmedia.com/the-rise-of-the-curation-class/” }

    Related on Tygart Media: curation class architecture · AI operator’s stack · Notion Command Center.