Agents

A workflow,
defined as data.

An agent is a JSON-defined production workflow — the single, reviewable source of truth between authoring and execution. Its runtime selects the engine; dynamic_subagents only controls fan-out. New production work becomes a new agent on the same runtime, never a new tool.

1

Structure

Anatomy of an agent

Agent definition · ch_<agent>.json IDENTITY & ROUTING id · name · runtime · category · enabled routing — how a ticket reaches this agent generic · unity · offer · data · engineering GROUNDING sources · retrieval · spec · coverage path_map · path_rules every value bound to a real source — never invented STAGES (the pipeline spine) ObserveTransform ValidateDecide Approve type · modeexecution_mode deterministicconfidence human gate configmanual·AI·auto gatepolicy deployer OUTPUTS & PROVENANCE validation · confidence thresholds · outputs · evidence studio — canvas layout (round-trips losslessly) · created_at / updated_at

Real top-level fields: id · name · runtime · dynamic_subagents · routing · category · enabled · path_rules · unity · validation · instructions · examples · stages · path_map · sources · spec · coverage · retrieval · studio. Each stage carries id · label · type · mode · execution_mode · config.

2

Live and qualifying

The agent fleet and rollout state

The defined agent roster by workspace. The roster below is a historical capability inventory; current installed agents and readiness vary by workspace. Repository-complete and qualifying families are labelled separately; an enabled definition or passing test does not prove certification, publication, commissioning or a production run. Design's character setup and the Dev engineering / bug-fix engine are in development, not yet live.

Ability (generic · 13 stages)

Ability-icon art: Photoshop export, sprite wiring, metadata, Git → the gotm client.

Flat Art Import (unity · 11 stages)

Zero-touch flat-art import: PSD → PNG, the _full sprite pivot, and ProtoDB sprite hookup via the live Unity bridge.

New Flat Art Setup (unity · 10 stages)

Stands up a new flat-art asset end to end in Unity — import, _full pivot, ProtoDB hookup — on a character branch off development.

PG Setup (generic · 7 stages)

Proving-Grounds setup workflow: assembles the required config and assets under the same governed contract.

Offers-DD Agent (offer · 8 stages)

Parallel Photoshop, dynamic dialog, offer packaging and LiveData sync → S3.

Offers-DD (offer · 13 stages)

Expanded offer production with artifact manifests, visual review, human sign-off and sealed publication.

DD Iconic Item (offer · 8 stages)

PSD/PSB → 764×1024 opaque PNG, confidence-gated, Content Bundles row → S3.

Faction Offers — Fabric Intelligence (typed · repository complete)

Dedicated multi-faction batch production with exact Jira/Perforce lineage, source-backed Photoshop artifacts, progressive subject-aware visual review, typed Content Bundles rows, and separately approved Git, sheet and Jira effects. Qualification and lifecycle evidence remain distinct from implementation.

2D Iconic Item (typed · independently qualified)

Ticket-to-Unity family covering grounded inputs, contained create-only asset preparation, graph/reference validation, catalog/dialog/battle-intro review and sealed delivery. Its exact Unity apply adapter passed disposable-project qualification with an independently signed, digest-bound attestation. Agent publication, promotion, commissioning and every delivery effect remain separately governed.

Design Character Setup (data · 12 stages)

Champion data/config setup into the gotm client — proto, shard, strings, sprite refs, content-strip: idempotent append on a new-character branch off development, dry-run by default.

Production Operations (7 stages)

Reads production planning data, builds release/work/resource intelligence, proposes Jira actions and performs governed writeback only after approval.

Offer and DD (offer · 7 stages)

QA-oriented offer and dynamic-dialog checks with the same governed runtime contract.

Engineering Bug Fix (engineering runtime · in development)

In development, not yet live. The governed bug-fix engine: a Bugsnag/JIRA crash advances a 17-state machine (observed → grounded → planned → patching → patched → reviewing → reviewed → validating → validated → awaiting_approval → approved → committed → draft_pr_created) over typed, trust-tagged artifacts. Patch runs under a CODE_FLOOR of 0.85; validation is blocked if any required check fails. It stops at a draft PR — never a merge or deploy.

