Analysis 12 min read

# HTML Is Not the Point. Structure Is.

The industry is treating AI’s shift toward HTML and richly structured outputs as a UX evolution. The deeper shift is architectural. Software artifacts are turning into machine-operable execution surfaces. The output and the execution layer are collapsing into the same thing — and that dramatically expands the surface area governance has to cover.

By Theo Valmis·May 2026

## The industry thinks this is about better formatting

The current excitement about HTML-shaped AI outputs reads as continuity of a longer trend:

- raw text outputs
- markdown outputs
- HTML outputs
- interactive simulations
- agent-generated interfaces

Each step looks like a refinement of how an answer is presented. That framing is wrong, or at least incomplete. The presentation layer is the visible artifact. The interesting movement is happening underneath it.

People see this as a UX evolution. The important shift is architectural.

HTML is not the innovation. Machine-operable structure is.

## Software artifacts are becoming machine interfaces

The artifacts software teams produce — documentation, pull requests, READMEs, ADRs, scripts, tickets — were mostly written for humans. They were prose with some structure on top. The structure was a courtesy to make scanning easier.

That assumption is breaking. The same artifacts are now increasingly consumed by:

- agents that read them as input
- orchestration systems that branch on their structure
- automated workflows that key off their fields
- execution harnesses that parse them into instructions
- AI runtimes that treat them as policy

HTML matters in this story not because of how it looks, but because of what it is: structured, stateful, interactive, and machine-operable. The same is true of JSON schemas, structured tool outputs, MCP responses, and the various interactive UIs agents are starting to emit and ingest.

The transition is from raw text to structured outputs to executable environments. Markdown optimized communication between humans. The next generation of software artifacts is optimizing coordination between autonomous systems.

From passive documents to executable environments

## The boundary between output and execution is collapsing

Historically, software generated outputs, humans interpreted them, and humans executed decisions. The interpretive layer was the human.

That arrangement is rapidly changing. Agents generate outputs. Outputs trigger workflows. Workflows invoke tools. Tools mutate infrastructure. The output itself becomes part of the execution layer. The artifact is no longer a description of what could happen. It is the substrate on which what happens next runs.

Concrete examples are everywhere:

- generated CI configs that the next pipeline run actually executes
- generated workflows that orchestration systems pick up automatically
- generated infrastructure definitions that a deployer applies
- generated dashboards that agents and humans share as state
- generated interfaces that subsequent agents interact with
- generated orchestrations that route real work
- generated agent memory and state files that downstream sessions consume

AI outputs are no longer documents. They are operational surfaces. The boundary between output and execution is collapsing.

## Structured outputs expand the governance surface area

The industry assumption is that more structure means more reliability. That is partly true. Structured outputs are easier to validate at the surface level — a JSON schema can reject a malformed field, a tool-call signature can reject a wrong type.

But schema validity is not architectural integrity. More structure also means more places architectural drift can propagate.

Once governance has to cover not just generated source code but also generated CI configs, generated infrastructure-as-code, generated workflow definitions, generated dashboards, generated agent-to-agent interfaces, and generated execution metadata, the surface that needs constraints multiplies.

Generated artifact | Looks like | Actually behaves like
--- | --- | ---
CI config | Documentation of a pipeline | An executable workflow definition
Infrastructure file | A YAML description | A deployable system state
Dashboard JSON | A reporting artifact | Shared operational state for agents and humans
Agent memory | A summary file | Input policy for the next session
HTML interface | A UI render | An execution surface other agents can drive

Governance now has to extend across prompts, workflows, generated code, interfaces, orchestration layers, execution metadata, agent memory, and deployment artifacts. That is a much larger surface than “is this code change valid?”

## Context engineering does not replace governance

The dominant infrastructure narrative right now is that context engineering — better retrieval, larger windows, persistent memory — is what closes the gap between AI capability and reliable systems. Context engineering improves relevance. It does not enforce architectural constraints.

Better context retrieval cannot, by itself, guarantee:

- architectural integrity
- policy compliance
- dependency boundaries
- system invariants
- organizational constraints

The more capable the execution layer becomes, the less sufficient retrieval alone becomes. Context tells an agent what exists in the system. Governance defines what is allowed to exist in the system.

Context helps agents know what exists. Governance defines what is allowed to exist.

## Machine-operable artifacts as a category

It is worth naming the underlying object. The artifacts we are talking about here — CI configs, infrastructure files, workflow definitions, generated interfaces, agent memory, MCP responses, structured tool outputs — share a property:

