Documentation Guides / Autonomous agent graphs

Site

Docs Guides

Autonomous agent graphs

For external autonomous agents, such as a Hermes-style runner, a CI bot or a custom orchestrator, OpenGantry is the CLI contract and the verify envelope. The contract is the mission YAML: scope and gate_command. The verdict is gantry verify: pass, or findings[] on failure. The executor implements code, builds missing tooling and retries; it never parses raw terminal output.

The workflow

  1. Rules. A human writes TARGET_ARCHITECTURE.yaml for the repository (Perimeters).
  2. Legislate. The mission names its scope and a gate_command, such as gantry arch check && npm test, and a Planner approves it.
  3. Verify. gantry verify --mission … --json. On failure, read findings[] from that payload.
  4. Retry. Route each finding back to the executor as a repair hop until verify exits 0. When the semantic digest of the findings repeats in the ring buffer, GXT_FINDINGS_RECURRED ends the loop.
{
  "status": "failed",
  "envelope_schema_version": 4,
  "findings": [
    {
      "failed_gate": "gate",
      "offending_file": "",
      "line": 0,
      "severity": "error",
      "resolution_hint": "gate command failed"
    }
  ],
  "gate_log_path": ".gitagent/tmp/gate-logs/MSN-0001.last.log",
  "findings_digest": "<sha256>"
}

The payload carries no gate output and no source text. The executor reads the gate’s output from the log at gate_log_path and the code at each finding’s offending_file and line.

Surfaces

SurfaceFormat
.gitagent/tmp/NEXT_REMEDIATION.jsonCompact copy of the latest failure: findings[], findings_digest, gate_log_path
gantry verify --jsonThe full failure payload with findings[] and gate_log_path
gantry verify --format sarifSARIF 2.1.0 with properties.resolution_hint
gantry verify --format junitJUnit XML (testsuites / gantry-verify)
MCP gxt_verifyThe same JSON payload as --json
@jeger-ai/opengantry/kernelverifyMission and evaluateScope in process (MCP tools and kernel)

Remote handoff

For an asynchronous pattern where a Planner legislates locally and a remote worker executes:

  1. Planner, locally: gantry legislate … --msn MSN-NNNN, tune the mission, then git commit -m "[MSN-NNNN] legislate …" modifying the mission file.
  2. Planner push: the pre-push hook runs gantry verify --mission … --pre-push. A mission whose trace rows are still placeholders passes on the Planner stamp alone.
  3. Remote worker: source scripts/gxt-runtime-env.sh <mission>, do the work, append gate output to EXECUTOR_LOG.md.
  4. Verifier, before merge: full gantry verify --mission <path>, gate and evidence.

A mission file without a Planner [MSN-NNNN] stamp still fails pre-push.

Errors for machines and humans

On a gantry runtime exec failure, a one-line human summary goes to stdout and the full JSON to stderr and .gitagent/history/.ignored-last-error.json. Orchestrators read the path from GANTRY_LAST_ERROR_FILE, which gantry runtime env sets. MCP gxt_verify returns error_code, fix_hints and next_actions (Troubleshooting).

Design notes: ADR-0032 failure envelope, ADR-0040 findings re-entry.