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:
- Structured approval objects with stable identifiers.
- Scope-limited requested actions.
- Risk level and required role fields.
- Constraints and allowed action IDs.
- Evidence references needed before or after approval.
- Expiration, revocation, rejection, deferral, and execution states.
- Enforcement at the execution boundary, not only in the UI.
- 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.