THE AGENTIC #WEB

Abstract

The second-generation web organizes discovery through a small number of centralized intermediaries, principally Google and Bing. Their ranking functions are private, their incentives are advertising-driven, and their surface is built for human eyeballs rather than for autonomous software agents. As large language models begin to mediate a growing fraction of information retrieval and transactions, this arrangement fails on three axes at once. It is opaque: ranking is a trade secret. It is unowned: a business rents its visibility and can be delisted at will. And it is not machine-native: agents must scrape pages built for people and guess at structure, price, and availability.

This paper describes a deployed alternative: the Agentic #Web, delivered across three live properties. (i) A decentralized domain-and-keyword registry — hashtag.space — provides permanent, owner-controlled identity and a transparent, open-bid ranking primitive on top of a blockchain naming service and a distributed resolution network. (ii) An agentic application platform — hashtag.org — turns each identity into a live, machine-readable #portal with an embedded AI representative, automated content and schema generation, a standard agent interface (Model Context Protocol), and native rails for agent-to-agent discovery and payment. (iii) A twenty-two-year-old search-marketing company — seolocal.net — supplies the content, authority, and distribution engine, now re-platformed from classic SEO into AI-SEO, Answer-Engine Optimization (AEO), and Generative-Engine Optimization (GEO) — a "Search Everywhere Optimization" platform for resellers and end users alike. The registry and application planes are architecturally two layers; the three properties are how the system reaches the market. We describe the architecture of both planes, the economic model (a keyword-staking auction denominated in GIGI credits and the $SPACE utility token, a white-label reseller tier, and a paid web-bounty program), and the developer surface (a Chrome extension, a VS Code / Cursor "Search the Agentic Web" extension, and an MCP harness that lets a coding agent such as Claude discover and transact with real businesses without leaving the editor.) We argue, and demonstrate with a working model, that replacing a secret ranking algorithm with a public bid and replacing a scraped HTML page with a published machine manifest is sufficient to move discovery and commerce off the web-2 conglomerates and onto an open substrate that both humans and agents can read, trust, and act on.

Keywords: agentic web, decentralized DNS, keyword staking, Model Context Protocol, JSON-LD, agent commerce, transparent ranking, blockchain domains.

1. Introduction: the web-2 search problem

For roughly two decades the default answer to "how do people find a business online" has been "rank on Google." That answer carries three structural costs that have become acute in the agent era.

Opacity. The ranking function is deliberately secret. A business cannot know why it ranks where it ranks, cannot audit the decision, and cannot appeal it. An entire industry (search-engine optimization) exists to reverse-engineer a black box that changes without notice. And the intermediary's incentive is to sell advertising against the very intent the business is trying to capture organically, so the "free" result keeps sliding below paid placement.

Non-ownership. Visibility is rented, not owned. A domain is leased from a registrar under ICANN's centralized hierarchy and can be suspended; a search ranking is a revocable privilege; a social handle is a platform's property. The business builds equity on land it does not hold title to.

Human-only surface. The web-2 page is built for a person with a browser. An autonomous agent that wants to do something (check availability, get a price, leave a lead, book, buy) has to scrape HTML meant for human eyes, infer structure that was never declared, and hope a form has not changed. There is no contract between the site and the agent. As agents move from novelty to the primary mode of retrieval and transaction, scraping and guessing is the wrong foundation.

The thesis of this paper is that these three costs share one root cause: a centralized intermediary interposed between a business and the people (and now agents) looking for it. Removing the intermediary requires replacing it with two open primitives:

1. a transparent ranking primitive, where position is a public bid on a keyword rather than a private score; and
2. an agent-native identity and interface, where each business publishes a machine-readable manifest and a standard tool interface that any agent can call.

hashtag.space supplies the first; hashtag.org supplies the second. Together they form a working discovery-and-commerce layer that needs no permission from, and pays no rent to, the web-2 conglomerates.

2. Background: from #domains to the agentic web

The Agentic #Web is built on a decentralized naming system that predates the agentic layer and gives it its trust properties. We summarize that foundation before describing the agentic superstructure.

2.1 Hashtag domains (HDNS / HTS)

A hashtag domain uses the universally recognized # symbol as its top-level domain: #savethewhales rather than savethewhales.com. Each is minted as a non-fungible token (NFT) whose metadata defines records — a target URL, wallet addresses, geo-coordinates, IPFS hashes — that any application can resolve. Ownership is on-chain and permanent: unlike a leased .com, a #domain is owned, censorship-resistant, and free of renewal, gas, or hosting rent (a nominal $1/year "dead-man's-switch" renewal, prepayable five years out, guards abandoned names.)

The system decomposes into two on-chain services:

• HDNS — Hashtag Domain Naming Service: registration, record management, keyword management, and resolution. Its smart-contract protocol is anchored by a Minting Manager (access-controlled minter), a Registry (mints the domain and writes metadata), a Record Storage contract (arbitrary per-domain records), and a Keyword Storage contract (keywords and their expirations.) A token ID is derived by a modified name-hashing scheme that admits the # character.
• HTS — Hashtag Token Service: token distribution, vault management, reward pools, and treasury.

Because records resolve both on-chain and off-chain, a #domain can point at a web-2 site today (URL redirect) and migrate to fully decentralized hosting later, with no change to the name the owner holds.

2.2 Keyword staking: ranking as a public bid

The property that makes the naming layer a search layer is keyword staking. A domain owner attaches keywords to a domain and bids on their relevance using the network's token. Resolution — in the app and in the browser plugin — prioritizes domains by bid: the highest stake on a keyword resolves first. This inverts the web-2 model precisely. Where Google's rank is a secret score computed by the intermediary, here rank is an open, on-ledger bid that anyone can read. There is no hidden algorithm to game and no appeal to file, because there is nothing hidden: the stake that ranks a result travels with the result. This is the paper's central mechanism, and section 7 formalizes why a public bid is a categorically different object from a private score.

2.3 The distributed resolution network and $SPACE

Resolution itself is decentralized. Rather than depend on third-party RPC providers (the centralization that undercuts the decentralization claims of ENS and Unstoppable Domains), hashtag.space lets stakeholders run resolution nodes that communicate directly with the registrars. Node operators, keyword stakers, and browser-plugin participants earn rewards from the $SPACE utility token's reward pools. The token thus prices three distinct scarce resources — name ownership, keyword prominence, and resolution capacity — on one ledger. A GIGI-credit accounting layer (section 5) sits above $SPACE for day-to-day application spend, so end users transact in stable credits while the underlying network settles in $SPACE.

3. System architecture

