What you'll build

Overview

In this tutorial you’ll deploy a small AI code-review agent on Render, twice — each time as a full stack via a Blueprint. Pattern 1 provisions a web service and a Postgres database. Pattern 2 adds a background worker and a Key Value queue on top of its own web service and database. Both stacks stay up so you can compare them side by side. The agent code is identical in both. The only thing that changes is where the work runs.

This is the deployment half of the Workflow Agents Workshop. Use the TypeScript or Python track. The follow-up tutorial, Run AI agents as Render Workflows, takes the same agent and runs it on Render Workflows.

The agent

The agent reviews a public GitHub pull request. It runs a fixed pipeline:

flowchart LR
  pr(["GitHub PR URL"])
  prep["prepare diff<br/>fetch per-file patches"]
  filter["filter diff<br/>drop lock files + bundles"]
  sec["security"]
  perf["performance"]
  ux["ux (frontend only)"]
  judge["judge<br/>approve / request-changes"]

  pr --> prep --> filter
  filter --> sec
  filter --> perf
  filter --> ux
  sec --> judge
  perf --> judge
  ux --> judge

• The prepare-diff step fetches the changed files from a public PR through the GitHub API.
• The filter-diff step drops noise such as lock files, minified bundles, and source maps before any tokens are spent. It returns the kept patches plus the list of dropped files, so the decision is visible in telemetry.
• security and performance always run. ux joins only when the diff touches frontend files. judge consolidates the findings into an approve or request-changes verdict.

The whole agent lives once in shared/agent and is imported unchanged by every pattern.

Repo layout

The workshop repo is a monorepo. Three packages each implement one runtime pattern, and three shared modules supply the code every pattern reuses.

workflow-agents-workshop-ts/
├── packages/
│   ├── naive-agent/
│   │   └── server.ts           # HTTP handler that awaits the review in-process
│   ├── queue-agents/
│   │   ├── web.ts              # Web tier (producer) — enqueues jobs, streams progress via SSE
│   │   ├── worker.ts           # Background worker (consumer) — pulls jobs off the Valkey stream
│   │   └── kv.ts               # Valkey stream + pub/sub helpers (XADD, XREADGROUP, XACK)
│   └── workflow-agents/
│       ├── server.ts           # Gateway — turns PR submissions into Render Workflow runs
│       └── workflow.ts         # Workflow service — auto-discovers and registers task definitions
├── shared/
│   ├── agent/                  # The review pipeline, imported unchanged by every pattern
│   │   ├── review.ts           # Re-exports and types for the pipeline composition
│   │   ├── agents.ts           # Agent definitions (security, performance, ux, judge)
│   │   ├── prepareDiff.ts      # Fetches per-file patches from the GitHub API
│   │   ├── model.ts            # LLM provider selection (or mock model when no key is set)
│   │   └── loop.ts             # Agent execution loop
│   ├── db/                     # Telemetry store — reviews, findings, and agent spans
│   │   ├── index.ts            # Auto-selects Postgres (DATABASE_URL) or in-memory backend
│   │   └── memory.ts           # In-memory backend for zero-setup local dev
│   └── ui/                     # Workshop dashboard served by every pattern
│       └── page.ts             # Renders the telemetry viewer HTML shell
├── package.json                # npm workspaces root
└── tsconfig.base.json

workflow-agents-workshop-py/
├── packages/
│   ├── naive_agent/
│   │   └── server.py           # HTTP handler that awaits the review in-process
│   ├── queue_agents/
│   │   ├── web.py              # Web tier (producer) — enqueues jobs, streams progress via SSE
│   │   ├── worker.py           # Background worker (consumer) — pulls jobs off the Valkey stream
│   │   └── kv.py               # Valkey stream + pub/sub helpers (XADD, XREADGROUP, XACK)
│   └── workflow_agents/
│       ├── server.py           # Gateway — turns PR submissions into Render Workflow runs
│       └── workflow.py         # Workflow service — auto-discovers and registers task definitions
├── shared/
│   ├── agent/                  # The review pipeline, imported unchanged by every pattern
│   │   ├── review.py           # Re-exports and types for the pipeline composition
│   │   ├── agents.py           # Agent definitions (security, performance, ux, judge)
│   │   ├── prepare_diff.py     # Fetches per-file patches from the GitHub API
│   │   ├── model.py            # LLM provider selection (or mock model when no key is set)
│   │   └── loop.py             # Agent execution loop
│   ├── db/                     # Telemetry store — reviews, findings, and agent spans
│   │   ├── __init__.py         # Auto-selects Postgres (DATABASE_URL) or in-memory backend
│   │   └── memory.py           # In-memory backend for zero-setup local dev
│   └── ui/                     # Workshop dashboard served by every pattern
│       └── __init__.py         # Mountable FastAPI router for the telemetry viewer
├── pyproject.toml              # uv workspace root
└── uv.lock

You only touch files inside one package at a time. The shared/ modules stay as-is throughout the workshop.

One agent, three runtime patterns

The workshop runs this agent three ways. You deploy the first two here:

The point of the exercise is the contrast. The same review, run on a richer runtime pattern, gets durability and scale you would otherwise build by hand.

Why deploy-first

You could run all of this locally. The workshop deploys instead, because the lesson is about runtime behavior on Render. A queue that survives a crash, a worker you scale to three instances, a review that finishes after you redeploy the web tier: none of that shows up on a single laptop process. Local commands stay in this tutorial as a quick fallback, not the main path.

Demo PRs

The reviewer works against any public GitHub PR. The workshop uses a small set of public demo PRs so everyone can run the same flow without creating test repos or GitHub webhooks.

Each deployed service serves the same workshop dashboard. You paste or pick a PR URL, click Review, and compare the Status, Workflow, token count, run time, findings, and spans across runtime patterns.

Before you start

Set these up first:

• A Render account. All services used in this workshop are free — Render covers the cost, so you won’t be charged anything. The workshop workspace won’t be available after today, but you can recreate these resources in your own workspace later to keep exploring.

• A GitHub account.

• The Render CLI installed and logged into the workshop workspace:

  # Install the CLI (macOS / Linux)
  curl -fsSL https://raw.githubusercontent.com/render-oss/cli/refs/heads/main/bin/install.sh | sh
  
  # Log in and select the workshop workspace when prompted
  render login

Fork the workshop repo

You deploy from your own copy so a git push redeploys on Render.

Clone your fork

Clone the repo so you have it locally for later steps:

git clone https://github.com/<your-github-username>/workflow-agents-workshop-ts.git
cd workflow-agents-workshop-ts
npm ci

git clone https://github.com/<your-github-username>/workflow-agents-workshop-py.git
cd workflow-agents-workshop-py
uv sync

By the end you’ll have two live deploys in your Render workspace and a clear sense of which one you’d reach for, and when.