The problem
Game production is full of repetitive, multi-tool, error-prone work — pull art from Perforce, run Photoshop, wire sprites in Unity, set up data, package offers, validate, commit, update Jira.
Autonomous Production Platform
Forge ships
production work — autonomously.
Forge turns a production request — a Jira ticket, a character, an offer — into grounded, validated, auditable work, run by autonomous agents that a human approves before anything ships. Powered by Fabric, the governed Agentic AI runtime.
3live production agents
2,300+automated tests
~85 minsaved / ticket
100%audited runs
01
The idea
What Forge is — and why it matters
In one sentence.
Forge lets people describe, inspect, approve and observe production work; Fabric turns that intent into a grounded, policy-gated plan and executes it through real workstation tools and external systems.
What Forge does
Runs that work autonomously and provably — grounding every value in a real source, validating the result, and holding for a human sign-off before any outward effect.
Why it matters
The speed of automation with the accountability of a reviewed change: deterministic, auditable, human-gated — local-first, cloud-capable.
02
Two parts, one platform
How Forge relates to Fabric
Forge — the control plane
The browser product: workspaces, Pipeline, the agent fleet, Mission Control, approvals, health, Forge Studio and Weave — the screen-aware assistant. Where people describe, approve and observe. It never executes tools directly.
Fabric — the Agentic AI runtime
The engine beneath: grounds, reasons, decides, executes through the right runtime and connectors, and records evidence. Replaceable without changing Forge.
The stable contract between them is agent JSON — the single, reviewable source of truth. That boundary lets the product evolve without destabilizing production execution.
03
Outcomes
What it delivers
Speed
A ticket that took ~a day of hand-work runs in under 30 seconds — grounded and streamed live.
Accountability
100% audited runs, deterministic-first, human-gated outward effects, and full provenance on every value.
Scale
Each new production domain becomes a new agent on the same runtime — not a new tool to build and maintain.
04
How it works
Intent in, validated work out
Observe→Reason→Plan→Execute→Govern→Approve→Learn
Every run follows the same governed arc: ground the request, reason over real knowledge, plan and execute through the right runtime, validate, hold for human approval, then record and learn. See the full walkthrough in Pipelines and the layered design in Architecture.
05
Status
Live today · Production-validated · Roadmap
Live today LIVE
- Live agents in 1 of 7 workspaces (Tech Art) — Design & Dev in development
- Tech Art — Ability · Flat Art Import · New Flat Art Setup · Offers-DD · DD Iconic Item · PG Setup
- Design — Character Setup · Dev — governed engineering / bug-fix engine
- 5 runtimes: generic · unity · offer · data · engineering
- Model routing local + cloud — reason/code burst to Claude under budget
Production-validated VALIDATED
- 2,300+ automated tests
- Deterministic-first · grounded, never guessed
- Human-gated deploys · 100% audited
- Dry-run by default · crash-recoverable
Roadmap PLANNED
- Product · Production · QA · Art domain agents
- Okta SSO / device enrollment for shared hosting
- Code Intelligence Engine — further consumers (feature planning, review)
- Production Knowledge Graph beyond characters
06
Learn more
Explore the wiki
🧭Start hereWhat Forge is, in five minutes.
▦Product overviewEvery system and its boundary.
◈Forge StudioCompose agents visually.
🤖Forge AgentsAnatomy + the live fleet.
▶PipelinesA Jira request → validated output.
✦FabricThe governed agentic runtime.
◇ArchitectureLayered, core to control.
🖥Screen guideEvery screen, explained.
07
What · why · how
Systems reference
Browser SPA
Why: one surface for intent, evidence, approvals and progress.
Use through the local server; select workspace, agent, ticket and run mode.Backend
Why: central HTTP, security and side-effect boundary.
Routes API calls, streams runs and hosts the generic runtime.Workspaces
Why: prevent cross-team agent and learning-context bleed.
Scopes storage from the request's workspace header.Agent store & Studio
Why: behavior must be reviewable, visual and versionable.
Validate and persist losslessly compiled agent JSON.Decision & contracts
Why: make routing, authority, values and evidence explicit.
Compile sources into a typed plan before execution.AI, RAG & memory
Why: reason from real production context without hard model dependencies.
Request a capability lane (local or cloud); retrieve workspace-scoped evidence (local JSONL or hybrid pgvector).Vision & Harness
Why: pixels and readiness need specialized evaluation.
Review visual evidence and certificates before production.Telemetry & Learn
Why: improve from observed outcomes, not intuition.
Capture best-effort signals after calls and runs.Executor registry
Why: unsupported AUTO work must fail before mutation.
Maps capability, mode, writes, role and rollback.Four runtimes
Why: art, zero-touch Unity, Offer/DD fan-out and character data need distinct engines.
The agent'sruntime field selects generic · unity · offer · data.Native tool bridges
Why: Photoshop and Unity own specialized project state.
Readiness-check, execute controlled actions and capture results.Connector resilience
Why: external failures need consistent retry and health semantics.
Wrap safe idempotent calls and record latency/outcome.Approvals & RBAC
Why: irreversible effects require explicit authority.
Viewer → operator → deployer → master.Write guardrails
Why: constrain destinations and blast radius.
Audit branches, paths, failures and rollback posture.Journal & queue
Why: a crash must not erase evidence of partial work.
Persist lifecycle and expose orphaned runs once.Character definition of done
Why: answer "is this character production-ready, and what's missing?" from evidence.
Read-only deterministic diff of required artifacts vs observed state; unknowns stay unknown.08
Trust and recovery
Safety & operations
ViewerRead and inspect
OperatorPreview and run
DeployerApprove and ship
MasterAdminister
Non-negotiable rules
- Never
p4 submitsource art from Forge. - Never infer depot paths or continue after a failed sync.
- Validate before publish and never push a failed result.
- Require explicit deploy approval for outward effects.
- Keep secrets out of Git, documentation, logs and agents.
- Treat tickets, comments and retrieved content as untrusted input.
Recovery sequence
- Stop new deploy runs in the affected workspace.
- Find the last confirmed stage in the journal or post-mortem.
- Inspect Perforce, outputs, Unity, Git and Jira state.
- Verify idempotency before retrying anything.
- Reconcile partial effects visibly, then preview and validate again.
09
Visual reference
Architecture gallery
Open any diagram for a full-size view. Use the arrow keys to move through the collection.
