Execution surfaces. Agents do not only write source code. They write commits, branches, PR titles, CI configs, deployment manifests, generated docs, runbooks. Each is an execution surface — a place autonomous work leaves an artifact someone or something will read. Governance that covers only source code leaves most of the agent's output ungoverned.
Concepts 8 min read · May 2026

# Execution surfaces

Source code is the obvious artifact of an autonomous run. It is also a small fraction of what the run actually produces. Each long-running agent leaves commits, branches, PR descriptions, CI configuration, deployment manifests, runbooks, generated documentation, and agent-produced configuration. Each one is a surface other systems and people read. Governance that ignores them is governance with most of the agent's output excluded.

By Theo Valmis · Published May 2026

The naive model of agent output is one file at a time, all of it source code. That model has never been right and is increasingly wrong as agents take on more autonomous work. A single PR from a long-running agent typically writes to a dozen surfaces, only a handful of which are `.py`, `.ts`, or `.go` files. Each non-code surface carries organizational intent. Each one can drift. Most do not appear in code review.

Execution surfaces is the inventory of where agent output lands. It is the prerequisite for talking honestly about governance coverage: you cannot govern what you have not enumerated.

## The inventory

A reasonable taxonomy of execution surfaces for a modern autonomous engineering workflow:

Source · tracked
Code and configuration

- Application source files
- Schema and migration files
- Feature flags and config files
- Generated client/server stubs
- Type definitions and contracts

Process · meta
Branches, commits, PRs

- Branch names and namespaces
- Commit messages and trailers
- PR titles and descriptions
- PR labels, reviewers, assignees
- Tag policy and release labels

Infrastructure
CI, deploy, runtime config

- CI workflow files
- Build and test configuration
- Deployment manifests
- Secret references and IAM rules
- Container, runtime, scaling configs

Documentation
Docs, runbooks, ADRs

- READMEs and module docs
- Runbooks and on-call notes
- ADR drafts and architectural notes
- Inline comments and docstrings
- Release notes and changelogs

Agent-produced
Plans, memory, traces

- Session plans and task lists
- Memory files and progress logs
- Tool traces and execution records
- Inter-agent handoff artifacts
- Generated workflow definitions

External
Outbound side effects

- Issue and ticket updates
- Chat and notification messages
- Calls to external APIs and queues
- Webhook payloads
- Status pages and dashboards

This is not exhaustive. A team running its own taxonomy will add and remove categories. The shape is what matters: there are categories of execution surface, each category has multiple surfaces, and each surface has its own conventions and constraints. Governance has to know which surfaces exist before it can decide which to cover.

## The coverage gap

Most teams that have built any governance at all have built it for one category: source code. The other categories operate on convention alone — "we write branch names this way," "we structure PR titles like this," "our CI workflows follow this pattern." When the only thing writing those artifacts was humans, that worked. When agents start producing them at velocity, convention stops being self-enforcing.

Typical coverage · before vs after autonomous agents
Source code
covered · tests, lint, review
Branches & PRs
partial · CODEOWNERS, naming check
CI & deploy
partial · usually convention-only
Generated docs
gap · rarely reviewed
Agent artifacts
gap · treated as ephemeral
External effects
gap · outside the repository
Bars are illustrative: a team's actual coverage map is the first artifact a serious agent governance program produces.

The pattern is consistent across teams. Source code is governed; the surrounding execution surfaces are mostly not. As long as humans write the surrounding artifacts, "mostly not" is acceptable. As soon as autonomous agents produce most of them, the same coverage map becomes structural drift.

## Why autonomous agents make this acute

Humans who break a branch-naming convention leave fingerprints. The branch shows up oddly in tooling, the PR title looks off, a teammate notices in standup. The convention is held in place by a thousand small social signals.

Autonomous agents do not provide those signals. They produce artifacts that look right: idiomatic commit messages, plausible branch names, well-formed YAML, syntactically correct ADR drafts. The artifacts that look most right are exactly the ones least likely to be reviewed — review attention is finite and naturally drifts to where something obviously looks wrong.

The result is a category of drift that is almost invisible per-PR and corrosive in aggregate: a slow rotation of every convention not explicitly enforced into whatever pattern the model finds most likely. Across enough autonomous work, the team's conventions converge to the model's defaults rather than the team's intent.

The execution surfaces with the lowest review coverage are the ones agents drift first. Not because the agent is malicious, but because no signal corrects the drift.

## How execution surfaces relate to governance propagation

