Skip to main content

Gates

Gates are verification checkpoints that determine whether agent-generated code meets your quality standards. They unify all verification mechanisms into a consistent interface: static checks, test execution, CI integration, human approval, and loop detection.

What Are Gates

Think of gates as quality control stations. Code must pass through each gate before being considered complete. Gates replace the older L0-L3 verification level concept with a more flexible, configurable system. Each gate defines:
  • What to check: The verification type and configuration
  • What to do on failure: Iterate, stop, or escalate
  • When to run: Conditions for gate execution

Gate Check Types

AgentGate supports five types of gate checks:
Run L0-L3 verification checksThe classic verification levels wrapped in a gate:
gates:
  - name: code-quality
    check:
      type: verification-levels
      levels: [L0, L1]
      timeout: 120000  # milliseconds
    onFailure:
      action: iterate
Verification Levels:
LevelNameChecks
L0ContractsRequired files, forbidden patterns, schemas
L1TestsTest command execution, exit codes
L2BlackboxFixture-based functional testing
L3SanityStructural validation, coverage rules
Start with L0 and L1 for fast feedback. Add L2 and L3 for comprehensive verification.

Failure Policies

When a gate fails, the failure policy determines what happens next:

Action Types

onFailure:
  action: iterate   # Continue with feedback
  # OR
  action: stop      # Stop execution immediately
  # OR
  action: escalate  # Notify and continue
ActionBehaviorUse Case
iterateGenerate feedback, run another iterationMost verification failures
stopStop execution immediatelyCritical failures, security issues
escalateNotify stakeholders, continueWarnings, partial failures

Retry Configuration

onFailure:
  action: iterate
  maxAttempts: 5           # Max retries for this specific gate
  feedback: auto           # How to generate feedback
  backoff:
    initial: "5s"          # Initial delay before retry
    max: "1m"              # Maximum delay
    multiplier: 2          # Exponential multiplier

Feedback Options

onFailure:
  feedback: auto           # Use built-in feedback generator
  # OR
  feedback: manual         # No automatic feedback
  # OR
  feedback:
    generator: "custom-feedback-service"

Success Policies

Control what happens when a gate passes:
onSuccess:
  action: continue         # Continue to next gate
  # OR
  action: skip-remaining   # Skip remaining gates
ActionBehavior
continueProcess next gate in sequence (default)
skip-remainingSkip all remaining gates, consider task complete

Gate Conditions

Control when gates run:
gates:
  - name: expensive-check
    check:
      type: custom
      command: "npm run e2e-tests"
    condition:
      when: on-change      # Only run if files changed
      skipIf: "iteration < 3"  # Skip in early iterations
    onFailure:
      action: iterate

Condition Options

OptionValuesDescription
whenalways, on-change, manualWhen to run the gate
skipIfexpressionCondition to skip the gate

Gate Pipeline

Gates execute in sequence as a pipeline:
1

Check Condition

Evaluate if the gate should run based on condition.when and condition.skipIf.
2

Execute Check

Run the gate check (verification, CI, custom command, etc.).
3

Collect Results

Gather pass/fail status, failures, and details.
4

Generate Feedback

If failed with feedback: auto, create structured feedback for the agent.
5

Apply Policy

Execute failure or success policy (iterate, stop, continue).
6

Continue Pipeline

If not stopped, proceed to next gate.

Gate Feedback

When gates fail, AgentGate generates structured feedback for the agent:
## Verification Failed

### CRITICAL Priority
- **lint** (verification-levels): 3 ESLint errors found

### Errors
- src/auth/login.ts:45: 'password' is declared but never used
  - Suggestion: Remove unused variable or use it in the authentication logic

- src/auth/login.ts:67: Missing return type on function
  - Suggestion: Add explicit return type `: Promise<User | null>`

### Warnings
- src/utils/hash.ts:12: Consider using bcrypt instead of MD5 for password hashing

Feedback Format

interface GateFeedback {
  summary: string;         // High-level failure summary
  failures: FormattedFailure[];
  suggestions: string[];   // Actionable improvement suggestions
  formatted: string;       // Ready for agent consumption
}

interface FormattedFailure {
  type: string;            // Error type
  message: string;         // Error message
  file?: string;           // Affected file
  line?: number;           // Line number
  details?: string;        // Additional context
}

