What you'll build

In Deploy an AI code-review agent on Render you ran one agent two ways and ended up owning a file full of queue coordination. This tutorial runs the same agent a third way, on Render Workflows, where that coordination is the platform instead of your code.

The thing you hand-rolled

Pattern 2 bought you scale and durability, and the bill was a queue helper: a stream, a consumer group, blocking reads, acks, retry-on-failure, and a pub/sub progress channel. Real code you write, debug, and keep correct. No built-in trace of which agent ran where.

The primitive that replaces it

Render Workflows gives you one building block: the task. A task is a plain async function plus a small config object.

import { task } from "@renderinc/sdk/workflows";

export default task(
  {
    name: "your-review",
    timeoutSeconds: 120,
    retry: { maxRetries: 2, waitDurationMs: 1000, backoffScaling: 2 },
  },
  async function yourReview(input) {
    // ...your logic...
  },
);

from render_sdk import Retry, Workflows

app = Workflows()

@app.task(
    name="your_review",
    timeout_seconds=120,
    retry=Retry(max_retries=2, wait_duration_ms=1000, backoff_scaling=2),
)
async def your_review(input: dict) -> dict:
    # ...your logic...
    return {}

Each task runs in its own isolated container with per-task retries, timeouts, and traces. Composition is just function calls: call a task from inside a task, wrap calls in the fan-out primitive for your track, and let the platform run the branches. The code-review pipeline becomes the same fan-out you already know, except each reviewer is a task.

Three runtime patterns, one fan-out

Here’s the same parallel review across all three patterns:

The punchline of the workshop: Pattern 2’s queue helper is, in Pattern 3, the Render platform.

On Workflows, the review is a tree of tasks. Each box below is a task that Render runs in its own isolated container, with retries and a trace you didn’t write:

flowchart TB
  cr["code-review<br/>task"]
  cr --> sec["security<br/>task"]
  cr --> perf["performance<br/>task"]
  cr --> ux["ux<br/>task (frontend only)"]
  sec --> judge["judge<br/>task"]
  perf --> judge
  ux --> judge

The plan

This tutorial stays deploy-first, then turns hands-on:

1. Deploy the workflow gateway and the separate workflow service, then submit a PR from the shared workshop dashboard and read a real run trace in the Render Dashboard.
2. Author your own review task locally, where a fast edit-run loop beats a deploy between every change.
3. Push your task and watch it run in production.

You’ll review the same public demo PRs as Part 1. Use the LlamaIndex baseline PR for the first hosted run and when you author your review task. Use the OpenAI Agents trace PR from the dashboard picker when you want a larger diff, or the Mastra frontend PR when you want the UX reviewer to join the fan-out.

The gateway uses the same dashboard as the first two patterns. Once more than one workflow is discovered, it also shows a Workflow selector so you can choose between the built-in review task and your authored task from the same PR form.