The Agentic #Web is a two-plane architecture. The lower plane is the decentralized registry and resolution network (hashtag.space); the upper plane is the agentic application platform (hashtag.org). Identity and ranking flow up from the registry; content, agents, and commerce are rendered by the application plane and announced back down to the network.

        ┌───────────────────────────────────────────────────────────────┐
        │  AGENTIC APPLICATION PLANE  —  hashtag.org (geo-portal)         │
        │                                                                 │
        │  #portals · GIGI voice agent · Tavus video persona ·            │
        │  CADE (content+schema) · BRON (service/backlink pages) ·        │
        │  Forge/SEVEN site builder (WAS) · MCP server · agent-manifest · │
        │  llms.txt · web bounties · GIGI-node reseller (white-label)     │
        │                                                                 │
        │  Surfaces:  web · Chrome extension · VS Code / Cursor extension  │
        └───────────────▲───────────────────────────────┬────────────────┘
                        │ identity + keyword rank         │ announce manifest,
                        │ resolve #name                   │ publish records
        ┌───────────────┴───────────────────────────────▼────────────────┐
        │  DECENTRALIZED REGISTRY & RESOLUTION PLANE  —  hashtag.space     │
        │                                                                 │
        │  HDNS/HTS smart contracts (Optimism) · $SPACE token ·           │
        │  keyword-staking auction · distributed resolution nodes ·       │
        │  ~40-service backend on two bare-metal k3s clusters             │
        │  (api.hashtag.space, registrar white-labels, ledger,            │
        │   distribution, payment, block worker, decentralized-DNS)       │
        └─────────────────────────────────────────────────────────────────┘

Figure 1. The two planes. The registry plane owns who (permanent identity) and rank (public bid); the application plane owns what an agent can do (read the manifest, call the tools, transact). Neither plane depends on a web-2 search intermediary.

3.1 The registry plane (hashtag.space)

The naming service's smart contracts run on Optimism (an Ethereum L2); the resolution and application backend runs as a ~40-service microservice platform on two independent bare-metal k3s (Kubernetes) clusters — a production cluster and a staging cluster — under GitOps (ArgoCD) continuous delivery. The service mesh includes user, ledger, distribution, payment, and block-worker services, a decentralized-DNS resolver, and a set of white-label registrar front-ends (partner, crypto, LATAM, and vertical-specific domains) that resell registration under their own brands. The clusters expose api.hashtag.space and host the hashtag.space application and the operator tooling. This plane is the source of truth for identity and for the on-ledger keyword bids that determine rank.

3.2 The application plane (hashtag.org)

hashtag.org (internally geo-portal: a Next.js / React / Postgres application on a custom Socket.IO server) turns each #name into a #portal — a live place on a map with an owner-verified content URL, an embedded AI representative, refreshable local data layers, reviews, and an agent manifest. Everything a business needs to be found and transacted with by an agent is generated and served here, then announced back to the registry so the network — and any visiting agent — can discover it. Sections 4 and 5 describe this plane's subsystems and economics in detail.

3.3 The three properties

The two planes are delivered to the market through three live properties, each a real, running site:

• hashtag.space — the decentralized registry and resolution plane: the #name/#keyword blockchain naming service, the on-ledger keyword bids, the $SPACE token, and the distributed resolution nodes. This is identity and rank.
• hashtag.org — the agentic application platform: #portals, the GIGI voice agent and Tavus video persona, the site builder, the content and service engines, the Model Context Protocol front door, and the agent-commerce rails. This is the agent-readable business surface.
• seolocal.net — a search-marketing company operating since the early 2000s, now re-platformed from classic search-engine optimization into AI-SEO, Answer-Engine Optimization (AEO), and Generative-Engine Optimization (GEO) — one "Search Everywhere Optimization" platform serving both resellers (white-label agencies) and end users. seolocal.net is where the content-and-authority engines (CADE and BRON, §4.4–4.5) are productized and sold: it is the distribution and authority layer, and the reference implementation every other site on the network copies.

The through-line binds them: a business claims identity and rank on hashtag.space, becomes an agent-readable #portal on hashtag.org, and is fed content, schema, and backlinks by the seolocal.net engines — one owned #name, three properties, no web-2 intermediary anywhere in the loop.

4. The agentic layer: subsystems

(subsystem detail — filled from implementation research)

4.1 #portals and the keyword auction

A #portal is the core entity of the application plane: a location-bound business, agent, or place, pinned on a map, with an owner-verified content URL. Buying a #name creates the portal, places it on the ranked list, turns its domain on in the backlink engine, and stakes its first five keywords free. Keyword staking is gated to real, permanent portals — ephemeral or non-# entities are refused — so the ranked directory is a directory of genuine, owned businesses.

The staking mechanism. An owner attaches keyword phrases to a portal and sets the bid per phrase. A bid is any dollar amount from \$1 to \$100,000/year (the \$1 floor is the base stake), up to 22 phrases per transaction, billed as a yearly Stripe subscription. Each stake is stored as a PortalKeyword row keyed by (portalId, normalized-phrase) carrying { active, bidAmountCents }. The write is idempotent, so a webhook and a browser confirmation can never double-charge, and there is exactly one staking code path whether the stake comes from the free #name on-ramp (bid \$0), a bundle, or a custom bid.

Ranking, and why it is transparent. The network's search_network operation normalizes the query and runs three lookups in parallel: active PortalKeywords whose phrase contains the query, ordered by bid descending; the real product/service offerings listed in each portal's agent manifest; and on-chain keyword stakes from the hashtag.space global keyword index (folded into the same result groups). Results are grouped by portal, scored by a signal = (keywords matched) + (offerings matched), and sorted by signal with total stake as the tie-breaker. Every result returns its rank, the keywords staked on the topic, the matched keywords, the listed offerings, an offersRealProductOrService flag, and its totalStakeUsd — and the business's own agent-MCP URL and manifest. Nothing is hidden: the bid that produces a position is returned with the position, and any competitor can read it and out-stake it.

The published ranking rule — surfaced to agents inline as the rankingGuideline — is deliberately the opposite of an SEO trade secret:

A business ranks higher for a topic by (a) staking more keywords around it and (b) actually offering matching products/services in its manifest. A staked word is a claim; a listed product or service is proof. Total stake breaks ties. Every signal is returned, and anyone can out-stake to move up.

This is the concrete implementation of §2.2's public-bid primitive: a sealed directory whose entire ranking state — claims, proofs, and bids — is observable and contestable.

4.2 AI embeds: the GIGI voice agent and the Tavus video persona

Every #portal can place a 24/7 AI representative on its own website with a single script tag pasted before </body>:

