Tag: AI Agents

  • The Human Expertise Gap in AI: Why Tacit Knowledge Is the Next Scarce Resource

    The Human Expertise Gap in AI: Why Tacit Knowledge Is the Next Scarce Resource

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    Large language models were trained on text. Enormous quantities of text — more than any human could read in thousands of lifetimes. But text is not knowledge. Text is the residue of knowledge that was visible enough, and important enough, for someone to write down and publish somewhere that a training crawler could find it.

    The vast majority of what experienced humans actually know was never written down. It was learned by doing, transmitted by watching, refined through failure, and held entirely in the heads of people who couldn’t have articulated it systematically even if they wanted to.

    This is the human expertise gap. And it is the defining feature of where AI currently falls short.

    What Tacit Knowledge Actually Is

    Tacit knowledge is the kind you can’t easily explain but reliably apply. A master craftsperson knows when something is right by feel before they can measure it. An experienced clinician senses when something is wrong before the test results confirm it. A veteran contractor knows which subcontractors will actually show up on a Tuesday in November just from having worked with them — knowledge that no review site has ever captured accurately.

    This knowledge exists at every level of every industry. Most of it has never been written down because the people who hold it are too busy using it to document it, because the incentive to document was never strong enough, or because no one ever asked in a form they could answer systematically.

    Why AI Can’t Close This Gap on Its Own

    The naive assumption is that AI will eventually capture tacit knowledge by observing enough human behavior — that more data, more modalities, more sensor inputs will eventually replicate what experienced humans know intuitively.

    This misunderstands the nature of the gap. Tacit knowledge isn’t just undocumented data. It’s judgment that was built through embodied experience — through having made the wrong call and learned from it, through having seen the same situation hundreds of times in slightly different forms, through having relationships that carry context no outsider can access. These are not data problems. They’re experience problems.

    AI can get asymptotically close to replicating some of this. But the closer it gets, the more valuable the verified human source becomes — because the question shifts from “does AI know this at all” to “how do we know the AI’s answer is correct,” and the only reliable answer to that question is “because a human who actually knows verified it.”

    The Window That’s Open Right Now

    There is a specific window in the development of AI where tacit knowledge held by humans is more valuable than it will ever be again. We’re in it now.

    AI systems are capable enough that people trust them with real questions — questions about their health, their legal situation, their business decisions, their trade. But AI systems are not capable enough to be reliably right about the specific, experience-based, local, industry-specific knowledge that those questions often require.

    The gap between trust and accuracy is the market. The people who figure out how to systematically capture, package, and distribute their tacit knowledge — in forms that AI systems can consume and cite — are building the content infrastructure for a post-search information environment.

    The Human Distillery as a Category

    What’s emerging is a new category of knowledge work: the human distillery. A person or organization that takes tacit knowledge held by experienced humans and refines it into something that AI systems can depend on.

    This isn’t ghostwriting. It’s not content marketing. It’s not thought leadership in the LinkedIn sense. It’s systematic extraction — the application of a disciplined process to get tacit knowledge out of human heads, give it structure, publish it at density, and make it available to the AI systems that will increasingly mediate how people get answers to important questions.

    The people who build this infrastructure now — while the gap is widest and the market is least crowded — are positioning themselves at the supply end of the most important information supply chain of the next decade.

    What is the human expertise gap in AI?

    The gap between what AI systems were trained on (text that was published online) and what experienced humans actually know (tacit knowledge built through embodied experience that was never systematically documented). This gap is structural, not temporary — it won’t close simply by training on more data.

    What is tacit knowledge?

    Knowledge you reliably apply but can’t easily articulate — the judgment of an experienced practitioner, the pattern recognition of someone who has seen the same situation hundreds of times, the relationship-based intelligence that no review site has ever captured. It’s built through experience, not text.

    Why is this a time-sensitive opportunity?

    We’re in a specific window where AI systems are trusted enough to be asked important questions but not accurate enough to answer them reliably without human verification. The gap between trust and accuracy is the market. That window won’t stay this wide indefinitely.

    What is a human distillery?

    A person or organization that systematically extracts tacit knowledge from experienced humans, gives it structure, publishes it at density, and makes it available in forms that AI systems can consume and cite. It’s a new category of knowledge work — distinct from content marketing, ghostwriting, or traditional publishing.

  • How to Build Your Own Knowledge API Without Being a Developer

    How to Build Your Own Knowledge API Without Being a Developer

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    When people hear “build an API,” they assume it requires a developer. For the infrastructure layer, that’s true — you’ll need someone who can deploy a Cloud Run service or configure an API gateway. But the infrastructure is maybe 20% of the work.

    The other 80% — the part that determines whether your API has any value — is the knowledge work. And that requires no code at all.

    Step 1: Define Your Knowledge Domain

    Before anything else, get specific about what you actually know. Not what you could write about — what you know from direct experience that is specific, current, and absent from AI training data.

    The most useful exercise: open an AI assistant and ask it detailed questions about your specialty. Where does it get things wrong? Where does it give you generic answers when you know the real answer is more specific? Where does it confidently state something that anyone in your field would immediately recognize as incomplete or outdated? Those gaps are your domain.

    Write down the ten things you know about your domain that AI currently gets wrong or doesn’t know at all. That list is your editorial brief.

    Step 2: Build a Capture Habit

    The most sustainable knowledge production process starts with voice. Record the conversations where you explain your domain — client calls, peer discussions, working sessions, voice memos when an idea surfaces while you’re driving. Transcribe them. The transcript is raw material.

    You don’t need to be writing constantly. You need to be capturing constantly and distilling periodically. A batch of transcripts from a week’s worth of conversations can produce a week’s worth of high-density articles if you have a consistent process for pulling the knowledge nodes out.

    Step 3: Publish on a Platform With a REST API

    WordPress, Ghost, Webflow, and most major CMS platforms have REST APIs built in. Every article you publish on these platforms is already queryable at a structured endpoint. You don’t need to build a database or a content management system — you need to use the one you probably already have.

    The only editorial requirement at this stage is consistency: consistent category and tag structure, consistent excerpt length, consistent metadata. This makes the content well-organized for the API layer that will sit on top of it.

    Step 4: Add the API Layer (This Is the Developer Part)

    The API gateway — the service that adds authentication, rate limiting, and clean output formatting on top of your existing WordPress REST API — requires a developer to build and deploy. This is a few days of work for someone familiar with Cloud Run or similar serverless infrastructure. It’s not a large project.

    What you hand the developer: a list of which categories you want to expose, what the output schema should look like, and what authentication method you want to use. They build the service. You don’t need to understand how it works — you need to understand what it does.

    Step 5: Set Up the Payment Layer

    Stripe payment links require no code. You create a product, set the price, and get a URL. When someone pays, Stripe can trigger a webhook that automatically provisions an API key and emails it to the subscriber. The webhook handler is a small piece of code — another developer task — but the payment infrastructure itself is point-and-click.

    Step 6: Write the Documentation

    This is back to no-code territory. API documentation is just clear writing: what endpoints exist, what authentication is required, what the response looks like, what the rate limits are. Write it as if you’re explaining it to a smart person who has never used your API before. Put it on a page on your website. That page is your product listing.

    The non-developer path to a knowledge API is: define your domain, build a capture habit, publish consistently, hand a developer a clear spec, set up Stripe, write your docs. The knowledge is yours. The infrastructure is a service you contract for. The product is what you know — packaged for a new class of consumer.

    How much does it cost to build a knowledge API?

    The infrastructure cost is primarily developer time (a few days for an experienced developer) plus ongoing GCP/cloud hosting costs (under $20/month at low volume). The main investment is the ongoing knowledge work — capture, distillation, and publication — which is time, not money.

    What publishing platform should you use?

    WordPress is the most flexible and widely supported option with the most robust REST API. Ghost is a good alternative for simpler setups. The key requirement is that the platform exposes a REST API you can build an authentication layer on top of.

    How long does it take to build?

    The knowledge foundation — enough published content to make the API worth subscribing to — takes weeks to months of consistent work. The technical infrastructure, once you have the knowledge foundation, can be deployed in a few days with the right developer. The bottleneck is almost always the knowledge, not the technology.

  • The $5 Filter: A Quality Standard Most Content Can’t Pass

    The $5 Filter: A Quality Standard Most Content Can’t Pass

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    Here is a simple test that most content fails.

    Would someone pay $5 a month to pipe your content feed into their AI assistant — not to read it themselves, but to have their AI draw from it continuously as a trusted source in your domain?

    $5 is not a lot of money. It’s the price of one coffee. It covers hosting costs and a small margin. It’s the lowest viable price point for a subscription product.

    And most content can’t clear it.

    Why Most Content Fails the Test

    The $5 filter exposes three failure modes that are common across the content landscape:

    Generic. The content says things that are true but not specific. “Good customer service is important.” “Location matters in real estate.” “Consistency is key in marketing.” These claims are not wrong. They’re just not worth anything to a system that already has access to the entire internet. If everything you publish could have been written by anyone with a general knowledge of your topic, your content has low API value regardless of how much traffic it gets.

    Thin. The content exists but doesn’t go deep enough to be useful as a reference. A 400-word post that introduces a concept without developing it. A listicle that names eight things without explaining any of them. Content that satisfies a keyword without actually answering the question behind it. This kind of content might rank. It’s not worth subscribing to.

    Inconsistent. Some pieces are genuinely excellent — specific, well-reported, information-dense. Most are filler published to maintain posting frequency. An inconsistent feed isn’t a reliable source. A system pulling from it can’t know when it’s getting the good stuff and when it’s getting noise. Reliability is a prerequisite for subscription value.

    What Passes the Filter

    Content passes the $5 filter when it has three properties simultaneously:

    It’s specific enough to be useful in a way that nothing else is. Not “here’s how restoration contractors approach water damage” — but “here’s how water damage in balloon-frame construction built before 1940 behaves differently from modern platform-frame, and why standard drying protocols fail in those structures.” The specificity is the value.

    It’s reliable enough that a system can trust it. Every piece maintains the same standard. The sourcing is consistent. Claims are documented. The author has credible experience in the domain. A subscriber — human or AI — knows what they’re getting every time.

    It’s rare enough that it can’t be found elsewhere. The test isn’t whether it’s good writing. The test is whether an AI system could get the same information from somewhere it already has access to. If yes, the subscription isn’t necessary. If no — if this is the only reliable source for this specific knowledge — the subscription is justified.

    Using the Filter as an Editorial Standard

    The most useful application of the $5 filter isn’t as a revenue test. It’s as an editorial standard.

    Before publishing anything, ask: if someone were paying $5 a month to access this feed, would this piece justify part of that cost? If the honest answer is no — if this piece is thin, generic, or inconsistent with the standard of the best things you publish — that’s the signal to either make it better or not publish it at all.

    This is a harder standard than “does it rank” or “did it get clicks.” It’s also a more durable one. The content that clears the $5 filter is the content that compounds — that becomes more valuable over time, that gets cited, that earns trust from both human readers and AI systems that draw from it.

    The content that doesn’t clear it is noise. And there’s already plenty of that.

    What is the $5 filter?

    A content quality test: would someone pay $5/month to pipe your content feed into their AI assistant as a trusted source? Not to read it — to have their AI draw from it continuously. Content that passes this test is specific, reliable, and rare enough to justify a subscription.

    What are the most common reasons content fails the $5 filter?

    Three failure modes: generic (true but not specific enough to be useful), thin (introduces a concept without developing it enough to be a real reference), and inconsistent (excellent pieces mixed with filler that degrades the reliability of the feed as a whole).

    Can the $5 filter be used as an editorial standard even without building an API?

    Yes — and that’s often the most valuable application. Using it as a pre-publish question (“would this piece justify part of a $5/month subscription?”) enforces a higher standard than traffic-based metrics and produces content that compounds in value over time.

  • Hyperlocal Is the New Rare: Why Local Content Has the Highest API Value

    Hyperlocal Is the New Rare: Why Local Content Has the Highest API Value

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    Ask any major AI assistant what’s happening in a city of 50,000 people right now. What you’ll get back is a mix of outdated information, plausible-sounding fabrications, and generic statements that could apply to any city of that size. The AI isn’t being evasive. It genuinely doesn’t know, because the information doesn’t exist in its training data in any reliable form.

    This is not a temporary gap that will close as AI improves. It’s a structural characteristic of how large language models are built. They’re trained on text that exists on the internet in sufficient quantity to learn from. For most cities with populations under 100,000, that text is sparse, infrequently updated, and often wrong.

    Hyperlocal content — accurate, current, consistently published coverage of a specific geography — is rare in a way that most content isn’t. And in an AI-native information environment, rare and accurate is exactly where the value concentrates.

    Why Local Knowledge Is Structurally Underrepresented in AI

    AI training data skews heavily toward content that exists in large quantities online: national news, academic papers, major publication archives, Reddit, Wikipedia, GitHub. These sources produce enormous volumes of text that models can learn from.

    Local news does not. The economics of local journalism have been collapsing for two decades. The number of reporters covering city councils, school boards, local business openings, zoning decisions, and community events has dropped dramatically. What remains is often thin, infrequent, and not structured for machine consumption.

    The result: AI systems have sophisticated knowledge about how city governments work in general, and almost no reliable knowledge about how any specific city government works right now. They know what a school board is. They don’t know what the school board in Belfair, Washington decided last Tuesday.

    What This Means for Local Publishers

    A local publisher producing accurate, structured, consistently updated coverage of a specific geography owns something that cannot be replicated by scraping the internet or expanding a training dataset. The knowledge requires physical presence, community relationships, and ongoing attention. It’s human-generated in a way that scales slowly and degrades immediately when the human stops showing up.

    That non-replicability is the asset. An AI company that wants reliable, current information about Mason County, Washington has one option: get it from the people who are there, covering it, every week. That’s a position of genuine leverage.

    The API Model for Local Content

    The practical expression of this leverage is a content API — a structured, authenticated feed of local coverage that AI systems and developers can subscribe to. The subscribers aren’t necessarily individual readers. They’re:

    • Local AI assistants being built for specific communities
    • Regional business intelligence tools
    • Government and civic tech applications
    • Real estate platforms that need current local information
    • Journalists and researchers who need structured local data
    • Anyone building an AI product that touches your geography

    None of these use cases require the local publisher to change what they’re already doing. They require packaging it — adding consistent structure, maintaining an API layer, and making the feed available to subscribers who will pay for reliable local intelligence.

    The Compounding Advantage

    Local knowledge compounds in a way that national content doesn’t. Every article about a specific community adds to a body of knowledge that makes the next article more valuable — because it can reference and build on what came before. A publisher who has been covering Mason County for three years has a contextual richness that no new entrant can replicate quickly.

    In an AI-native content environment, that accumulated local context is a moat. It’s not the kind of moat that requires capital to build. It requires consistency and presence. Both are things that a committed local publisher already has.

    Why is hyperlocal content valuable for AI systems?

    AI training data is sparse and unreliable for most small cities and towns. Accurate, current, consistently published local coverage is structurally scarce — it can’t be replicated by scraping the internet because the content doesn’t exist there in reliable form. That scarcity creates value in an AI-native information environment.

    Who would pay for a local content API?

    Local AI assistant builders, regional business intelligence tools, civic tech applications, real estate platforms, journalists, researchers, and developers building products that touch a specific geography. The subscriber is typically a developer or AI system, not an individual reader.

    Does a local publisher need to change their content to make it API-worthy?

    Not fundamentally. The content just needs to be consistently structured, accurately maintained, and published on a platform with a REST API. The knowledge is the hard part — the technical layer is relatively straightforward to add on top of existing publishing infrastructure.

  • 8 Industries Sitting on AI-Ready Knowledge They Haven’t Packaged Yet

    8 Industries Sitting on AI-Ready Knowledge They Haven’t Packaged Yet

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    Most discussions about AI and knowledge focus on what AI already knows. The more interesting question is what it doesn’t — and where the humans who hold that missing knowledge are concentrated.

    Here are eight industries where the gap between human knowledge and AI-accessible knowledge is largest, and where the first person to systematically package and distribute that knowledge will have a durable advantage.

    1. Trades and Skilled Contracting

    Restoration contractors, plumbers, electricians, HVAC technicians — these industries run on tacit knowledge that has never been written down anywhere AI has been trained on. How water behaves differently in a 1940s balloon-frame house versus a 1990s platform-frame. Which suppliers actually deliver on time in which markets. What a claim adjuster will approve and what they’ll fight. This knowledge lives in the heads of working tradespeople and almost nowhere else. A restoration contractor who systematically publishes what they know about their trade creates a source of record that no LLM training corpus has ever had access to.

    2. Hyperlocal News and Community Intelligence

    AI systems know almost nothing accurate and current about most cities with populations under 100,000. They have no reliable data about local government decisions, zoning changes, business openings, school board dynamics, or community events in the vast majority of American towns. A local publisher producing accurate, structured, consistently updated coverage of a specific geography owns something genuinely scarce — and it’s the kind of current, location-specific information that AI assistants are being asked about constantly.

    3. Healthcare and Medical Specialties

    Clinical knowledge at the specialist level — how a specific condition presents in specific populations, what treatment protocols actually work in practice versus what the textbooks say, how to navigate insurance approvals for specific procedures — is dramatically underrepresented in AI training data. Practitioners who publish systematically about their clinical experience are creating a resource that medical AI applications will pay for access to.

    4. Legal Practice and Jurisdiction-Specific Law

    General legal information is well-covered. Jurisdiction-specific, practice-area-specific, and procedurally specific legal knowledge is not. How a particular judge in a particular county tends to rule on specific motion types. How local court practices differ from the official procedures. What arguments actually work in a specific venue. Attorneys with deep local practice knowledge are sitting on an information asset that legal AI tools are actively hungry for.

    5. Agriculture and Regional Farming

    Farming knowledge is intensely regional. What works in the Willamette Valley doesn’t work in Central California. Crop rotation strategies, soil amendment approaches, pest management, water management — all of it varies dramatically by microclimate, soil type, and local practice tradition. The accumulated knowledge of experienced farmers in a specific region is largely oral, rarely published, and almost entirely absent from AI training data. Extension offices and agricultural cooperatives that systematically document regional best practices are building something AI systems will need.

    6. Veteran Benefits and Government Navigation

    Navigating the VA, understanding how to build an effective disability claim, knowing which VSOs in which regions are actually effective, understanding how different conditions interact in the ratings system — this knowledge is held by experienced advocates, veterans service officers, and attorneys who have processed hundreds of claims. It’s the kind of procedural, outcome-based knowledge that AI assistants give confident but frequently wrong answers about, because the real knowledge isn’t online in a reliable form.

    7. Niche Retail and Specialty Markets

    Independent watch dealers, vintage guitar shops, specialty food importers, rare book dealers — businesses that operate in deep specialty markets accumulate knowledge about their inventory, their suppliers, their customers, and their market that no general AI has. The person who has been buying and selling vintage Rolex watches for twenty years knows things about specific reference numbers, condition grading, authentication, and market pricing that would be genuinely valuable to anyone building an AI tool for that market.

    8. Professional Services and Methodology

    Marketing agencies, management consultants, financial advisors, executive coaches — anyone who has developed a distinctive methodology through years of client work. The frameworks, playbooks, diagnostic tools, and hard-won lessons that experienced professionals have built represent some of the highest-value knowledge that AI systems currently lack access to. The consultant who has run 200 strategic planning processes has pattern recognition that no LLM has encountered in training. Packaging that into a structured, publishable, API-accessible form is both a content strategy and a product.

    In every one of these industries, the window to be the first credible, structured, consistently updated knowledge source in your vertical is open. It won’t be open indefinitely.

    Which industries have the most AI-accessible knowledge gaps?

    Trades and contracting, hyperlocal news, medical specialties, jurisdiction-specific legal practice, regional agriculture, veteran benefits navigation, specialty retail markets, and professional services methodology all have significant gaps between what experienced practitioners know and what AI systems can reliably access.

    What makes a knowledge gap an opportunity?

    When the knowledge is specific, current, human-curated, and absent from existing AI training data — and when there’s a clear audience of AI systems and agents that need it. The combination of scarcity and demand is what creates the market.

    How do you know if your industry has a valuable knowledge gap?

    Ask an AI assistant a specific, detailed question about your specialty. If the answer is confidently wrong, superficially correct, or missing the nuance that only practitioners know, you’re looking at a gap. That gap is the asset.

  • The Knowledge Distillery: Turning What You Know Into What AI Needs

    The Knowledge Distillery: Turning What You Know Into What AI Needs

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    There’s a gap between what an expert knows and what AI systems can access. Closing that gap isn’t a single step — it’s a pipeline. And most people who try to build it get stuck at the beginning because they’re trying to skip stages.

    The full pipeline has four stages. Each one builds on the last. Understanding the sequence changes how you approach the work.

    Stage One: Capture

    Most expertise never gets captured at all. It lives in someone’s head, expressed in conversations, demonstrated in decisions, lost the moment the meeting ends or the job is finished.

    Capture is the act of getting the knowledge out of the expert’s head and into some retrievable form. The most natural and lowest-friction method is voice — recording conversations, client calls, working sessions, or simple voice memos when an idea surfaces. Transcription turns the recording into raw text. That raw text, however messy, is the ingredient everything else requires.

    The key insight at this stage: you are not creating content. You are preventing knowledge from disappearing. The standard is different. Raw transcripts don’t need to be polished. They need to be honest and specific.

    Stage Two: Distillation

    Distillation is the process of pulling the discrete, transferable knowledge nodes out of raw captured material. A ten-minute conversation might contain three useful ideas, one important framework, and six minutes of context-setting. Distillation separates them.

    A knowledge node is the smallest unit of useful, standalone knowledge. It can be named. It can be explained in a paragraph. It can be understood by someone who wasn’t in the original conversation. If it requires too much context to be useful on its own, it isn’t a node yet — it’s still raw material.

    This stage is where most of the intellectual work happens. It requires judgment about what’s actually useful versus what just felt important in the moment.

    Stage Three: Publication

    Publication is the act of giving each knowledge node a permanent, addressable home. An article on a website. An entry in a database. A page in a knowledge base. The format matters less than the fact that it’s structured, findable, and consistently organized.

    High-density publication means each piece contains as much specific, accurate, useful knowledge as possible — not padded to a word count, not optimized for a keyword, but written to be genuinely worth reading by someone who needs to know what you know.

    This is also where the content becomes machine-readable. A well-structured article on a platform with a REST API is already one step away from being API-accessible. The publication step creates the raw material for the final stage.

    Stage Four: Distribution via API

    The API layer is what turns a collection of published knowledge into a product that AI systems can actively consume. Instead of waiting for a search engine to index your content, you’re offering a direct, structured, authenticated feed that an AI agent can call on demand.

    This is the stage that creates the recurring revenue model — subscriptions for access to the feed. But it only works if the prior three stages have been executed well. An API built on top of thin, generic, low-density content doesn’t have a product. An API built on top of genuinely rare, specific, human-curated knowledge does.

    The Flywheel

    The pipeline becomes a flywheel when you close the loop. API subscribers — AI systems pulling from your feed — generate usage data that tells you which knowledge nodes are being accessed most. That tells you where to focus your capture and distillation effort. More capture in high-demand areas produces better content, which justifies higher subscription tiers, which funds more systematic capture.

    The human expert at the center of this system doesn’t need to change what they know. They need to change how they let it out.

    What is the knowledge distillery pipeline?

    A four-stage process for converting human expertise into AI-consumable knowledge: Capture (get knowledge out of your head into raw form), Distillation (extract discrete knowledge nodes from raw material), Publication (give each node a permanent structured home), and Distribution via API (expose the published knowledge as a structured feed AI systems can pull from).

    What is a knowledge node?

    The smallest unit of useful, standalone knowledge. It can be named, explained in a paragraph, and understood without requiring the full context of the original conversation or experience it came from.

    Why is voice the best capture method?

    Voice capture requires no interruption to thinking — talking is how most people naturally process and articulate ideas. Recording conversations and transcribing them produces raw material that contains the knowledge at its most natural and specific, before it gets flattened by the effort of formal writing.

    Can anyone build this pipeline or does it require technical skill?

    The capture, distillation, and publication stages require no technical skill — just discipline and a consistent editorial process. The API distribution layer requires either technical help or a platform that handles it. The knowledge work is the hard part; the infrastructure is increasingly accessible.

  • Information Density Is the New SEO

    Information Density Is the New SEO

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    For most of the internet era, content was optimized for one thing: getting humans to click and read. The metrics were traffic, time on page, bounce rate. The editorial standard was loose — if it brought visitors, it worked.

    AI changes the standard entirely. When the consumer of your content is a language model — or an AI agent pulling from your feed to answer someone’s question — the question isn’t whether someone clicked. The question is whether what you published was actually worth knowing.

    Information density is the new SEO. And it’s a much harder standard to meet.

    What Information Density Actually Means

    Information density is the ratio of useful, specific, actionable knowledge to total words published. A 2,000-word article that contains 200 words of actual substance and 1,800 words of padding has low information density regardless of how well it ranks.

    High information density looks like: specific facts, precise terminology, named entities, concrete examples, actual numbers, documented processes, and claims that a reader couldn’t easily find anywhere else. Every sentence either advances the reader’s understanding or it doesn’t belong.

    This isn’t a new editorial standard. Good writers have always known it. What’s new is that AI makes it economically measurable in a way it never was before.

    The $5 Filter

    Here’s a useful test: would someone pay $5 a month to pipe your content feed into their AI assistant?

    Not to read it themselves — to have their AI draw from it continuously as a trusted source of information in your domain.

    If the answer is no, it’s worth asking why. Usually it’s one of three things: the content is too generic (nothing you’re saying is unavailable elsewhere), too thin (not enough specific knowledge per article), or too inconsistent (some pieces are excellent and most are filler).

    Each of those is fixable. But they require a different editorial process than the one that optimizes for traffic volume.

    How AI Evaluates Content Differently Than Humans

    A human reading an article will forgive thin sections if the headline was interesting or the introduction was engaging. They’re reading for a feeling as much as for information.

    An AI pulling from a content feed is doing something closer to extraction. It’s looking for claims it can use, facts it can cite, frameworks it can apply. Filler paragraphs don’t hurt it — they just don’t help. But if a source consistently produces content with low extraction value, AI systems learn to weight it less.

    The publications and creators that win in an AI-mediated information environment are the ones where every piece contains something genuinely worth extracting. That’s a different editorial culture than “publish frequently and optimize for keywords.”

    The Practical Shift

    Publishing fewer pieces with higher density outperforms publishing more pieces with lower density in an AI-native content environment. This runs counter to the volume-first content playbook that dominated the SEO era.

    The shift in practice looks like: more reporting, less summarizing. More specific numbers, fewer generalizations. More named examples, fewer abstract claims. More documented methodology, less opinion dressed as expertise.

    None of this is complicated. It’s just a higher standard — one that the AI consumption layer is now enforcing whether you’re ready for it or not.

    What is information density in content?

    Information density is the ratio of useful, specific, actionable knowledge to total words published. High-density content contains specific facts, precise terminology, concrete examples, and claims a reader couldn’t easily find elsewhere. Low-density content is padded with filler that doesn’t advance understanding.

    Why does information density matter more now?

    AI systems consume content differently than humans. They extract claims, facts, and frameworks — and learn to weight sources by how reliably useful those extractions are. High-density sources get weighted higher; low-density sources get ignored regardless of traffic volume.

    How do you increase information density?

    More reporting, less summarizing. Specific numbers instead of generalizations. Named examples instead of abstract claims. Documented methodology instead of opinion. Every sentence should either advance the reader’s understanding or be cut.

    Is publishing less content the right strategy?

    In an AI-native content environment, fewer high-density pieces outperform more low-density pieces. Volume-first strategies optimized for keyword traffic are increasingly misaligned with how AI systems evaluate and weight content sources.

  • Your Expertise Is an API Waiting to Be Built

    Your Expertise Is an API Waiting to Be Built

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    Every person with genuine expertise is sitting on something AI systems desperately want and largely cannot find: accurate, specific, hard-won knowledge about how things actually work in the real world.

    The problem isn’t that the knowledge doesn’t exist. It’s that it hasn’t been packaged in a form that machines can consume.

    That gap — between what you know and what AI can access — is a business opportunity. And the people who figure out how to close it first are building something that didn’t exist five years ago: a knowledge API.

    What an API Actually Is (For Non-Developers)

    An API is just a structured way for one system to ask another system for information. When an AI assistant looks something up, it’s making API calls — hitting endpoints that return data in a predictable format.

    Right now, those endpoints mostly return publicly available internet data. Generic. Often outdated. Frequently wrong about anything that requires local, industry-specific, or human-curated knowledge.

    A knowledge API is different. It’s a structured feed of your specific expertise — your frameworks, your observations, your community’s accumulated intelligence — formatted so AI systems can pull from it directly. Instead of an AI guessing what a restoration contractor in Long Island would know about mold remediation, it calls your endpoint and gets the real answer.

    The Three Types of Knowledge That Have API Value

    Not all knowledge translates equally. The highest-value knowledge APIs share three characteristics:

    Specificity. Generic knowledge is already in the training data. What’s missing is specific knowledge — the kind that only comes from being in a particular place, industry, or community for a long time. A plumber who’s worked exclusively in older Chicago brownstones knows things about cast iron pipe behavior that no AI has ever been trained on. That specificity is the asset.

    Recency. LLMs have knowledge cutoffs. Local news from last week, updated regulations, new product releases, recent market shifts — anything time-sensitive is a gap. If you’re producing accurate, current information in a specific domain, you have something AI systems can’t replicate from their training data.

    Human curation. The internet has enormous quantities of information about most topics. What it lacks is a trustworthy human who has filtered that information, applied judgment, and produced something reliable. Curated knowledge — where a credible person has done the work of separating signal from noise — has a value premium that raw data doesn’t.

    What “Packaging” Your Knowledge Actually Means

    Building a knowledge API doesn’t require writing code. It requires a different editorial discipline.

    The content you publish needs to be information-dense, consistently structured, and specific enough that an AI pulling from it actually gets something it couldn’t get elsewhere. That means writing with facts, not filler. It means naming things precisely. It means being the source of record for your domain, not just a voice in the conversation about it.

    The technical layer — the actual API that exposes this content to AI systems — can be built on top of almost any publishing platform that has a REST API. WordPress already has one. Most major CMS platforms do. The knowledge is the hard part. The plumbing, by comparison, is straightforward.

    The Business Model

    The model is simple: charge a subscription for API access. The price point that works for community-tier access is low — $5 to $20 per month — because the value isn’t in any single piece of content. It’s in the continuous, structured feed of reliable, specific information that an AI system can depend on.

    For professional tiers — higher rate limits, webhook delivery when new content publishes, bulk historical pulls — $50 to $200 per month is defensible if the knowledge is genuinely scarce and genuinely reliable.

    The question isn’t whether the technology is complicated enough to charge for. The question is whether the knowledge is scarce enough. If it is, the API is just the delivery mechanism for something people would pay for anyway.

    Where to Start

    The starting point is an honest audit: what do you know that AI systems don’t have reliable access to? Not what you think you could write about — what you actually know, from direct experience, that is specific, current, and human-curated in a way that no scraper has captured.

    That knowledge, systematically published and structured for machine consumption, is your API. You already have the hard part. The rest is packaging.

    What is a knowledge API?

    A knowledge API is a structured feed of specific expertise — industry knowledge, local information, curated intelligence — formatted so AI systems can pull from it directly rather than relying on generic training data.

    Do you need to be a developer to build a knowledge API?

    No. Most publishing platforms already have REST APIs built in. The knowledge is the hard part. The technical layer that exposes it to AI systems can be built on top of existing infrastructure with relatively little engineering work.

    What makes knowledge valuable as an API?

    Specificity, recency, and human curation. Generic, outdated, or unverified information is already in AI training data. What’s missing — and therefore valuable — is specific knowledge from direct experience, current information that postdates training cutoffs, and content that a credible human has curated and verified.

    What should a knowledge API cost?

    Community-tier access typically works at $5–20/month. Professional tiers with higher rate limits and push delivery can command $50–200/month. The price is justified by knowledge scarcity, not technical complexity.

  • Notion-Deep, Surface-Simple: How to Build Knowledge Systems That Actually Get Used

    Notion-Deep, Surface-Simple: How to Build Knowledge Systems That Actually Get Used

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart Long-form Position Practitioner-grade

    There’s a useful architecture for how to hold complex knowledge inside an organization while keeping it accessible to the people who need to act on it.

    Call it Notion-Deep, Surface-Simple: build the internal knowledge structure as deep as you want, then surface it in the voice and format of whoever needs to use it.

    The Core Idea

    Most knowledge management systems fail in one of two directions.

    The first failure: they optimize for depth and comprehensiveness at the expense of usability. The system knows everything, but nobody can navigate it. It becomes the internal equivalent of a technical manual that everyone agrees is accurate and nobody reads.

    The second failure: they optimize for simplicity at the expense of utility. The output is clean and accessible, but the underlying knowledge is shallow. When edge cases show up — and they always do — the system has no answer.

    Notion-Deep, Surface-Simple resolves this by treating depth and accessibility as separate layers with separate jobs, rather than as tradeoffs against each other.

    What the Deep Layer Does

    The deep layer — think of it as the Notion workspace, the knowledge base, the internal documentation — is where you hold everything. It doesn’t compress. It doesn’t simplify. It doesn’t optimize for any particular audience.

    This layer holds the full process documentation. The exception cases. The history of why decisions were made. The technical architecture. The client-specific context that only your team knows. The frameworks that took years to develop. All of it goes here, as deep as it needs to go.

    The standard for this layer is completeness and retrievability — not readability for a general audience.

    What the Surface Layer Does

    The surface layer is not a simplified version of the deep layer. It’s a translation of it — rendered in the specific voice, vocabulary, and complexity level of whoever needs to act on it.

    The translation is the work. You pull from the deep layer exactly what’s needed for a specific person to make a specific decision or take a specific action. You render it in their language. You strip everything else.

    A prospect presentation pulls from the deep layer but speaks in the prospect’s language. A client onboarding document pulls from the deep layer but speaks in operational terms the client’s team actually uses. A quick brief for a new team member pulls from the deep layer but surfaces only the context they need to start.

    The depth doesn’t disappear. It’s available when the conversation earns it. But the default output is calibrated, not comprehensive.

    Why This Architecture Works

    When depth and accessibility are treated as tradeoffs, you’re always sacrificing one for the other. Every time you simplify, you lose fidelity. Every time you add depth, you lose accessibility.

    When they’re treated as separate layers, neither has to compromise. The deep layer stays complete. The surface layer stays accessible. The intelligence is in the translation — knowing what to pull, what to leave in, and how to render it for who’s in front of you.

    This also means the system scales. As the deep layer grows, the surface layer doesn’t have to get more complex. It just draws from a richer source. The translation skill remains constant even as the underlying knowledge compounds.

    How to Build This in Practice

    The starting point is a clear separation of intent. When you’re adding something to your knowledge base — documentation, process notes, client history, research — you’re feeding the deep layer. Don’t self-censor for a hypothetical reader. Put in everything that’s true and useful.

    When you’re building an output — a proposal, a client update, a training document, a content piece — you’re working the surface layer. Start from the deep layer as your source. Then translate deliberately: who is this for, what do they need to know, and in what voice will it land?

    Over time, the habit becomes automatic. The deep layer becomes the intelligence layer. The surface layer becomes the communication layer. And the translation between them — which is where most of the real thinking happens — becomes the core competency.

    What does Notion-Deep, Surface-Simple mean?

    It’s a knowledge architecture principle: build your internal knowledge base as deep and comprehensive as you need, then surface outputs from it in the specific voice and format of whoever needs to act on the information. Depth and accessibility are separate layers, not tradeoffs.

    What’s the difference between simplifying and translating?

    Simplifying removes information. Translating renders the same information in a different register. The goal is translation — pulling the right pieces from the deep layer and expressing them in the receiver’s language, without losing the underlying substance.

    Why do most knowledge systems fail?

    They optimize for either depth or accessibility, treating them as competing priorities. The result is either a comprehensive system nobody navigates or an accessible system that can’t handle edge cases.

    How does this scale as the knowledge base grows?

    As the deep layer grows richer, the surface layer draws from a better source without becoming more complex itself. The translation skill stays constant even as the underlying knowledge compounds over time.

  • Claude Managed Agents Pricing: $0.25/Session-Hour — Full 2026 Cost Breakdown

    Claude Managed Agents Pricing: $0.25/Session-Hour — Full 2026 Cost Breakdown

    Updated May 2026

    Pricing updated to reflect current Opus 4.7 launch ($5/$25 per MTok) and the retirement of Claude Sonnet 4 and Opus 4 on April 20, 2026. Managed Agents moved to public beta — see the complete pricing guide for current rate details.

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    Long-form Position
    Practitioner-grade

    $0.08 Per Session Hour: Is Claude Managed Agents Actually Cheap?

    Claude Managed Agents Pricing: $0.08 per session-hour of active runtime (measured in milliseconds, billed only while the agent is actively running) plus standard Anthropic API token costs. Idle time — while waiting for input or tool confirmations — does not count toward runtime billing.

    When Anthropic launched Claude Managed Agents on April 9, 2026, the pricing structure was clean and simple: standard token costs plus $0.08 per session-hour. That’s the entire formula.

    Whether $0.08/session-hour is cheap, expensive, or irrelevant depends entirely on what you’re comparing it to and how you model your workloads. Let’s work through the actual math.

    What You’re Paying For

    The session-hour charge covers the managed infrastructure — the sandboxed execution environment, state management, checkpointing, tool orchestration, and error recovery that Anthropic provides. You’re not paying for a virtual machine that sits running whether or not your agent is active. Runtime is measured to the millisecond and accrues only while the session’s status is running.

    This is a meaningful distinction. An agent that’s waiting for a user to respond, waiting for a tool confirmation, or sitting idle between tasks does not accumulate runtime charges during those gaps. You pay for active execution time, not wall-clock time.

    The token costs — what you pay for the model’s input and output — are separate and follow Anthropic’s standard API pricing. For most Claude models, input tokens run roughly $3 per million and output tokens roughly $15 per million, though current pricing is available at platform.claude.com/docs/en/about-claude/pricing.

    Modeling Real Workloads

    The clearest way to evaluate the $0.08/session-hour cost is to model specific workloads.

    A research and summary agent that runs once per day, takes 30 minutes of active execution, and processes moderate token volumes: runtime cost is roughly $0.04/day ($1.20/month). Token costs depend on document size and frequency — likely $5-20/month for typical knowledge work. Total cost is in the range of $6-21/month.

    A batch content pipeline running several times weekly, with 2-hour active sessions processing multiple documents: runtime is $0.16/session, roughly $2-3/month. Token costs for content generation are more substantial — a 15-article batch with research could run $15-40 in tokens. Total: $17-43/month per pipeline run frequency.

    A continuous monitoring agent checking systems and data sources throughout the business day: if the agent is actively running 4 hours/day, that’s $0.32/day, $9.60/month in runtime alone. Token costs for monitoring-style queries are typically low. Total: $15-25/month.

    An agent running 24/7 — continuously active — costs $0.08 × 24 = $1.92/day, or roughly $58/month in runtime. That number sounds significant until you compare it to what 24/7 human monitoring or processing would cost.

    The Comparison That Actually Matters

    The runtime cost is almost never the relevant comparison. The relevant comparison is: what does the agent replace, and what does that replacement cost?

    If an agent handles work that would otherwise require two hours of an employee’s time per day — research compilation, report drafting, data processing, monitoring and alerting — the calculation isn’t “$58/month runtime versus zero.” It’s “$58/month runtime plus token costs versus the fully-loaded cost of two hours of labor daily.”

    At a fully-loaded cost of $30/hour for an entry-level knowledge worker, two hours/day is $1,500/month. An agent handling the same work at $50-100/month in total AI costs is a 15-30x cost difference before accounting for the agent’s availability advantages (24/7, no PTO, instant scale).

    The math inverts entirely for edge cases where agents are less efficient than humans — tasks requiring judgment, relationship context, or creative direction. Those aren’t good agent candidates regardless of cost.

    Where the Pricing Gets Complicated

    Token costs dominate runtime costs for most workloads. A two-hour agent session running intensive language tasks could easily generate $20-50 in token costs while only generating $0.16 in runtime charges. Teams optimizing AI agent costs should spend most of their attention on token efficiency — prompt engineering, context window management, model selection — rather than on the session-hour rate.

    For very high-volume, long-running workloads — continuous agents processing large document sets at scale — the economics may eventually favor building custom infrastructure over managed hosting. But that threshold is well above what most teams will encounter until they’re running AI agents as a core part of their production infrastructure at significant scale.

    The honest summary: $0.08/session-hour is not a meaningful cost for most workloads. It becomes material only when you’re running many parallel, long-duration sessions continuously. For the overwhelming majority of business use cases, token efficiency is the variable that matters, and the infrastructure cost is noise.

    How This Compares to Building Your Own

    The alternative to paying $0.08/session-hour is building and operating your own agent infrastructure. That means engineering time (months, initially), ongoing maintenance, cloud compute costs for your own execution environment, and the operational overhead of managing the system.

    For teams that haven’t built this yet, the managed pricing is almost certainly cheaper than the build cost for the first year — even accounting for the runtime premium. The crossover point where self-managed becomes cheaper depends on engineering cost assumptions and workload volume, but for most teams it’s well beyond where they’re operating today.

    Frequently Asked Questions

    Is idle time charged in Claude Managed Agents?

    No. Runtime billing only accrues when the session status is actively running. Time spent waiting for user input, tool confirmations, or between tasks does not count toward the $0.08/session-hour charge.

    What is the total cost of running a Claude Managed Agent for a typical business task?

    For moderate workloads — research agents, content pipelines, daily summary tasks — total costs typically range from $10-50/month combining runtime and token costs. Heavy, continuous agents could run $50-150/month depending on token volume.

    Are token costs or runtime costs more important to optimize for Claude Managed Agents?

    Token costs dominate for most workloads. A two-hour active session generates $0.16 in runtime charges but potentially $20-50 in token costs depending on workload intensity. Token efficiency is where most cost optimization effort should focus.

    At what point does building your own agent infrastructure become cheaper than Claude Managed Agents?

    The crossover depends on engineering cost assumptions and workload volume. For most teams, managed is cheaper than self-built through the first year. Very high-volume, continuously-running workloads at scale may eventually favor custom infrastructure.


    Related: Complete Pricing Reference — every variable in one place. Complete FAQ Hub — every question answered.

    What to do next

    Now that you have the cost — here’s how to choose and implement

    You know the session-hour rate. The harder decision is whether Managed Agents is the right architecture vs. building on the raw API — or vs. OpenAI’s equivalent.