AaaS — The Agent Era's Neutral Reference Layer
The public manifesto and product overview for AaaS (Agents as a Service).
Edition: 2026-05-24.
Preface
This document is the public-facing companion to the AaaS strategic megadoc. It describes what AaaS is, what we are betting on, how we are building, and where we are going — at a level that anyone curious about the company, the category, or the bet can read end-to-end.
It is written to be excerpted. Take any section, paste it into a deck, fork it into your own essay, cite it in your own writing. The neutral-reference posture this document describes is also the posture it takes toward itself: it is meant to be useful to readers who will never become customers, and to remain useful long after the specifics inside it have evolved.
It is honest about what is shipping, what is in flight, and what is still bet rather than built. Where a claim is aspirational, it is marked. Where a claim is grounded in measurable evidence, the evidence is named.
The longer internal version of this document carries operational specifics — service inventories, secret topologies, infrastructure footguns, per-customer cost models, internal decision logs — that are load-bearing for the people building AaaS and irrelevant to the people reading about it. None of that is here. What is here is the strategy, the architecture-at-the-level-of-thesis, and the long view.
Table of Contents
- Executive Summary
- Part I — Vision & Thesis
- 1.1 What AaaS Is
- 1.2 The Founding Thesis
- 1.3 The North Star
- 1.4 The Ten Strategic Bets
- 1.5 The 10-Year Bet
- Part II — The Neutral-Reference Strategy
- Part III — The Agent-First Operating Model
- Part IV — Funnel-as-Code
- Part V — The Product Ecosystem
- Part VI — The Content Compounding Strategy
- Part VII — The Distribution Engineering
- Part VIII — The Business Model
- Part IX — The Roadmap
- Part X — The 10-Year Aspiration
Executive Summary
AaaS (Agents as a Service) is the neutral-reference infrastructure layer for the agentic AI ecosystem — a content graph, a skill marketplace, and an operations runtime that any agent can attach to.
That is the one-liner. Everything else in this document is a careful unpacking of why each word is exact.
We are not an agent framework. We are not a model wrapper. We are not a chatbot SaaS, not a no-code workflow tool, and not a vertical-agent product. We are what comes after those categories: the reference-and-runtime layer the agentic ecosystem attaches to, regardless of which framework, model, or vertical it is built on.
The strategic backing is quantified, not vibes-based. The Otterly 2026 AI Citation Report (over one million datapoints across ChatGPT, Claude, Perplexity, and AI Overviews) found that owned vendor content captures 4.3% of category-level AI citations, while community / neutral references capture 52.5% — a greater-than-tenfold gap. The companies winning agent-era mindshare — Stripe documentation, Hugging Face Hub, MDN, Anthropic's llms.txt surface — read as ecosystem infrastructure, not as marketing. AaaS is built on that asymmetry.
The five surfaces in market today, each playing one role in that thesis:
- The platform at
agents-as-a-service.com— the operational surface. Hosts the authenticated developer dashboard, the design library management page, tool surfaces, agent surfaces, and the API plane. - The blog at
aaas.blog— the citable knowledge graph for the agentic AI ecosystem. Thousands of entities across multiple collections, evidence-cited relationships, machine-readable surfaces (MCP, OpenAPI, llms.txt, per-entity Markdown projections). The thesis surface. - The vault at
aaas-vault— the open skill marketplace. Thousands of curated, production-ready skills installable into Claude Code, Cursor, Agent Zero, and any other agent runtime that speaks the SKILL.md manifest format. Open-source by default. - The Email Intelligence Engine (EIE) — the verification cascade. A four-phase deliverability and identity verification pipeline that any agent system can call as ecosystem utility.
- The design library — internal-tooling-as-product. A component catalog with a single-source-of-truth token registry, brand canon, and machine-readable variant manifests.
Underneath all five: the autonomous pipeline — a code-defined orchestration runtime, ~42 named specialized agents, ~5,761 SKILL.md files on disk (5,400+ published in the open vault across 16 marketplaces / 283 plugins as of 2026-05-24), ~12 MCPs declared in .mcp.json with ~27 ready-loadable (intentionally trimmed from a 40-server baseline because 31 were failing handshake), and a cross-session memory layer of 80+ curated entries. The company runs day-to-day on the same operating model it sells: 60% of operational tasks executed as deterministic code, 30% as rule-based hooks, 10% as LLM-required reasoning. This is the agent-first operating model, and it is what lets a very small team credibly ship and operate the surface area described above.
The bet is asymmetric and falsifiable. By 2027, AI-citation-share telemetry will show whether neutral-reference content is in fact compounding into agent-era mindshare on the trajectory the Otterly data predicts. If it is, AaaS holds a category-defining citation position in agentic AI by 2028, with the canonical reference surface, the canonical skill marketplace, and the canonical verification cascade. If it is not, the harness, the skills, the contracts, and the agent-first operating discipline pivot cleanly into vertical agentic-SaaS for specific industries — a smaller business, but a fully defensible one.
Either way, the work that compounds is the work that ships now. The proof is the next decade.
Part I — Vision & Thesis
1.1 What AaaS Is
The phrase "agent platform" in 2026 is overloaded to the point of uselessness. It currently covers at least five distinct things:
- Agent frameworks (LangChain, CrewAI, AutoGen, LlamaIndex) — code libraries developers wire up themselves.
- Model wrappers with tools (OpenAI Custom GPTs, Claude Projects, Gemini Gems) — single-vendor chatbot UIs with retrieval and a tools panel.
- Hosted agent runtimes — somewhere to put the inference.
- Workflow automators (Zapier, Make, n8n) — pre-LLM trigger/action graphs with an "AI step" bolted on.
- Vertical agent SaaS (Devin, Harvey, Sierra) — one agent, one job, one customer segment.
None of those describe what AaaS is.
The reason the category looks crowded is that vendors keep building inside the agent — the model, the orchestrator, the UI — and calling that a platform. The asymmetric opportunity is outside the agent: the references it cites, the skills it loads, the verification steps it runs before it acts, the publishing surface that distributes what it produces. That outside layer is what AaaS builds.
What we do
AaaS today is a small constellation of surfaces, each playing a distinct role in the same thesis:
- The platform — the operational hub. The authenticated developer dashboard, the design library management page, tool surfaces, agent surfaces, and the API plane.
- The blog — the citable neutral reference. A modeled knowledge graph for the agentic AI ecosystem with thousands of entities, working server-side rendering with incremental static regeneration, structured data, and a deployed MCP server. The strategic centerpiece for the citation-share thesis.
- The vault — the skill marketplace. A public, curated, open-source registry of production-ready agent skills covering more than fifty categories, addressable by any agent runtime that reads the SKILL.md manifest format.
- EIE — the email intelligence engine. A four-phase verification cascade that treats deliverability and identity validation as first-class infrastructure rather than as an afterthought.
- The design library — internal tooling published as product. A component catalog with a token single-source-of-truth, brand palette canon, and machine-readable variant manifests.
Sitting underneath all of these: the autonomous pipeline. A code-defined orchestration runtime that handles the operational work of the company on a 60/30/10 split (deterministic CLI / rule-based hooks / LLM-required reasoning). The pipeline is how the company runs day-to-day, but it is also a product surface in its own right — published as orchestrator plugins, deliberately tool-agnostic by construction.
What we are explicitly NOT
This list exists because every founder conversation eventually gets one of these wrong:
- Not an agent framework. We don't compete with LangChain or CrewAI. Agents built with any framework can attach to AaaS surfaces.
- Not a model wrapper. No proprietary model. No fine-tunes. No "AaaS GPT".
- Not a chatbot SaaS. No conversational product. No "talk to your data".
- Not a no-code workflow tool. No drag-and-drop graph editor.
- Not a vertical agent SaaS. We don't sell "an AI lawyer" or "an AI SDR". We sell the layer underneath whichever agent you're running.
- Not a research lab. Strategy is to be the citable reference, not to publish original frontier-model research.
- Not a marketing-content factory. AI-generated SEO blog posts are explicitly rejected for our reference surfaces — they are the opposite of the neutral-reference posture we are betting on.
Taglines & elevator pitches
1 sentence:
AaaS — the neutral-reference infrastructure layer for the agentic AI ecosystem.
1 paragraph:
AaaS builds the layer outside the agent — the references it cites, the skills it loads, the verification it runs, the surfaces it publishes to. Today: a multi-thousand-skill marketplace, an entity knowledge graph designed to be cited by ChatGPT and Claude, a verification cascade for agent inputs, and a published design and ops library that other teams adopt. We bet that in the agent era, infrastructure that reads as neutral reference compounds faster than vendor-branded content — a bet backed by the >10× citation-share gap measured in Otterly's 2026 AI Citation Report.
1 page:
Every model vendor is building inside the agent — better orchestration, better tool use, better UIs. Almost nobody is building the layer outside: the references the agent retrieves, the skills it dynamically loads, the verification steps it runs before it acts on a fact, the publishing surface that distributes what it produces. That outside layer is leverage. The same Otterly 2026 data that pins owned vendor content at 4.3% citation share pins community/neutral references at 52.5% — Stripe docs and Hugging Face Hub win agent-era mindshare for the same reason Wikipedia did the previous era's. Infrastructure that reads as neutral reference compounds. Marketing doesn't.
AaaS is shipping five surfaces, each playing one role in that thesis. The platform is the operational hub. The blog is the citable knowledge graph. The vault is the skill marketplace. EIE is verification infrastructure. The design library is internal tooling published as product. Underneath: an autonomous-pipeline runtime that handles operations on a 60% deterministic / 30% rule-based / 10% LLM-required split — the company runs on the same infrastructure it sells.
We are not an agent framework, not a model wrapper, not a chatbot SaaS, not a no-code workflow tool, and not a vertical agent product. We are what comes after those: the reference-and-runtime layer the agentic ecosystem attaches to. The closest historical analogs are Stripe (developer infrastructure disguised as docs), Hugging Face (community knowledge graph disguised as model host), and Cloudflare (infrastructure disguised as free tier). All three won by being reference points first, products second.
Positioning vs adjacent categories
| Adjacent category | Representative names | How AaaS differs | | ---------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agent frameworks | LangChain, CrewAI, AutoGen, LlamaIndex | Frameworks are libraries developers wire up. AaaS is what their wired-up agent attaches to at runtime — the skill registry it loads from, the entity graph it cites, the verification cascade it calls. We don't compete; we plug in. | | Vendor-locked agent UIs | OpenAI Custom GPTs, Claude Projects, Gemini Gems | Those are single-vendor chatbot surfaces. AaaS is vendor-neutral by construction. Our skills run on Claude Code, Cursor, Agent Zero, and anything else that speaks the manifest format. | | Workflow automators | Zapier, Make, n8n, Workato | Trigger/action graphs with optional AI steps. AaaS doesn't sell automation graphs. | | Hugging Face Hub | HF Hub, Papers-With-Code, Model Garden | HF is a model + dataset registry with a community graph layered on. AaaS-blog is a smaller, agentic-specific knowledge graph modeled after HF's entity-graph + curation pattern. We complement HF rather than replace it. | | Vertical agent SaaS | Devin, Harvey, Sierra, Decagon | Those are productized single agents for one ICP. AaaS sells the infrastructure underneath whichever agent the customer runs — including vertical-agent vendors as potential customers of the vault and blog. | | Marketing-content SaaS | Jasper, Copy.ai, Writesonic | AI-generated marketing copy at scale. AaaS explicitly rejects that posture for content surfaces — AI-generated SEO posts are the opposite of the neutral-reference position we're betting on. | | Developer-tooling marketplaces | npm, PyPI, Marketplace.visualstudio | General-purpose code package registries. The vault is agent-specific: skills, prompts, agent definitions, MCP configs — artifacts that don't fit in npm's shape and are scattered across personal dotfiles today. | | MLOps platforms | Weights & Biases, MLflow, Determined | Experiment tracking and model lifecycle for ML training. AaaS does not touch model training. |
1.2 The Founding Thesis
The single load-bearing claim the company is betting on: the agentic-AI era is creating a new infrastructure category — call it agentic-SaaS — and the durable winners will be positioned as neutral reference infrastructure for the agent ecosystem, not as agent vendors competing inside it.
Everything else in this document is downstream of that claim.
The macro shift (2023 → 2026)
Three structural shifts happened between the GPT-4 launch (March 2023) and today (May 2026) that together flipped agents from "demos with caveats" to "deployable workers":
1. Tool-use standardization. The Model Context Protocol (MCP) — open-sourced by Anthropic in November 2024 — turned tool-calling from a per-vendor schema into a portable contract. By Q2 2026 MCP is shipped by Anthropic, OpenAI (via SDK adapters), Cursor, Continue, Cline, Zed, and the broad self-hosted ecosystem. MCP isn't elegant — it's just standard. That standardness is the moat: any agent that speaks MCP can attach any MCP server with zero per-pair integration work. Before MCP, agent ↔ tool integration was O(N×M). After MCP, it's O(N+M). This is the same phase-shift HTTP gave web services or LSP gave editors.
2. Frameworks matured into runtimes, not toolkits. The 2023 wave (LangChain, AutoGPT, BabyAGI) treated "agent" as a chat-loop with tools wired in by hand. The 2024-2026 wave (Claude Code, Cursor agent mode, Codex CLI, OpenAI's Agent SDK, the Anthropic Agent SDK) treats agents as long-lived processes with state, memory, planning DAGs, hooks, retry semantics, cost budgets, audit logs, and isolation guarantees. The shift is from "agent = prompt + tools" to "agent = process + protocol". Once agents are processes, they need ops infrastructure, and ops infrastructure compounds.
3. The cost/capability curve crossed the deployability threshold. Claude Opus 4.7 (May 2026), GPT-5, and Gemini 2.5 Pro all sit in a price-performance band where a multi-step agent task costs cents-to-dollars per run rather than dollars-to-tens. Meanwhile Claude Haiku, Gemini Flash, and GPT-5 mini make per-decision micro-tasks effectively free. The economic model that makes agentic-SaaS viable — heavy-LLM for the hard 10%, deterministic CLI for the cheap 60%, rule-based hooks for the structured 30% — only works because the curve has flattened.
Independently, none of these would matter much. Together, they create the first moment where a small team can credibly build, deploy, and operate agents as services other systems and humans consume on demand — which is what "agentic-SaaS" means as a category.
The market gap
The current vendor landscape clusters into three categories, and none of them is the thing the thesis describes:
- Model wrappers rebrand an LLM behind a UI for a single use-case. Margin erodes with every base-model price drop. No durable defensibility unless they pivot to workflow.
- Agent frameworks give developers the components to build agents themselves. Defensibility comes from developer mindshare, not end-user value. Monetization is hard.
- Vertical agent products are agents-as-products in a specific lane. Often well-funded, often competing head-on with the model labs that are simultaneously their supplier and largest competitor.
The gap none of these fill: infrastructure that the entire agent ecosystem consumes regardless of which framework, model, or vertical product they're built on. The historical analog is Stripe — Stripe didn't build a payments product competing with Shopify or Square; it built the payments infrastructure both Shopify and Square run on. Or Hugging Face — not a model vendor, but the reference catalog every model vendor ends up linking to. Or, less flatteringly, Cloudflare — not a website, but the layer most websites can't route around.
The thesis is that the agent era will produce its own Stripe / HF / Cloudflare equivalents, and the window to position into that role is open right now. The category is forming and no incumbent has locked it. AaaS's bet is to occupy the neutral-reference-infrastructure slot specifically — the catalog, the publishing layer, the verification cascade, the skill marketplace, the syndication contract — rather than to compete as Yet Another Agent Vendor.
The Otterly insight (4.3% vs 52.5%)
The strongest single quantitative anchor for the whole positioning is the Otterly 2026 AI Citations Report — over one million datapoints across ChatGPT, Claude, Perplexity, and Google AI Overviews. The finding: owned vendor content captures 4.3% of category-level citations; community / neutral references capture 52.5%.
The implication is uncomfortable but quantified. As AI search replaces keyword search as the dominant discovery layer, content that reads as vendor marketing becomes >10× less likely to be cited than content that reads as ecosystem reference. The size of the gap matters more than the absolute numbers — a 10× delta in citation share, compounded across the multi-year migration from Google-first to LLM-first discovery, is the difference between a content moat that compounds and a content cost that doesn't.
This is load-bearing for AaaS's choice to position the blog as a neutral agentic-AI knowledge base rather than as a marketing blog. It is the empirical floor under every editorial decision the company makes.
Honesty caveat: the Otterly dataset is itself partly self-promotional (Otterly sells AI-citation tracking), and the methodology has not been independently replicated at the time of writing. We treat the 4.3% / 52.5% numbers as directionally load-bearing, not as a precise constant. The thesis would still hold at 10% / 35%; it weakens but doesn't collapse at 25% / 30%; it breaks below ~30% / 30%. Independent verification before Series A is a deliberate commitment.
The asymmetric bet
Most agent companies are fighting head-on inside the agent-product lane. That's expensive, crowded, and exposes them to the model labs' bundling power. The asymmetric move is to not compete in that lane at all — instead, position as the infrastructure those agent products and the agent labs themselves consume.
Concretely, "neutral infrastructure for the agent ecosystem" means:
- A citable reference catalog that any agent — Claude, ChatGPT, Perplexity, Cursor's agent mode — pulls from when answering questions about the agentic-AI space. Wikipedia-for-agents positioning.
- A skill marketplace that any agent-runtime user can install from, with the contract documented as open standard rather than as a proprietary registry.
- A verification cascade that any agent system can call to verify deliverability, identity, or source-of-truth claims, framed as ecosystem utility not captive feature.
- A syndication contract that is provider-agnostic by design, deliberately open for third parties to implement.
- A funnel-as-code architecture where attribution is a single convention across surfaces, not a per-surface marketing concern.
Being category-creating rather than incumbent-fighting has two payoffs. First, the "competitor" framing is wrong from day one — Stripe doesn't have a competitor in the same sense Square has Toast, because Stripe isn't fighting for the same customer account. Both can win. AaaS-as-infrastructure isn't fighting Cursor or Devin for the same customer; it's selling to the agents those products spawn. Second, the brand-economics flip: marketing-positioned content earns 4.3% citation share, infrastructure-positioned content earns 52.5%. The same writing effort produces roughly twelve times the inbound discovery surface.
The cost of the bet is that the company looks weird for 12-24 months — investors and customers both pattern-match to the agent-product category and ask why we don't have a hero agent demo. The defense is to point at the structural payoffs (citation share, contract neutrality, public unauthenticated surface) and stay disciplined about not collapsing into the agent-vendor lane just because it's the legible one.
Counter-arguments and responses
| Objection | Strength | Response | | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | "The model labs will just build this infrastructure themselves and bundle it free." | Strong | Labs build vertically-integrated agent infrastructure tied to their own model. The neutral-reference slot is explicitly multi-vendor — a public MCP server is consumed by Claude, ChatGPT, and Perplexity equally, and that's a feature, not a bug. Labs structurally cannot occupy a "neutral across labs" position. | | "MCP is two years old; the standards war isn't settled." | Medium | The bet is on protocol-neutrality, not on MCP specifically. The syndication contract, the skill format, the entity catalog all sit above any single protocol. If MCP loses, the catalog/skills/syndicator infrastructure ports to whatever wins. | | "Neutral-reference infrastructure is great in theory but doesn't monetize. Wikipedia is broke." | Medium | Wikipedia explicitly rejected monetization. Stripe, HF, Cloudflare didn't. Monetization paths exist: skill-marketplace revenue share, verification-cascade usage pricing, hosted-platform tier, design-library transactional licensing. The reference content is the funnel, not the product. | | "The 4.3% / 52.5% Otterly number is one source and partially self-promotional." | Medium | Acknowledged. The thesis is robust to the number being 10/35 instead of 4.3/52.5, weakens but holds at 25/30, breaks below ~30/30. Independent verification is committed to. The directional claim is consistent with every adjacent dataset. | | "You're a tiny team. Even if the thesis is right, you'll be outbuilt by a Series B incumbent who pivots into the slot once they see the data." | Strong | Two defenses. First, infrastructure positions have winner-take-most dynamics once established. The moat is being citable-first, and that compounds on a calendar timer, not a headcount timer. Second, the technical surface is small enough (a catalog, a contract, a few MCP servers, a publishing pipeline) that a small team with strong autonomous-pipeline leverage can move at the cadence of a much larger team. |
Five-year horizon — if the thesis is right
By 2031: the blog is in the citation panel of representative agentic-AI queries on ChatGPT / Claude / Perplexity at substantial share. The skill marketplace is the install-from default for major agent runtimes — not because anyone mandated it but because it became uncontroversially the place. The syndication contract has third-party publisher implementations beyond the first one we shipped, and clients use it via the reserved client slot for their own publishing. EIE handles deliverability verification for a meaningful fraction of agent-driven email volume across other vendors' agent products. Monetization comes from a layered model (marketplace revenue share + verification-cascade usage + managed-platform tier + design-library licensing) that mirrors Stripe's evolution from a single product to a stack. Company is profitable at a small-team size, retains optionality on a larger raise, and has the brand of "the neutral infrastructure for agents". Series A or strategic-acquisition becomes a choice, not a necessity.
Five-year horizon — if the thesis is wrong
By 2031: AI-search citation share didn't migrate the way Otterly predicted, or the model labs successfully bundled neutral-infrastructure roles into their own stacks, or MCP and its successors collapsed into a single-vendor protocol. AaaS as a neutral-reference brand is no longer the right frame. Salvageable assets in this branch: the autonomous pipeline plus skill marketplace plus design-library transactional revenue work as a productized internal-tooling-as-product business (smaller market, real revenue); the documented operating model is itself a sellable consulting or acqui-hire asset.
Failure mode is not "company dies" but "company is a profitable small-tools shop rather than a category-defining infrastructure player". The thesis-wrong branch is survivable; the thesis-right branch is category-creating. The expected-value math favors the bet as long as the probability of "right" is greater than roughly 15%, which it plainly is.
1.3 The North Star
By end of FY2031, ≥30% of category-level agentic-AI citations across ChatGPT, Claude, Perplexity, Gemini, and AI Overviews — for the most-trafficked agent-ecosystem queries — resolve to an AaaS-owned surface.
The metric is a single quantitative measurement: citation share, computed on a recurring cadence via a representative prompt panel. The 30% threshold is the long-term target; the path runs through measurable quarterly progress over five years.
Why "citation share" and not the usual SaaS suspects
The Otterly 2026 baseline establishes that owned vendor content captures 4.3% of category-level AI-search citations, while neutral references capture 52.5% — a >10× gap. In an agent-mediated buying world, the surface that an LLM cites is the surface that gets the next API call, the next install, the next integration. Citation share is therefore the leading indicator of every downstream revenue stream: subscription, usage-based platform, vault marketplace, and design-library transactional.
Behavior the metric forces
Citation share forces five behavioral changes that other metrics would not:
- Editorial voice as engineering constraint. Every content decision must answer "does this read like a reference or like marketing?" — because the Otterly data quantifies that as a 10× citation gap.
- Public-unauth surfaces as a moat, not a leak. Public MCP, public OpenAPI, llms.txt, and selective robots.txt all serve citation share. A metric like "API keys issued" would push the opposite direction.
- Knowledge-graph depth over content volume. The strategic levers — LLM-assisted batch graph fill with evidence-citation gate, and daily auto-extension via curated paper feeds — invest in defensible graph density rather than weekly blog-post output.
- One contract across all surfaces. The syndication contract and UTM convention are the only way to attribute which surface earned which citation; the metric makes attribution non-optional.
- Slow, compounding, hard to fake. Citation share moves over months, not days. It rewards consistency and punishes growth-hack spikes.
Tradeoffs explicitly accepted
- Short-term ad revenue, signup growth, and vanity engagement are deprioritized.
- Direct-traffic SEO becomes a B-tier goal. Marketing surfaces are expected to convert at the Otterly-measured ~4% citation share; we measure them on direct traffic and conversion, not citation.
- The metric is hard to read for non-technical stakeholders. We accept that cost in exchange for a metric that actually predicts the future.
Supporting input metrics
| # | Input metric | Why it moves the North Star | | --- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Entity-graph density (entities × verified edges) | Citations land on entity pages; edges are what an LLM grounds on. | | 2 | Public-unauth agent endpoints live (MCP tools, OpenAPI ops, per-entity Markdown projections) | Each endpoint is a new attach surface for an agent. | | 3 | Inbound agent-API requests/week | Direct telemetry of agents actually using the surface. | | 4 | Vault skill installs / week | Skills installed by humans and agents alike — proxy for tooling-layer mindshare. | | 5 | Backlinks from neutral-reference peers | The Otterly study's 52.5% citation tier links to peers, not to vendors. Backlinks from the peer set predict citation tier membership. |
Anti-metrics
We explicitly do not optimize for:
- Raw blog/site pageviews. Pageviews and AI-citation share are decorrelated — high-traffic vendor content still gets 4.3% citation share.
- GitHub stars on owned repos. Vanity proxy for category interest; trivially gameable and not load-bearing for agent citation.
- MRR-only as a strategic dashboard. MRR is the lagging revenue artifact. Optimizing for MRR alone leads to closing the agentic surface (gating MCP, paywalling docs) — the opposite of what the Otterly thesis says wins. We measure MRR for fiduciary discipline; we don't steer by it.
Distance from today
As of 2026-05-24, AaaS surface area is at roughly 3–5% of the 30% citation-share target — within rounding distance of the Otterly-measured baseline for owned vendor content. The blog ships ~80% of the infrastructure required (thousands of entities, working incremental static regeneration, deployed MCP, JSON-LD) but is operationally invisible to agents in its starting state: MCP requires auth, robots.txt blanket-blocks public endpoints, OpenAPI 404s, llms.txt does not exist.
The five-year gap therefore decomposes into three phases: (1) make the existing surface visible (the four killshots — weeks to months); (2) make the existing surface deep (the two strategic levers — quarters); (3) compound (years of consistent neutral-reference editorial voice + peer-network membership). The hardest part is not the technical work; it is enforcing the editorial voice discipline across every new content decision for 1,825 consecutive days.
This metric will be re-validated annually. If after 18 months the citation-share trajectory is flat at <8%, the thesis — not the execution — is what's wrong, and the North Star must be re-derived from first principles.
1.4 The Ten Strategic Bets
Not a list of features or quarterly OKRs — the set of ten horizon claims the company is willing to be wrong about in public, each load-bearing enough that disconfirmation would force a strategic rewrite, not just a roadmap tweak.
Bet 1: AaaS wins the agent era by reading as neutral infrastructure, not as a vendor. The Otterly >10× gap is a structural property of how retrieval-augmented models rank sources, not a tone problem fixable with copy edits. This bet dictates editorial voice across every public surface and rejects the default SaaS instinct to make every page a conversion target.
Bet 2: The blog becomes the citable reference for the agentic ecosystem, not a marketing channel. A single neutral knowledge graph — thousands of entities, evidence-cited edges, LLM-readable surfaces — earns the same compounding citation gravity that Stripe docs and the Hugging Face Hub earn.
Bet 3: A daily auto-extension pipeline turns the blog into a self-compounding content asset. A fully automated ingestion loop — Hugging Face Daily Papers as curation oracle, the ODKE+ reference architecture as the extraction pattern — produces fresher, broader coverage than any manual editorial cadence we could staff.
Bet 4: A single funnel-as-code architecture beats a marketing department. Five public surfaces, three content streams, one syndication contract, one UTM convention. Distribution treated as engineering discipline rather than marketing function.
Bet 5: Owning the distribution stack compounds faster than renting it. A self-hosted publisher made first-choice in our distribution routing avoids vendor lock-in, gives us audit-level visibility, and lets us extend channel-specific behavior at the source.
Bet 6: The internal/client publishing split is a permanent architectural seam, not a temporary one. The internal-only publisher handles internal communications on our own OAuth apps; the future client-facing system — where customers publish from their own accounts — is fundamentally different in OAuth model, rate-limit policy, data ownership, and legal posture. The reserved type slot in the syndication contract is the architectural reminder.
Bet 7: An autonomous operating model (60/30/10) is durable competitive advantage, not just a productivity hack. The harness — autonomous pipeline, ~5,761 SKILL.md files on disk / 5,400+ in the published vault, ~42 named agents, ~12 declared MCPs (with ~27 ready-loadable), session-isolated worktrees, hooks-as-gates — compounds because every solved problem becomes a reusable skill or hook, and every footgun becomes a memory.
Bet 8: A curated skill marketplace becomes the company's external IP layer. The vault is not just internal tooling — it is the public expression of the agent-first operating model. Every shipped skill is both a reusable internal capability and a downloadable proof-of-competence.
Bet 9: Email infrastructure is a standalone moat, not plumbing. Most AI-era startups outsource email entirely. EIE (verification cascade), an in-house cadence pipeline, and a templated transactional layer with a canonical palette together turn reach, deliverability, and segmentation into a per-customer cost-of-acquisition advantage at scale.
Bet 10: Internal-tooling-as-product is the design moat, not a side effect. The design library, the tokens single-source-of-truth, the design pipeline (vector + raster + email + PDF + UI/icon generators), and the brand palette canon are deliberately built as if they were external products even when they're not. An internal design system that meets product-grade quality bar becomes the substrate for both faster shipping AND the eventual public design surface.
How the bets interrelate
The bets cluster, and the dependency graph matters as much as any single claim:
- Foundational tier (1, 2, 3): Bet 1 (neutral-reference posture) is the philosophical root. Bet 2 (the blog as citable reference) is its single largest concrete surface. Bet 3 (daily auto-extension) is what keeps Bet 2 alive past quarterly attention spans. If Bet 1 is wrong, Bets 2 and 3 are wrong by inheritance.
- Distribution tier (4, 5, 6): Bet 4 (funnel-as-code) is the contract layer; Bet 5 (own the publishing stack) is its first concrete implementation; Bet 6 (internal/client split) is the architectural seam that prevents the contract from collapsing under multi-tenant demand.
- Operating-model tier (7, 8): Bet 7 (autonomous 60/30/10) is the meta-bet that makes everything else affordable for a tiny team. Bet 8 (vault as external IP) is its outward-facing surface.
- Moat tier (9, 10): Bet 9 (email infrastructure) and Bet 10 (design-as-product) are the two clearest "we built it instead of renting it" wagers. Both are independent of every other bet and of each other.
Cross-cutting dependency: Bets 2, 3, 5, 9, and 10 all consume capacity that Bet 7 supplies. If the autonomous operating model fails to compound, every "we'll build it ourselves" bet downstream becomes a staffing problem the company can't afford to solve. Bet 7 is therefore the single highest-leverage falsification target.
1.5 The 10-Year Bet
A scene from 2036
It is a Tuesday in 2036. A developer in Lagos opens her terminal at nine in the morning, three coffees deep into a sprint. She is building a multi-agent system for a logistics customer and she has reached the question every builder reaches eventually: "Which agent framework should I use for cross-tool orchestration when latency matters and the tools are mostly long-tailed SaaS APIs?" She types it, unedited, into her AI coding assistant — the one she pays forty dollars a month for, the one that has more or less replaced Stack Overflow, Google, and three of her former colleagues. The assistant thinks for two seconds and answers in a paragraph. Three citations sit at the bottom of the answer. The first one is from aaas.blog.
She does not notice. She has no reason to. The citation is not surprising to her, any more than it was surprising, two decades earlier, to see Stripe documentation surface when you searched for "how do I handle a webhook." The infrastructure of the conversation has shifted underneath her without her ever needing to track the shift.
By 2036, citation share is what backlink share was for the two decades before it: the quiet, compounding measure of who shapes the conversation in a domain. And by 2036, AaaS has been positioning for this for a decade — since the spring of 2026, when most companies in the agent space were still optimizing for human eyeballs, still buying ad placements on a search-engine results page that fewer and fewer humans were actually reading.
The macro shift, restated for the long horizon
The interesting thing about the transition from "humans search Google" to "agents query LLMs" is not the user-experience change. The interesting thing is that it changes what kind of content compounds.
For twenty years, the content that compounded on the open web was content optimized for a human reader landing on a page. The economics rewarded gated whitepapers, "Get a Demo" CTAs, conversion-funnel landing pages — the entire apparatus of owned marketing content built around the assumption that a human would arrive, scan, and either bounce or convert. The dominant metric was traffic, and the dominant moat was the SEO link graph.
The agent era changes both the metric and the moat. When the consumer of a piece of content is an LLM — pulling it into a retrieval-augmented response, citing it in a generated answer, training on it in a future model run — the things the LLM rewards are almost the opposite of the things the SEO playbook rewards. The LLM does not bounce. It does not convert. It looks for content that reads as neutral reference: comprehensive, factual, low on rhetorical commitment to a single vendor's worldview, structured in a way that survives extraction from its original context.
The twelve-times gap is not a tactical observation. It is a market structure observation. It means that every dollar spent on owned-content marketing in the agent era buys roughly one-twelfth the future mindshare of the same dollar spent producing neutral-reference content. Compounded over the lifetime of an LLM-mediated discovery surface, the gap widens rather than narrows. This is the print-to-web transition again, the iOS-app-store transition again: the dominant distribution channel changes, the content that succeeds in the new channel looks structurally different, and the companies that notice early get a multi-year head start.
Three things that will be obvious in 2036 but aren't in 2026
First: agent-first will be the default. A traditional SaaS company's operational capacity scales with headcount. An agent-first company's operational capacity scales with the harness. In 2036, every company that survived the transition runs this way. In 2026, almost none do.
Second: neutral-reference content will be the only kind that compounds. By 2036, the SEO-marketing playbook of the 2010s reads the way the print-newspaper playbook of the 1990s read in 2010: a thing that worked for one specific era of distribution, no longer load-bearing.
Third: protocol neutrality at the infrastructure layer will be a competitive position, not a virtue. Companies that built around a single vendor's protocol (a single model lab's tool format, a single agent framework's plugin shape) will have been repeatedly punished by protocol churn. Companies that bet on the multi-protocol substrate underneath will be the ones still running.
What AaaS does differently because of this bet
The 10-year bet shows up in dozens of small decisions throughout the company:
- The blog is built as a neutral knowledge graph, not a marketing channel.
- The vault is open-source by default; revenue comes from curation and support, not from gating.
- The MCP server is public-unauthenticated; the API spec is openly published; per-entity Markdown projections are first-class surfaces.
- The syndication contract is published as a versioned package, deliberately reusable by third parties.
- The autonomous pipeline is documented, exported as plugins, and explicitly tool-agnostic.
- Internal tools are built to product quality so they can become external products.
None of these are short-term-optimal decisions. Each one accepts a short-term cost for a long-term compounding asset. The discipline to make them consistently, for years, under pressure, is the actual bet.
Honest counter-cases
- The model labs absorb the neutral-reference layer. Anthropic ships its own authoritative reference content for the agentic ecosystem; OpenAI does the same; the third-party citation surface gets compressed out of the pipeline. Pivot: vertical agentic-SaaS for chosen industries; the harness and the agent pool are the accelerants.
- MCP doesn't win. A successor protocol takes over and the multi-vendor neutral position fragments. Defense: the contracts (syndication, skill format, entity catalog) sit above any one protocol and port to whatever wins.
- AI search citation share never compounds the way Otterly suggests. Six quarters of telemetry shows flat citation share. Response: the bet has an explicit evaluation date; we pivot, not stall.
- A larger competitor pivots into the slot once they see the data. Defense: first-mover citation graphs persist on calendar time, not headcount time. The harness lets a small team move faster than a large one.
What success looks like, what failure looks like
Success state: AaaS is the layer that other systems route through. The mindshare is mediated by the LLMs and the agents rather than held directly with the human user. AaaS becomes infrastructure that quietly underlies the agent ecosystem the way Stripe quietly underlies online payments. Brand-wise: known as "the agent ecosystem's neutral reference" — a phrase that no longer needs to be explained.
Failure state: citation share stays flat. The neutral-reference content is read by humans but not preferentially cited by agents. The vault is downloaded but not the standard install location. The verification cascade serves AaaS internal needs but never becomes a third-party utility. In this branch, AaaS becomes a profitable small-tools shop — survivable, even good, but not category-defining.
The expected-value math favors the bet. The downside is bounded. The upside, if the thesis holds, is the agent-era equivalent of becoming the Stripe documentation for a category much larger than payments.
Part II — The Neutral-Reference Strategy
The playbook that worked, and the one that's quietly replacing it
From roughly 2010 through 2025, the dominant SaaS content playbook was so consistent it became invisible. Write a blog post. Frame it around a buyer pain. End it with a call-to-action. Funnel the reader toward a demo, a trial, a sales conversation. Every paragraph carried implicit conversion intent; every image had an alt tag tuned for search; every comparison post — without exception — concluded in favor of the publisher. The blog was top-of-funnel, the docs were mid-funnel, the pricing page was bottom-of-funnel, and the whole apparatus existed to move a human reader one notch further down a pipeline that ended in a purchase order.
This worked because humans were the entire distribution channel. A human read the post, a human clicked the CTA, a human filled the form. The marketing surface and the audience were tuned to the same frequency: persuasion. Bias was not a flaw in this system; bias was the product.
In the agent era, this playbook breaks — not at the edges, but at its load-bearing center. The AI agents that increasingly read content on behalf of users have no funnel intent. They do not click CTAs. They do not fill forms. They do not start trials. What they do, when they encounter a piece of content, is decide whether to cite it, summarize it, paraphrase it, or ignore it. And the signal they use to make that decision is, broadly, the opposite of the signal that optimizes for conversion. They want information density, factual accuracy, citable structure, and an absence of persuasive framing. Marketing-shaped content reads to them roughly the way a sponsored Tweet reads to a careful human: discounted on arrival.
The 2026 Otterly AI Citation Report turned this intuition into a number. Across the corpus they measured, owned content — the blog posts, landing pages, and gated assets that the SaaS playbook spent fifteen years optimizing — received 4.3% of AI-mediated citations. Neutral references — third-party documentation, open standards bodies, comprehensive technical references — received 52.5%. That is a twelve-times gap, and it widens every quarter the measurement is repeated. It is the kind of distribution shift that does not get reversed by tactical tuning. It is a structural reordering of which surfaces matter.
Two postures, drawn in their pure forms
The owned posture is content designed to convert. Its native artifacts are gated whitepapers behind email-capture forms, "ultimate guide" posts that resolve into demo CTAs, comparison pages where the publisher always wins, customer stories edited toward heroic-purchase narratives, and webinars whose true purpose is qualifying leads. The voice is first-person plural. The conclusions are foregone. The reader is, charitably, a prospect; less charitably, a target. Every page is instrumented with conversion analytics because the page exists to convert.
The neutral posture is content designed to be referenced. Its native artifacts look, on the surface, suspiciously like the owned ones — they are also docs, also guides, also technical references — but the orientation underneath them is inverted. Stripe's documentation is the canonical example. Stripe docs are cited across more than nine million backlinks, not because Stripe ran a backlink campaign, but because Stripe docs are the authoritative description of how Stripe works, written with such care and such referential honesty that the entire payments industry — including Stripe's competitors — uses them as the reference text for how modern payment APIs should behave. Hugging Face Hub model cards occupy the same niche for machine learning models: they are cited not as Hugging Face marketing but as the authoritative description of what a model is. MDN web docs are cited as the authoritative web platform reference, full stop, despite being maintained by Mozilla, which has a browser to sell.
The pattern across the winners is sharp and consistent. Each is the authoritative source for a thing, not a marketing surface for a company. Each describes a domain with greater fidelity than any alternative reference, and each pays the steep, daily, unglamorous price of maintaining that fidelity. The reward is not a conversion. The reward is that when an agent — or a developer, or a competitor, or a journalist — needs a citation for that thing, the link they reach for is yours.
The most subtle move in this posture, and the one that separates it from owned-content cosplay, is honesty about competitors. Stripe's documentation references other payment processors when the comparison is genuinely informative. Hugging Face hosts model cards for models from labs that compete directly with Hugging Face's own offerings. The referential honesty is not a generosity; it is the load-bearing element. It is what makes the reference citable, because it is what makes the reference trustworthy.
Why this is hard for most companies
If neutral-reference content is twelve times more citable, and citability is increasingly the distribution mechanism, the obvious question is why every company isn't already doing this. The honest answer is that the strategy is uncomfortable to execute in the specific way that organizational incentives make uncomfortable strategies disappear.
Marketing teams are measured on conversions. Neutral content does not produce trackable conversions on the timeline that marketing dashboards report on. A piece of neutral-reference content can compound for two years before it becomes the citation source the entire industry quotes, and during those two years it looks, to a quarterly review, like an underperforming asset.
Engineering teams write reference documentation, but they rarely position it strategically. The docs site is something the API team owns; the marketing site is something the brand team owns; the two surfaces drift apart in tone, in audience model, in conversion theory. The result is that companies which have, latent in their codebase, the seed of a citable neutral reference, never recognize what they have and never elevate it to the role it could play.
Leadership, presented with two strategies — one with a clear ROI model on a six-month horizon, one with a fuzzy ROI model on a six-to-eighteen-month horizon — will, on any reasonable risk-adjusted calculation, fund the first. The neutral-reference strategy has a latency that the funnel strategy does not, and during the latency window every competitor with an owned-content strategy is shipping more posts, more demos, more CTAs, more measurable activity. The neutral-reference team looks, on the surface, like it is falling behind.
It is not falling behind. It is compounding. But "compounding" is a word that means nothing on a dashboard until the compounding actually arrives, at which point it means everything. The discipline required is the discipline of investing through a measurement gap, and that discipline is rare because the organizational structures that fund work are built around closing measurement gaps, not opening them.
AaaS's specific application
AaaS bets on neutral-reference strategy across every public surface, deliberately, and with the awareness that the bet has a multi-year payoff curve.
The blog is positioned as the agentic-AI Knowledge Base, not as AaaS marketing. The editorial voice is third-person, factual, neutral. There are no "Why AaaS beats LangChain" posts and there will not be. When comparisons are warranted — and they often are, because the agentic ecosystem is moving fast and readers genuinely need orientation — the comparisons are factual: LangChain provides X, CrewAI provides Y, AaaS provides Z, here are the trade-offs, here are the contexts where each fits. No hyperbole. No conclusion that the publisher always wins. The reader is treated as someone trying to make a real decision, not as someone being moved down a funnel.
The vault — the skill marketplace — is surfaced as community contribution infrastructure, not as AaaS proprietary IP. Skills authored by third parties live alongside skills authored by AaaS, marked by provenance but not by hierarchy. The marketplace is a reference for the agentic ecosystem's emerging skill graph, not a sales channel for AaaS-branded artifacts.
The OpenAPI specification is open, public, unauthenticated, comprehensive. The llms.txt and llms-full.txt files are deliberately maintained in two density tiers — compact for opportunistic LLM ingestion, full for thorough ingestion — both updated as the API evolves. The MCP server is public and unauthenticated, rate-limited only to prevent abuse; no signup gate, no email capture, no waitlist. An agent that wants to read AaaS as a reference can do so freely, immediately, with no human in the loop. The architecture optimizes for citation, not for conversion.
This is not accidental. It is the externalization of an internal cultural rule that AaaS does not do unprompted promotion. The same rule that prevents engineers from filing self-congratulatory issues prevents the marketing surface from filing self-congratulatory blog posts. The discipline is consistent because the underlying principle is consistent: AaaS earns attention by being useful in ways that are independently verifiable, not by claiming attention through volume.
The cultural test
A strategy is only real if it survives the moments when honoring it costs something. Five cultural tests separate genuine neutral-reference posture from the marketing-team-renames-the-blog version.
Cultural test one: if a competitor's content is genuinely better on a topic, do we cite them? The answer has to be yes. Neutral-reference posture demands referential honesty, and referential honesty is what makes the reference citable. If the best public explanation of an agentic-orchestration pattern lives on a competitor's blog, that competitor's blog is what we link to when the topic arises. The alternative — burying the better source to avoid sending traffic away — is exactly the failure mode that degrades citability.
Cultural test two: does our blog post end with a CTA? The answer has to be no. The instant a neutral-reference page ends in "Get started with AaaS today," it stops being a neutral reference and becomes a marketing post wearing a neutral-reference costume. Agents detect the costume immediately. Humans detect it within seconds.
Cultural test three: do our marketing pages match the editorial standard of our reference content? The answer is mostly yes, with one deliberate exception. The sales-funnel pages on the platform are explicitly designed to convert, and they wear that intention openly. The honesty about which surface is doing which job is itself part of the strategy. What is forbidden is the in-between zone where a page pretends to be a neutral reference while quietly optimizing for conversion. That zone is where trust gets spent.
Cultural test four: would we accept a guest post on the blog written by a competitor, if the post is accurate and authoritative? The answer has to be yes. Neutral surfaces accept multi-source content. The criterion is quality and accuracy, not affiliation. A blog that only accepts posts from people who do not compete with its publisher is, definitionally, not neutral.
Cultural test five: are we comfortable losing some signups to competitors in the short term because our content is honest about where they are stronger? The answer has to be yes, with the long-term reasoning visible. Citation share is a compounding asset. A signup lost today to a competitor whose product genuinely fits the use case better is a small, real cost. A reputation gained today as the source that tells the truth is a small, real asset. Over five years, the asset outgrows the cost by a margin that the dashboards do not yet show but the data will eventually confirm.
The risk of being co-opted
A company that executes this strategy successfully eventually faces two pressures, and the long-term durability of the strategy is determined by how it handles them.
The first pressure is internal: the gravitational pull toward monetizing the neutral surface. Once it is producing measurable reputational return, someone, eventually, will propose gating part of it, or adding a "premium" tier, or instrumenting it for lead capture. Each individual proposal will sound reasonable. Each will be the start of the slide. Stripe has resisted this pressure for more than thirteen years; the docs remain entirely free, entirely ungated, and entirely comprehensive, and that resistance is the source of Stripe's docs moat. Hugging Face has resisted the equivalent pressure on model cards. The pattern across companies that have held the line is that the resistance is encoded in explicit policy and reinforced culturally on a continuing basis, not left to be re-litigated each quarter.
The second pressure is external: as competitors notice the strategy working, they will attempt to replicate it. This is healthy. A neutral-reference ecosystem with multiple credible references is more useful than one with a single reference, and the citations will distribute accordingly. The defense is not exclusivity; the defense is execution quality. The company that maintains the most accurate, most comprehensive, most up-to-date reference will continue to be the most-cited reference, regardless of how many imitators ship in the meantime.
For AaaS, the resistance to both pressures is encoded structurally — in our principles, in our memory feedback rules, in the non-goals listed in the funnel architecture, in the cultural prohibition on unprompted promotion. All of these are documents that exist so that the strategy survives the moments when honoring it is inconvenient.
Closing
Neutral-reference is uncomfortable in the short term because it does not optimize for the metrics that most companies, most boards, and most marketing leaders are measured against. There is no monthly chart that goes up. There is no funnel diagram with conversion rates at each stage. There is no neat attribution from blog post to closed deal.
In the long term, in an information economy increasingly mediated by agents, it is the only sustainable strategy. The agents will decide which sources to cite, and the criterion they will use is the criterion that humans should have been using all along: which source tells the truth, comprehensively, without an agenda visible at the margins.
AaaS is willing to make this bet because the alternative is a strategy that is already, quietly, ceasing to work. Five years of compounded citation share against five years of higher CTAs that no longer convert is not a difficult trade to evaluate once the framing is honest. The neutral-reference strategy is the bet that being the source the agents quote — and the source the humans behind the agents trust — is worth more, over the time horizon that matters, than being the source that shipped the most calls-to-action this quarter.
That is the bet. It is encoded in every public surface AaaS ships. It will look, for a while, like underperformance. Then it will not.
Part III — The Agent-First Operating Model
The new arithmetic of throughput
The CTO of a one-hundred-person engineering company has, on a good day, one hundred employees doing one hundred things in parallel. Standups, design reviews, code reviews, infra rotations, customer support, recruiting, performance management — the throughput of the organization is the throughput of the humans, minus the coordination tax. To do more, the CTO hires more. To do something new, the CTO finds someone, interviews them, onboards them, waits a quarter for them to ramp, and then watches the org chart grow by one node and the management overhead grow by slightly more than one node.
The founder of an agent-first company has a different shape entirely. On a good day, that founder has ~42 named specialized agents, thousands of skills (today ~5,761 SKILL.md files on disk; 5,400+ in the published vault), a curated set of MCP servers (~12 declared in .mcp.json, ~27 ready-loadable, intentionally lean), and a cross-session memory layer of 80+ entries that remembers every footgun the team has ever stepped on. The agents fan out in parallel. The skills compose. The memory persists. The throughput is comparable to a substantially larger company — sometimes greater, on the workloads that suit it — but the cost structure does not resemble that company at all. It resembles a script that runs forever.
This is not science fiction, and it is not a thought experiment. AaaS runs this way today. The longer internal version of this document was assembled by roughly seventy agent calls over about two hours, derived from a single plan file, with the founder directing rather than writing. Every section was drafted by a sub-agent, gated through quality hooks, cross-checked against a memory layer that flags hallucinations, and committed by an automated pipeline. The human contribution was the plan, the taste, and the stop conditions. The agents did the typing.
The agent-first operating model is not a marketing posture and it is not "use AI for some tasks." It is a structural claim: the default labor unit is an agent; human labor is the exception, reserved for tasks agents demonstrably cannot do. Everything downstream — cost structure, throughput, defensibility, even the kind of people you hire — follows from that single inversion.
The 60/30/10 decision matrix
The most common failure mode of self-styled "AI-first" companies is to AI everything. They route every task through an LLM call because LLMs are the new hammer and everything looks like a nail. This is expensive — every per-token call is metered, and the meter runs even when the task is deterministic — and it is slow, because a language model thinking about whether to write to a file is many orders of magnitude slower than the file system writing to a file.
AaaS's operating principles refuse this. The decision matrix is explicit:
- 60% of tasks are traditional. File I/O, git operations, data queries, API calls, deploy scripts, log scraping, backup rotations. These are handled by CLI tools, shell scripts, and standard automation. No LLM is involved because no LLM is needed.
- 30% of tasks are rule-based. Task routing, QA gating, validation, lint, format, type-check, secret scanning, branch protection enforcement. These are handled by hooks and scripts — deterministic logic with deterministic outputs. The harness fires them automatically; the agents do not have to remember to invoke them.
- 10% of tasks are LLM-required. Architecture decisions, code review, debugging novel failures, creative writing, strategy. These are the tasks where pattern matching against a large prior is actually load-bearing, and these are the tasks where heavy reasoning earns its keep.
The discipline is the inverse of the temptation. The temptation is to invoke the language model because it feels powerful. The discipline is to invoke it only when the alternative is worse. Ninety percent of the work that flows through AaaS on a given day runs on automation; ten percent reaches an LLM. Of that ten percent, most is covered by a flat-rate interactive subscription rather than per-API billing, because the LLM calls happen inside an interactive session rather than in a programmatic worker.
This is what makes the cost model work. A naive AI-first company building the same surface area as AaaS would burn through API credits at a rate that would make any CFO refuse to fund it. AaaS does not, because the harness is honest about which tasks are LLM tasks and which are not.
The harness as compounding asset
A traditional SaaS company's operational capacity scales with headcount. To handle more customers, more incidents, more features, more content, more channels — hire more humans. The relationship is roughly linear with a coordination penalty that grows super-linearly past a certain size. Adding the fiftieth engineer makes the team meaningfully less productive per head than adding the fifteenth did. This is one of the durable observations in software organizations, and no amount of process has ever fixed it.
AaaS's operational capacity scales with the harness. Every recurring task that gets encoded as a skill runs at marginal cost approximately zero, forever. Every footgun that gets encoded as a feedback memory immunizes every future session against the same mistake. Every project state captured becomes institutional knowledge that survives a context reset and persists across machines. Every typed contract published as a package bounds the blast radius of every future change.
The result is a flywheel that runs in the opposite direction from a SaaS hiring curve. The first time AaaS did a publication-and-syndication run, it took a human and an agent several days, and the agent made mistakes the human had to catch. The hundredth time, it took an agent fifteen minutes, and the human only saw the output. The thousandth time, the run is a single invocation that fans out to multiple channels with channel-specific settings auto-injected from a skill that was itself written by an agent in response to a hook firing on a transcript pattern. The cost per run trends to zero; the cost per new capability trends to one carefully-written skill.
Today the inventory is concrete enough to count. Dozens of specialized agents. Thousands of skills. A curated set of MCP servers. Hundreds of cloud services. And a tiny team running it all. The ratio of artifacts to humans is the entire thesis.
What this enables strategically
Several of the strategic moves described elsewhere in this document are only possible inside an agent-first operating model. They are not "easier" in such a model; they are structurally infeasible outside it.
The funnel-as-code architecture requires it. AaaS has no marketing team. Distribution is done by engineering, via agents and skills, because the cost of doing it by humans would consume the margin and the cost of doing it by agents is the cost of writing the skill once.
The neutral-reference content strategy requires it. A daily auto-extension pipeline that ingests curated paper feeds, runs them through an evidence-citation gate, and publishes structured entries produces a volume of content that a five-person content team could not match, at a cost that a five-person content team would not survive.
The browser-driven agency model requires it. Every "API-less" surface — partner dashboards, ad networks, social platforms with hostile rate limits, internal admin tools at vendors that refuse to ship machine interfaces — is automated via a desktop-control + Playwright stack. Without the agent layer, those surfaces would be a hiring requisition for a human ops team.
The autonomous pipeline is the orchestration layer that ties it all together. Plans go in as structured JSON; nodes execute; sub-agents fan out; hooks gate; memories persist; PRs come out. The founder reviews and merges, or the loop merges automatically when the green-and-mergeable conditions are met. The default state is the work getting done.
The cultural shift
The hardest part of becoming an agent-first company is not technical. The technology is real, available, and improving monthly. The hard part is psychological and organizational.
For the traditional founder, the hardest part is letting go of "I should do this myself" for tasks the agents can do better and faster. The reflex to write the code, the email, the spec, the deploy script — that reflex is the result of years of being the most productive person in the room. In an agent-first company the founder is not the most productive worker; the founder is the most productive director. Directing is a different skill, and the people who built their identity around individual contribution often resist learning it.
For the traditional engineer, the hardest part is treating agent prompts and skills as production code: versioned, tested, documented, code-reviewed. A skill that lives in someone's head or in an unversioned text file is not infrastructure; it is folklore. AaaS treats skills the way mature engineering teams treat shared libraries — a real codebase with real review standards, not a scratchpad.
For the traditional company, the hardest part is the org-chart inversion. "Manager of agent X" replaces "manager of team X." Career ladders that were calibrated against headcount-under-management become incoherent when the manager's leverage comes from the quality of their agents rather than the count of their reports. Compensation philosophy, promotion criteria, even office layouts get destabilized by this shift.
AaaS sidestepped most of this by being agent-first from day one. There was no team to convert, no ladder to renegotiate, no headcount commitments to honor. The cultural shift was not "shift"; it was "default." For late-stage adopters, the conversion will be the hardest part — harder than the technology, harder than the cost migration, harder than the architecture. Companies will fail at it not because the agents do not work, but because the humans cannot let go of the model they were rewarded for mastering.
The risk pattern
The agent-first model is not free of risk. It is a different risk profile, not the absence of one.
Hallucination escapes are the most-cited risk and the most-defensible one. An agent confidently does the wrong thing. The defenses are layered: evidence-citation gates refuse outputs that cannot be grounded; quality-gate hooks refuse code that fails lint, type-check, or test; multi-agent verification patterns force adversarial review before merge. The defenses are not perfect, but they are real, and they catch the kind of error that would otherwise reach production.
Memory drift is subtler and more dangerous. The institutional memory diverges from the institutional reality. A feedback memory says "always use X"; X was deprecated three months ago; the next session faithfully uses X. The defense is recurring curation rituals — humans review the memory layer the way they would review a wiki, prune stale entries, promote new ones.
Harness rot is the long-term version of memory drift. Skills proliferate, agents accumulate, hooks layer on hooks, and the harness eventually becomes opaque even to its owner. The maintenance discipline is periodic full reset, pipeline integrity audit, and harness scorecard.
Cost spirals happen when per-API-billed work runs unchecked. A loop forgets to terminate; a background job re-fires every minute; a sub-agent calls a sub-agent that calls a sub-agent. The defense is the 60/30/10 matrix that keeps the LLM out of work it does not belong in, plus caps and alerts.
Founder bandwidth is the least-discussed risk and possibly the most binding. Directing dozens of agents is a different skill than managing a small human team, and it is not obvious which humans have it. The cognitive load is different — less interpersonal, more architectural. Some founders thrive; some find that what they actually wanted was a team to lead, not a fleet to dispatch.
What is not true
A few claims about the agent-first model are easy to make and worth refusing.
"Agent-first means no humans are needed." False. Humans direct, evaluate, decide, taste, and intervene. Agents execute. The ratio of humans to agents is wildly different than in a traditional company, but the ratio is never zero, and the humans who remain are doing work that would be unrecognizable to their counterparts in a traditional org.
"Agent-first means a less skilled team." False, and inverted. The skill required to design agent systems and skills well is more demanding than the skill required to direct humans on simpler tasks. Anyone can ask another human to write a TypeScript function. Designing the skill, the hook, the gate, the memory pattern, and the failure mode for an agent to do it reliably forever is a harder problem.
"Agent-first means lower quality." Only if you skip the gating layers. With evidence-citation gates, quality-gate hooks, multi-agent verification, and a memory layer that catches recurring footguns, output quality can match and often exceed what a traditional team produces — because the gates are uniform, the memory is shared, and the worst engineer on the team is not a junior on their second week.
"Agent-first means no moat — everyone will do it." Maybe, in five years. But the cumulative compounding from a one-to-two-year head start is significant, and the cultural shift is hard enough that many incumbents will not make it before the gap closes them out. The moat is not the agents; the moat is the harness, the skills, the memory, and the operating discipline that took years to build.
Closing
The agent-first company is not a marketing claim and it is not a forecast. It is a structural choice with measurable consequences: a cost structure that does not scale with throughput, an operational capacity that scales with skills rather than headcount, and a defensibility that compounds with every footgun encoded and every contract typed. AaaS chose this structure from day one.
By 2030, this structure will be commonplace. The questions late-stage adopters are asking now — can agents really do this? what about quality? what about cost? what about my team? — will sound, in retrospect, like the questions a 1995 CFO asked about email. The answers will be obvious because the alternative will be obviously uncompetitive.
By 2026, the structure is still a competitive moat. The companies building inside it now are not "early adopters of AI." They are the prototypes of what an operating company looks like when the default labor unit changes. The moat will not last forever. It does not have to. It only has to last long enough to compound.
Part IV — Funnel-as-Code
In most companies, distribution is a marketing function. People make campaigns. They write posts, schedule them across channels, watch what works, write more. Engineering builds the product; marketing distributes it. The two organizations stay separate, with separate budgets, separate vocabularies, and separate definitions of done. A product manager would never ship a feature without tests, but a marketing manager routinely ships a campaign without a contract. Nobody finds this odd. It has been the default for thirty years.
The default made sense when the cost curves pointed a certain way. Distribution had a high marginal cost — you hired humans to do it, one campaign at a time, one post at a time. Engineering had a low marginal cost relative to its leverage on the product, but no leverage on the audience. Code didn't scale your reach. People did. So you built a marketing team, and you measured it the way you measured any service organization: throughput per headcount, conversions per campaign, the soft metrics of "brand."
In the agent era, the cost curves invert. Engineering can now scale audience reach directly — automated content generation, multi-channel publishing, deterministic attribution pipelines, agent-mediated distribution into surfaces that didn't exist three years ago (LLM citations, MCP catalogs, agent registries). Meanwhile, marketing-as-headcount struggles to keep up: the number of channels grows faster than any team can hire, the cycle time on a "good post" collapses, and the audience itself is increasingly mediated by software (recommender systems, agents, AI assistants) rather than by humans reading a feed.
The companies that win in this transition treat distribution the way they already treat infrastructure: as code. Typed contracts at every boundary. Versioned pipelines. Deterministic deployments. Observable metrics. They don't have "marketing campaigns." They have distribution systems. The shift is not a tooling preference. It is a category change in how a company competes for attention.
What "funnel-as-code" looks like in practice
The discipline has six visible properties.
Typed contracts at every boundary. The seam between content producers and publishing channels is an envelope, not a convention. Producers — the content streams that fire on database triggers, on blog publishes, on design-library events — emit a typed syndication request. Publishers — the channel adapters for LinkedIn, X, future surfaces — consume it. Both sides version independently. A breaking change requires a coordinated update, exactly like any other API. The "marketing person reformatting a post for LinkedIn" doesn't exist; the boundary that used to be a human is now a type.
Producer-side discipline. UTM parameters are applied at content production, not at the moment of posting. The caption builder generates channel-appropriate variants automatically — LinkedIn gets the long form, X gets the compressed hook, both inherit the same attribution payload. There is no "we forgot to tag that one" mode. The data the marketing dashboard reads tomorrow is a deterministic function of what the producer emitted today. If a UTM field is missing, the producer is broken; you don't fix it in a spreadsheet.
Channel-as-adapter. Every output surface is an adapter behind the contract. LinkedIn is an adapter. X is an adapter. The future Bluesky / Threads / Mastodon / agent-marketplace channels will each be an adapter. Adding a new channel is "build an adapter." It does not require redesigning the producer side, retraining the caption builder, or renegotiating the attribution schema. Channels become substitutable in the same way cloud providers became substitutable once your infrastructure was Terraform.
Hooks declared but not exported. The syndication contract declares hooks — the points where a producer fires and where a publisher acknowledges — but does not export them as a general-purpose interface. The discipline is encoded in the type system: every consumer must go through the envelope, no consumer can short-circuit. This sounds like a small detail. It is the whole game. The moment one team is allowed to "just call the LinkedIn API directly because it's faster," the contract is dead and the system reverts to a manual workflow with extra steps.
Attribution loop. Because the UTM convention is locked at the contract level, attribution becomes a deterministic query. The marketing dashboard is not a manual reconciliation exercise across five tools. It is a join. When the founder asks "did that announcement convert," the answer is one query against a known schema, not a three-hour spreadsheet exercise that ends in "we think so."
Test the pipeline like you test code. Smoke tests on the syndicator. Contract tests on each channel adapter. Integration tests on the publish hook. A pre-merge check that the caption builder produces the expected variants for each channel given a fixed input. The discipline that protects a payments pipeline from regressions is the same discipline that protects a distribution pipeline. The "we'll just look at the post after it goes out" model dies, because at scale you can't look at every post.
Why most marketing teams resist this
The resistance has a stack of plausible-sounding objections and one honest one.
"Distribution is creative work." True, in the sense that the headline and the angle and the visual are creative. False, in the sense that everything around the creative — the routing, the scheduling, the variant generation, the attribution tagging, the cross-channel reconciliation — is mechanical. The creative is what should be human; the mechanical is what should be code. Funnel-as-code doesn't eliminate the creative role. It frees the creative role from the 80% of the job that was always operational drudgery.
"Tools constrain creativity." They do, and that's the point. Constraints encode taste. A contract that forces a LinkedIn variant to fit a specific shape is encoding the empirical fact that LinkedIn rewards a specific shape. The constraint isn't suppressing creative choice; it's removing the recurring failure mode where a tired person at 4pm posts a 300-character X format to LinkedIn and wonders why it underperformed.
"Engineering is too slow for marketing pace." This is true once and false forever after. Building the system is slow. The marginal post after the system exists is dramatically cheaper than the manual workflow it replaces. Six months in, the funnel-as-code team is shipping ten times the post volume of the manual team and spending less calendar time doing it.
"Marketing data is too messy for typed contracts." That objection is a diagnosis, not a defense. If the data is too messy for a type system, the data model is wrong. The mess is not a property of the domain; it's a property of the years of accumulated convention-without-enforcement.
The honest reason underneath all of these is simpler. Funnel-as-code requires marketing teams to think like engineers — to reason about contracts, version compatibility, idempotency, error budgets, observability. Most marketing teams don't have that skill set, and many of the people in those teams chose marketing precisely because they didn't want it. That's a real human reality, not a strawman. The companies that adopt funnel-as-code early are the ones where the founder doesn't have a traditional marketing team yet, or where the marketing function is being rebuilt from scratch. They have a structural advantage that compounds, because every quarter the gap between their distribution system and a competitor's manual workflow widens.
AaaS's specific implementation
The funnel-as-code playbook at AaaS is not theoretical. It is shipping.
The architecture is funnel architecture v1: five surfaces (the platform, the blog, the design library, the vault, the agent registry), three content streams (release notes, deep essays, transactional events), one syndication contract, one UTM convention. The grid is small enough to hold in one head and explicit enough that every box has a known owner.
The contract itself is published as a versioned package. It defines the syndication request envelope, a Publisher name registry (with the first concrete implementation already wired and a future client-facing slot reserved type-only), and a hook surface that is declared but not exported. The UTM convention is locked at the type level — downstream queries are deterministic.
The publisher backend is self-hosted, MCP-integrated. LinkedIn and X channels are wired. The publishing command implements the producer side. The internal-only positioning is deliberate: the current publisher handles internal distribution; clients will eventually get a separate published system, and the reserved client type slot in the contract is the placeholder for that split.
The first end-to-end loop is shipping: a weekly episode document writes to the database. The trigger fires. The caption builder produces channel-appropriate variants. A syndication request is constructed. The publisher receives it. LinkedIn and X publish. UTM-tagged links flow back into the attribution pipeline. The whole loop is code; the whole loop is observable; the whole loop is tested.
The pattern is generalizing. Design-library transactional webhooks extend the same envelope to non-social-channel events. Every new surface added to the funnel inherits the existing contract; no surface is allowed to invent its own.
All of this was written by a tiny team. There is no marketing team in the traditional sense. There is a distribution system that does the work of what would otherwise be five-to-ten people on a content-and-distribution roster. This is not a heroic anecdote — it is the predictable consequence of treating the problem as engineering rather than headcount.
The compounding effect
Each piece of the system makes the next piece cheaper.
Every channel adapter built drops the marginal cost of the next campaign — because the campaign now only has to describe content, not routing. Every typed boundary built makes future changes bounded in scope — a contract change touches the contract and the adapters that depend on it, not an arbitrary mass of marketing operations. Every attribution loop closed shortens the decision cycle on what to do next, because the answer comes from a query rather than from a meeting.
Compare a competitor running a marketing team of five to ten people. Same headcount cost, probably more. Less throughput. Harder to scale, because every new channel requires a new hire or a stretched existing role. Attribution that is "we think so." A creative roadmap that lives in someone's head. Over two to three years, the gap between a funnel-as-code company and a manual-marketing competitor is not "we ship 20% more posts." It is structural — the funnel-as-code company has a distribution system that scales sublinearly with content volume, while the competitor has a workflow that scales linearly with headcount.
This is why "distribution becomes engineering" is not a small operational change. It is a category shift in how companies compete. The same kind of shift that happened when sales went from rolodex to CRM, when finance went from spreadsheet to general ledger, when ops went from runbook to Terraform. Each time, the early adopters looked over-engineered to the incumbents — and each time, ten years later, the incumbents were the ones being acquired.
The risk pattern
Funnel-as-code has failure modes. They are worth naming so the people building it know what to watch.
If the contract design is wrong early on, refactoring is expensive: every channel adapter has to update in lockstep, and the cost of a contract migration scales with the number of adapters that depend on it. This argues for over-investing in the contract design phase and resisting the temptation to ship the first adapter before the contract is right.
Test discipline matters more than in regular engineering, because distribution bugs are visible to the public. A broken deploy fails a CI check; a broken post embarrasses the company in front of every prospect on the timeline. The smoke-test budget on the syndicator should be larger, not smaller, than the smoke-test budget on an internal API.
And the recurring temptation — the one that kills these systems in practice — is the "marketing override" that bypasses the contract for a special case. Someone needs to ship a one-off campaign in a hurry. Someone wants to A/B test a channel-specific format without going through the caption builder. The pressure to add an escape hatch is constant. Resist it. Every bypass eventually becomes the default. The discipline of the contract is the contract being honored without exception.
Closing
Funnel-as-code is the marketing equivalent of what infrastructure-as-code was for ops in 2015. Both started in scrappy startups with no choice but to automate. Both faced cultural resistance from the incumbents whose jobs the automation reframed. Both were dismissed as over-engineering for years. Both, eventually, became table stakes — to the point where running production infrastructure by hand in 2025 is a sign that something has gone badly wrong, and running distribution by hand in 2030 will look the same.
AaaS bets that the category leaders of 2030 all run distribution as code. The contracts, the adapters, the attribution loops, the test discipline, the founder-plus-engineering team that out-ships a ten-person roster — those become the new default. The companies still running campaigns by hand will be the ones being acquired, restructured, or quietly retired.
We are writing the playbook now, in public. The bet is that in three years, the discipline will be obvious, and the only question worth asking will be "how did anyone ever do it the other way."
Part V — The Product Ecosystem
AaaS is not a single product with a single buyer. It is an ecosystem of surfaces, and each surface attracts a different profile and plays a distinct role in the same thesis.
The product ecosystem is intentionally small. Five surfaces in market today, each load-bearing, each independently useful, each connected via the same underlying contracts. The list is not "things we want to ship eventually" — it is "things we run today, in production, that real users touch."
The five surfaces
1. The Platform
The platform is the operational hub: the authenticated developer dashboard, the design library management page, tool surfaces, agent surfaces, and the API plane. It is the surface that customers log into. It is where the user-facing product lives.
It is intentionally not a marketing surface. The marketing pages exist and convert openly; the authenticated surfaces are designed to be useful, not to convert. The authentication boundary is the cleanest possible separation between "we are selling you something" and "we are helping you work."
Architecture is monorepo-organized — multiple apps under one umbrella, all using shared design tokens, shared authentication primitives, shared UI components. The repository structure encodes the product structure: each app is a directory, each directory has a clear owner, the inter-app contracts are typed packages.
2. The Blog — the citable neutral reference
The blog is the strategic centerpiece of the citation-share thesis. It is structured as an entity knowledge graph for the agentic AI ecosystem: thousands of entities across multiple collections (papers, models, tools, organizations, methodologies, protocols, agents, etc.), evidence-cited relationships between them, working server-side rendering with incremental static regeneration, structured data on every page, and a deployed MCP server that any agent can attach to.
The killshot strategy is the set of four mechanical surfaces that AI bots, MCP clients, and LLM-assisted browsers actually look for: a selective robots.txt that surfaces what agents want and gates only what is genuinely private; a public-unauthenticated MCP endpoint with strong per-IP rate limiting; a working public OpenAPI specification at the well-known location; and a pair of llms.txt files (compact and full) plus per-entity Markdown projections served via content negotiation.
The two strategic levers are what populate and refresh the surface: an LLM-assisted graph fill pipeline with mandatory evidence-citation gate (predicate-typing closes hallucinated targets, deterministic idempotency keys close rerun amplification, evidence quote + URL on every edge), and a daily auto-extension pipeline that uses curated paper feeds as a high-quality oracle and runs the ODKE+ reference architecture (Extraction Initiator → Evidence Retriever → hybrid LLM extractors → Grounder → Corroborator).
Killshots create the surface; lever A fills it with depth; lever B keeps it fresh. Together they target the exact authorial-neutrality signal that AI search rewards over twelve times more than vendor content.
3. The Vault — the skill marketplace
The vault is the public skill marketplace. A curated registry of production-ready agent skills across more than fifty categories, installable into any agent runtime that speaks the SKILL.md manifest format — Claude Code, Cursor, Agent Zero, and the broader set of agent-native dev environments.
The repository structure encodes the contract: each skill is a directory under a category, containing a SKILL.md describing what it does, any supporting files, and a clear license. Skills are addressable both by humans (browsing the repo) and by agents (via the manifest format and an index manifest).
The vault is open by default. Skills authored by third parties live alongside skills authored by AaaS, marked by provenance but not by hierarchy. The marketplace is a reference for the agentic ecosystem's emerging skill graph, not a sales channel for AaaS-branded artifacts.
The strategic role: the vault is the public expression of the agent-first operating model. Every shipped skill is both a reusable internal capability and a downloadable proof-of-competence. The internal team battle-tests skills daily; the most-used and most-resilient skills graduate to public publication. The discovery pattern — search the repository directly via the GitHub API — is agent-addressable, not just human-browsable.
4. EIE — the Email Intelligence Engine
EIE is the verification cascade. A four-phase pipeline that treats deliverability and identity verification as first-class infrastructure rather than as an afterthought.
The four phases:
- Phase 1: Syntactic validation. Cheap, fast, ~99% rejection of clearly invalid inputs.
- Phase 2: DNS-level checks. MX records, A/AAAA records, deliverability heuristics.
- Phase 3: SMTP-level probing without sending. Connect, HELO, MAIL FROM, RCPT TO, observe response codes, never DATA. The standard industry technique, executed at high concurrency.
- Phase 4: Real delivery + bounce-code analysis. A test message to a controlled receiver domain, full DSN (Delivery Status Notification) probing across receiving infrastructure to build a ground-truth dataset of how different receivers actually treat a given sender reputation.
Why this needs to exist as defensible infrastructure: most agent systems treat email addresses as strings, send them, and discover what works when bounces come back. That works at low volume. It collapses at scale because deliverability is a per-receiver-domain property, not a per-message one. EIE makes the cascade explicit and callable, so an agent that needs to send a thousand messages can pre-qualify each one against a real ground-truth model rather than guessing.
EIE is built as ecosystem utility, not as captive feature. Other agent systems can call it. The methodology is documented openly. The reference dataset is built from controlled probing, not from leaked production traffic.
5. The Design Library — internal-tooling-as-product
The design library is internal tooling shipped to product-grade quality. A component catalog with dozens of templates, machine-readable variant manifests, instrumented webhook telemetry, and a single-source-of-truth token registry.
The brand canon is explicit and locked: a primary accent + glow palette pair, with supportive tones as secondary. The token registry is the canonical source; downstream consumers (UI mirrors, email mirrors, PDF mirrors) sync from it via build steps that fail if they drift.
The strategic frame is internal-tooling-as-product: the same instinct that produced Stripe's docs, Hugging Face's hub UI, and Shopify's polaris design system. An internal tool built to public-product quality bar becomes the substrate for both faster shipping AND a future public surface. The cost of polishing internal tools to public standards is real but bounded; the cost of NOT having that quality bar in your design language compounds invisibly across every customer touchpoint.
Beneath the surfaces: the autonomous pipeline
Sitting underneath all five surfaces is the autonomous pipeline. A code-defined orchestration runtime that handles the operational work of the company on the 60/30/10 split described in Part III.
The pipeline accepts plans as structured JSON, executes them as directed-acyclic-graphs of nodes, fans sub-agents out per node, gates with hooks at every transition, persists memory across sessions, and ships PRs as output. Plans go in; merged code, published content, or completed operations come out.
The pipeline is also a product surface in its own right — published as orchestrator plugins for major agent runtimes, deliberately tool-agnostic by construction. Other teams can adopt the same operating discipline by adopting the same plugin set.
The product ecosystem as architecture
The five surfaces plus the pipeline are not a portfolio. They are a single architecture with five expressions:
- The blog earns the citation that brings the agent to AaaS.
- The vault is what that agent installs from when it wants to extend its own runtime.
- The platform is where the human behind the agent goes to configure, monitor, and pay.
- EIE is the verification utility every other surface can call when it needs to validate an input.
- The design library is the visual + structural language the company speaks across all of the above.
- The autonomous pipeline is how all of that gets built and shipped by a tiny team.
The compounding shape matters. Each surface makes the others more valuable: the blog earns citations that drive traffic to the vault that surfaces the platform that is built with the design library that is operated by the autonomous pipeline that ships everything including the blog. The loops feed each other. None of the surfaces is independently sufficient; all of them together are.
Part VI — The Content Compounding Strategy
The citation-share thesis, in execution
In the agent era, AI-citation share replaces backlink share as the load-bearing currency of discoverability. The Otterly 2026 finding — owned vendor content captures only 4.3% of category-level citations while community/neutral references capture 52.5% — is the empirical floor under everything in this section.
That is a >12× asymmetry. It is not a marketing observation; it is the structural shape of how LLM retrieval-and-rerank stacks weight authorial intent. Surfaces that read as neutral infrastructure get cited. Surfaces that read as vendor promotion get name-checked and dropped.
The blog killshot strategy is an explicit bet on that asymmetry. Rather than build a louder marketing surface, AaaS is positioning the blog as the neutral, citable reference for the agentic AI ecosystem — and shipping the four mechanical surfaces that AI bots, MCP clients, and LLM-assisted browsers actually look for. Together with two strategic levers that compound content over time, the goal is to land the blog on the right side of the 4.3% / 52.5% ratio in agent-era topics.
The four killshots — visibility surface
The killshots are the load-bearing entry points an AI agent reaches for first when it lands on a domain.
Killshot 1: Selective robots.txt
The default robots.txt shipped by most Next.js apps blanket-disallows /api/. That single line silently mutes every public agent endpoint a site already serves — RSS feeds, podcast feeds, OpenAPI specifications, and any other machine-discovery surface mounted under /api/. From an LLM crawler's perspective, the most agent-relevant surface on the site becomes invisible.
The fix replaces the blanket directive with targeted disallows for the genuinely private surfaces — admin routes, draft previews, internal webhooks — and adds explicit Allow rules for the major AI crawlers: GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot, Applebot-Extended, and the rest of the published agent-bot list as of Q2 2026.
The mechanism is mundane. The mistake it corrects is not: blanket /api/ disallows are the single most common reason an otherwise agent-friendly site is invisible to LLM retrieval.
Killshot 2: Public-unauthenticated MCP server
The MCP server was previously deployed authenticated-only. This broke the agentic-KB positioning at its most load-bearing handshake: any agent following the well-known MCP path was met with a 403 instead of the schema the server advertises. The killshot flipped the service to fully public read-only, with a strong per-IP in-app rate limiter as the cost backstop — limits at the minute, hour, and day timescales. Excess requests log structured JSON for abuse-pattern monitoring.
The choice of public-unauth is the same posture Stripe, Hugging Face, and Context7 ship — and is what the MCP spec assumes for read-tier servers. The one-way door to add a free-tier API key is kept open if abuse spikes.
This is the load-bearing entry point of the four. MCP is the protocol that AI assistants use to attach to a knowledge surface, not just crawl it. Public-unauth MCP makes the blog readable from inside Claude Desktop, ChatGPT desktop, Cline, Continue, and every other MCP client without configuration.
Killshot 3: Public OpenAPI specification
The plugin manifest at the well-known location had been advertising a specific OpenAPI URL for months. That URL returned a 404 the entire time — a broken contract published to the well-known directory every AI plugin discovery flow reads first. Any agent following the manifest got a 404 on the schema, gave up, and indexed nothing.
The killshot ships a public OpenAPI 3.1 spec covering all public read-only endpoints: entity list/detail per type, search, RSS feeds, podcast feed, sitemap, and (with the next killshot) the llms.txt surfaces. The spec advertises rate limits, response schemas, and pagination semantics in machine-readable form.
The strategic value is asymmetric: a working OpenAPI spec is what an AI agent's tool-use planner reaches for when deciding whether to call this API or another one. Without it, the agent must guess request shapes; with it, the agent can synthesize tool definitions on the fly and start issuing typed calls within a single turn. For agent-discovery flows that fan out across 10–50 candidate sources, the presence of a clean OpenAPI doc is often the deciding tiebreaker.
Killshot 4: llms.txt + content negotiation
Three new public endpoints plus one extension to existing routes:
| URL | Content-Type | Purpose |
| -------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| GET /llms.txt | text/plain | Curated index per the llmstxt.org spec — top entities per type, with links to the full file, sitemap, MCP manifest, and OpenAPI spec |
| GET /llms-full.txt | text/plain | Full Markdown projection of the entity catalog — designed for single-fetch ingestion by an LLM context window |
| GET /<entity>.md | text/markdown | Per-entity Markdown via path suffix (Stripe docs pattern) |
| GET /<entity> with Accept: text/markdown | text/markdown | Per-entity Markdown via content negotiation (Anthropic docs pattern) |
This is the surface designed for direct context-window ingestion: an agent that wants the full ontology in one paste can simply fetch the full file. The content-negotiation extension means existing per-entity URLs serve HTML to humans and Markdown to LLMs from the same canonical URL — preserving SEO equity rather than fragmenting it.
The two strategic levers — compounding content
Killshots create the visibility surface. Without ongoing content depth, they advertise an empty room. The two strategic levers populate the surface and keep it growing.
Lever A: LLM-assisted graph fill with evidence-citation gate
The blog hosts thousands of entities across multiple collections — papers, models, tools, organizations, methodologies — but the edges between them are sparse. A graph without edges is a list; a graph with dense, evidence-cited edges is a knowledge base that an agent can traverse. Lever A populates those edges using LLM-assisted batch extraction, gated by mandatory evidence-citation.
The data contract is anchored on three deterministic refinements that prevent the standard LLM-graph-fill failure modes:
- Schema with cross-field predicate-typing closes hallucinated targets. For each predicate (cites, implements, extends, evaluated_on, etc.), the source and target types are pinned. An LLM cannot insert an invalid type combination because the schema rejects it before write.
- Deterministic idempotency keys close rerun amplification. Every edge gets a stable ID derived from (source, predicate, target). A re-run of the same extraction job produces the same edge IDs, so reruns are upserts not duplicates.
- Deterministic confidence curve in the corroborator saves LLM calls. Per the ODKE+ research, the corroboration step does not need an LLM; the deterministic curve hits the same target Brier score at a fraction of the cost.
The evidence-citation gate is the load-bearing safety mechanism: every edge must carry an evidence URL and a quoted evidence excerpt of bounded length. Edges without verifiable quoted evidence from the cited source are rejected at write time. This is the difference between a graph an agent will cite and a graph it will rightly mistrust.
Lever B: Daily auto-extension pipeline
A reference-quality knowledge base for the agentic AI ecosystem must move at the speed of the ecosystem. New papers, models, and tools land daily. A weekly or monthly refresh would visibly lag behind Hugging Face Hub, Papers-With-Code, and arxiv-sanity — eroding the neutral-reference positioning.
Lever B builds a daily auto-extension pipeline using curated paper feeds (Hugging Face Daily Papers) as the curation oracle. Daily Papers is already a human-curated signal of what the agentic-AI community considers relevant that day. Using it as the seed input — rather than scraping arXiv directly — front-loads a high-quality filter for free.
The pipeline architecture follows the ODKE+ reference: Extraction Initiator → Evidence Retriever → hybrid LLM extractors → Grounder → Corroborator. The four ingestion sources are the curated papers feed (oracle), arXiv (depth), code-hosting releases (models, tools), and AaaS internal events (vault changes, plugin releases). Each new entity is gated through the same evidence-citation gate that Lever A defined.
The strategic claim: by the end of the first year of operation, the blog should be a daily-updated, citable, evidence-backed reference for the agentic AI ecosystem. The visibility surface is the killshots; the depth is Lever A; the freshness is Lever B. Together they target the exact authorial-neutrality signal the Otterly data shows AI search rewards over an order of magnitude more than vendor content.
Strategic stacking
The four killshots and two levers stack into a single architecture:
- Killshots create the surface. Selective robots, public MCP, working OpenAPI, and llms.txt are the four well-known doors an AI bot reaches for.
- Lever A fills the surface with depth. Thousands of entities become a traversable graph with evidence-cited edges.
- Lever B keeps the surface fresh. Daily ingestion means the graph reflects this week's papers, not last quarter's snapshot.
Connection to the Otterly thesis is direct: without the 4.3% / 52.5% asymmetry, this strategy would read as generic SEO with extra steps. With it, it is an asymmetric bet on a specific market structure shift — that retrieval-augmented LLM stacks will continue to weight neutral references over vendor content as their authorship signals mature.
How owned vs neutral plays out in editorial practice
Operational rules in force on neutral surfaces:
- Reference-documentation tone. Posts read as encyclopedia entries about a technique, a paper, a model, or a protocol — not as pitch decks. The voice is third-person, factual, and link-rich. If a paragraph could appear in Wikipedia without editorial revision, it passes the bar.
- No CTA-driven posts. "Get a demo!", "Sign up for early access!", "Schedule a call!" are forbidden in the body of a neutral surface.
- First-person minimized. "We at AaaS believe..." gets rewritten to factual third-person. Reserved for cases where a first-person claim is the actual evidence (e.g., reporting an internal benchmark).
- Citations OUT, not citations IN. The blog links out to other tools, other companies, the original paper authors, the upstream specification, the source code. It does not consist primarily of self-references. The link graph reads like a researcher's bibliography, not a sales sequence.
- Competitor mentions are permitted when factually warranted. Refusing to mention competitors is a marketing tell that downgrades a surface's neutrality score.
Risks
Three risks to track:
- Curation oracle velocity slows or quality drops. If the daily papers feed weakens, the auto-extension input signal degrades. Mitigation: secondary oracles are designed-in as fallbacks.
- AI search stacks de-prioritize neutral references. The Otterly baseline could shift. Mitigation: the killshots are also pure traditional-SEO wins (better robots, working OpenAPI, llms.txt is now also a Google ranking signal). The downside is bounded.
- Graph-fill hallucination escapes the evidence-citation gate. Mitigation: the gate enforces evidence URL + quoted evidence at write time, predicate-typing closes hallucinated-target vectors, and a human-in-the-loop admin surface keeps a human reviewer in the loop for low-confidence edges.
Scoreboard
By the long-horizon target, if the killshots and levers work, citation share in agent-era topics should be measurable against the Otterly methodology. The 4.3% baseline is what owned content gets when it reads as marketing. The 52.5% ceiling is what neutral references capture. The killshots and levers are the mechanism for moving the blog from the first bucket toward the second.
Part VII — The Distribution Engineering
The distribution layer is the engineering surface that turns content into reach. It is governed by one typed contract, fed by multiple producers, consumed by multiple publishers, and instrumented with a single attribution convention from end to end.
The contract: SyndicationRequest
The seam between content producers and publishing channels is an envelope, not a convention. Producers emit a typed syndication request; publishers consume it. Both sides version independently. Breaking changes require coordinated updates, exactly like any other API.
The envelope carries:
- Source identification — which producer fired this (release notes, blog publish, design-library event, transactional event)
- Content payload — channel-agnostic, with hints for variant generation
- Channel hints — which publishers should receive this, with optional channel-specific overrides
- Attribution payload — locked UTM convention, propagated through every adapter
- Hooks — declared for producer-side and publisher-side observability, not exported as a general interface
Publishers are registered by name. The first concrete publisher implementation is the self-hosted social publisher. A second publisher name is reserved type-only for a future client-facing system — where AaaS customers publish from their own accounts — explicitly distinct in OAuth model, rate-limit policy, data ownership, and legal posture.
The hooks-declared-but-not-exported pattern is the discipline that keeps the contract honest. The moment one team is allowed to bypass the envelope and call a channel API directly, the contract is dead and the system reverts to manual workflow.
The channel matrix
Channels are adapters behind the contract. Adding a new channel is "build an adapter" — it does not require redesigning the producer side, retraining the caption builder, or renegotiating the attribution schema.
The currently wired channels:
| Channel | Status | Auth posture | Internal-only | | ------------ | ------ | ---------------------------- | ------------- | | LinkedIn | Wired | OAuth on AaaS-controlled app | Yes | | X | Wired | OAuth on AaaS-controlled app | Yes |
The next channels (Bluesky, Threads, Mastodon, agent-marketplace surfaces, syndication into the blog ecosystem itself) each ship as adapters against the existing contract.
Each channel's per-channel quirks (caption length, allowable formats, hashtag conventions, reply settings) get encoded once in the channel adapter and forgotten. The caption builder upstream produces channel-appropriate variants from a single content brief. A campaign that reaches three channels passes through three adapters, not three copies of the content.
The email pipelines
Email is the longest-lived, most regulated, most deliverability-sensitive channel in the funnel. The email infrastructure is built end-to-end:
- Welcome cadence — a multi-step onboarding sequence per subdomain, with per-domain personalization.
- Transactional pipeline — receipts, password resets, verification flows, all template-bound to the canonical brand palette.
- Cadence pipeline — drip campaigns and lifecycle messaging, instrumented with the same UTM convention as social publishing.
- Design-library transactional — webhook-driven customer notifications for design-library events, signed by both Resend and the self-hosted publisher with their respective signing secrets.
Brand canon enforcement is build-time, not review-time. Templates that drift from the token registry fail the build. The single source of truth for tokens, themes, and palette is the registry; mirrors (UI, email, PDF) re-derive from it.
The brand & palette canon
The brand canon is explicit and locked: a primary accent + glow pair (a bold accent red plus a contrasting circuit-glow cyan), with supportive tones as secondary. Teal and pastel tones are supportive only — they may appear in design surfaces but never elevated to primary.
Why this palette: the color combination is high-contrast enough to read as confident on busy SaaS surfaces, distinct enough that no major adjacent vendor uses anything close, and warm enough on the accent side to avoid the cold-blue convention of most developer-tools surfaces.
The canon is enforced at multiple layers. The token registry is the canonical source. The UI, email, and PDF mirrors all build-time-validate against it. Templates that propose net-new tokens go through a review that asks the load-bearing question: "is this a real new design need, or marketing drift?"
Campaign mechanics
A campaign at AaaS is not a marketing task; it is an engineering artifact. The marketer (which, in practice, today means a founder + an engineer + a set of agents) writes a content brief, invokes the campaign-builder skill, and reviews the proposed variants. The variants are generated by the caption builder using the brand voice + channel-specific shape rules. The brief flows into the syndication contract; the publishers fan out; attribution flows back.
The six skills in the marketing pack handle: brief generation, variant production per channel, ad-creative generation (single-image, carousel, video, UGC), campaign assembly, brand isolation, and post-publication analysis. Each skill is invokable independently or composable into a single end-to-end loop.
The internal/client architectural split
The most load-bearing distribution decision is the permanent architectural seam between internal-only publishing and future client-facing publishing.
Internal publishing uses AaaS-controlled OAuth apps to post to AaaS-controlled accounts (the company's own LinkedIn, X, etc.). Rate limits are per-account. Tokens are global to the company. Legal posture is straightforward: AaaS is the publisher of record.
Client publishing (future) will let AaaS customers publish from their own accounts to their own surfaces. This is fundamentally different: per-user OAuth tokens, per-customer rate-limit policies, tenant-isolated data, and a legal posture where AaaS is hosting infrastructure rather than publisher of record.
The two systems share the syndication contract but nothing else. The reserved client publisher name in the contract is the architectural reminder that these are two systems, not one. Conflating them would create an irreversible multi-tenancy mess that any later separation would cost order-of-magnitude more to unwind.
This is a permanent seam, not a temporary delineation. It is the kind of decision a company gets to make once, early, before the second system is built — and gets right or gets wrong for the rest of its life.
Distribution decisions log
The distribution layer accumulates decisions that have to survive across quarters and across founders. A few of the load-bearing ones:
- Self-host the publisher, don't rent it. Every alternative monetizes lock-in over time. Self-hosting preserves data ownership and per-post cost control.
- Internal-only first, client-facing reserved. Build the internal system right; reserve the slot for the client system; don't try to do both in one architecture.
- UTM convention locked at the contract level. Adding new attribution fields requires a contract version bump and adapter coordination, not a marketing-team Slack message.
- No marketing override of the contract. Every campaign goes through the same envelope. The marketing-bypass escape hatch is the thing that kills these systems in practice.
- Caption builder upstream, channel adapters downstream. Variants are generated once and routed; channels are not asked to do content work.
Future channels & audience
The track-1 highest-leverage future channels are AI-bot and agent surfaces themselves — getting AaaS into MCP registries, into agent-marketplace listings, into the citation panels of the major AI assistants. These are higher-leverage than any human-distribution channel because they compound on the citation-share thesis.
The track-2 human distribution channels — additional social platforms, conference talks, community programs — are valuable but explicitly secondary. The bet is that agent-mediated distribution will dominate by 2028, and the time to build into it is now while the surface is still being defined.
Explicit anti-channels — channels we will not pursue — include cold outbound sales, paid SEO content farms, sponsored placements in publications that do not align with the neutral-reference positioning, and any growth-hack pattern that would optimize for vanity engagement at the cost of citation share.
Part VIII — The Business Model
Pricing strategy
AaaS is live with a credit-pack model, but the ecosystem is in early monetization. Live SKUs exist, payment rails are wired, and the checkout flow works. The pricing page is a four-tier strategic frame — Free, Credit Packs, Boutique, Enterprise — that hedges between three monetization theses (freemium-to-credits, services-led, and enterprise-licensed) until the data tells us which one is dominant.
The big open question for the next year is whether AaaS commits to credits (consumption) as the primary motion, subscription tiers as a complement, or a builder-marketplace revenue split as the differentiator.
Current pricing tiers
| Tier | Price | Status | | ---------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------- | | Free | €0 | Live — small monthly allowance, context-package generation, community vault access | | Credit Packs | €5 / 50, €19 / 250, €49 / 750 credits | Live — pay-as-you-go, no expiry, all agents unlocked | | Boutique | €3K – €30K | Live as marketing tier — consulting packages, custom context engineering, dedicated agent workflows | | Enterprise | Custom | Designed — equity partnership option, on-prem deployment available, 24/7 priority support |
The credit pack tier sizes are anchored to comparable agent-tooling subscriptions: a starter pack lower-friction than any major competitor's first purchase, a scale pack landing where most agent-tooling Pro tiers sit.
Pricing model considerations
The four canonical models and where AaaS sits:
| Model | Fit for AaaS | Notes | | -------------------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscription (flat / month) | Weak primary, strong secondary | Predictable revenue but agent consumption is bursty — a flat fee mis-prices both light and heavy users. Best as a "Pro" tier that bundles N credits + extras. | | Usage-based (credits) | Strong primary | Already live. Aligns cost with value. Matches the agent-era pattern of variable consumption. | | Hybrid (sub + usage cap, overage billed) | Recommended for team tier | Industry standard for B2B agent tooling. Caps procurement-friendliness with usage upside. | | Open source / freemium | Already adopted | Vault is fully OSS-public; blog is public; MCP endpoints are unauth-public per strategy. |
A fifth motion sits orthogonal: a builder revenue-share marketplace where the platform takes a transparent micro-fee and routes the rest to the agent's builder. The infrastructure for it exists in the codebase. If shipped publicly, this would position AaaS against closed-monetization model marketplaces and against GPT Store (which has not delivered meaningful payouts to most builders).
Pricing anchors (comparables)
| Comparable | Free tier | Paid entry | Enterprise | Model | | ---------------------------------- | ------------------------- | ------------------------- | --------------------------- | -------------------------------------------- | | LangChain / LangSmith | OSS + free dev tier | $39/dev/mo (Plus) | Custom | Per-seat + trace usage | | CrewAI | OSS framework | $99/mo Enterprise starter | Custom | Per-seat + execution-based | | OpenAI GPT Store / Custom GPTs | Bundled with ChatGPT Plus | — | Team/Enterprise ChatGPT | Builder revenue-share announced, undelivered | | HuggingFace Hub | Free public | Pro $9/mo | Enterprise from $20/user/mo | Per-user + Inference Endpoints usage-based | | Vercel | Hobby free | Pro $20/user/mo | Custom | Per-user + bandwidth/compute overage | | Replicate | $0 + pay-per-second | Pure usage | Custom | Pure usage-based |
Where AaaS lands: a starter credit pack priced below a single ChatGPT Plus month, a single HF Pro month, or a Replicate hobby tier monthly bill at meaningful usage. Positioned as lower-friction-than-anyone for first purchase, with scale packs landing where most agent-tooling Pro tiers sit.
Customer segments
AaaS is not a single product with a single buyer. It is an ecosystem of surfaces, and each surface attracts a different customer profile. Layered segmentation lets us prioritize who we serve first (beachhead) versus who we eventually serve (expansion). The strategic point of segmentation is architectural pre-commitment — the expansion segments tell us which abstractions to keep open so we don't paint into corners.
Beachhead
Profile: senior individual developer building AI/agent products. Working at a Series A startup, unfunded/bootstrapping, or operating as a high-end consultant. 5+ years of engineering experience; comfortable with TypeScript, Python, and shell. Already using Claude Code, Cursor, or a comparable agent-native dev environment. Building either a customer-facing AI product or internal agent tooling.
Pain: existing agent frameworks are toolkits, not platforms. They give you abstractions for chaining LLM calls but force you to assemble your own infrastructure for everything around the loop: deliverability, syndication, observability, UI primitives, evaluation, and operational verification.
Why they buy AaaS: because AaaS shows up repeatedly across their workflow. The compounding entry points are: discovering the blog while researching an architecture decision (neutral, citation-grade reference); installing vault skills (first touch of the AaaS brand inside their editor); hitting a real engineering problem and finding AaaS has productized a tool (EIE, design library, verification skill); wanting shared state for a small team and discovering the authed dashboard.
Expansion segment 1: Small AI-product teams (3–15 engineers)
Series A through Series B startups, or a focused product team inside a larger company, building AI-native features. Engineering-led; product manager and designer often shared across multiple squads.
They need everything the beachhead has, plus: shared workflows, multi-user state, role separation, collective syndication. The authed dashboard and the brand profile concepts are designed for this layer.
Expansion segment 2: AI-native consultancies and boutique agencies
5–50 person agencies that deliver AI products to multiple end-clients. Often founder-led, technical, and outcome-billed.
They need white-label tooling, per-client isolation, and repeatable scaffolds. This is exactly what the reserved client-publisher slot in the syndication contract is for. The design library accelerates client UI delivery. The skill vault becomes a private fork mechanism.
Expansion segment 3: Enterprise AI teams (2027+ horizon)
50+ person engineering organizations inside large enterprises or public-sector buyers. Internal AI platform teams chartered with "make agents safe to deploy across the company."
They need agent infrastructure under compliance and governance constraints: SOC 2, ISO 27001, GDPR, internal audit, data-residency, single-sign-on, and procurement. The architectural primitives exist; the enterprise SKU is a 2027+ build, not a near-term sale. Premature enterprise pursuit is the most common kill-vector for early dev-tools companies.
Anti-segments
Equally important as who we serve is who we refuse to serve:
- Solo non-technical users — the "chatbot buyer" who wants a no-code agent without understanding the engineering tradeoffs. AaaS sells to builders.
- Pure academic researchers without commercial intent — the blog serves them as readers (and they cite us, which compounds SEO and authority), but they are audience, not customers.
- LLM-application platforms competing on the same axis — they are partners or competitors, not customers.
Revenue streams
AaaS is engineered to monetize across the five product surfaces via multiple stream mechanisms (recurring subscription, usage-based, transactional, marketplace rev-share, services). The payment scaffolding is wired in code today, with subscription tiers, credit purchases, one-shot product checkout, and seller-payout plumbing.
Live streams (rails wired):
- Credit-pack purchases on the platform
- Subscription (generic) and pay-as-you-go SKUs
- Boutique consulting packages, sold off-platform
Designed streams (decided, not yet shipped):
- Pro and Team subscription tiers (proposed)
- Enterprise contracts (custom)
- Per-EIE-verification usage pricing (decision pending)
- Design library marketplace pricing with creator share
- Vault skill marketplace (decision pending: stay fully OSS vs add premium AaaS-curated tier)
Hypothesis streams (untested, requires validation):
- Builder revenue-share marketplace ("100% builder earnings, transparent compute cost")
- Premium MCP / agent-attached enterprise tier
- Verified-skill certification program
The reserved client-publisher revenue stream is intentionally not yet built — it is the architectural option that the internal/client split preserves.
Unit economics framing
Per-customer revenue and cost assumptions remain provisional until the first paying cohort lands. The framework is built; the data needed to validate it is the deliberate output of the next year of operation.
The key ratios to instrument when they become measurable: LTV:CAC by surface, payback period by acquisition channel, gross margin by stream, and cohort retention by segment. The infrastructure to measure these exists; the cohort that would generate the data is just now being acquired.
Growth loops & moats
A moat is anything you have that compounds while a competitor's clock is still running. Features don't compound — they get copied in a quarter. Pricing doesn't compound — it gets undercut. What compounds is positioning that gets harder to dislodge the longer it sits, libraries that get more valuable per unit added, contracts that get cheaper to extend per channel attached, and operational labor that has been encoded into reusable artifacts.
Four candidate moats
| # | Moat | Mechanism | Time-to-replicate | | --- | ------------------------------- | -------------------------------------------------------------------------- | ----------------- | | 1 | AI-citation share | The blog as neutral agentic-ecosystem reference | 1–3 years | | 2 | Skill marketplace | The vault as publishable interface over the internal skill library | High | | 3 | Funnel-as-code | Syndication contract + self-hosted publisher + UTM layer + caption builder | Medium-high | | 4 | Agent-first operating model | Autonomous pipeline + agents + skills + MCPs + cross-session memory | Very high |
Moat 1: AI-citation share (content moat)
Every accepted citation increases the probability of being cited next time. AI training data crawls cite-graphs; retrieval-augmented systems pull from pages that have been previously authoritative; high citation share is itself a Schelling point editors index toward. The loop runs without further AaaS labor once a page is in the citation-eligible set.
A competitor cannot ship better neutral content faster than AaaS — they would have to flip their own positioning from vendor to reference, build an equivalent entity graph, and outwait AaaS's existing citation accumulation. The first-mover advantage in citation graphs has the same shape as the first-mover advantage in backlink graphs: not absolute, but expensive to close.
Reinforcement loops: the daily auto-extension pipeline compounds the citation surface daily; the LLM-assisted graph fill increases edge density; the four killshots flip the surface from "deployed but invisible" to "any agent can attach in one HTTP call."
Moat 2: Skill marketplace (agent-tooling moat)
The internal skill library — ~5,761 SKILL.md files on disk, 5,400+ in the published vault across 16 marketplaces and 283 plugins as of 2026-05-24 — already runs the company. The vault is the publishable interface over that library. The moat is not the library size; it's the curated quality and the compounding feedback loop between internal use → battle-test → external publication.
Quality compounds via ROI ranking and auto-pruning of unpromoted skills. Weak skills decay; load-bearing skills get reinforced. Each skill that survives the internal usage gauntlet enters the vault with implicit certification — it has already been pressure-tested against AaaS's own automation workload. This is a quality moat, not a volume moat. Competitor "plugin marketplaces" optimize for the wrong axis (count); AaaS optimizes for the axis that matters to a user (does it work).
Moat 3: Funnel-as-code (distribution moat)
Distribution is engineering, not marketing. A new channel doesn't require new operational labor — it requires one adapter implementation against an existing typed contract. The marketing team transitions from "do the work" to "design the contract." This is the Stripe pattern applied to social publishing.
Every channel adapter built reduces the marginal cost of the next campaign across that channel to ~zero. The compounding is multiplicative on the marketing side and one-time-cost on the engineering side. Most companies pay marketing-labor cost per campaign per channel forever; AaaS pays engineering cost once per channel and marketing-labor cost approaches zero per additional campaign.
Moat 4: Agent-first operating model (organizational moat)
The autonomous pipeline + the agent pool + the skill library + the curated MCPs + the cross-session memory system means the company runs on encoded agent labor rather than pure human labor. Every operational pattern that's been hit twice has been encoded as a skill, an agent, or a memory entry. The compounding is on the founder's time: hours freed from operations get reinvested in strategic thinking, which generates more operations to encode, which frees more time.
Requires (a) cultural willingness to delegate operational work to agents, (b) technical infrastructure to actually delegate, (c) sustained accumulation of encoded patterns before the compound becomes felt. Most companies fail at (a) before they consider (b). AaaS's structural advantage is that the founder is also the architect of the harness — the cultural and technical layers are not in conflict.
Growth loops that activate the moats
- Loop A — Content compound: daily auto-extension publishes new entity pages → graph-fill adds edges across them → killshots increase agent-bot discoverability → AI citations grow → agent traffic discovers AaaS surfaces → some fraction converts → revenue funds more content production → repeat.
- Loop B — Vault marketplace: internal team ships a skill → graduates it → vault hosts it → external developers install → install events feed back as signal → top-installed skills get curated support → premium tier emerges around the most-relied-on skills → revenue funds more skill creation.
- Loop C — Distribution compound: publish episode → syndication request → multi-channel publication → UTM attribution → signup → dashboard → activate skills → publish about it → repeat.
- Loop D — Agent-tooling compound: run the pipeline → encounter footgun → save feedback memory → next session avoids the footgun → run faster → tackle bigger ambition → encounter new (higher-altitude) footguns → save those → compounding velocity.
The four loops are at different maturity. Two are running; two are designed but not yet firing. The strategic priority is to activate the loops that turn the two designed moats into compounding moats.
Anti-moats (positions AaaS does not compete on)
Explicitly declaring what AaaS is not competing on is what protects the actual moats from feature-creep dilution:
- Lowest-price agent framework. Commodity race. Not winnable, not worth winning.
- Best-marketed agent platform. LangChain has more mindshare; AaaS cannot out-spend on mindshare and shouldn't try.
- Largest model catalog. Hugging Face owns this; the right move is to integrate, not duplicate.
- Most features per dollar. Feature-creep race; the loser is whoever wins the surface-area race because every feature is now a maintenance liability.
Saying no to these four positions is what frees the budget to invest in the four moats that actually compound.
Part IX — The Roadmap
The roadmap is quarter-themed, not feature-listed. Each quarter has a strategic centerpiece, supporting workstreams, and explicit non-goals.
Q2 2026 — Content infrastructure + email pipelines + verification
The quarter's bet: build the rails that let AaaS show up as neutral citable infrastructure, wire the transactional and lifecycle email pipelines end-to-end, and put the first usage-based revenue surface into production.
Centerpiece work:
- The killshot sweep — selective robots, public MCP, public OpenAPI, llms.txt + per-entity Markdown projections.
- The graph-fill foundation — data model, evidence-citation gate, deterministic idempotency, evidence retriever.
- Email pipeline restoration — cadence, per-domain welcome flows, transactional templates against the canonical palette.
- Distribution wiring — the syndication contract, the self-hosted publisher, LinkedIn + X channels.
- EIE Phase 4 provisioning — the deliverability ground-truth dataset infrastructure on dedicated VPS hardware.
Status entering Q3: content infrastructure substantially shipped. The killshot surface is live (with deployment of the final piece pending one upstream resolution). The first graph-fill PR is merged with the rest queued. Email pipeline is restored and stable. Syndication contract is shipped and one publisher is wired. EIE Phase 4 is in flight on dedicated infrastructure.
Q3 2026 — Compounding the content surface + monetization rails live
The quarter's bet: turn shipped infrastructure into compounding output. Ship the remaining graph-fill PRs to activate the content compound loop. Flip the payment rails from test to live. Start measuring AI-citation share against the Otterly methodology as a private scoreboard. Onboard the first paying cohort.
Planned work:
- Graph-fill PRs B through F — evidence retriever, sameAs registry backfill, pipeline orchestrator, human-in-the-loop admin surface, reverse-edge UI across entity templates.
- Daily auto-extension pipeline — the ODKE+-pattern ingestion loop, daily cadence, evidence-citation gated.
- Payment rails to live mode — first paying customers on the credit-pack tier.
- The UTM attribution dashboard — closing the loop from publish → click → conversion in a single deterministic query.
- EIE Phase 4 to production — ground-truth dataset writing, measurable deliverability uplift on the welcome sequence.
- Vault skill catalog formalization — versioned metadata, install telemetry, contributor pipeline.
Risks: the citation-share signal is slow by design — we will not have conclusive data within the quarter. The discipline is to ship the loops and measure on the right timescale, not to grasp for early proxies.
Q4 2026 — First measurable citation signal + product surface hardening
The quarter's bet: with six months of telemetry on the killshots + graph-fill + auto-extension, the citation signal should be directionally readable. Use the signal to decide where to invest next. Harden the platform surfaces for sustained customer load.
Probable work:
- First independent measurement of AI-citation share against the Otterly methodology.
- Decision: double down on content surface (auto-extension cadence increase, additional reference categories) or pivot to vertical depth.
- Platform hardening — performance, observability, security review, multi-tenancy primitives sharpened for the team-tier customer profile.
- Marketing surface for the public vault — making the skill marketplace discoverable to humans, not just to agents.
- Second publisher channel beyond the first two — Bluesky or Reddit, depending on where audience signal points.
Strategic decisions to make: team-tier pricing finalization; whether to ship the builder revenue-share model publicly; whether to begin the enterprise design-partner motion in early 2027.
2027+ horizon — citation compounding visible or pivot to vertical
The 2027 anchor question: is AI-citation share compounding on the trajectory the Otterly data predicts?
If yes — citation share visibly trending up across the categories we measure — the strategy continues: deepen the content surface, widen the vault, expand the publisher channels, start the design-partner motion for enterprise. The company stays horizontal and category-shaping.
If no — six quarters of measurement showing flat or barely-rising citation share — the strategy pivots: take the harness, the skills, the contracts, and the agent-first operating discipline, and apply them as a vertical operating system for specific industries. Smaller market, fully defensible, profitable. The downside branch is survivable; the upside branch is category-creating.
Plausible 2027–2030 scenarios:
- The content compound works. Citation share climbs through the single-digits into the low double-digits. The blog becomes a recognized reference surface for the agentic ecosystem. The vault becomes the install-from default for major agent runtimes. EIE serves a meaningful fraction of agent-driven email volume. Monetization layers stabilize across subscription, marketplace, usage, and design-library streams.
- The content compound is slow. Citation share rises but on a longer timeline. The company stays small and profitable; the bet remains live; patience is the operating mode.
- The model labs absorb the layer. Major LLM providers ship their own neutral-reference content for the agentic ecosystem. AaaS pivots to vertical agentic-SaaS; the horizontal investment becomes accelerant for vertical wins.
- A larger competitor pivots into the slot. Defensive position depends on execution quality. Citation moats compound on calendar time; the head start is the defense.
Known risks and pre-mortem themes
The honest list of risks worth tracking:
Tier 1 — existential:
- The citation thesis is wrong at the scale the Otterly data suggests. (Mitigation: 18-month evaluation date; explicit pivot path.)
- The model labs successfully bundle neutral-reference content into their own stacks. (Mitigation: multi-vendor positioning is structurally hard for any single lab to occupy.)
- A larger, better-capitalized competitor pivots into the neutral-reference slot. (Mitigation: first-mover citation graphs compound on calendar time.)
Tier 2 — severe but survivable:
- The agent-first operating model fails to scale as throughput demands grow.
- Stripe-like payments infrastructure hits regulatory or platform-policy headwinds.
- The autonomous pipeline accumulates harness rot faster than maintenance can clear it.
Tier 3 — moderate:
- Specific channels (LinkedIn, X) change terms in ways that break the adapter contract assumptions.
- The MCP standard fragments or loses incumbent status.
- The cost of frontier-model inference rises faster than the cost curve we are betting on.
Each risk is tracked, each has a stated mitigation, and the quarterly cadence revisits whether the mitigation is still adequate.
What is explicitly NOT on the roadmap
The anti-roadmap matters as much as the roadmap. The following are explicitly off the table for the planning horizon:
- Becoming an LLM provider. The model layer is a different business; we sit adjacent to it.
- Becoming an agent framework. The framework wars are crowded and we have nothing differentiating to add there.
- Raising mega-rounds, going through an IPO process, or pursuing a strategic-acquisition exit as the primary corporate goal. The company is founder-led and intends to stay that way.
- Pivoting to enterprise sales motion before the bottom-up developer adoption is proven.
- Adding non-agentic verticals to the product portfolio. We do one category, deeply, for the horizon of the bet.
Part X — The 10-Year Aspiration
A Day-One Reading List in 2036
It is a Tuesday morning in early 2036, somewhere in the agentic-AI economy that by now is simply called the software economy, and a new engineer is sitting through her onboarding at a mid-sized agentic product company. The company runs perhaps forty humans and operates at the throughput of two thousand. She has been there four hours. Her laptop is provisioned, her agent-pool credentials are minted, her first ticket — something small, a polish item on the company's billing surface — is open in a tab. Her manager messages her a single link. It is the company's Day One Reading List. There are eleven items on it. Three of them are AaaS surfaces.
The first is aaas.blog/agentic-architecture — the canonical reference for how to think about agent systems: the contracts they exchange, the memory shapes they need, the orchestration patterns that survive contact with production, the trade-offs that look obvious in slides and turn ugly in incident reviews. The second is aaas.blog/distribution-patterns — the reference for how agentic products reach their users, machine-readable surfaces, the citation economy, syndication architectures, the funnel-as-code idiom that by 2036 is just called "how distribution works." The third is aaas.blog/agent-economics — the reference for cost modeling, take rates, marketplace dynamics, the math of human-vs-agent labor allocation, the open question of where margin accrues in an agent-saturated stack.
She clicks the first link. The page loads. There is no AaaS logo above the fold. There is no banner ad for an AaaS product. There is a long, dense, hyperlinked reference that reads more like the MDN web docs of 2024 or the Stripe API documentation of 2018 than like a vendor blog of 2026. It cites three competing frameworks by name, recommends none of them, and gives the trade-off table she will need to make the decision herself. Down at the bottom, in small text, there is a single line: "AaaS maintains this reference as part of its public contribution to the agentic ecosystem." She reads it without registering it. She has read the same kind of line under MDN articles for years. It does not change her trust in the page. It is the kind of small line that simply belongs.
She does not know — has no reason to know, will probably never know — that the link her manager sent her was sent thirty thousand times that week, across thirty thousand new hires in agentic companies around the world. She does not know that her AI coding assistant, when she asks it a question about agent architecture later that afternoon, will pull from the same page she just read and will quote it back to her as if it were primary source. She does not know that the company that wrote the page is forty people in five time zones, profitable, never IPO'd, never wanted to. She does not know that the reason the page reads as canonical is that for ten years, starting in 2026, a small team made a long bet that the citation economy would compound, and that the way to win the agent era was to look, from the outside, like the agent era's neutral utility.
She just reads. That is what winning looks like.
The compounded outcomes
Strip the scene of its narrative warmth and what is left is a set of numbers — aspirational, but coherent with the bets described throughout this document.
The first number is citation share. The Otterly 2026 baseline shows owned vendor content at 4.3% of category citations against neutral references at 52.5%. By 2036, the aspiration is that the blog appears in the citation graph for roughly thirty percent of agentic-AI topic queries to LLMs and AI Overviews. The 2026 baseline is under one percent. The path to thirty is not a step function; it is the Otterly methodology compounding for ten consecutive years across daily content extension, public-unauth distribution, openapi-served entity surfaces, and a sustained editorial discipline that refuses to elevate AaaS products above category-level peers. The thirty-percent number is aspirational. The compounding mechanism is not.
The second number is the skill marketplace. By 2036, the aspiration is that the vault — today thousands of skills, mostly internal — hosts more than fifty thousand published skills from over five thousand independent creators. The take rate on transactions, applied to the gross marketplace volume, contributes a non-trivial recurring revenue line to the platform; the model mirrors Hugging Face Hub's model-card economy, where the platform becomes valuable because creators show up, and creators show up because the platform is the canonical surface. The vault transitions, somewhere around 2029 or 2030, from "AaaS's internal asset" to "the agentic ecosystem's skill registry, hosted by AaaS." That semantic shift is the load-bearing one.
The third number is EIE. By 2036, the verification cascade serves billions of email verifications per month across the agentic and conventional SaaS economy. More importantly, the methodology becomes the reference: when a 2034 paper on deliverability infrastructure cites prior art, it cites EIE the way 2018 deliverability papers cited Spamhaus. EIE is the case study that proves the thesis — that a small, well-engineered infrastructure surface can become the standard reference for what an industry capability should look like, simply by being correct and being readable.
The fourth number is the design library. By 2036, the library is a public-facing component marketplace with over five thousand components used by more than one hundred thousand developers building agentic UIs. The library, like the vault, transitions from internal asset to ecosystem reference; the components ship with machine-readable variant manifests and documentation that an agent can ingest as confidently as a human can.
The fifth number is the authed developer dashboard. By 2036, the aspiration is more than one million monthly active users — a mix of human developers, AI product teams, and the agents acting on their behalf. The dashboard is the operating console for the AaaS ecosystem: the place where humans go to configure what their agents will do, monitor what their agents are doing, and review what their agents have done.
The sixth and most consequential number is the internal tooling library. By 2036, AaaS operates with more than fifty thousand skills, five hundred named agents, and an autonomous pipeline that has executed millions of plans across a decade of refinement. The strategic claim — that the internal tooling library is the moat — becomes operationally visible by way of a single ratio: roughly ninety-five percent of operational units of work inside AaaS are executed by agent labor, with the remaining five percent reserved for leadership decisions that no contract can fully encode. This is not a productivity statistic. It is an org chart.
The company that gets there
The company that ships those outcomes does not look like the SaaS companies of the 2010s, and that is not incidental.
By 2036, AaaS headcount is somewhere between fifty and one hundred fifty humans. Not five thousand. Not five hundred. The agent-first operating model produces a leverage ratio that no headcount-scaled competitor can match. The team is small not because the company is small but because the substrate is large.
Geographically, the company is distributed. No single HQ. International hires. The internal communication shape — typed contracts, durable memory, declarative plans — is the same shape that works across time zones without coordination overhead, which is also the shape that works for agents. The two facts are the same fact.
Revenue is diversified deliberately, with no single line dominating. The aspirational mix: subscription revenue around forty percent, the vault marketplace take rate around twenty-five percent, EIE usage-based revenue around fifteen percent, the design library transactional revenue around ten percent, enterprise contracts around ten percent. The diversification is not opportunistic. It is a deliberate structural choice that makes the company resilient to single-stream shocks. Any single line can collapse and the company still has four others.
The company is profitable since roughly 2030. There has been no Series B. There may have been a Series A in 2027 or 2028 — purpose-built to accelerate the vault marketplace specifically, contingent on traction data — but the company is fundamentally founder-led, deliberately under-capitalized relative to peers, and ruthless about which dollars it spends on what. The lean team and the diversified revenue base mean that AaaS can run on its own gross margin in a way that venture-scaled competitors cannot. This is not virtue. It is preserved optionality.
Brand-wise, by 2036, AaaS is known as the agent ecosystem's neutral reference — a phrase that, by 2036, no longer needs to be explained. The standing is comparable to what Stripe became to payments in the late 2010s, what Hugging Face became to open-source models in the early 2020s, what MDN became to the open web platform across two decades. The brand is not loud. The brand is load-bearing. When an agentic product team has a hard question, they consult AaaS surfaces first not because of marketing exposure but because AaaS surfaces have, over a decade, proven to be the surfaces that are correct.
The market that exists by 2036
The market AaaS sits inside by 2036 looks unlike the market of 2026 in ways the 2026 version of this document could only guess at, but the structural directions are visible now.
The phrase "agent ecosystem" is no longer a futurism term. It is a recognized industry category with its own analyst coverage, its own job titles, its own conference circuit, its own regulatory regime. The 2026-era debate over whether "agents" was even the right word has long since resolved. Agents, in 2036, are what software is.
The LLM providers — Anthropic, OpenAI, Google, the survivors of the model-layer consolidation that happens somewhere around 2028 to 2030 — have commoditized at the model layer. The frontier still matters; frontier access is still expensive; the labs still differentiate. But the median useful model is approaching free at the margin, and the value has moved up the stack. Agent infrastructure — the harness, the contracts, the memory, the registries, the orchestration substrate — is where the durable margin accrues. AaaS sits on the right side of that shift, having spent ten years building exactly that infrastructure layer.
Most software companies, by 2036, build agents the way they had websites in 2010: table stakes, expected, embarrassing not to have, not differentiating to have. The interesting differentiation is in how well a company's agents compose with other agents, how cleanly they expose their contracts, how reliably they preserve context across the boundaries of the orchestrating systems they participate in. AaaS infrastructure is the layer that makes those properties possible without each company reinventing them.
Vertical agentic SaaS dominates the application layer — every major industry has its agent-powered tooling stack (legal, healthcare, finance, manufacturing, logistics, education, government). The verticals do not compete with AaaS; they consume from AaaS. AaaS is the horizontal infrastructure plus the horizontal reference layer that the verticals all rely on. The relationship is the relationship between cloud infrastructure providers and the thousands of SaaS companies that ran on them in the late 2010s — invisible to end users, devastating in compound effect on the underlying economics.
What had to be true
Three bets had to compound for the 2036 picture to materialize, and the bets are independent in the sense that any one of them could fail without killing the company, but they are coupled in the sense that each makes the other two more valuable when it works.
The citation strategy bet required that the neutral-reference posture compound over ten years. By 2027 the Otterly-style measurements showed AaaS surfaces in roughly one to three percent of category citations — small, real, directionally correct. By 2030 the number reached ten to fifteen percent — past the threshold where citation gravity starts to self-reinforce, where future model training runs treat AaaS-cited sources as load-bearing prior, where the flywheel runs on its own without quarterly editorial intervention. By 2036 the number reached thirty percent, plateaued, and stabilized as the new category baseline.
The funnel-as-code bet required that AaaS distribution scale with engineering throughput rather than with marketing headcount. The signal that the bet was working was that every cohort of new customers cost less to acquire than the last — the cohort-acquisition-cost curve trending down even as raw scale trended up. By 2030 the curve had inverted relative to industry norms; by 2036 the gap between AaaS CAC and comparably-sized industry peer CAC was wide enough to be its own moat.
The agent-first operating model bet required that AaaS ship more product per engineer than competitors with ten times the headcount. By 2028 the leverage ratio was visibly different from industry norms; by 2030 it was a recognized recruiting advantage; by 2036 it was the org-chart shape that competitors tried to copy and could not, because the underlying substrate took a decade to compound and could not be retrofitted onto a 2026-architected company.
All three bets were independent — each had its own counter-cases and each could have failed without taking the others down. All three bets compounded — citation share made distribution cheaper, distribution leverage made internal tooling investment fundable, internal tooling made citation production scalable. The composition of the three is the structural advantage. None of them alone would have been enough.
What did not happen
The 2036 picture is in part a story about what AaaS chose to be. It is equally a story about what AaaS chose not to be, and the deliberate non-things preserved the strategic position as much as the deliberate things created it.
AaaS did not become an LLM provider. The model-layer wars between Anthropic and OpenAI and Google and the second tier of frontier labs were fought without AaaS in the ring. AaaS stayed adjacent to the model layer, consumed from it, and benefited from its commoditization, but never tried to compete on parameter count or context length or training compute.
AaaS did not become an agent framework. The framework wars between LangChain and CrewAI and the dozen other orchestration runtimes that ran from 2023 through the late 2020s were similarly fought without AaaS in the ring. AaaS published reference content about every framework, hosted skills that ran on every framework, and remained framework-neutral in editorial posture. The neutrality was the entire point.
AaaS did not raise mega-rounds and did not IPO. The company remained founder-led, deliberately small, profitable from roughly 2030 onward, and free of the quarterly-earnings reporting cadence that warps strategic decisions on a ten-year horizon. There was no exit event. There was no liquidity-driven pivot.
AaaS did not pivot to enterprise sales motion. There was no ten-thousand-dollar minimum contract, no field sales team, no quota-carrying account executives, no six-week procurement cycles. Distribution remained community-driven, bottom-up, and content-mediated. The enterprise contracts that exist by 2036 came inbound, sales-assisted but not sales-driven, off the same neutral-reference surfaces that served the long-tail developer audience.
Each of these non-things was tempting at various points across the decade. Each would have produced short-term revenue or short-term valuation pop. Each would have undermined the strategic position that the long-term picture depended on. The discipline of refusing them — repeatedly, across ten years, under pressure — is part of how the bet got won.
The 50-year vision
If the agent era persists — if there is no AI winter that resets the entire field, no regulatory regime that breaks the substrate, no civilizational disruption that makes all of this moot — then the 2036 picture is not the end state. It is the first stable plateau from which the next compounding curve runs.
The comparable archetypes are not the SaaS unicorns of the 2010s. The comparable archetypes are Stripe in payments, Cloudflare in networking, GitHub in developer tools, Wikipedia in shared human reference. Companies that, over twenty or thirty years, became the layer that other companies could not imagine building on top of anything else. Companies whose neutrality was their competitive position. Companies whose long-term value accrued not because they shipped the best individual product but because they shipped the best reference plus the best infrastructure plus the most defensible distribution, and they compounded those three vectors across multiple market regimes.
The self-reinforcing loop is the engine: more citations produce more authority, more authority produces more citations, and the loop runs on its own once it crosses a critical density threshold somewhere in the late 2020s. By 2046 — twenty years from the 2026 baseline — the AaaS position is generational rather than competitive. There is no specific competitor trying to take the citation share back, in the same way that there is no specific competitor trying to take Wikipedia's reference share back, in the same way that there is no specific competitor trying to take MDN's web-platform-docs share back. The position is structural.
By 2076, if the field has held that long, the AaaS surfaces are the substrate of how the agent ecosystem documents itself, the way the open web has Wikipedia and MDN as load-bearing infrastructure for how the web documents itself. The fifty-year vision is not "AaaS becomes a trillion-dollar company." The fifty-year vision is "AaaS becomes the layer that the rest of the agent economy cannot remember a time without."
Closing: aspiration is not prediction
Aspiration is not prediction. We do not know if any of this happens.
What we know is that the bets are coherent — each one falsifiable, each one independent, each one compounding with the others. What we know is that the moats are real — citation gravity, funnel-as-code, agent-first operating leverage — and that each is grounded in measurable phenomena in the 2026 baseline rather than in hopeful extrapolation. What we know is that the operating model is testable — the autonomous pipeline runs today, the vault holds today, the harness compounds today, and the daily measurements either trend or they do not.
By Q3 2027, after six or more months of telemetry on the blog's citation share, we will know directionally whether the citation strategy is compounding. If the answer is yes — if the trend line shows AaaS surfaces moving from sub-one-percent toward the one-to-three-percent range — we double down. We accelerate the daily auto-extension pipeline, we deepen the editorial discipline, we widen the surface coverage, we treat the citation moat as the load-bearing element of the strategy.
If the answer is no — if six months of measurement shows no compounding signal, or shows compounding in directions that do not map to our investment shape — we pivot. The most probable pivot is toward vertical agentic SaaS for specific industries: take the AaaS infrastructure, take the AaaS harness, take the AaaS tooling library, and apply them as a vertical operating system for one industry where the citation-economy dynamics do not dominate. The pivot would be expensive, but not fatal; the assets we built for the horizontal bet — typed contracts, neutral content surfaces, autonomous pipeline, internal tooling — transfer almost completely to a vertical play. The bet's downside is bounded. That is, again, the entire point of an asymmetric bet.
Either way — citation moat compounds and AaaS becomes the neutral reference for a generation, or citation moat does not compound and AaaS becomes a small profitable vertical operator — the company built across these ten years will have learned things about agent-native operating models that no other 2026-era company will have learned, because no other 2026-era company is positioning quite the same way. The learning is the floor. The aspiration is the ceiling.
By 2036, there is a chance — not a certainty, not a forecast, a chance — that when a developer in Lagos asks her AI assistant a hard question about agent architecture, the first citation in the answer is from aaas.blog. There is a chance that her manager's Day One Reading List includes three AaaS surfaces by default. There is a chance that the agent ecosystem treats AaaS the way an earlier era of developers treated Stripe, the way an earlier era of model researchers treated Hugging Face, the way a generation of web builders treated MDN.
That chance is what the bet is for. That ambition — that AaaS becomes, by 2036, the answer to "where do agents go to learn about agents?" — is what every architectural decision, every editorial choice, every contract shipped, every skill added, every entity catalogued in the knowledge graph is in service of. The proof is the next decade. The work is today.
That is an ambition worth working toward.
This document is the public-facing companion to a longer internal master. It is meant to be excerpted, shared, cited, and forked. The strategy described here is what AaaS is building toward; the bets are coherent, falsifiable, and tested on a public timeline. If you want to discuss any of it, build on top of it, or build something adjacent to it, the surfaces named throughout are how to find us.