Agent = the plan
A reviewable JSON definition of stages, grounding, policies and gates. It doesn’t do anything on its own.
Pipelines
Intent in,
validated work out.
A pipeline is the staged, governed flow an agent runs. The agent is the definition; the pipeline is that definition executing — observing, reasoning, acting, and always passing through validation and a human gate before any outward effect.
1
Model
Agent vs. pipeline
Pipeline = the run
The engine executing that plan on a real ticket: dispatching stages, calling tools, streaming progress and recording evidence.
2
Shape
The stages
Every pipeline follows the same governed arc. Capability stages (Source, Transform, Validate, Decide, Publish) are the concrete steps inside it. The art/data verticals run this stage spine; the Dev / engineering runtime runs a distinct 17-state governed bug-fix machine (observed → … → draft_pr_created) that stops at a draft PR — same governance, different shape. Across both, evidence carries a trust tier (trusted / internal / untrusted), and untrusted free-form text is quarantined, never executed as instruction.
3
Walkthrough
A Jira request becomes a validated output
Ground
Forge fetches the ticket; Fabric observes and reasons over it (RAG + local LLM) and builds a plan. Missing values stay unresolved, not guessed.
Sync source
Perforce syncs only explicit //GoT_Match/… paths from the ticket; a failed or unmapped file stops the run before any mutation.
Execute
The runtime does the real work — parallel Photoshop export, resize, Unity meta / ProtoDB, or character data setup — streaming stage progress over NDJSON.
Validate
Deterministic validators check resolution, naming, alpha, metadata and pipeline rules; the Harness can simulate and certify. A recorded Unity validation feeds the character definition-of-done.
Human sign-off
Live and dry runs reach an operator decision. Accept teaches positive evidence, deny/request changes teaches a correction, and Ignore is a neutral resolution for broken or irrelevant evidence.
Prepare & publish
An approved dry run can continue into a separate sealed publication approval. Forge advances the exact approved manifest through distinct delivery effects — source-control publication, destination verification, optional downstream systems, and ticket updates — so each effect has its own evidence, approval and recovery boundary.
Record
Run history, telemetry, KB facts and the durable journal close the run; the human decision becomes scoped calibration evidence.
Failure & recoveryValidation failure, unresolved stages, missing executors or denied approval stop publishing. A resolved approval requeues the exact durable job at its governed checkpoint; it never starts a second run or trusts browser-supplied evidence. The journal exposes partial effects for reconciliation. Arbitrary-stage resume remains blocked until every effect in that stage has a proven idempotency contract.
4
Delivery contract
One governed pattern, different project destinations
Forge does not assume that every project publishes through the same repository, artifact store, deployment service, sheet or ticket workflow. Each agent binds a typed delivery adapter that declares the authoritative destination and the evidence required to prove that exact delivery.
Declare delivery authority
The adapter identifies the trusted destination for that workflow: for example an immutable remote commit, an artifact-store object, a deployment receipt, or another versioned production system. A project convention belongs in its workspace skill or adapter configuration, not in the shared platform policy.
Verify immutable evidence
Completion requires the produced artifact digest to match retained destination evidence. Repository-backed delivery also verifies the immutable commit object, trusted remote visibility and reachability. A local file existing is useful evidence, but is not by itself proof of publication.
Split outward effects
Commit/push, destination verification, optional downstream publication, ticket comment and ticket transition are separate governed stages. Failure in one stage cannot be hidden inside a combined “delivery” step, and replay cannot repeat an already-proven effect blindly.
Require only selected connectors
A connector is blocking only when the compiled plan selects a capability that depends on it. Optional integrations may report warnings without blocking unrelated work; a selected unhealthy connector fails closed before its effect.
Human approval resumes work; it does not grant broad authority.
An approval is bound to one operation, one plan digest, one effect and one durable job. After approval, the worker resumes from that checkpoint and revalidates current state. Changed plans, artifacts or destination evidence invalidate the old approval.