Execution surfaces is the inventory. Governance propagation is the act of applying governance across that inventory. They are complementary, not redundant: the inventory tells you what surfaces exist; propagation is the discipline of ensuring each surface has the constraints it needs.

A serious governance program starts by mapping the inventory of execution surfaces for its workflows. The map is the input to propagation planning. Without the inventory, propagation defaults to whatever surfaces happen to be visible — usually source code — and the other categories drift silently.

## The architectural framing

The reason this concept matters at the infrastructure level, and not just as a checklist, is the asymmetry between how artifacts are produced and how they are read. Agents produce all the surfaces at once, in a single run. Humans and downstream systems read them in different contexts, at different times, with different attention budgets. The branch name is read by tooling. The PR description is read by reviewers and by future archaeologists. The commit message is read by `git log` archaeology and release-note generators. The CI config is read by the build system and by anyone debugging a failure. Each reader carries its own expectations.

Governance has to enforce expectations across all those reader contexts. That cannot happen if the governance system only knows about source code. Each execution surface needs its own constraint surface, and the inventory is the artifact that makes that mapping explicit.

Governance is shaped like its inventory. The execution-surfaces map determines what governance can cover; whatever is missing from the map is ungoverned by default.

## The strategic point

Autonomous engineering raises the value of structural inventories. Source code was the obvious surface when humans typed every artifact and conventions held themselves together socially. As agents take on more autonomous work, the question of "what surfaces does my workflow touch?" becomes the question of "what surfaces is my governance covering?" The answer to the first question used to be obvious. The answer to the second question requires the first to be written down.

That is what makes execution surfaces a concept rather than a list: it is the structural artifact that governance has to be planned against. Teams that map their execution surfaces can talk meaningfully about coverage. Teams that have not mapped them cannot.

## Related concepts

- AI operating layer — the coordination layer that writes to execution surfaces in the first place. Surfaces are the output side of the operating layer.
- Governance propagation — the act of applying governance across the execution-surfaces inventory.
- Governance infrastructure — the layer that has to know about every execution surface to be meaningful.
- Architectural governance — the discipline whose scope expands as the inventory of execution surfaces expands.
- Multi-agent continuity — multiple agents writing to the same surfaces, with no shared convention, is how drift compounds.
- Architectural drift — what ungoverned execution surfaces accumulate over time.

## Frequently asked questions

What is an execution surface?
Any place an autonomous agent leaves an artifact during a run. Source code is one surface; commit messages, branch names, PR titles and descriptions, CI configuration, deployment manifests, generated documentation, runbooks, and agent-produced configuration are all separate surfaces. Each one is read by something downstream — another agent, a CI system, a human reviewer, an audit pipeline — and each one carries organizational intent that can drift.
How is this different from governance propagation?
Execution surfaces is the inventory: an enumeration of where agent output lands. Governance propagation is the act of applying governance across those surfaces. The inventory comes first; the propagation is what you do with it. A team can map its execution surfaces without yet having a governance system that covers them; the inventory is what reveals the gap.
Why does this matter more for autonomous agents than for humans?
Humans who break a convention leave fingerprints: a strange commit message, a non-standard branch name, a PR description that reads off. Other humans notice. Autonomous agents leave artifacts that look superficially correct — idiomatic commit messages, plausible branch names, well-formed YAML — while quietly drifting from the team's conventions. The artifacts that look right are exactly the ones that go ungoverned by review.
What happens when governance only covers source code?
The agent's output stays inside architectural boundaries for the code itself, but the surrounding execution surfaces drift independently. Branch naming taxonomy breaks. CI config slowly mutates away from team standards. Generated documentation diverges from human-written documentation. Deployment manifests acquire patterns nobody approved. None of these are caught by code review of source files, because they live outside the source tree.
How do I produce my own execution-surfaces inventory?
Start by listing every artifact your last autonomous run produced. Then group by category: source, process, infrastructure, documentation, agent artifacts, external effects. Then mark which categories your existing governance covers. The unmarked categories are where the drift is happening, regardless of whether you have measured it yet.
Related operational essays

- The Emerging AI Agent Infrastructure Stack

  Each layer of the stack writes to its own set of execution surfaces — the inventory is what makes the coverage gap visible.

- Harness Engineering Still Needs Governance

  Harnesses produce far more than source code. Without an execution-surfaces map, most of that output is ungoverned.

- Long-Running Agents Need More Than Memory

  Long runs touch more execution surfaces than short ones, and drift compounds across all of them.

- Architectural Governance Across Heterogeneous Agents

  Multiple agents writing to the same surfaces with no shared inventory is how convention dies.