Autonomous Production Platform

Fabric ships
production work — autonomously.

Fabric 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 Intelligence, the governed Agentic AI runtime.

New user setup → Start here Product overview Explore architecture
Fabric control plane above Fabric Intelligence orchestration and production systems
3live production agents
2,300+automated tests
~85 minsaved / ticket
100%audited runs
01

The idea

What Fabric is — and why it matters

In one sentence.

Fabric lets people describe, inspect, approve and observe production work; Fabric Intelligence turns that intent into a grounded, policy-gated plan and executes it through real workstation tools and external systems.

◆

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.

◈

What Fabric 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 Fabric relates to Fabric Intelligence

Fabric — the control plane

The browser product: workspaces, Pipeline, the agent fleet, Mission Control, approvals, health, Fabric Studio and Weave — the screen-aware assistant. Where people describe, approve and observe. It never executes tools directly.

Fabric Intelligence — the Agentic AI runtime

The engine beneath: grounds, reasons, decides, executes through the right runtime and connectors, and records evidence. Replaceable without changing Fabric.

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; governed Faction Offers and 2D Iconic Item families are in qualification
  • 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
  • Fabric Intelligence Learning Studio — bounded demonstrations, semantic review, saved Task Workspaces and governed capability-gap handoff

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

  • Qualification Operations — attestor, corpus, environment and review state
  • Real Photoshop/Unity campaigns · two-host runtime proof
  • Signed distribution · Okta SSO · device enrollment
  • Product · Production · QA · Art commissioned agents
Planned — not yet shipped. See the ordered feature sequence →
06

Learn more

Explore the wiki

🧭Start hereWhat Fabric is, in five minutes. ▦Product overviewEvery system and its boundary. ◈Fabric StudioCompose agents visually. ●Learning StudioTeach and review governed workflows. 🤖Fabric AgentsAnatomy + the live fleet. ▶PipelinesA Jira request → validated output. ✦Fabric IntelligenceThe 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's runtime 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

Recovery sequence

  1. Stop new deploy runs in the affected workspace.
  2. Find the last confirmed stage in the journal or post-mortem.
  3. Inspect Perforce, outputs, Unity, Git and Jira state.
  4. Verify idempotency before retrying anything.
  5. Reconcile partial effects visibly, then preview and validate again.
Aravindh Subramanian
Aravindh Subramanian
Architect, Fabric
✉ asubramanian@zynga.com 💬 Slack
↗

Updated for 2026.9.84

New user: set up Executor

Start on this Mac

Install, configure and run your first ticket. Set the real game repository, test required connectors, and import a signed agent. Treat package install, certification review and run readiness as separate checkpoints.

Every Settings field · Complete 2026.9.7–2026.9.84 change history · Current roadmap and gates

100%

Architecture diagram