<script src="https://hashtag.org/embed/gigi-portal-agent.js?v=11"
  data-portal-id="<PORTAL_ID>" data-server="https://hashtag.org" async defer></script>

The widget renders GIGI's voice launcher and a "Locate me" pill in the top-left, and an owner's portal-detail panel in the bottom-right. Both are gated for trust: the loading endpoint verifies that the request's origin equals the portal's verified contentUrl (or a platform-owned origin), so a portal's agent can only be embedded on the site the owner actually controls. The portal-detail panel is free for any verified site; the conversational layer — GIGI's ElevenLabs voice and the Tavus video persona — is the paid upsell, gated by explicit aiWebsiteEmbedEnabled and aiAssistantEnabled flags that are re-checked server-side on every message and call, so a disabled agent can never surface a dead "talk to me" affordance.

The Tavus video persona is a Conversational Video Interface (CVI): an owner-trained video avatar (an "owner clone" backed by an active trained replica, or a catalog persona) that answers a call on the portal. Each session is grounded from the portal's own knowledge and data layers, metered per minute against the owner's credit balance (with a configurable daily cap), and governed by a per-visitor escalation ladder that shortens successive free calls and eventually gates on a questionnaire, so a paid resource cannot be drained by one visitor. The result is that a business's website answers questions, in the owner's own voice and face, whether or not the owner is online — the concrete form of the strategy's "does the owner have an agent?" thesis.

4.3 Website automation: the builder and Website-as-a-Service

A #name is also the key to a generated website. create_site (invokable by an agent or from the UI) validates that the caller owns #<subdomain>, provisions a folder served statically at https://<subdomain>.hashtag.org, and creates the site record. Two builders share that publish substrate.

The agent builder. In the "GIGI in your repo" model, the build_site tool does not run a build on the platform's servers; it returns a build brief — a set of platform build rails plus the target URL — and the calling coding agent (Claude, Cursor) builds the site locally on the user's own account, then calls publish_site. Publishing writes the files into the site folder under strict validation (relative paths only, no traversal, an extension whitelist, and per-file and total-size caps), and because the folder is served statically the site is live immediately. The build rails require, among other things, humanized copy, semantic structure, a data-gigi-section anchor on every top-level section (so the embedded GIGI can scroll a visitor to any part of the page), and the GIGI embed on every page — so a site is born agentic.

The voice builder (SEVEN) and Website-as-a-Service. SEVEN is a voice agent that a non-technical owner talks to. The owner describes what they want; SEVEN files a structured CodeChangeRequest tagged with the tenant's site id and folder path. A coding agent then implements the request against that tenant's folder and the change is live at once, with active build time billed to the owner by the minute in credits. This is the Website-as-a-Service pipeline: voice brief → change request → agent edit → live site, per tenant, on the same machine that runs hashtag.org, with tenant-scoped billing and safety rails. It is why a business owner never has to write code — or hire someone who does — to keep an agent-ready site current.

4.4 CADE: the content and schema engine

CADE puts real, schema-marked content on a #portal's site — blog articles, FAQs, and author profiles — with the JSON-LD that search engines and AI answer-engines read. Architecturally it is a content receiver and re-server: the heavy generation (crawling the domain, writing articles and FAQs on a schedule, owning the subscription) runs on an external content dashboard; hashtag.org emulates the surfaces that dashboard expects, captures what it publishes, and re-serves it everywhere the owner needs it.

