Safe Outputs: The Most Important Pattern in GitHub's Agentic Workflows

GitHub launched Agentic Workflows. You’ve already seen the headlines: write CI/CD in Markdown, compile to Actions YAML, run Copilot or Claude Code in a container. “Continuous AI” — the agentic evolution of continuous integration.

Most of the coverage is about the surface — the gh aw CLI, the markdown-to-YAML compiler, the supported agents. That’s the feature. But buried in the security architecture docs is the design decision that actually matters: Safe Outputs.

Safe Outputs is a write-ahead log with validation gates for agent actions. The agent proposes changes. The system evaluates them through a deterministic pipeline. Only approved changes are applied. The agent never directly modifies the repository.

This is not a feature. This is a primitive. And it’s the most important thing GitHub built.

The split that changes everything

The first thing to understand about GitHub’s launch is what they chose NOT to build. Agentic workflows are explicitly not part of CI/CD. They cannot build. They cannot test. They cannot deploy. They are a parallel system.

	CI/CD	Continuous AI
Determinism	Same input, same output	Same input, different outputs
Purpose	Build, test, release	Triage, docs, quality, investigation
Failure mode	Build breaks (clear)	Agent does wrong thing (silent)
Trust model	Trust the code	Trust the code AND the model

This is the right call. Deterministic and nondeterministic workflows have fundamentally different failure modes, audit requirements, and trust properties.

But this split creates a problem: how do you let a nondeterministic system safely modify a deterministic one?

The answer is Safe Outputs.

How Safe Outputs works

The architecture has three privileged containers on the Actions runner: a Network Firewall (domain-whitelisted egress via Squid proxy), an API Proxy (holds auth tokens the agent never sees), and an MCP Gateway (isolated containers per MCP server).

But the critical piece is the output path:

Agent executes with read-only access. It can read the repo, call MCP servers, make API requests. But it cannot write.
All writes are buffered as artifacts. When the agent wants to create a PR, post a comment, or apply a label, the action is captured as a typed object in a buffer. It does not execute.
After the agent completes, the buffer is processed. A deterministic pipeline of filters, sanitizers, and analyses evaluates each buffered action.
Only approved actions are applied. The pipeline decides. The agent doesn’t.

Insight

If you’ve worked with databases, this is a write-ahead log. If you’ve worked with event sourcing, this is an event store with projections. If you’ve worked with capability-based security, this is an object-capability pattern where the agent holds a capability to propose but not to execute.

The agent lives in the nondeterministic box. It can think wrong thoughts and propose bad actions. That’s fine — the validation pipeline is deterministic. The boundary between nondeterministic intent and deterministic effect is explicit, auditable, and configurable.

Why this matters beyond GitHub

Safe Outputs is not a GitHub feature. It’s a design pattern that every agent system needs.

Consider what happens without it:

A coding agent accidentally commits an API key — leaked credentials
A customer service agent sends an email with wrong information — customer impact
A financial agent executes a trade based on a hallucination — real money lost
A deployment agent runs a destructive migration — production down

In all these cases, the failure is not that the agent reasoned incorrectly — models will always sometimes reason incorrectly. The failure is that incorrect reasoning was directly connected to irreversible effects.

The Safe Outputs pattern breaks this connection. The agent is a proposal engine. It generates candidates for action. A separate, deterministic system decides which candidates to execute.

Through the lens of the 10 Elements

Using the Elements of Agentic System Design framework I’ve been working on at Idyllic, here’s what GitHub got right and what’s missing.

What they nailed:

Agency (Element 3): Safe Outputs IS the Agency element — the translation layer from text to effects with policy enforcement.
Artifacts (Element 6): Buffered outputs are typed objects with lifecycle (proposed, validated, approved/rejected, applied).
Autonomy (Element 7): Event-driven and scheduled triggers with full context reconstruction.

What’s missing:

Evaluation (Element 8): Absent. Human review is the only quality gate. No automated measurement of whether the agent’s output was actually good.
Feedback (Element 9): Structural only. No semantic feedback. The agent doesn’t learn that its last PR comment was unhelpful.
Learning (Element 10): Not attempted. No mechanism to improve agent behavior based on past runs.

GitHub built the infrastructure for safe agent execution but not for agent improvement. The Evaluation, Feedback, Learning stack is where the frontier is.

The Dependabot incident: when the human gate fails

GitHub’s architecture relies on human review as the final gate. The Dependabot incident shows what happens when that fails.

A Copilot agent implementing a version upgrade added an inappropriate replace statement and included unrelated changes. The AI reviewer (Copilot itself) actually flagged the issues. But the human maintainer merged without reading the review.

The irony: the nondeterministic agent caught the problem. The deterministic process (human clicks “merge”) missed it.

Warning

As agent output volume increases, review fatigue increases, and the quality of the human gate degrades. You need automated evaluation — not to replace human review, but to catch the things humans miss when they’re reviewing their 50th agent-generated PR of the day.

The bigger picture

GitHub’s “Continuous AI” framing is correct: CI and AI are parallel systems, not a continuum. But the conversation is stuck on the surface.

The interesting questions are architectural:

How do you validate nondeterministic output with deterministic guarantees?
How do you measure whether agent output is improving?
How do you persist improvements across runs?
How do you coordinate multiple agents in the same repository?

GitHub built the execution layer. The intelligence layer — evaluation, feedback, learning — is wide open. That’s where the real work is.

Sources: GitHub Agentic Workflows, Ken Muse, The Register, AGENTS.md