AI curriculum

Course outline for The Agent-Accessible Web

An agent can discover a website capability without having permission to invoke it. Describe and expose one local capability with typed preconditions, side-effect declarations, and explicit access checks. Compare supplied protocol material with direct APIs and browser interaction without claiming universal client support or protocol conformance.

Technology: AI-Native Web and Application Development
Duration: 6 hours
Modules: 3 · 2 hours each
Level: Level 3

About The Agent-Accessible Web

The Agent-Accessible Web Course Objectives

Compare supplied WebMCP, NLWeb, API, and browser-interface artifacts by role and support assumptions.
Describe a capability's input, output, preconditions, and side effects.
Separate observation, recommendation, and mutation capabilities.
Enforce identity, authorization, and object-version checks in a local API.
Verify that discovery does not grant mutation permission.

Pre-requisites

Web/API competence equivalent to Web Application Foundations for AI Engineers.
Agent/tool-boundary competence equivalent to Agentic AI Foundations.
Familiarity with HTTP, JSON, and structured data; interoperability and security courses provide optional depth.

Before this course

Complete the required courses or bring equivalent experience. Recommended courses add useful depth; they are not enrolment gates.

Required preparation

Recommended preparation

Understands web/API contracts and agent responsibilities before exposing discoverable, authorized capabilities.

Find your place in the learning map

Lab Setup

Computer with a browser, JSON editor, local HTTP server, and test runner.
Use mock clients, synthetic identities, supplied browser traces, and dated official protocol examples; no public deployment is necessary.
The API/catalog lab is vendor-neutral and does not require WebMCP or NLWeb support in the installed browser or client.

Detailed Course Outline

Module 1: Interface options and structured evidence

WebMCP: Compare dated supplied protocol examples by interface role and support assumptions; identify specification, client availability, and conformance questions before implementation.
NLWeb: Compare supplied natural-language interface artifacts with direct APIs and browser interaction; separate described capabilities from verified support and protocol-specific behavior.
Structured data: Describe entities, fields, and source meaning explicitly; distinguish machine-readable representation from factual correctness and permission to act.

Practical outcome: Compare supplied dated official examples for interface role, data description, and support assumptions; label protocol-specific claims requiring verification.

Module 2: Explicit capability contracts

Machine-readable interfaces: Define discoverable capability schemas, outputs, and preconditions; compare stable contracts with browser interaction that depends on page structure.
APIs for agents: Expose typed read and mutation operations through a local API; validate inputs and enforce access independently of the consuming agent.
Capability contracts and side effects: Separate observation, recommendation, and mutation; declare target versions, preconditions, and exact effects so callers can assess operational consequences.

Practical outcome: Build a vendor-neutral capability catalog and local API describing observation, recommendation, mutation, typed preconditions, version requirements, and effects.

Module 3: Discoverable but controlled access

Identity: Identify the synthetic client making a capability request; distinguish recognized identity from discoverability and permission to mutate protected records.
Authorization: Enforce operation, target, and version checks at the API boundary; require denied requests to leave protected state unchanged.
Agent discovery: Publish a capability catalog without granting invocation rights; compare discoverable metadata with independently verified authority and current client support.

Practical outcome: Test a synthetic client that can discover a capability but cannot mutate until independently authorized; reject stale writes and compare with a supplied browser trace.

Practical exercise

Submit a local capability catalog, mock client/API, access tests, and an interface decision record.
Test public discovery, an allowed read, unauthorized mutation, malformed input, and a stale-version write.
Require all denied requests to leave protected state unchanged and the valid authorized request to perform exactly its declared effect.
Run every supplied access case and identify at least two support/conformance questions before choosing a live protocol implementation.

What you will produce

Expose a discoverable local capability with independently enforced action authority.

How the work is checked

The catalog specifies roles, schemas, preconditions, versions, and side effects.
Discovery grants no mutation rights and all unauthorized or stale fixtures preserve protected state.
The decision record separates generic API behavior from unverified protocol conformance.

Six-hour local contract/access lab; named protocols are artifact comparisons, not promised conformant live implementations.

When another approach is better

A direct documented API may be simpler than adding discovery protocols for a known client.
Do not choose a protocol before verifying current specification and client support.
Browser automation remains fragile when page structure is the only available contract.

How we train

Ask about exercises, instructor feedback and the prior knowledge you need. Tool-specific courses marked provisional may become modules in a broader course.

Discuss your learning goals