Common Gate Patterns

Basic Quality Gates

gates:
  # Fast checks first
  - name: lint
    check:
      type: verification-levels
      levels: [L0]
    onFailure:
      action: iterate
      maxAttempts: 10

  # Then tests
  - name: unit-tests
    check:
      type: verification-levels
      levels: [L1]
    onFailure:
      action: iterate
      maxAttempts: 5

  # Finally CI
  - name: ci
    check:
      type: github-actions
    onFailure:
      action: iterate
      maxAttempts: 2

Security-First Gates

gates:
  # Security must pass first
  - name: security-scan
    check:
      type: custom
      command: "npm audit --audit-level=high"
    onFailure:
      action: stop  # Never continue with security issues

  # Then quality checks
  - name: quality
    check:
      type: verification-levels
      levels: [L0, L1, L2]
    onFailure:
      action: iterate

Progressive Gates

gates:
  # Quick smoke test
  - name: smoke-test
    check:
      type: custom
      command: "npm run test:smoke"
    onFailure:
      action: iterate
      maxAttempts: 3

  # Full tests only after smoke passes
  - name: full-tests
    check:
      type: verification-levels
      levels: [L1, L2]
    condition:
      when: on-change
    onFailure:
      action: iterate
      maxAttempts: 5

  # CI only after local tests pass
  - name: ci
    check:
      type: github-actions
    condition:
      skipIf: "gatesPassed < 2"
    onFailure:
      action: stop

Human-in-the-Loop

gates:
  # Automated checks
  - name: automated-checks
    check:
      type: verification-levels
      levels: [L0, L1, L2]
    onFailure:
      action: iterate

  # Human review for sensitive changes
  - name: security-review
    check:
      type: approval
      approvers: [security-team]
      minApprovals: 1
    condition:
      when: manual  # Triggered manually
    onFailure:
      action: stop

Verification Levels (L0-L3)

For backward compatibility, here’s what each level checks:
Static checks that don’t execute code:
  • Required files: Ensure specific files exist
  • Forbidden patterns: Block secrets, keys, credentials
  • Schema validation: Validate JSON/YAML against schemas
  • Naming conventions: Enforce file/folder naming rules
contracts:
  requiredFiles:
    - package.json
    - src/index.ts
  forbiddenPatterns:
    - "**/.env"
    - "**/secrets/**"
    - "password = "
Execute test commands:
  • Test execution: Run test suites
  • Exit code checking: Verify success/failure
  • Output capture: Collect stdout/stderr
  • Timeout enforcement: Prevent hanging tests
tests:
  - name: typecheck
    command: "npm run typecheck"
    timeout: 120
  - name: lint
    command: "npm run lint"
    timeout: 60
  - name: unit-tests
    command: "npm test"
    timeout: 300
Functional testing with fixtures:
  • Fixture-based testing: Run against test data
  • Assertions: Check outputs match expectations
  • JSON schema validation: Validate API responses
  • File comparison: Compare output files
blackbox:
  - name: api-test
    fixture: test/fixtures/api
    command: "npm run build && node dist/server.js"
    assertions:
      - type: json_schema
        path: response.json
        schema: expected-schema.json
Structural validation:
  • File existence: Verify expected files created
  • Test coverage: Ensure minimum coverage
  • Pattern matching: Check code structure
  • Size limits: Prevent bloated changes
sanity:
  requiredFiles:
    - src/**/*.test.ts
  testCoverage:
    minimum: 80
    paths:
      - src/**/*.ts

Best Practices

1

Order Gates by Speed

Run fast gates first to get quick feedback:
  1. L0 (contracts) - seconds
  2. L1 (tests) - seconds to minutes
  3. Custom commands - varies
  4. L2/L3 (blackbox/sanity) - minutes
  5. GitHub Actions - minutes to hours
2

Use Appropriate Actions

  • iterate for recoverable failures
  • stop for critical/security issues
  • escalate for warnings that need attention
3

Set Retry Limits

Prevent infinite loops by setting maxAttempts:
  • Lint/format: 10+ (usually quick fixes)
  • Tests: 5-10 (may need logic changes)
  • CI: 2-3 (external system, expensive)
4

Provide Context in Feedback

Custom commands should output helpful error messages that guide the agent to fix issues.