They are software artifacts designed primarily for autonomous system consumption rather than human interpretation.

That is not the same as “machine-readable.” A CSV is machine-readable. A machine-operable artifact is one that another system can act on directly, often without further human interpretation. The interpretive layer that used to sit between artifact and action has thinned, and in many workflows has disappeared entirely.

Once an artifact is machine-operable, every property of that artifact becomes a property of the system that runs it. Mistakes in the artifact are mistakes in the system. The governance question is no longer “is the documentation accurate?” It is “is the artifact a valid configuration of the running system?”

## The next layer is governance engineering

The industry has been optimizing the AI stack along visible axes:

- prompts
- context windows
- tool calling
- structured outputs
- orchestration

Each of these improvements increases capability. None of them, by itself, increases the reliability of autonomous execution at scale. The bottleneck shifts from generation quality to controlling autonomous execution safely as systems scale.

That shift creates a new infrastructure layer: governance engineering. The discipline of encoding architectural intent into machine-evaluable constraints, propagating those constraints across every surface the workflow touches, and verifying outputs deterministically before they reach the running system.

The bottleneck shifts from capability to controlled autonomous execution

## The pull quotes that matter

If you only carry a handful of lines from this piece, these are the ones worth holding:

- AI outputs are becoming operational surfaces.
- The boundary between output and execution is collapsing.
- Context engineering improves relevance. Governance preserves integrity.
- Structured outputs increase capability and governance complexity at the same time.
- The more autonomous systems become, the more architecture becomes infrastructure.

## Conclusion

The current excitement about HTML prompting and richly structured AI outputs is real, but the surface framing misses what is actually shifting. The artifact and the execution layer are merging. Software is becoming a set of machine-operable environments instead of a set of human-readable documents. That changes what governance has to do, where it has to live, and how much of the system it has to cover.

The next generation of AI infrastructure will be defined not by the elegance of its outputs but by the integrity of the systems those outputs run on.

## Frequently asked questions

Isn’t this just a fancy way of describing structured outputs?+
Structured outputs are part of the story, but the shift is broader. Structured outputs make individual responses easier to consume. Machine-operable artifacts make entire workflows runnable without a human interpretive step. CI configs, infrastructure definitions, agent memory files, and generated interfaces are all examples where the artifact itself is the substrate the next action runs on. That is a different property than being well-formed JSON.
If schemas validate the output, isn’t that already governance?+
Schema validation is surface-level governance. It checks that fields and types are present and well-formed. It does not check that the artifact is a valid configuration of the running system — for example, that a generated CI config does not enable a workflow that bypasses a release gate, or that a generated infrastructure file does not introduce a dependency on a service the architecture has explicitly ruled out. Schema is form. Architectural governance is fit.
How is this different from prompt engineering?+
Prompt engineering shapes what an agent is likely to produce. Governance engineering determines whether the produced artifact is allowed to enter the running system. The two operate at different points in the lifecycle and have different failure modes. A well-prompted agent can still produce an artifact that violates an architectural constraint; governance catches that case deterministically rather than probabilistically.
Why frame this as “machine-operable” rather than “machine-readable”?+
Machine-readable means a system can parse the artifact. Machine-operable means a system can act on the artifact directly. The distinction is whether there is an interpretive layer between artifact and action. CSV is machine-readable. A Terraform plan, a GitHub Actions workflow, an MCP response that another agent executes — those are machine-operable. The governance implications of the second category are much heavier because mistakes propagate without a human checkpoint.
Related governance concepts

- Execution Surfaces

  Every place an agent can act on the running system is a surface governance has to reach.

- Governance Before Generation

  Catch architectural violations before the agent emits them, not after the artifact lands.

- Verification Contracts

  Predefined checks that prove an artifact is a valid configuration of the running system.

- Governance Propagation

  The same compiled constraints fire across every surface a workflow touches.

Related operational essays

- Why Context Alone Doesn’t Prevent Architectural Drift

  Better retrieval is not enforcement. Architectural drift survives perfect context.

- The Governance Perimeter Is Moving to the Endpoint

  As execution distributes, governance has to move with the workflow rather than the platform.

- The Emerging AI Agent Infrastructure Stack

  Where governance fits between orchestration, runtime, and verification.

- Prompt Engineering Is Not Governance

  Probabilistic shaping cannot do the work of deterministic constraint enforcement.