Approval Is Not Chat Memory

Core Thesis

One of Forge's clearest governance insights is that approval must be a structured record, not a conversational implication. Chat can explain intent, but it should not be the authorization boundary for execution.

The phrase to preserve is: approval is not chat memory.

Condensed Thought

Agentic systems often rely on conversational consent: a human says "go ahead," the agent acts, and the system treats the chat as approval. That is fragile. It is hard to audit, hard to revoke, hard to scope, and hard to connect to risk level, role, constraints, evidence, and expiration.

Forge treats approval as an object in the Forge Run Spine, visible in Lenses. An ApprovalRequest should include the run, requested action, risk level, required role, constraints, evidence references, and expiration or revocation rules when applicable.

Why It Stands Out

This idea cuts through one of the main ambiguities of agentic workflows: permission. When an agent can inspect, propose, submit jobs, or perform implementation work, teams need to know exactly what was authorized.

Forge's approval model creates a bridge between human-in-the-loop UX and enterprise governance. It makes approval inspectable, enforceable, and reusable across products. It also makes approval modes explicit: readonly, proposal, operator, and sandboxed implementation are different levels of operational permission.

Forge Ecosystem Hooks

• ApprovalRequest is the record of authorization.
• ForgeRun links approval to the run context.
• Lenses displays approval state and human review.
• Fleet should only execute approved template jobs when the relevant approval exists.
• Workcells operate under approval modes.
• Self-Host Alpha uses an on-disk approval request in approved state to gate allowlisted local runner actions.

Architecture Implications

A strong approval model needs:

1. Structured approval objects with stable identifiers.
2. Scope-limited requested actions.
3. Risk level and required role fields.
4. Constraints and allowed action IDs.
5. Evidence references needed before or after approval.
6. Expiration, revocation, rejection, deferral, and execution states.
7. Enforcement at the execution boundary, not only in the UI.
8. Visible approval history in Lenses.

Approval should not be treated as a single yes/no switch. It should be part of the run's lifecycle.

Blog Post Seed Paragraph

A chat transcript is not an approval system. It may contain useful context, but it does not reliably encode who approved which action, under what risk level, for what scope, with what expiration, and against which evidence. Forge makes approval a record in the run spine. That shift matters because agentic software work increasingly crosses from suggestion into execution. Once an agent can run a job, mutate a branch, or prepare a pull request, permission must be explicit enough to audit and enforce.

Risks And Counterarguments

Structured approval can add friction. Forge should keep low-risk flows lightweight while making higher-risk flows explicit. The key is progressive governance: the approval burden should scale with autonomy level, execution power, data sensitivity, and blast radius.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

• Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
• Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
• Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Related

• Platform reference architecture
• Agents and workcells
• Autonomy levels

Agent contract

Allowed actions

• summarize this page for evaluation questions
• cross-reference claims via claim_ids and source_refs

Safe to infer

• the architectural boundary described here is the intended design

Do not infer

• production readiness beyond the stated maturity level
• specific vendor, customer, or benchmark commitments

Key artifacts

• forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.