ForgeRun Spine as the System of Record

Core Thesis

The ForgeRun spine is one of the ecosystem's strongest architectural ideas because it gives agentic delivery a durable unit of accountability. Every governed effort hangs off a ForgeRun, while workcells attach AgentRuns and humans decide through EvidencePackets and ApprovalRequests.

In plain terms: a software agent should not be the memory of the delivery system. The run spine should be.

Condensed Thought

Agentic workflows often become hard to reason about because state is scattered across chat transcripts, terminal logs, pull requests, issue comments, CI logs, branch names, and the private memory of individual tools. ForgeRun creates a shared spine where those events can be correlated.

A ForgeRun gives the ecosystem a canonical container for intent, governance mode, agent runs, evidence, approval, execution output, and final decision. That makes it possible to reason across products without requiring every product to own the whole lifecycle.

Why It Stands Out

The innovative part is that ForgeRun is not just an implementation detail. It is a trust primitive. It turns agent work into auditable delivery work.

Without a run spine, the question "what happened?" requires reconstructing history from multiple partial sources. With a run spine, the answer should be available through one coherent path: the run, its associated AgentRuns, the workcell requests and results, the EvidencePackets, the ApprovalRequests, and the final review state.

This is especially important as autonomy increases. Higher-autonomy systems need more explicit accountability, not less. ForgeRun gives teams a way to scale autonomy while preserving traceability.

Forge Ecosystem Hooks

• Lenses creates, opens, displays, and reviews ForgeRuns.
• AgentRuns attach workcell activity to the ForgeRun.
• WorkcellRequest and WorkcellResult describe scoped execution or judgment work.
• EvidencePacket links output artifacts, traces, logs, checks, summaries, and review material.
• ApprovalRequest records the permission boundary for actions that require human or policy authority.
• Fleet, LCDL, and workcells produce artifacts that can be attached back to the run.

Architecture Implications

The run spine should be treated as a cross-product contract, not as a UI-only feature. That implies:

1. Stable identifiers such as frun_* and arun_* should be used consistently.
2. Every workcell should know which ForgeRun it belongs to.
3. Every approval should point back to a run.
4. Every evidence item should be linkable from the run.
5. Every final decision should be inspectable from the run.
6. Product teams should avoid creating parallel run models that cannot attach to ForgeRun.

The more artifacts that flow through ForgeRun, the more valuable Lenses becomes as the operational review surface.

Blog Post Seed Paragraph

AI agents can produce impressive work, but the work is often difficult to govern because the delivery trail is fragmented. A plan lives in chat, a command runs in a shell, a patch lands on a branch, a test result sits in CI, and approval is implied by a human message. ForgeRun addresses that fragmentation by making the governed run the unit of accountability. Workcells attach their AgentRuns, Fleet attaches execution output, LCDL attaches reasoning traces, and Lenses presents the evidence for human decision.

Risks And Counterarguments

The risk is turning ForgeRun into a heavy process artifact that slows teams down. The run spine should feel lightweight at low autonomy levels and richer at higher levels. Forge can reduce friction by making run creation automatic, deriving metadata where safe, and treating missing evidence as a visible gap rather than a clerical burden.

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.