PTENES
MODULE 1.4

🚀 Production and governance

Plan compatibility, rollout, incidents, ownership, and evolution of WebMCP contracts.

6

Topics

3h

Load

Expert

Level

Operations

Type

0 of 60%
1

Define real compatibility

What is it: Browser support, experimental API, fallback, provider, and catalog version form a testable matrix.

Why learn this: A generic support claim doesn’t represent combinations users actually run.

Release candidate starting state Observed canary observable decision Governed operations verifiable result

Before modeling

Write down the person's request, the current state, and the evidence that will prove completion.

Starting error

Starting with a function name or a button produces a tool without a clear human goal.

Anticipate before opening the code

What information changes the decision? What effect needs to appear in the interface? Answer before implementing.

matrix: browser × webmcp_surface × agent_provider × journey
status: tested_at + evidence
Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

browser channel

02

feature detect

03

fallback

04

catalog version

2

Version contracts with intent

What is it: Changes to names, schemas, effects, or errors follow compatibility and deprecation policies.

Why learn this: The agent may retain old context during a rollout, requiring a predictable transition.

QuestionStrong contractWeak contract
When should you use it?The description names the intent and context.“Does things” or “manages.”
What does it receive?Only the data needed.Generic, unlimited object.
What does it return?Verifiable state and next action.Text without a protocol.
How does it fail?Code, reason, and recovery.Opaque exception.

Do

  • ✓ Use specific verbs.
  • ✓ Define the inputs.
  • ✓ State the evidence.

Avoid

  • ✗ Mix intents.
  • ✗ Accept any object.
  • ✗ Hide effects.
buscar_cursos_v1 -> deprecatedAt
buscar_cursos_v2 -> preferred
remove only after telemetry window
Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

semantic change

02

deprecation

03

dual publish

04

migration

3

Roll out progressively

What is it: Feature flags and canaries limit exposure by journey, tenant, risk, and channel.

Why learn this: Small batches produce evidence before expanding the blast radius.

1

Observe

Capture state, input, and context before taking action.

2

Decide

Validate preconditions and choose the allowed transition.

3

Run

Apply the shared rule and honor cancellations.

4

Prove

Update the interface and return a structured result.

Checkpoint

If step 2 fails, the tool doesn’t try to “make it work”: it returns an explicit recovery path.

rollout: 1% read-only -> 5% low-risk -> 25% -> 100%
rollback: disable catalog registration
Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

feature flag

02

canary

03

blast radius

04

rollback

4

Operate by SLO and error budget

What is it: Availability, task success, latency, and unauthorized effects have clear objectives.

Why learn this: The SLO connects the agent experience to the team's operational capacity.

REFERENCE CODE

SLO task_success >= 99.0%
SLO unauthorized_effects = 0
p95 tool_latency < 3s
Input

It is small, documented, and verifiable.

Execution

Reuses the application's actual rule.

Output

Lets you verify the effect and continue.

Read the code as a contract

Underline where input is validated, where the effect happens, where cancellation arrives, and where the UI is updated.

Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

SLI

02

SLO

03

error budget

04

alert

5

Prepare for incidents and a kill switch

What is it: Runbooks cover incorrect tools, loops, outages, leaks, and unexpected draft changes.

Why learn this: The response must disable capabilities quickly without disrupting the human experience.

Simulated failure

Run the scenario with missing state, invalid input, or unavailable capacity.

Expected recovery

The response explains what failed, what remains safe, and what action can continue.

Minimum test matrix

✓ reproducible happy path

✓ actionable invalid input

✓ cancellation ends the work

✓ fallback preserves the user journey

✓ interface reflects the state

✓ backend retains authorization

if (incident.severity >= 1) flags.disable("webmcp_mutations");
preserveManualJourney();
Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

runbook

02

kill switch

03

containment

04

postmortem

6

Establish ownership and governance

What is it: Product, engineering, security, and operations share decisions with defined owners and evidence.

Why learn this: The platform remains sustainable as the catalog and policies change.

Synthesis exercise

  1. 1. Explain the problem without using the name of the technology.
  2. 2. Design the before and after states.
  3. 3. Implement the smallest working proof.
  4. 4. Trigger a failure and record the recovery.
  5. 5. Deliver code, evidence, and one known limitation.

Module challenge

Deliver a production readiness review with SLOs, rollout, rollback, runbook, ownership, and change policy.

Responsible Expert criterion

The implementation must work, explain its limitations, and preserve the human path when the experimental capability is unavailable.

owner: Agent Platform
approvers: [Product, Security]
reviewEvery: 90d
evidence: evalReport + threatModel + runbook
Going deeper: evidence worth keeping

Record the input, previous state, decision made, result, and visible change to the page.

Also include a simulated failure and the observed behavior without WebMCP support.

Key Concepts

01

RACI

02

review cadence

03

exception

04

audit trail

📦 Module delivery

Deliver a production readiness review with SLOs, rollout, rollback, runbook, ownership, and change policy.

Acceptance criteria

The implementation works with WebMCP support and preserves the manual path when the API is unavailable.

Evidence

Include code, the tested scenario, the observed result, and one known limitation.

← Back to the trackValidate the final catalog →

Technical sources