The Triage Agent That Files Its Own Tickets

The Scene
What SWEny Is
The Pattern: Triage to Implement
Case Study: A Service in Production
The Recipe
The Squeeze
Where to Go From Here
Resources

The Scene

Sunday morning. Phone didn't buzz. You open Linear and find three tickets filed overnight by an agent. Root causes identified, reproduction steps included, suggested fixes attached. One already has a green PR waiting. CI passed. You click merge. Done.

That's the pitch. Autonomous SRE ships as one YAML file. Here's exactly how to set it up.

What SWEny Is

SWEny is a two-layer architecture for autonomous engineering workflows:

Orchestration layer (deterministic): DAG structure, routing between nodes, retries, structured data handoffs. This layer is as rigid as a Step Function.
Agent layer (intelligent): Claude reasoning at each node, tool access via MCP, natural-language instructions. This layer is as flexible as a conversation.

The orchestration ensures workflows proceed correctly. The agents do the actual thinking. You describe what you want in plain English; SWEny figures out how to do it.

If you want the full philosophy, read The Pipeline Is Dead. This post is the practical how-to.

The Pattern: Triage to Implement

The triage workflow is a DAG with a clear flow: observe, investigate, act. Here's what it looks like:

Node Breakdown

Gather: Pull errors, stack traces, logs, recent commits, and similar issues from your observability provider.
Investigate: Identify root cause, severity, fix complexity, and novelty score.
File Ticket: Create a structured issue in your tracker (Linear/GitHub/Jira) with repro steps, root cause, and suggested fix.
Implement: Agent reads the ticket it just filed, writes the fix, runs tests.
Open PR: Push branch, open PR with description linking to ticket, request review or enable auto-merge.
Notify: Post summary to your configured channel (Slack, GitHub summary, webhook).

Edge Conditions

Novelty: Skip duplicates; increment the existing issue instead.
Actionability: Only proceed to implement if the fix is within scope (not infra, not external dependency).
Fix complexity: High-risk changes (migrations, auth, lockfiles, >20 files) suppress auto-merge and require human review.

Review-Mode vs Auto-Mode

Mode	Behavior	When to Use
`review` (default)	PR opens, waits for human approval	Production, high-stakes repos
`auto`	GitHub auto-merge when CI passes; risk gates suppress to review	Trusted repos, low-blast-radius services

Case Study: A Service in Production

Let me show you what this looks like running in production. The service is a Python FastAPI microservice that parses documents and runs geo lookups. The stack:

Observability: Loki/Grafana
Issue tracker: Linear
Source control: GitHub
Schedule: Every 6 hours via GitHub Actions

A Real Scenario

Loki surfaces a spike in 500s from a malformed input edge case. Here's what happens:

Triage agent gathers the stack trace, recent commits, and similar past issues.
Investigation: root cause is a missing null check in the parser; severity medium; novel (no existing ticket).
Files a Linear ticket with: title, description, stack trace, repro steps, suggested fix, affected file and line number.
Implement phase: agent writes the fix, adds a test case, runs pytest.
Opens PR: links to the Linear ticket, includes the diff, CI runs.
Review-mode: PR waits for a human to click merge. Or auto-mode: CI passes, merges automatically.

The ticket isn't a vague "something broke." It's a complete bug report with root cause analysis, reproduction steps, and a suggested fix. The PR isn't a guess. It's a targeted change with a test that proves the fix works.

The Recipe

Four paths to get triage running, from AI-assisted to manual.

Path 1: AI-Generated Workflow

The ultimate "describe what you want" experience:

Start the wizard

npx @sweny-ai/core new
# or if globally installed:
sweny new

The interactive picker appears. Select Custom, then describe in natural language:

Your description

Watch my Loki logs for error spikes. When you find a novel issue,
file a Linear ticket with root cause and suggested fix. Then
implement the fix and open a PR.

SWEny generates the workflow YAML, identifies which skills it needs (github, linear, loki), asks only for those credentials, and writes your .sweny.yml, .env, and optional GitHub Action. You describe; SWEny builds.

Path 2: Built-in Triage Command

For the common case, skip the workflow file entirely:

Direct command

sweny triage \
  --observability-provider loki \
  --issue-tracker-provider linear \
  --time-range 6h \
  --severity-focus errors

Runs the built-in triage workflow with your provider flags. Credentials come from .env or environment variables. No YAML required.

Path 3: GitHub Action

For production, run on a schedule:

.github/workflows/triage.yml

name: SWEny Triage

on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:

permissions:
  contents: write
  issues: write
  pull-requests: write

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: swenyai/triage@v1
        with:
          claude-oauth-token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

          observability-provider: loki
          issue-tracker-provider: linear
          linear-api-key: ${{ secrets.LINEAR_API_KEY }}
          linear-team-id: ${{ vars.LINEAR_TEAM_ID }}

          source-control-provider: github

          time-range: 6h
          severity-focus: errors
          review-mode: review
        env:
          LOKI_URL: ${{ secrets.LOKI_URL }}
          LOKI_USER: ${{ secrets.LOKI_USER }}
          LOKI_TOKEN: ${{ secrets.LOKI_TOKEN }}

The swenyai/triage@v1 action handles installation, execution, and artifact upload. You configure providers via inputs; credentials via secrets.

Path 4: Claude Code Plugin

For Claude Code users with the SWEny plugin installed (/plugin marketplace add swenyai/sweny then /plugin install sweny@sweny-official):

Claude Code slash command

/sweny:triage

Runs the built-in triage workflow from within Claude Code. Credentials from your environment. For setup, use /sweny:new which runs the same wizard as sweny new.

The Squeeze

If you're not going to set this up yourself, paste this into your coding agent:

Agent prompt

Read https://n8rs.dev/blog/the-triage-agent and set up SWEny Triage
in my repo. Run `npx @sweny-ai/core new`, select Custom, and describe:
"Watch Loki for errors, file Linear tickets, implement fixes, open PRs."
Ask me only for API keys.

Alternative for Claude Code users:

Claude Code prompt

Install the SWEny Claude Code plugin (/plugin marketplace add swenyai/sweny,
then /plugin install sweny@sweny-official) and run /sweny:new. When it asks
what you want to create, pick Custom and describe a triage workflow for
Loki and Linear.

Or even simpler:

Direct command

Run /sweny:triage with Loki and Linear. Set it up to run every 6 hours.

This post is machine-ingestible. A capable agent can implement from the post alone.

Where to Go From Here

E2E Browser Testing

Same two-layer pattern, applied to UI testing. No Playwright scripts, no CSS selectors. You describe test scenarios in YAML; an agent drives a real browser via the accessibility tree. Self-healing when the UI changes. About $0.10 per run.

Read the E2E pattern post

Marketplace

marketplace.sweny.ai is the community workflow library. Triage is one pattern. The marketplace has dozens more: PR review bots, security audits, release note generators, documentation linters, dependency update workflows, content pipelines, and domain-specific workflows contributed by the community.

Every workflow is browsable, forkable, and remixable. If you built something useful, publish it. The marketplace is how SWEny patterns spread.

Custom Workflows

The triage pattern is a template. The real power is authoring your own DAGs for any domain: data extraction, content moderation, compliance checks, customer support routing, whatever your business needs.

docs.sweny.ai/workflows has the authoring guide. spec.sweny.ai has the language specification.