Skip to main content

Examples

Modulo adapts to how your team works. Here are common adoption patterns with concrete pipeline configurations.

1. Autonomous PR pipeline

A team uses Claude via BYOK (bring your own key) with pre-built agents from the Modulo community library to automate the PR lifecycle, from diff analysis through to draft description.

Flow: PR opened → fetch diff → analyze → gate on impact → draft or escalate

Pipeline config

Pipeline config
{
  "name": "pr-automation",
  "nodes": [
    { "id": "fetch-diff", "type": "connector", "connector": "github", "action": "get_diff" },
    { "id": "classify-impact", "type": "llm", "model_backend": "claude", "prompt": "Classify this PR change as low or high impact. Return only 'low' or 'high'." },
    { "id": "draft-description", "type": "llm", "model_backend": "claude", "prompt": "Write a PR description from this diff." },
    { "id": "impact-gate", "type": "gate", "condition": "{{ run_context.classify-impact == 'low' }}" },
    { "id": "post-draft", "type": "connector", "connector": "github", "action": "create_comment" },
    { "id": "request-human-review", "type": "gate", "human_only": true }
  ],
  "edges": [
    { "from": "fetch-diff", "to": "classify-impact" },
    { "from": "classify-impact", "to": "draft-description" },
    { "from": "classify-impact", "to": "impact-gate" },
    { "from": "draft-description", "to": "impact-gate" },
    { "from": "impact-gate", "to": "post-draft" },
    { "from": "impact-gate", "to": "request-human-review" }
  ]
}

What happens:

  • Low-impact PRs auto-post a draft description and finish
  • High-impact changes stop at a human review gate before progressing
  • Every action is logged immutably
  • The agent uses Claude via your own API key (BYOK)

2. Gradual SDLC migration

An existing manual SDLC team adopts Modulo one section at a time.

Phase 1 – Issue triage: Connect Linear + GitHub. An agent reads new issues, classifies them as bug/feature/question, assigns labels, and drafts an initial comment.

Pipeline config
{
  "name": "issue-triage",
  "nodes": [
    { "id": "new-issues", "type": "trigger", "trigger": "webhook", "source": "linear" },
    { "id": "classify", "type": "llm", "model_backend": "claude", "prompt": "Classify this issue as bug, feature, or question." },
    { "id": "label", "type": "connector", "connector": "linear", "action": "add_labels" },
    { "id": "draft-response", "type": "llm", "model_backend": "claude", "prompt": "Draft a helpful first response acknowledging the issue." },
    { "id": "post", "type": "connector", "connector": "linear", "action": "create_comment" }
  ],
  "edges": [
    { "from": "new-issues", "to": "classify" },
    { "from": "classify", "to": "label" },
    { "from": "label", "to": "draft-response" },
    { "from": "draft-response", "to": "post" }
  ]
}

Phase 2 – Add PR review: Insert a review agent between “PR opened” and “human reviews” events. The agent does a first pass on style, test coverage, and security-sensitive patterns before the human reviews.

Phase 3 – Full pipeline: Add release note generation, changelog updates, deployment tracking, and postmortem drafts. HITL gates guard production writes only.

3. Self-serve onboarding

A platform engineering team publishes a library of pre-built pipeline blueprints. Teams across the organization copy, adapt, and connect their own tools.

Available blueprints:

Release notes (3-node)

Pipeline config
{
  "name": "release-notes",
  "nodes": [
    { "id": "merged-prs", "type": "trigger", "trigger": "webhook", "source": "github" },
    { "id": "summarize", "type": "llm", "model_backend": "claude", "connector": "github", "prompt": "Summarize merged PRs into release notes grouped by type (feature/fix/docs)." },
    { "id": "post-to-notion", "type": "connector", "connector": "notion", "action": "create_page" }
  ],
  "edges": [
    { "from": "merged-prs", "to": "summarize" },
    { "from": "summarize", "to": "post-to-notion" }
  ]
}

Security review (5-node with HITL gate)

Pipeline config
{
  "name": "security-review",
  "nodes": [
    { "id": "fetch-changes", "type": "connector", "connector": "github", "action": "get_diff" },
    { "id": "scan", "type": "llm", "model_backend": "claude", "prompt": "Flag any security-sensitive patterns in this diff: credential leaks, SQL injection, auth bypass, dependency changes." },
    { "id": "human-gate", "type": "gate", "human_only": true },
    { "id": "create-ticket", "type": "connector", "connector": "linear", "action": "create_issue" },
    { "id": "post-comment", "type": "connector", "connector": "github", "action": "create_comment" }
  ],
  "edges": [
    { "from": "fetch-changes", "to": "scan" },
    { "from": "scan", "to": "human-gate" },
    { "from": "human-gate", "to": "create-ticket" },
    { "from": "human-gate", "to": "post-comment" }
  ]
}

Each blueprint documents expected connectors and model backends. Teams configure their own credentials in the Connector Hub and deploy with one click.

4. Compliance audit trail

An organization under SOC 2 or ISO 27001 needs auditable AI agent activity. Every Modulo run produces an immutable snapshot: input, all agent outputs, human decisions, and final artifact.

Pipeline config
{
  "name": "compliance-review-pipeline",
  "nodes": [
    { "id": "trigger-run", "type": "trigger", "trigger": "manual" },
    { "id": "fetch-input", "type": "connector", "connector": "filesystem", "action": "read_file" },
    { "id": "execute-agents", "type": "llm", "model_backend": "anthropic", "prompt": "Process the artifact according to pipeline definition." },
    { "id": "human-signoff", "type": "gate", "human_only": true },
    { "id": "log-result", "type": "connector", "connector": "filesystem", "action": "write_file" }
  ],
  "edges": [
    { "from": "trigger-run", "to": "fetch-input" },
    { "from": "fetch-input", "to": "execute-agents" },
    { "from": "execute-agents", "to": "human-signoff" },
    { "from": "human-signoff", "to": "log-result" }
  ]
}

Why this matters:

  • Export any run as JSON for compliance reviews
  • Replay a run with identical inputs to verify agent behavior over time
  • Each agent action is timestamped and attributed to a specific prompt version
  • HITL decisions (approve/reject) are recorded with reviewer identity and timestamp