Examples

Study realistic Iron Gorilla agent examples that show the public authoring model clearly.

These examples are meant to show design intent, not just syntax. They intentionally focus on the authoring model customers need to understand: scope, triggers, step boundaries, and outputs.

Support triage agent

This pattern is a good first agent because the job is clear and the output is structured enough to review.

Example

import { defineAgent, step } from '@forge/sdk';
import { z } from 'zod';

const Intake = z.object({
  customerId: z.string(),
  summary: z.string(),
});

const RoutingDecision = z.object({
  queue: z.string(),
  urgency: z.enum(['low', 'medium', 'high']),
});

export default defineAgent({
  identity: {
    name: 'support_triage',
    scope: 'dept/support',
    authority: 'support-operations',
  },
  tools: ['ticketing'],
  data: {
    permitted: ['support'],
    prohibited: ['PHI'],
    llmExcluded: ['PII'],
  },
  triggers: [{ id: 'manual-entry', type: 'manual', enabled: true }],
  workflow: ['triage_request', 'route_request'],
  trust: { initialTier: 'medium' },
  steps: [
    step('triage-request', Intake, RoutingDecision, async (input) => {
      return {
        queue: 'billing-review',
        urgency: 'medium',
      };
    }),
  ],
});

Why this is a good public example:

It has one obvious business purpose.
The trigger is explicit.
The output is structured and easy to inspect.
The example is specific without leaking runtime-only platform details.

Incident intake agent

This pattern is useful when another system notifies Iron Gorilla that something happened and the agent needs to decide what happens next.

Example

import { defineAgent, step } from '@forge/sdk';
import { z } from 'zod';

const IncidentPayload = z.object({
  incidentId: z.string(),
  severity: z.enum(['low', 'medium', 'high']),
  summary: z.string(),
});

const IntakeDecision = z.object({
  destination: z.string(),
  requiresReview: z.boolean(),
});

export default defineAgent({
  identity: {
    name: 'incident_intake',
    scope: 'dept/ops',
    authority: 'site-reliability-engineering',
  },
  tools: ['incident-routing'],
  data: {
    permitted: ['operational'],
    prohibited: ['PHI'],
    llmExcluded: ['PII'],
  },
  triggers: [
    {
      id: 'incident-webhook',
      type: 'webhook',
      signing: { algorithm: 'hmac-sha256', enabled: true },
      enabled: true,
    },
  ],
  workflow: ['classify_incident', 'route_incident'],
  trust: { initialTier: 'high' },
  steps: [
    step('classify-incident', IncidentPayload, IntakeDecision, async (input) => {
      return {
        destination: input.severity === 'high' ? 'critical-response' : 'standard-triage',
        requiresReview: input.severity === 'high',
      };
    }),
  ],
});

What to look for

The job each agent owns is narrow.
Triggers are explicit and justified.
Step boundaries are visible in the structure.
The examples show contracts you can adapt to your own workflows.

Support triage agent

Incident intake agent

What to look for

On this page