Bugsnag Fix (dev · entry point · in development)

Focused Bugsnag ingestion that routes a crash into the governed engineering run above. In development alongside the engine.

Product workspace (shell ready)

Full workspace shell — pipeline, queue, approvals, knowledge — ready to commission domain agents through Studio when its contract is defined. No live agents yet.

Art workspace (shell ready)

Full workspace shell for the Art discipline, ready to commission domain agents through Studio. No live agents yet.

3

Operations

Lifecycle, testing & failure handling

Author

Compose & ground

Build in Studio; bind sources; set stages, policies, validators and confidence thresholds.

Certify

Lint · simulate · certify

Harness produces an explainable readiness certificate; golden baselines guard regressions.

Run

Preview → approve → execute

Dry-run shows reads/writes; a deployer approves; the runtime executes and streams progress.

Monitor

Observe & learn

Mission Control, telemetry, run journal and post-mortems record every run; outcomes feed future confidence.

Failure & retryOnly transient, idempotent connector calls retry automatically. Each batch job owns its artifact manifest and terminal outcome; one failed ticket must not prevent an independent ticket from running or cause its files to be committed.
◇

Reference

Import a signed agent

  1. Get the intended .forge-agent file and publisher details from your maintainer. Select the correct workspace in Executor.
  2. Choose Pipeline → Import agent, select the file, and review its identity, version, package integrity and compatibility.
  3. If the publisher is unknown or the signature is invalid, stop and verify the source with the maintainer. Do not edit the archive to bypass checks.
  4. Complete the permitted import action. Imported definitions enter under Executor control; review the actual admission result and any retained verified certification evidence.
  5. Resolve the admission requirements shown, connector access and commissioning when required before execution. See the agent card and run contract for missing gates.

Signing protects the package bytes. A retained independent Fabric Intelligence attestation is verified separately; it is not a user-supplied certification claim. Neither signature nor attestation supplies this Mac’s credentials.

◇

Reference

Understand the agent’s state

ConceptWhat it proves
Package signatureThe package matches the signed bytes and trusted publisher identity.
CompatibilityThis Executor can understand the package format and required runtime contract.
CertificationEvidence for the exact agent revision and evaluated contract. Changed revisions require matching evidence.
CommissioningExecutor-owned permission/lifecycle gate for this installed agent.
ReadinessRequired connectors, paths, models, capabilities and safety checks are usable now.
ApprovalAuthorization for the exact proposed effect and outputs. It is not inferred from certification or chat.
CompletionVerified runtime and downstream evidence. An open PR or a green model indicator does not prove delivery.
◇

Reference

Update an installed agent

  1. Obtain the newer signed package and inspect its version and intended changes. Wait for relevant work to be idle before replacing an active definition.
  2. Use the package import/update flow and review the proposed installed-agent changes. Installed copies remain versioned; Studio edits do not silently replace them.
  3. Check certification against the new revision and the runtime’s commissioning/readiness result. Re-run validation when required.
  4. Prepare a supervised test with known inputs before production use. Keep historical runs as evidence of their original revision; do not reinterpret them as tests of the update.

Agent upgrades are authored in Studio. Re-export of an imported certified package re-verifies the retained package and preserves valid independent attestation while applying the exporting developer’s signature. This does not manufacture certification for modified code.

◇

Reference

Certified imports: ready for manual runs

A trusted package with valid independent Fabric Intelligence certification and satisfied dependencies can become ready immediately for manual governed runs, without a second commissioning step. Automatic routing and production-effect authority remain disabled. Other valid imports stay disabled/decommissioned until their admission requirements are met. Unknown, invalid or revoked signatures are quarantined.

Every update re-evaluates its own package evidence. A previous version’s certification is not inherited by changed bytes. Readiness never supplies credentials or approves the run’s external effects.