You proved the task locally. Now ship that same task to the hosted Workflow service and verify that production shows the trace you expect.

1. Commit and push

Make sure you removed the forced failure from the retry demo. Then:

git add packages/workflow-agents/src/workflows/your-review/index.ts
git status   # sanity-check what's about to land
git commit -m "your-review: compose security reviewer as a task"
git push

git add packages/workflow_agents/src/workflow_agents/workflows/your_review.py
git status   # sanity-check what's about to land
git commit -m "your-review: compose security reviewer as a task"
git push

Keep the diff small. A tight commit makes a rollback cheap if the hosted run misbehaves.

2. Redeploy the workflow service

Auto-deploy on push is on by default, so the push triggers a deploy.

Two services may redeploy because they share the repo. Watch the Workflow service. That is the service that reloads the task code and registers your-review / your_review.

1. Watch the Workflow service deploy Open it in the Render Dashboard. It reinstalls dependencies and re-registers tasks on startup.
2. Confirm your authored task is registered

   The loader rediscovers it from the workflow module. No registration step on your part.

   

The gateway also redeploys because it shares the repo, but nothing about it changed.

sequenceDiagram
  participant You
  participant GitHub
  participant WF as Workflow service
  You->>GitHub: git push
  GitHub->>WF: auto-deploy
  WF->>WF: re-register tasks
  You->>WF: trigger authored task
  WF-->>You: run trace with nested security task

3. Run it in production

Trigger your authored task against the LlamaIndex baseline PR. Open the gateway dashboard, choose your authored task from the Workflow selector, paste the PR URL, and click Review.

You can also trigger it from the CLI. In production, use the Workflow slug plus task name:

render workflows start workflow-agents/your-review \
  --input='[{"url":"https://github.com/run-llama/LlamaIndexTS/pull/2234"}]'

render workflows start workflow-agents/your_review \
  --input='[{"url":"https://github.com/run-llama/LlamaIndexTS/pull/2234"}]'

If the Workflow service has a pending deploy version, release it before starting the task:

render workflows versions release <workflow-id>

1. Trigger the task Use the same PR URL you ran locally.
2. Open the run trace Find the run on the workflow service.
3. Confirm the nested task Your authored task shows the nested my-reviewer task you customized, its LLM turns, and token usage, the same shape you saw under render workflows dev.

At this point, the task you wrote on your laptop is running in your Render workspace. The production run has the same shape as your local run, but Render owns the isolation, retries, and trace.

4. What changed

You’ve run one agent three ways. Here’s the decision this tutorial was building toward:

The agent never changed across any of it. That’s the takeaway: pick the runtime pattern for the operational properties you need, and let it carry the coordination so your code stays about the work.

5. Take it to production

This tutorial ends at a durable, traced, multi-agent reviewer. Shipping that for real is mostly more tasks, steps, and config on the same graph. Four directions, and where each plugs into this codebase:

• Evals. Score the shared review runner over a labeled corpus of PRs to catch quality regressions before they ship. The mock model makes runs reproducible in CI, and the decision parser gives you a structured verdict to compare against expectations.
• Guardrails. Validate input and output: strip prompt-injection from a diff before an agent sees it, and re-ask when the judge’s JSON is malformed. The filter-diff step is already the first guard, and the decision parser is where a re-ask loop attaches.
• Circuit breakers. Cap tokens and wall-clock per run, and fail fast when a dependency degrades instead of burning the budget on retries. The shared Budget type and per-task retry config are the starting points.
• Observability. Track p95 latency, token spend, and per-agent failure rate. Every agent already runs as a traced task keyed by runId, so the signal exists. The work is aggregation and export.

None of these change the agent. As with every pattern in this tutorial, the substrate does the work.

The task code stayed the same shape. The runtime changed.

Locally, render workflows dev ran the task on your machine and showed the trace. In production, Render runs the task in isolated Workflow instances, applies the retry config, and keeps the trace in the Dashboard.

Every service in this tutorial runs on a paid plan. Delete them when you’re done.

1. Delete the hand-created Workflow service Open workflow-agents (the Workflow service you created in step 06) and delete it. Blueprint deletion does not remove it because you created it outside the Blueprint.
2. Delete the workflow project Open the project holding the gateway and delete it. That removes the gateway web service and workflow-agents-db.
3. Delete the queue project Open the project holding queue-agents-web and delete it. That removes the web service, queue-agents-worker, queue-agents-valkey, and queue-agents-db.
4. Delete the naive project Open the project holding naive-agent and delete it. That removes the web service and naive-agent-db.

======== The shared workshop workspace is torn down after the session. Until then, the Workflow stack stays useful for inspecting runs, traces, and dashboard rows while you finish the tutorial.