article.yaml

title: "Another Week, Another Three Agentic Standards Enter the Stage"
slug: another-week-agentic-standards
summary: "ARD, OKF, A2A, MCP — and what I've actually been building to meet them: an A2UI catalogue, an A2Knowledge pipeline, and a live study app that proves the pattern."
topic: ai-engineering

# URLs below use GitHub raw paths — flip repos public on article day
# https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/...

blocks:

  - type: body
    text: >
      There's a pattern forming. If you work anywhere near AI infrastructure right now,
      you've probably had the experience of picking up where you left off on a Friday only
      to find that three new protocols, formats, or specifications have arrived before
      Monday morning coffee.

      Google has quietly dropped something called **Agentic Resource Discovery (ARD)** — a
      specification for how AI agents should discover, evaluate, and connect to resources
      across the web. Alongside that, Google has published the **Open Knowledge Format (OKF)**
      — an open specification that formalises something many AI teams have already been doing
      informally: representing internal knowledge as a directory of markdown files with YAML
      frontmatter, portable across any system without translation. The problem OKF targets is
      real and widespread: every organisation building on AI is solving the same
      context-assembly problem from scratch, with knowledge scattered across incompatible
      wikis, proprietary metadata catalogs, and code comments no agent can reliably reach.
      OKF proposes a vendor-neutral format — just files, just markdown, no SDK required —
      so that knowledge produced by one system can be consumed by any agent without a bespoke
      integration. And underpinning all of it, A2A and MCP continue to mature as the plumbing
      layer for how agents actually talk to each other and to tools.

      This post is my attempt to make sense of where these fit — not in the abstract, but in
      the context of things I've actually been building.

  - type: divider

  - type: heading
    text: "My Conviction: Useful for Humans, Declarative for Agents"

  - type: body
    text: >
      Before I get into the specifics, the thread that runs through everything here is a
      conviction I've been stress-testing in my own work:

  - type: quote
    text: "AI needs to be useful for humans and declarative for AI agents."

  - type: body
    text: >
      These aren't two separate goals. They're the same goal expressed at two different
      layers of the stack. If the human-facing output isn't genuinely useful, the agent
      hasn't done its job. If the agent-facing specification isn't declarative and
      machine-readable, you haven't built an agent workflow — you've just written more
      glue code.

      This is the lens through which I've been approaching everything below.

  - type: divider

  - type: heading
    text: "What ARD Actually Proposes"

  - type: body
    text: >
      ARD is Google's answer to a practical problem: agents need to find things. Not web
      pages — *resources*. APIs, tools, knowledge bases, render surfaces. The spec proposes
      two complementary paths.

  - type: diagram
    url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/diagrams/ard-architecture.svg"
    caption: "ARD architecture — Catalog layer (publish side) + Registry layer (discovery side), consumed by agents via A2A, MCP, or plain API"

  - type: body
    text: >
      **The Catalog layer** is the publish side. Any resource owner can host an
      `ai-catalog.json` at a well-known path on their domain. No registration, no central
      authority. The catalog declares what you have, what it does, and how to invoke it.

      **The Registry layer** is the discovery side. An optional indexed service that crawls
      catalogs, ranks results by agent intent, and returns structured matches. Think of it
      as the difference between putting a sign on your door versus being listed in a
      directory that agents are actively searching.

      The agent at the bottom consumes from either or both, verifies identity via Trust
      Manifests, and invokes resources using whatever protocol they declare — A2A, MCP, or
      plain API.

      What I found interesting about ARD when I read it: it's not trying to replace anything.
      It's a discovery and capability description layer that sits *above* the transport
      protocols. A2A and MCP handle *how* agents communicate. ARD handles *how they find what
      to communicate with*.

  - type: divider

  - type: heading
    text: "Where My Work Fits In: The A2UI Catalogue"

  - type: body
    text: >
      A few months ago I started building what I've been calling an **A2UI catalogue** — a
      vocabulary of UI atoms that render across different surfaces. The key insight from
      Google's A2UI work was that if you express UI declaratively (as a schema describing
      *what to show* rather than *how to show it*), an agent can compose a useful, rendered
      experience without needing to understand any frontend framework.

      My catalogue currently covers four surfaces: Google Apps Script, web/blog (powering
      this site), Google Meet stage panels, and Google Chat cards. Each atom in the catalogue
      is tagged with which surfaces can render it — which matters, because surface constraints
      are real. The GAS iframe environment, for example, has limitations that some atoms
      simply don't fit.

      In ARD terms, my A2UI catalogue is a **catalog entry** that describes render
      capabilities. An agent that discovers it knows: *this resource can take a structured
      payload and return a rendered learning app, and it works on GAS, and here's the URL
      to invoke it.*

  - type: divider

  - type: heading
    text: "The Apps Script Renderer: A Pattern Worth Pausing On"

  - type: body
    text: >
      This deserves a moment because the pattern it enables is genuinely unusual.

      Google Apps Script has a constraint that, if you look at it a certain way, becomes a
      feature: the execution environment is sandboxed, the output is served from Google's
      infrastructure, and the URL is stable and shareable. What I found is that you can
      encode an entire app's content as a base64 payload in the query string. The published
      GAS app decodes it and renders the relevant atoms.

  - type: bullet_list
    items:
      - label: "One published app"
        text: "— single deployment, single URL, always current"
      - label: "N different experiences"
        text: "— each driven by a different base64-encoded payload in the URL parameter"
      - label: "No backend"
        text: "— the \"database\" is the URL itself"
      - label: "Generation in under 10 seconds"
        text: "— give an agent the atom vocabulary from the catalogue, ask it to compose a payload for a specific use case, encode it, done"

  - type: body
    text: >
      This works well for apps up to roughly 8K characters of encoded content. Beyond that,
      you'd publish a dedicated URL for that specific payload — still declarative, just not
      sharing the same entry point.

      The important architectural point: **Apps Script is just a service.** The A2UI catalogue
      is what declares it as a capability, describes what it can render, and tells an agent
      how to invoke it. Swap out GAS for another surface tomorrow, and the catalogue entry
      changes — the agents consuming it don't need to.

  - type: divider

  - type: heading
    text: "A2Knowledge: Testing the ARD Principle with a Second Catalogue"

  - type: body
    text: >
      I wanted to push the ARD concept further: what happens when you have *two* declarative
      catalogues and an agent that can compound them?

      Knowledge transfer was the use case I landed on. The inputs are always fairly standard
      — curriculum, course content, certification format — and the outputs have real human
      value. It's also a domain where the friction of current tools is obvious: PDFs,
      scattered official documents, per-student manual effort.

      So I built an **A2Knowledge catalogue**: a schema-driven pipeline that takes official
      curriculum sources, extracts competency-mapped knowledge as a structured markdown,
      validates coverage against a schema, and transforms it into an A2UI payload. The atoms
      the agent can use are the ones declared in the A2UI catalogue. The surface constraints
      are already baked in. The agent doesn't need to reason about what's renderable — the
      catalogue tells it.

  - type: pipeline
    steps:
      - "Source document"
      - "Schema YAML"
      - "curriculum.md"
      - "Suitability check"
      - "payload.json"
      - "Live app"

  - type: divider

  - type: heading
    text: "The Brevet Test Case"

  - type: body
    text: >
      My daughter is sitting the French **Brevet** — the DNB (Diplôme National du Brevet)
      — this week. I decided to use this as a live test of the knowledge catalogue pipeline.

      The DNB covers five written exam areas:

  - type: bullet_list
    items:
      - label: "Français"
        text: "— reading comprehension, grammar, dictation, extended writing"
      - label: "Mathématiques"
        text: "— geometry, algebra, statistics, problem solving"
      - label: "Histoire-Géographie + EMC"
        text: "— combined paper: contemporary history, geopolitics, civic education (Éducation Morale et Civique)"
      - label: "Sciences"
        text: "— single paper covering SVT (life and earth sciences), Physique-Chimie, and Technologie"
      - label: "Oral / Projet"
        text: "— a defended project assessed on reasoning, expression, and structured argument"

  - type: body
    text: >
      For each subject, I used official French Government curriculum sources (Bulletin
      Officiel) to define the schema — required competencies, exam format, out-of-scope
      topics. Conscious of token costs on side projects, I used a pattern I rely on often:
      **ask Claude to produce the schema and a structured prompt, then pass that to Gemini**
      (via the consumer app) to do the heavy document parsing. This keeps personal API spend
      manageable and plays to each model's strengths — Claude for structure and schema,
      Gemini for bulk content extraction.

      The result is a set of curriculum markdown files, one per subject, that any parent or
      student can use as a revision source of truth — and that an agent can compile into a
      rendered GAS study app in seconds.

  - type: callout
    style: info
    text: "**Live brevet study app (no login required):** [Open app](https://script.google.com/macros/s/AKfycbzEz1TNzeXCfjTLHbpcOUvQHxHnBFj-0l1JvuCLga7J4Gy2bEE25zHJBajvwYdetIcHuA/exec?nav=brevet-2026)"

  - type: carousel
    caption: "Brevet 2026 revision app — one GAS deployment, five subjects, built from official curriculum sources"
    slides:
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2015.15.03.png"
        label: "DNB Overview"
        subtitle: "Hub with all five exam subjects and point allocation"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.36.08.png"
        label: "Français — Les 4 Entrées littéraires"
        subtitle: "Key takeaways per literary entry type, mapped to the official programme"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.36.33.png"
        label: "Histoire — La France en République (1944-2000)"
        subtitle: "Brevet timeline atom: key dates with event detail on tap"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.36.44.png"
        label: "Géographie de la France"
        subtitle: "Flashcard drill: population, territoires productifs, aménagement"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.36.49.png"
        label: "EMC — Enseignement Moral et Civique"
        subtitle: "Three axes: Respecter autrui · Rôle de la loi · Valeurs de la République"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.37.12.png"
        label: "Sciences — Physique-Chimie"
        subtitle: "Formula flashcards: v=d/t, P=mg, U=RI, P=UI and wave physics"
      - url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/GAS%20Brevet/Screenshot%202026-06-21%2014.37.18.png"
        label: "SVT — Tectonique des plaques"
        subtitle: "Definition drill: lithospheric plates, foyer, épicentre, volcanisme"

  - type: divider

  - type: heading
    text: "Compounding Two Catalogues: The Enterprise Angle"

  - type: body
    text: >
      The Brevet is a relatable example. But let me make the enterprise case with something
      more familiar to readers here: **TOGAF**.

      The Open Group Architecture Framework is one of the more widely held enterprise
      architecture certifications globally. It has two levels (Foundation and Practitioner),
      a defined competency framework, and a published exam blueprint. It's exactly the kind
      of structured knowledge that fits the A2Knowledge pipeline.

      What the compound pattern looks like in practice:

  - type: steps
    items:
      - label: "Discover knowledge"
        text: "An agent reads the A2Knowledge catalogue — discovers the TOGAF schema, the competency list, the coverage mapping"
      - label: "Discover render surface"
        text: "It reads the A2UI catalogue — discovers the available atoms, confirms which ones are GAS-compatible, gets the invocation URL"
      - label: "Compose payload"
        text: "It composes a payload: a study app scoped to TOGAF Part 1, structured around the ADM phases, with knowledge checks mapped to the official competency IDs"
      - label: "Return shareable URL"
        text: "It encodes the payload and returns a GAS URL — no build step, no deploy, ready immediately"

  - type: body
    text: >
      The agent has produced a custom, curriculum-aligned, interactive study tool. It didn't
      hallucinate the competency framework — it read it from a catalogue. It didn't choose
      arbitrary UI components — it picked from a declared vocabulary. The result is
      deterministic and verifiable.

      This is what "declarative for agents" buys you in practice. The agent's creativity is
      bounded by what's in the catalogues. That's not a limitation — it's the point.

  - type: divider

  - type: heading
    text: "A Sidebar on Media: The Same Pattern, Applied to Images"

  - type: body
    text: >
      There's a natural extension to this catalogue pattern that I want to name, even though
      it's not something I'm building right now.

      Every time an agent needs a visual — a cover image for a study app, a diagram for a
      document, an illustration for a course — it generates one from scratch. There's no
      shared registry to check first. The same conceptual image gets generated thousands of
      times independently, with no awareness between callers.

      A media catalogue would fix this with one constraint: **the vocabulary used to generate
      the image becomes the storage key**. Not a filename, not a UUID — the semantic intent.
      An agent looking for a cover image for the Brevet exam presents its vocab
      (`"French education diploma cover, dark navy, tricolor ribbon, minimal"`) and either
      gets a cache hit or hits a gate.

      That gate is what makes it interesting. Authority rules on creation — cost policy,
      content scope, domain rules — mean the catalogue isn't just a cache. It's a governed
      resource. Agents can read freely; writes require permission.

      This isn't a hypothetical. The cover image on the `domain_brief` tab of the Brevet app
      above was generated this way: a single vocab string, passed to Imagen 3, stored with
      that vocab as the catalogue entry key. The IPTC Digital Source Type vocabulary already
      classifies *what kind* of asset a generated image is. A media catalogue uses that same
      vocabulary as the *address*.

  - type: callout
    style: note
    text: "The world doesn't have this yet. There's no standard for prompt-keyed image registries. The pattern exists in research datasets (DiffusionDB has 14M prompt-image pairs) but not as live, governed, agent-accessible infrastructure. That's the gap."

  - type: divider

  - type: heading
    text: "Going Open Source: NIST AI RMF"

  - type: body
    text: >
      After the TOGAF exercise, I wanted to push the knowledge catalogue pattern somewhere
      that had zero IP ambiguity — a fully open source knowledge domain I could publish
      without reservation. The obvious candidate: the **NIST AI Risk Management Framework
      (AI RMF 1.0)**.

      NIST AI 100-1 is a U.S. Government document. It's public domain. NIST published it in
      January 2023 and has been updating guidance around it ever since. More to the point,
      it's exactly the kind of structured, competency-mapped knowledge the A2Knowledge
      pipeline was designed for: four core functions (GOVERN, MAP, MEASURE, MANAGE), 72
      subcategories across those functions, seven trustworthiness characteristics — all
      formally documented, schema-ready, and genuinely useful to practitioners.

      Running it through the pipeline:

  - type: steps
    items:
      - label: "Schema"
        text: "`schemas/pro-cert/nist/nist-ai-rmf.yaml` — four functions as domains, each with its categories and subcategories as required competencies, with atom hints per competency type"
      - label: "Extraction"
        text: "Scraped NIST AI 100-1 from `nvlpubs.nist.gov`, read all four function tables and subcategories verbatim into `nist-ai-rmf.curriculum.md` with section tags and competency anchors"
      - label: "Transform"
        text: "Transformer read the curriculum glossary blocks and emitted 82 flashcards — GOVERN (19), MAP (18), MEASURE (22), MANAGE (13), plus trustworthiness characteristics and bias categories"
      - label: "Render"
        text: "`payloads/nist-ai-rmf.json` → `nist_airmf_page.gs` → live GAS app"

  - type: callout
    style: info
    text: "**Live NIST AI RMF reference app (no login required):** [Open app](https://script.google.com/macros/s/AKfycbySUgHU2ynyj-GMc9_oR9qiWlwCVrNSeCwFXY_JYExxIldHYnQFfqgo_vE_uUBJg2L7/exec?nav=nist-ai-rmf)"

  - type: image
    url: "https://raw.githubusercontent.com/curtiskrygier/a2knowledge/main/screenshots/NIST apps script.png"
    alt: "NIST AI RMF reference app built with A2UI atoms"
    caption: "NIST AI RMF 1.0 — 82 flashcards across GOVERN, MAP, MEASURE, MANAGE and Trustworthiness, rendered as a GAS study app"

  - type: body
    text: >
      The interesting thing about this one isn't the output — it's what the pipeline does to
      the source material. The PDF is 45 pages. The curriculum.md is the canonical, versioned,
      competency-anchored distillation of it. The GAS app is just a rendered view. If NIST
      updates the framework, you update the curriculum.md, re-run the transformer, redeploy.
      The pipeline doesn't care what the source says — it just maps sections to atoms. That
      separation between knowledge and rendering is what makes the compound catalogue pattern
      composable.

      This is also the first entry in the A2Knowledge catalogue that any other agent could
      consume with zero IP concern. The `ai-catalog.json` entry for this resource, once the
      ARD registry is live, will point to a public domain knowledge base with a declared
      render surface. Any agent that discovers it knows: *this is structured AI governance
      knowledge, it renders on GAS, and you can use it freely.*

  - type: divider

  - type: heading
    text: "Where This Is Heading"

  - type: body
    text: >
      ARD is early. Most of the interesting parts — federated registry crawling, Trust
      Manifest verification at scale, ranked intent matching — are still ahead. But the
      catalog layer works *today*, and the pattern of declaring capabilities in
      machine-readable form and letting agents discover and compose them is real and useful
      right now.

  - type: bullet_list
    items:
      - label: "A2UI catalogue"
        text: "— published, four surfaces, atom vocabulary declared"
      - label: "A2Knowledge catalogue"
        text: "— Brevet live, NIST AI RMF live, pipeline documented and open"
      - label: "ARD registry"
        text: "— static today (my own resources), query endpoint next"

  - type: body
    text: >
      The article will get more interesting when other people start publishing
      `ai-catalog.json` files. That's when ARD shifts from a pattern you implement for
      yourself to infrastructure that changes how agents navigate the web.

  - type: divider

  - type: github_repo_card
    repo: curtiskrygier/a2ui
    label: "a2ui — Atom Catalogue"
    description: "Vocabulary of UI atoms that render across Google Apps Script, web/blog, Meet stage panels, and Google Chat. The render surface for everything in this article."

  - type: github_repo_card
    repo: curtiskrygier/a2knowledge
    label: "a2knowledge — Knowledge Catalogue"
    description: "Schema-driven pipeline from any official curriculum source to a live A2UI study app. Brevet 2026 and NIST AI RMF 1.0 live. Schema system supports pro certs, national curricula, and open frameworks."

  - type: github_repo_card
    repo: curtiskrygier/ard
    label: "ard — Agentic Resource Directory"
    description: "ARD registry implementation — ai-catalog.json, agent-card.json, and registry YAML for the A2UI and A2Knowledge catalogues."

  - type: closing
    text: "The catalogues are the compound. The apps are just views."