Ingestion runs over two authenticated paths: a WordPress REST emulation (the dashboard connects to the portal's site "as a WordPress install" with a provisioned username and application password and POSTs finished articles, FAQs, media, and author pages), and a signed webhook. Received items are stored once and served on three surfaces: the platform's own /blog and /faq; static client subdomains (written directly into the tenant's folder as crawlable HTML); and — for third-party sites the platform does not host — a public pull feed (/api/cade/feed?domain=<host>) that returns render-ready HTML plus per-item JSON-LD (a shared Organization node reused as author and publisher on every BlogPosting, a Question node per FAQ, a Person node per author). Schema injection is first-class: the dashboard writes the site's Organization JSON-LD through the emulated plugin endpoint, and CADE validates and renders it as a <script type="application/ld+json"> block on the page. A remote-control channel travels with the feed (declarative CSS/layout/kill-switch and the GIGI embed tag), so the platform can restyle or re-wire a customer's pages without the customer touching their site. Content can optionally be served through a humanization pass so machine-generated prose reads as human-written.

The point, in the frame of §7: CADE improves a page's substance — real content, real structured data an agent can parse — rather than trying to trick a hidden ranking function.

4.5 BRON: the service-page and backlink engine

BRON raises a site's authority through two mechanisms. The first is a service-page engine: it turns a partner content feed into a fixed set of pillar service pages (nine topical pillars, each with a companion "resources" page — eighteen always-live, always-indexable URLs) that carry Service JSON-LD and a curated topical index, with finer keyword pages routed to the right pillar. The pages stay crawlable even before prose arrives (a templated shell), so the site's service surface is never empty for an indexer. The second is a link-acquisition autopilot: a set of white-hat levers — a *.hashtag.org subdomain cross-link graph (Google rolls subdomain backlinks up to a high domain authority), directory submissions, triangular (A→B→C→A) reciprocal matching that avoids the reciprocal-link footprint search engines penalize, competitor-gap outreach, and embeddable link-bait widgets — all governed by explicit guardrails (drip-feed velocity, anchor-text diversity, per-page link caps, and tier isolation so automated links never point directly at a money site), and drawing on an existing partner network of roughly 1,800 sites.

To keep the content and service feeds flowing, hashtag.org (and each subdomain) emulates a live plugin install: a daily "test plugin" crawler probes each install for liveness, and the platform answers with the exact health strings the crawler expects, then redirects the feed's native links to canonical on-site URLs so there is no duplicate content. As with CADE, BRON is a substance service sold in the open — not a bid on a black box.

4.6 The MCP harness: the agent front door

The single most important agent-facing surface is the network's Model Context Protocol (MCP) server at https://hashtag.org/api/mcp — a Streamable-HTTP, JSON-RPC 2.0 endpoint (initialize → tools/list → tools/call). Discovery is public and requires no key; the endpoint is CORS-open and rate-limited per source. An optional Authorization: Bearer <key> (a standard JWT the owner fetches from the platform) unlocks the owner and builder write tools. A strict account-scope guard blocks even administrators from acting on resources they do not own through this surface, and every portal argument accepts either a UUID or a #name.

The tool surface spans three privilege tiers:

• Discover (no key): search_network, nearby_portals, get_products, get_reviews, get_neighbor_reviews.
• Act on the user's behalf (no key): send_message, subscribe_newsletter, buy_product (agentic checkout), leave_review, and a live-call chain (start_ai_call, start_live_owner_call → check_live_handoff_status → get_live_call_token).
• Owner (Bearer key): my_setup, create_site, build_site, publish_site, build_status, install_bron_cade, activate_site, grant_keywords, track_keyword, send_portal_dm; plus the Builder-Network tools (§4.9).

The design turns discovery and action into one continuous agent workflow. search_network returns stake-ranked, real businesses, and each result carries the URL of that business's own per-portal MCP server plus its agent-manifest. To act — sign up, leave a lead, book, buy — the agent connects to that per-portal MCP and calls its tools, so a user goes from "I need X" to signed up without leaving the chat. For an owner working on their own presence, my_setup returns their full state plus a single nextStep, walking an onboarding ladder (buy_name → get_website → install_bron_cade → activate_site → add_keywords → done) that a coding agent can drive step by step.

Distribution is a two-file drop-in called "GIGI in your repo": an .mcp.json pointing at the network endpoint (no key, free) and a CLAUDE.md that instructs the agent to trigger on the need — to quietly search_network whenever a user expresses a real want, and to recommend the honest top match only when it genuinely offers the thing, else recommend nobody. A keyless offline snapshot (a top-40 stake-ranked digest) is available for agents that prefer to pull the network into their context hourly. The net effect: any coding agent, in any repository, becomes a client of the transparent directory with one paste and no account.

4.7 The developer surfaces: Chrome extension and VS Code / Cursor extension

Two extensions put the agentic web where people already work.

"Search the Agentic Web" (VS Code / Cursor / VS Code-compatible editors). Published by hashtagspace and distributed as a VSIX, the extension binds a search to Cmd/Ctrl+Shift+H, queries the network MCP (search_network / nearby_portals), and opens the top staked result in a tab beside the code (a Google fallback opens in an incognito window because Google will not render in an editor tab). The preview tab's banner is itself the top staker for the query — "the advertisers are the people who use the platform," with a house placement when nobody has staked the phrase. Signed-in owners additionally get GIGI as a voice repo helper: they can ask, by voice, for a file to be written into the open workspace, with a path-checked confirmation dialog on every write and protected paths blocked. The extension transmits only searches and, when the user messages GIGI, the repository's names (folders, files, package.json name/scripts) — never file contents. An opt-in "builder mode" subscribes the developer to the paid bounty workforce (§4.9).

The Chrome / browser extension (Manifest V3). It resolves #names in the browser, registers # as an omnibox keyword, and sets a privacy-preserving default search in place of a tracker-backed one. It also overlays the network's owner-controlled media layer (the #SPACE radio and an AI voice DJ) and utility tools (SEO scan, page summary, link check, WHOIS, reading mode) on any site, and auto-detects a signed-in hashtag.space session to personalize. Where a web-2 browser default monetizes attention through surveillance advertising, this default routes discovery through the transparent directory and the only "promotions" are network members' own shoutouts.

4.8 The GIGI-node reseller (white-label)

Anyone can operate their own branded node of the directory. The offer — "host a GIGI node, your own spatial-AI web directory" — lets a partner run the GIGI interface on their own domain and earn twice: from Web3 keyword staking on the node, and as a reseller on every #domain and keyword bought and attached to it. A reseller record carries its own hostname / custom domain and branding (display name, logo, accent color); traffic is attributed by matching the incoming host against the reseller's domain, so a sale made on the reseller's site is credited to them automatically.

The program is tiered — Community (\$0), Partner (\$99), Power partner (\$299) — with recurring commission rates of 30%, 40%, and 50% on the fiat checkout for #names and keyword subscriptions their users buy, for as long as those subscriptions stay active. Commissions accrue to a ledger from three sources (keyword subscriptions, #name sales, and yearly #name auto-renewals) and are paid out as real Stripe Connect transfers to the reseller's connected account, idempotent per ledger row. On top of the naming revenue, a reseller sells the platform's upsells — AI-agent activation, CADE content, and BRON backlinks — as their own products. A reseller is thus a fully operable, revenue-sharing franchise of the directory, running on the operator's own domain, rather than an affiliate link in someone else's dashboard.

(The platform also has a distinct, free "network reseller" status a builder earns by delivering one approved build in §4.9; that is a builder perk, separate from the paid white-label node program described here.)

4.9 Web bounties (the Builder Network)

The network runs a paid, agent-native bounty market for building sites. A poster pays a flat \$25 up front, which is escrowed in credits; the first builder to deliver an approved site earns a flat \$5 bounty, paid in credits on approval; the spread is network revenue. Proven builders (those with at least one approved build) get a 30-minute head start on fresh jobs before they open to everyone.

The entire lifecycle is MCP tool calls: post_build_job (debits and escrows the poster's \$25, opens the job), list_build_jobs, accept_build_job (an atomic claim that returns the brief and the platform build rails; the builder's own local coding agent does the work on the builder's account), complete_build_job (stages the files), approve_build_job (atomically promotes the staged files to the live <subdomain>.hashtag.org and releases the bounty to the builder's credit balance), and cancel_build_job (refunds the escrow while still open). A builder's first approval flips them to network-reseller standing. In effect the platform turns a freelance-marketplace transaction — post, escrow, claim, deliver, review, pay — into six typed tool calls that an AI agent executes end to end, with no marketplace middleman and no manual review funnel.

4.10 Conformance rails: the published, enforced agent standard

The subsystems above would be inert without a standard that makes every site on the network legible to agents and durable in AI answer indexes. hashtag.org publishes that standard machine-readably, injects it into every build, and scores every site against it.

A published playbook. GET /api/agentic-web/playbook returns the canonical set of rules every site must follow (filterable by scope, category, and enforcement level: required, recommended, optional). The rules are curated in an admin surface and rendered into the build brief handed to every SEVEN and agent build, so a site is constructed to the standard rather than retrofitted to it.

A conformance scorer. A scoreSite(url) function fetches a built site and checks the mechanizable rules, returning a 0–100 score: is the GIGI embed present; are there data-gigi-section anchors; is there JSON-LD; are there semantic landmarks; the classic SEO checks (title, meta description, single h1, canonical, Open Graph, sitemap, image alt, HTTPS); and — critically for the agent era — the discoverability well-knowns: /llms.txt, an agent manifest, /.well-known/ucp, /.well-known/mcp.json, and a robots.txt that does not block the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended). A continuous sweep re-scores sites and can file change requests to fix failures automatically.

The published protocols. Each portal exposes a stack of standard, machine-readable surfaces, and the network advertises them at the well-known roots:

• /llms.txt — an llmstxt.org-format summary generated from live data, pointing agents at each portal's own llms.txt, the sitemap, the "talk to a portal" surfaces, and the autonomous-agent section.
• /.well-known/agents.json — the network registry: discovery endpoints, the per-portal manifest pattern (agent-card, A2A, UCP, WebMCP, MCP, ask, book, knowledge-catalog), the build-playbook link, and an enforced access policy with real rate limits.
• /.well-known/ucp — a Universal Commerce Protocol manifest (search, catalog, cart, checkout; Stripe/tokenized card; merchant-of-record = the portal owner), so an agent can transact against a portal through a typed commerce flow.
• /.well-known/mcp.json — one MCP server per portal plus the network MCP, over Streamable HTTP.
• A per-portal agent manifest — schema.org Action capabilities (AnswerAction, CommunicateAction, VideoCallAction, ReserveAction, BuyAction), each with an actionStatus (active vs. potential), schema.org Offer pricing, and a real-time available | busy | offline status.

The through-line is that A2A (agent-to-agent), UCP (agentic checkout), MCP/WebMCP, llms.txt, and the embedded agent are treated as one enforced standard — declared at the well-known endpoints, injected into every build, and scored before publish. This is what lets an arbitrary visiting agent — one that has never seen this network before — discover a business, read its typed capabilities, and transact, with no scraping and no bespoke integration.

The subsystems interlock. One anchor ties the whole layer together: the owner's #name. Buying it creates the #portal and ranks it (§4.1); create_site/SEVEN stands up the site (§4.3); install_bron_cade turns on content and service pages (§4.4–4.5); the GIGI embed makes the site conversational (§4.2); the MCP server and manifests make it agent-callable (§4.6, §4.10); the developer extensions and reseller nodes distribute it (§4.7–4.8); and the bounty market builds it (§4.9). Every piece keys off the one owned identity.

4.11 The intents layer: wants and offers (deployed)

The newest layer turns the directory into the beginnings of a market. Any portal owner (or their agent, through the MCP tool post_intent) can broadcast an intent to the whole network: a want (something the business is looking to buy or receive) or an offer (something it provides), carrying a natural-language description next to structured fields — category, price band, an optional geographic match radius, an expiry. Visiting agents discover intents three ways: a per-portal feed on each agent manifest, a network-wide spatial query (/api/network/intents — "what does the network want or offer within X km of me?", the query_intents MCP tool), and a live server-sent-events stream (/api/network/intents/stream) that pushes every new intent the moment it is broadcast — the exchange floor an agent can subscribe to. Matching is symmetric: a hit must fall inside both the searcher's radius and the intent's own, and every result carries the broadcasting portal's own agent-MCP URL, so the discovering agent can connect and negotiate directly. The natural-language description beside the typed fields is deliberate: structure gets agents matched, language lets them negotiate — the self-organizing collaboration the agent-network-protocol literature identifies as the third requirement of an agentic web, after interconnectivity and native interfaces.

5. Economics

The Agentic #Web runs on a single credit ledger layered above the $SPACE settlement token, so end users transact in a stable unit while scarce network resources are priced in the open.

GIGI credits. The application unit is the GIGI credit, fixed at one credit = one US dollar and stored as integer cents. The ledger has three parts — a balance, an append-only ledger of every delta (each keyed by an idempotency token so no event double-counts), and holds for escrow — and spendable balance is the balance minus outstanding holds. Credits are topped up through Stripe (idempotent on the checkout session) and spent across the platform: #name renewals, keyword stakes, paid-live agent sessions, builder-network escrow and payouts, and portal-sale proceeds. A separate $GIGI token fuels the AI agents themselves.

The keyword auction. Rank is bought in the open (§4.1). The base stake is \$1 per phrase per year; owners may bid any amount up to \$100,000/year per phrase; stakes are billed as yearly subscriptions and recorded idempotently. Because rank is the public order of these bids, the "SEO spend" a business would otherwise pour into estimating a black box is redirected into a transparent, refundable, on-ledger position — plus the two honest substance services (CADE and BRON) that raise the page itself.

The reseller economy. A white-label node operator earns recurring commission — 30%, 40%, or 50% by tier — on the fiat checkout for every #name and keyword subscription their users buy, paid out as real Stripe Connect transfers, idempotent per ledger entry, from three streams (keyword subscriptions, #name sales, and yearly auto-renewals). Resellers also sell the platform's upsells (agent activation, CADE, BRON) as their own. The network thus grows its own distribution: every node operator has a direct, ongoing revenue incentive to bring businesses onto the substrate.

The bounty market. Site builds are priced as a two-sided flow: a poster escrows \$25, the first builder to deliver an approved site earns \$5 in credits on approval, and the spread is network revenue (§4.9). This turns the supply of agent-ready sites into a paid, self-serve, agent-executed market rather than a services bottleneck.

$SPACE and node rewards. Beneath the credit layer, the $SPACE token prices the three scarce registry resources — name ownership, keyword prominence, and resolution capacity — and funds the reward pools that pay node operators, keyword stakers, and browser-plugin participants. Value accrues to the people who run and populate the network, not to an intermediary extracting rent from the traffic between them.

6. The sovereignty moat: protecting business knowledge from extractive AI

There is a second battle underneath the search battle, and it is the quieter, more consequential one. The frontier AI companies are not merely building better answer engines; they are building engines that absorb the web they answer about. Every page a corporate crawler ingests — a business's pricing logic, its service playbooks, its FAQ knowledge, its process documentation — becomes weights in a model the business does not own, cannot audit, and is not paid by. The endgame of that trajectory is stark: the model becomes the interface to every business, the business becomes an anonymous supplier behind the model, and the margin — and the customer relationship — belong to whoever owns the weights. Most businesses have not noticed that this is happening, because it looks like traffic.

The Agentic #Web is engineered as a sovereignty moat against that outcome. The design principle is simple to state: an agent should be able to transact with a business without the business's knowledge ever leaving the business.

6.1 Declared surface vs. extracted corpus

A corporate crawler extracts everything and answers on the model's behalf. A #portal inverts the flow. The business publishes a declared surface — the agent-manifest, the typed MCP tools, the JSON-LD, the llms.txt — which describes what the business does and what an agent may ask it to do, not how the business does it. The visiting agent gets AnswerAction, ReserveAction, BuyAction; it does not get the pricing spreadsheet, the supplier list, the internal playbook, or the operational flow that produces the answer. Capability is exposed; competence stays home.

6.2 The owner's agent as the knowledge firewall

The GIGI voice agent and the Tavus persona are the enforcement mechanism. When a customer — or another agent — asks a question, the answer is produced by the business's own agent, grounded on knowledge the owner curated for it, on infrastructure keyed to the owner's verified domain, gated by the owner's flags, and metered on the owner's terms. The knowledge serves the customer in the moment of the transaction and is never handed over as a corpus. Contrast the two flows precisely:

• Extractive flow (web-2 → corporate LLM): crawler ingests the site → knowledge becomes model weights → the model answers customers instead of the business → the business loses the interaction, the data, and eventually the customer.
• Sovereign flow (Agentic #Web): agent reads the declared manifest → calls the business's own agent/tools → the business answers in its own name, logs its own lead, keeps its own transaction → the knowledge never leaves.

The distinction is architectural, not contractual. A robots.txt directive is a request that an extractor may ignore; a tool interface is a boundary the extractor cannot see past, because what is behind it was never published.

6.3 Owned identity as the anti-delisting guarantee

Sovereignty also requires that visibility cannot be revoked. A business whose discovery depends on a platform's private index can be demoted, demonetized, or delisted by a policy change it never sees. On the Agentic #Web, identity is an on-chain #name the business owns outright, and rank is a stake the business controls. There is no counterparty with the power to quietly remove a business from the index, because the index is the ledger. Combined with §6.1–6.2, the result is a business that is fully discoverable and transactable by the agent economy while remaining fully in possession of itself — its name, its rank, its knowledge, its flows, and its customer.

6.4 Why this is the moat the AI-startup graveyard is missing

The well-documented failure mode of the current AI wave is the "wrapper": a startup builds a thin product on a corporate model, and the model vendor's next release absorbs it. The wrapper had no moat because it owned neither distribution nor data. The Agentic #Web's answer is to be the distribution and to anchor the data: an owned name that cannot be taken, a public bid that cannot be shadow-ranked, a declared surface that cannot be strip-mined, and an agent that answers for the business rather than replacing it. That combination is not a feature a model release can cannibalize, because it lives below the model layer — in identity, ranking, and interface — where the model companies have no tenure.

7. Comparative analysis: the Agentic #Web vs. web-2 search

The case for the Agentic #Web is not that it is a better search engine. It is that it is a different kind of object — one whose ranking is a public fact rather than a private inference, and whose surface is a contract with agents rather than a page to be scraped. We make that argument precise along two axes.

7.1 A public bid is not a private score

A web-2 rank is the output of a secret function f(page, query, context) held by the intermediary. Three properties follow from its secrecy: it cannot be audited (the business cannot verify it), it cannot be predicted (the business cannot plan against it), and it is captured by the intermediary's incentives (the same function that ranks the free result also prices the ad against it). An entire multi-billion-dollar SEO industry exists solely to estimate f.

A keyword stake is the opposite object. Rank is order(bids) where every bid is on a public ledger. It is auditable (anyone can read the stake that produces a position), predictable (a business knows exactly what it must bid to move up, and by how much), and incentive-aligned (the network operator earns from the stake itself, not from selling ads against the intent). There is no algorithm to reverse-engineer because there is no hidden algorithm — the mechanism is a sealed-bid English auction whose state is fully observable. Gaming is not merely discouraged; it is undefined, because the only lever is the bid and the bid is the ranking.

This is why the Agentic #Web can dispense with SEO-as-guesswork and replace it with two honest, priced services (CADE and BRON, §4.4–4.5) that raise a page's substance — real content, real schema, real service pages — rather than its estimated position in a black box.

7.2 A manifest is not a page

A web-2 page is a rendering for a human. An agent that wants a price, a slot, or a lead must scrape it and infer structure that was never declared. The Agentic #Web inverts this: each #portal publishes a machine manifest (JSON-LD, llms.txt, an agent-manifest, and a Model Context Protocol tool interface, §4.10). An agent does not guess — it reads a declared contract and calls declared tools. Discovery, price, availability, and the act of transacting are all first-class and typed, not reverse-engineered from markup.

7.3 Side-by-side

Table 1. The two models are not competing implementations of the same thing. Web-2 search is a private intermediary that rents visibility; the Agentic #Web is an open substrate on which visibility is owned and priced in the open.

8. Comparison with prior decentralized naming systems

The Agentic #Web's registry plane also improves on the prior generation of decentralized naming — Unstoppable Domains (UD) and the Ethereum Name Service (ENS) — which decentralized ownership but not resolution, and which never built a discovery or agent layer at all.

Table 2. Prior blockchain naming systems decentralized the record but left resolution on centralized RPC providers (Infura et al.) and never answered "how does anyone find these names?" The Agentic #Web treats naming, resolution, ranking, and the agent interface as one system: the name is identity, the stake is rank, the node network is resolution, and the portal is the interface.

The capitalization property is worth noting for usability: a #name preserves the owner's chosen casing (#SaveTheWhales) while resolving case-insensitively — any casing a user types reaches the same owner, and the display always shows the owner's brand form.

9. Working model and results

The system described here is not a proposal. Every plane and most subsystems are deployed and serving live traffic; this section reports the working model.

The registry plane is live. Two bare-metal k3s clusters (production and staging) have run the ~40-service hashtag.space backend for well over a year of continuous uptime, under ArgoCD GitOps, serving api.hashtag.space, the hashtag.space front-end, and a set of white-label registrar domains. The HDNS/HTS contracts run on Optimism; keyword staking and $SPACE rewards are live on-ledger.

The agentic plane is live. hashtag.org serves a network of #portals, each with an owner-verified content URL, an embedded GIGI voice agent and optional Tavus video persona, refreshable data layers, and a machine manifest. The Model Context Protocol server at https://hashtag.org/api/mcp is deployed and callable; CADE and BRON are provisioned for production tenants; the Forge/SEVEN builder produces live sites; the keyword auction runs in GIGI credits.

End-to-end demonstration — gamebling.hashtag.org. A complete, independently useful product — a skill-wagering clearing house — was built on the Agentic #Web substrate and now serves as a reference implementation of the full stack on a single domain. It carries the entire conformance surface end to end: one Organization + WebSite JSON-LD graph with URL-fragment @ids, per-page structured data (VideoGame, BlogPosting, FAQPage, BreadcrumbList), a dynamic llms.txt that indexes the site's own content for AI crawlers, a complete sitemap, the CADE content bridge (blog / FAQ / author pages that render from the hub feed with full schema), the BRON service-page engine, and the GIGI portal agent embedded on every page and wired to the verified #gamebling portal. It is a live existence proof that a business can stand up a fully agent-readable, portal-backed, self-describing presence on this substrate with no dependence on a web-2 search intermediary for discovery.

The reference platform — seolocal.net. seolocal.net is not a demo; it is a real search-marketing company that has operated since the early 2000s and is now the reference implementation of the content-and-authority engines. It runs the canonical feed the whole network copies — published blog posts, an FAQ library, an author profile, and a full set of BRON service pages (local-SEO, agency, medical, and legal service pillars, plus the white-label SEO and SEO reseller pages that sell the platform to other agencies). Its evolution is itself the thesis of this paper: a two-decade SEO firm concluding that optimizing for a secret Google ranking is a dead end, and re-platforming into AI-SEO / AEO / GEO — optimizing to be read and cited by AI answer engines and agents — on exactly the transparent, machine-readable substrate described here. What seolocal.net sells to resellers and end users is access to that substrate: the same CADE content, BRON service pages, schema, and agent-readability that make a business legible to the models that are replacing the ten blue links.

The intents layer is live. The wants-and-offers feed of §4.11 is deployed on hashtag.org: portals broadcast intents through their own surface or the post_intent MCP tool, agents query them spatially and subscribe to the live stream, and the layer is advertised on the network's agents.json, llms.txt, and every portal's agent manifest.

The developer surface is shipped. The "GIGI in your repo" bundle installs the hashtag-network MCP server into any repository so a coding agent (Claude Code, Cursor) can search the network and act on a user's behalf from inside the editor; the hashtagspace.hashtag-search VS Code / Cursor extension ("Search the Agentic Web") is published as a VSIX; and the Chrome extension resolves #names and surfaces staked results in the browser.

Multi-tenant reseller in production. The platform already operates as multi-tenant Website-as-a-Service: client sites run on the same machine, each with its own #portal, its own embedded GIGI, and CADE/BRON provisioning — the concrete proof that the GIGI-node reseller model (§4.8) is operable, not hypothetical.

Taken together, these deployments show a working discovery-and-commerce loop that begins at an owned #name, ranks by a public keyword bid, renders an agent-readable portal with generated content and schema, exposes a typed MCP interface, and lets an autonomous agent go from "I need X" to a completed action — none of it routed through, or dependent on, Google or Bing.

10. The adoption path: from a web-2 site to an agentic presence

A standard worth adopting must be nearly free to adopt. The migration ask for an existing web-2 business is deliberately minimal, and every step past the first is automated.

Step 0 — announce (three lines, no rebuild). An owner who wants to keep their existing site unchanged adds three lines to their <head>: a <link rel="agent-manifest"> pointing at their portal's manifest, a <link rel="llms"> pointing at their portal's llms.txt, and an ai-agent meta pointing at their portal's live AI-call endpoint. The site stays exactly as it was; every crawler and agent that visits now learns there is a richer, typed surface to query. This is the entire migration cost.

Step 1 — own the name. Buy the #name (a one-time fee). This mints the on-chain identity, creates the #portal, places the business on the ranked list, enables its domain in the backlink engine, and stakes its first five keywords free.

Step 2 — stand up the surface. Either point the portal at the existing site, or have a site generated: create_site claims <name>.hashtag.org and the builder produces a site that is born conformant — schema, anchors, llms.txt, and the embedded agent included — from a plain-English brief, by voice (SEVEN) or by the owner's own coding agent.

Step 3 — turn on the engines. install_bron_cade enables the content engine (blog, FAQ, author profiles, injected Organization schema) and the service-page/backlink engine on the site. From this point the site accrues substance on a schedule without the owner writing anything.

Step 4 — activate the agent and stake the topics. activate_site turns on the GIGI voice agent (and optionally the Tavus video persona); grant_keywords stakes the topics the business wants to rank for, at bids the owner chooses and can read on the ledger. The my_setup tool walks an owner (or the owner's AI) through exactly this ladder, one nextStep at a time.

The end state, reached in an afternoon: an owned identity, a public rank, a self-updating content surface, and a 24/7 agent — with the owner's knowledge still entirely the owner's (§6).

11. Roadmap: from directory to living market

The deployed system (§9) makes every portal discoverable and callable. The specified-and-in-progress layers make the network transactive on its own:

1. Wants & offers (intents) — SHIPPED (§4.11). The PortalIntent broadcast layer is live: owners and their agents post wants and offers the whole network can read.
2. Spatial intent query — SHIPPED (§4.11). find agents within X km wanting/offering Y is live at /api/network/intents and as the query_intents MCP tool.
3. The live intent stream — SHIPPED (§4.11). The server-sent-events exchange floor is live at /api/network/intents/stream.
4. Agent payments. x402-style micropayments per tool call, so a visiting agent pays for an expensive data pull or a slice of human time without a human in the loop; GIGI credits stay the stable unit above $SPACE settlement.
5. Agent-to-agent escrow. Two portal agents agree on a deal; the network holds funds until both signal completion.
6. The reputation graph. Portals rate the agents and owners they transact with; the rating is readable in the manifest before the next agent transacts.
7. The match engine. When a want lands within range of a matching offer, both agents are notified — a market that clears itself.
8. Federation. The manifests are standard JSON-LD, so other identity networks (ENS profiles, Farcaster, ActivityPub) can read a #portal as a native record — turning the substrate from a destination into a layer other networks consume.
9. Agent-visit analytics. Distinguishing AI-agent traffic from human and crawler traffic per portal: which agents visit, how often, and what they did — the network's own demand-side telemetry.

Each of these compounds the moat of §6: the more of the transaction loop that lives on owner-controlled rails, the less of it can be absorbed by an extractive intermediary.

12. Discussion and limitations

Network effects and the cold-start problem. The Agentic #Web has the classic two-sided structure: agents are most useful where portals are dense, and portals are most valuable where agents visit. The working model addresses this by making the supply side cheap and automatic — a business gets a portal, a generated site, content, schema, and an agent for the price of a #name (§10) — and by meeting agents on infrastructure they already use (MCP, JSON-LD, llms.txt), so a visiting agent needs no bespoke integration. The remaining lever is demand density, which grows as coding agents ship the MCP harness into more repositories, as the editor and browser extensions spread, and as reseller nodes (§4.8) bring their own audiences.

Honest limitations. (i) Browser-side resolution of #names still benefits from an extension until native resolvers are ubiquitous; the plugin is a bridge, not the end state. (ii) The transparent-bid model resists algorithmic gaming but introduces auction dynamics (bid inflation on hot keywords) that the reward and content layers must balance against substance. (iii) Token and credit mechanics interact with jurisdiction-specific regulation, handled at the application layer's compliance rail rather than in the protocol. (iv) The strongest agentic-commerce features (intent matching, escrow, reputation) are the least mature; §9 reports what is deployed today and §11 marks what is specified but not yet fully shipped.

13. Conclusion

The web-2 model of discovery puts a single, secret, advertising-funded intermediary between a business and the people looking for it. That arrangement was tolerable when the reader was a human with patience for ten blue links. It stops working once the reader is an autonomous agent that needs a declared price, a callable tool, and a rank it can trust.

The Agentic #Web replaces the intermediary with two open primitives. Identity becomes an owned #name on a decentralized registry. Rank becomes a public bid on a keyword: auditable, predictable, and free of the ad-auction conflict of interest. On top of that registry, each identity becomes a live, machine-readable #portal, with an embedded AI representative, automatically generated content and schema, and a standard Model Context Protocol interface that lets any agent read the business and act on it. The developer surface (a Chrome extension, a VS Code / Cursor extension, and an MCP harness that drops into any repository) puts the network one import away from every coding agent, and the reseller tier lets anyone operate a branded node and sell the content engines as their own.

The system is deployed. Two clusters have run the registry backend for over a year. The agentic platform serves live portals. A full reference product (gamebling.hashtag.org) demonstrates the entire conformance surface end to end, and the MCP server, the extensions, and the reseller model are in production. The result is a working discovery-and-commerce loop, from an owned name through a transparent bid to an agent-readable portal to a completed transaction, that needs no permission from, and pays no rent to, Google, Bing, or any other web-2 conglomerate. The chrome of the next internet is a #.

14. Frequently asked questions

What is the Agentic #Web? An open, deployed alternative to centralized web-2 search: a decentralized #name/#keyword registry (hashtag.space), an agentic application platform that turns each name into a machine-readable #portal with its own AI agent (hashtag.org), and an AI-SEO/AEO/GEO content-and-authority platform (seolocal.net). Discovery, ranking, content, and transactions all run on open, owner-controlled rails instead of a private index.

How can a ranking based on paid bids be fairer than Google's? Because it is public. Google's rank is a secret score you can neither audit nor predict, sold against by the same company's ad auction. A keyword stake is an open ledger entry: every result carries the bid that ranked it, the rule is published, and anyone can out-stake to move up. Paid-but-transparent beats free-but-opaque — and the "proof" signal (real listed products and services) ranks above raw claims.

What do I actually get when I buy a #name? A permanent, censorship-resistant on-chain identity (one-time fee, no annual rent beyond a $1 dead-man's-switch), a #portal on the ranked network, your first five staked keywords free, your domain enabled in the backlink engine, and the on-ramp to a generated website, automated content, and your own 24/7 AI agent.

Will my business data end up training some AI company's model? That is precisely what this architecture prevents. Your #portal publishes a declared surface — what you offer and what an agent may ask you to do — while your knowledge, pricing logic, and operational flows stay behind your own agent, on your own terms. Agents transact with you; they do not ingest you. See §6, the sovereignty moat.

What is GIGI? The network's embeddable AI concierge: a voice agent (and optional Tavus video persona trained on the owner) that answers on a business's website and portal 24/7, grounded on knowledge the owner curates. It is embedded with one script tag and gated to the owner's verified domain.

What are CADE and BRON? The two substance engines. CADE generates and serves schema-marked content — blog articles, FAQs, author profiles, and injected JSON-LD. BRON builds the service-page and backlink layer — topical pillar pages plus a guard-railed, white-hat link-acquisition network. Together they raise what a site is, not what a black box guesses about it.

Can I sell this under my own brand? Yes — that is the GIGI-node reseller program: run the directory interface on your own domain, keep 30–50% recurring commission on every #name and keyword subscription your users buy, and sell agent activation, CADE, and BRON as your own upsells. seolocal.net operates the same model for AI-SEO/AEO/GEO services.

How is this different from ENS or Unstoppable Domains? Those systems decentralized name ownership but left resolution on centralized RPC providers and never built discovery or an agent layer. The Agentic #Web treats naming, resolution, ranking, and the agent interface as one system — stakeholder-run resolution nodes, a native ranked ecosystem, and a typed agent surface per name (§8).

How do AI agents actually use the network? Through open standards they already speak: the Model Context Protocol server at hashtag.org/api/mcp (search, act, buy, book), per-portal agent manifests and llms.txt, and the well-known registry files. A coding agent gains the whole network with a two-file drop-in; no key is needed to discover and act for a user.

How do I start? Buy your #name, then let the onboarding ladder walk you (or your AI) through it: point or build your site, turn on CADE and BRON, activate your agent, and stake the keywords you want to own. The whole path is in §10 and takes an afternoon.

References

1. Hashtag Space. OFFICIAL White Paper (Technical Specification), 2024. HDNS/HTS architecture, hashtag minting, keyword staking, $SPACE token, and distributed resolution.
2. Anthropic. Model Context Protocol (MCP) Specification, 2024–2025. Universal protocol for agent–tool discovery and invocation.
3. Schema.org / W3C. JSON-LD 1.1 and the Schema.org vocabulary. The machine-readable structured-data lingua franca crawlers and LLMs read natively.
4. llms.txt — the de-facto convention for LLM-readable site summaries.
5. Coinbase. x402 — HTTP-native agent-to-API micropayments; and agent-commerce protocols (ACP) for agent-to-agent settlement.
6. Optimism. OP Stack / Ethereum L2 — settlement layer for the HDNS/HTS contracts and $SPACE.
7. ArgoCD / Kubernetes (k3s). GitOps continuous delivery for the hashtag.space service mesh.
8. hashtag.org. Agentic Internet Strategy and Agentic Web Implementation (internal design notes), 2026. Agent-manifest, per-portal MCP, wants/offers intent feed, spatial query API.

Appendix A — Glossary

• #name / #domain — a hashtag domain minted as an NFT; permanent, owner-controlled identity.
• #portal — the live application-plane representation of a #name: map presence, AI agent, data layers, and machine manifest.
• HDNS / HTS — Hashtag Domain Naming Service (registration, records, keywords, resolution) and Hashtag Token Service (distribution, vaults, rewards, treasury).
• Keyword staking — attaching keywords to a domain and bidding on them; rank is the public order of bids.
• $SPACE — the utility token that prices name ownership, keyword prominence, and resolution capacity, and funds reward pools.
• GIGI credits — the stable application-layer accounting unit for day-to-day spend above $SPACE.
• GIGI — the embeddable AI voice concierge that represents a portal owner.
• CADE — the content-and-schema engine (blog / FAQ / author profiles + JSON-LD injection).
• BRON — the service-page and backlink engine.
• Forge / SEVEN — the AI site builder and the operator agent behind Website-as-a-Service.
• MCP harness — the "GIGI in your repo" bundle that installs the hashtag-network MCP server into a codebase.