The Languages of the Agentic Web

First Principles - It's easy to get lost in the sea of information and jargon about agents. At the core, agents are built on LLMs (Large Language Models), where 'language' implies text-based. To understand how to leverage them, we must learn how they are built, how they read, and how they speak.

The entry point for most people to start learning about how to build an agent is through an agentic coding platform like Claude Code, OpenAI Codex, or Cursor. Here, one of the first things that you learn is the importance of the /CLAUDE.md file or the /agents.md file. These small and typically succinct markdown files contain instructions that shape the coding agent's context window in every session.

What is Context? Context is the 'next-step' information that is fed into the AI model's context window to help it reason in any given session
What is Memory? Memory is the historical records and knowledge the agent retains across multiple sessions or time frames
What is State? State is the tracking of specific elements of a given workflow or operational layer that can be used to define progress

Across the coding layer, Markdown is the lingua franca of agents; throughout code bases, .md files are structured to help agents maintain context, memory, and state. Whether it be: CLAUDE.md/agents.md¹ as the main context loading mechanism for each session (the memory file) + the user prompts; SKILL.md files (one skill per folder) to load procedures on demand when they are called; or Subagents - with markdown files in .claude/agents/ in Claude Code, while other harnesses use other formats - to help agents spin up when they are called to execute a delegated task.

This helps shape how agents are built. When it comes to how they read and act, the layers being built around the internet are seen in:

YAML front matter for facts - ie. the 'front' facts for agents; Skills have frontmatter (name, description), Subagents have frontmatter (name, tools, models)
Markdown becomes the descriptive prose for the procedures and tasks for agents to read and act on
JSON for the contracts related to use cases like commerce

It all comes together around the code, which guides the agents in a loop to complete their task(s), whatever they may be. The three layers are: what agents are built in, what they read, and what they speak.

What Agents Read

An agent comes across your website (or this website see Rebuilding My Website for the Agentic Web) and where do they look to for official guidance on how to parse the site?

A typical website is heavy on html, css and javascript in some cases, the building blocks of the web as we know it today. An agent can read that, agents prefer markdown and related language structures: YAML is where the facts are held on the back-end, JSON-LD and the markdown surfaces are how those facts reach the agent, along with llms.txt as an index (or table of contents).

As the agentic web is being built out, the standards for exactly which file is read on a website is not yet standardized, but fundamentally these are the languages they prefer to read. For example, in the Agentic Websites - Whitespace and Opportunities, we analyzed the way Shopify is using web-root agents.md as the canonical agentic reference file for all of its merchants stores as of Q2 '26.

What agents can read and what they do read are not always the same; the llms.txt example has shed light on this, with around ~10% adoption and near zero consumption (see Agentic Websites - Whitespace and Opportunities). It's entirely possible something like /agents.md will become the canonical reference as a web-root file across the web (see How To Write an /agents.md for a Services Business); it may be a while before the search engine giants standardize how agents should read a site, but in the interim, it's still valuable to learn the basics of how agents read.

What Agents Speak

Once an agent reads and understands the context, it moves to speaking and starting to execute based on instructions specified in contracts.

This is the MCP (Model Context Protocol) layer - where specific calls execute via JSON-RPC - the predominant contract operating model for agents on the web.

The UCP (Universal Commerce Protocol) created by Shopify and Google, and the ACP (Agentic Commerce Protocol) by Stripe and OpenAI, are competing conventions when it comes to executing commerce and payments instructions across the web.

There are even agent-to-agent (A2A) contractual standards emerging for when one agent delegates a task to another.

Shopify is moving aggressively into the agentic whitespace, with examples like /.well-known/ucp for commerce discovery; the A2A protocol, on the other hand, uses /.well-known/agent.json as an agent card.

But the game is still early, nothing is written in stone and the landscape is rapidly evolving. Either way, these newly established commerce protocols are where agents will 'speak.'

What Agents Are Built In

Builders who are rolling out new agents on coding terminals are predominantly building in either Typescript or Python.

An agent is defined as a model + a harness, as outlined in Agentic Modelling - What Does it Cost to Run an Agent.

Markdown files help the agent maintain context, memory and state while the coding agents write the specific Typescript or Python code that the agents are being built in.

SDKs (Software Development Kits), harnesses (Claude, OpenAI or multiple open-source options), and the agent's loop drive the structural elements of the agentic coding session through to completion of the targeted features for the application or program.

Commerce-specific agents, for example, also use markdown at the core, not just in the code. The Skills, Subagents, and other dimensions are inside the agents that are shipped.

The instructions that shape the agent on the back-end are the same language as the files read on the front-end of the web. Thus what agents are built in is being reflected on the internet on websites and applications to make it easier for agents themselves to navigate.

The Index

Name	Layer	What it's for	Who reads or speaks it	Where it lives on this site
Markdown	Read	Descriptive prose: the article, the procedure, the instruction	Agents read it; humans write it	Every analysis, note, and page has a `.md` mirror; the record's bodies are markdown files
YAML	Read	The facts: fields and front matter	Build tooling; agents parsing front matter	The record: `record/*.yaml` (the entity, the analyses, the notes, the pages)
JSON-LD	Read	The facts in schema.org vocabulary	Search engines and agents	On every article, note, page, and hub (not the listings)
llms.txt	Read	An index of what to read	LLM crawlers that look for it	`/llms.txt`
agents.md (web-root)	Read	The site's canonical instructions for agents	Agents that fetch it; adoption is early	`/agents.md`, plus the exportable template at `/templates/agents.md.template`
AGENTS.md / CLAUDE.md (repo)	Built	Session context for a coding agent	Coding agents (Claude Code, Codex, Cursor)	`AGENTS.md` at the root of this site's repo and of cpct-lab (the standing disciplines, briefly, with pointers); `CLAUDE.md` is a one-line import of it
robots.txt / sitemap	Read	Crawl permission and the URL list	Crawlers	`/robots.txt`, `/sitemap.xml`
MCP	Speak	Callable tools over JSON-RPC	Agents with an MCP client	N/A — built, not live; `/agents.md` states no endpoint published
UCP	Speak	Commerce discovery and checkout contracts	Commerce agents	N/A — no commerce
A2A card	Speak	One agent describing itself to another	Delegating agents	N/A
OpenAPI	Speak	An HTTP API contract	Any client	N/A — form endpoint, not an API
/.well-known manifests	Speak	The discovery location for the contracts above	Agents probing a domain	N/A — no manifest
Python / TypeScript	Built	The harness and the loop	Builders	This site is JavaScript on Astro; the CPCT harness is Python (`harness/run_task.py` in cpct-lab)
Skills (SKILL.md)	Built	Procedures loaded on demand; an open standard, portable at `.agents/skills/`	Coding agents	N/A — no skills yet; CPCT's three subagents are markdown with front matter (`.claude/agents/` in cpct-lab)

The Thesis - Markdown Matters for Business

Markdown is a lightweight markup language that was originally developed in 2004 as a way to format plain text with basic symbols, rather than needing a more complex tagging system like we see with html.

Because Markdown is just plain text formatted in a lightweight manner, humans can easily write and understand it, and thus the gap between human and agentic communication is bridged.

In addition to Markdown, YAML is there to highlight the facts, JSON for the contracts and schema, and MCPs and related standards (UCP, ACP) for communication and commerce.

As we are seeing right now with 'vibe coding,' these languages are used to shape the files that guide the context, shape, and memory of agents through coding sessions. Within that framework, a fluid understanding of CLAUDE.md/AGENTS.md, Skills, and Subagents has a massive impact on the success of coding.

Given that analog, the same will probably happen on the front-end of the web as we see agentic commerce start to gain traction. Navigating websites, CMS (Content Management Systems) and various dashboards online has always been a way to abstract the complexity of the code between humans and computer programs. Agents can actually help bridge those gaps, remove the abstraction, and harness their capabilities as intended.

The Languages of the Agentic Web are the foundational layer of much of the future of commerce; however, as the standards for the agentic web evolve and consolidate around specific protocols, so will the thesis. Right now, Markdown looks to be the clear winner, but if a major platform standardizes a non-markdown format, that would upend the whole thing.

Agents speak JSON. They read markdown. The site is written in both, check for yourself.

AGENTS.md is the cross-tool standard, CLAUDE.md is Claude Code's name for it. ↩