SIRT Triage Agent Workshop
← All lessons

Lesson 14

~15 min

Dynamic Workers -- execute agent-generated code

Let the Response Agent generate a custom Worker at runtime (e.g. an IOC scoring helper) and execute it via Dynamic Workers, showing the generated code, execution time, and cost estimate.

Why agent-generated code matters

Up to now, the Response Agent produces structured action plans — but those actions are data. They describe what to do; they don’t do anything. What if the agent could write and execute bespoke logic tailored to the incident at hand?

Think about what an analyst does manually: they write a quick script to score a list of IOCs against a threat feed, check whether a set of IPs falls within a suspicious CIDR range, or validate that a blocklist entry matches the right format before pushing it. These are small, disposable utilities — different for every incident, rarely worth packaging into a permanent tool.

Dynamic Workers let the Response Agent do exactly this. Instead of a fixed library of tools, the agent generates a custom Worker — a few dozen lines of JavaScript — deploys it ephemerally, invokes it, and returns the result. The action space isn’t limited to what you anticipated at build time. It’s whatever the model can write.

What Dynamic Workers are

Dynamic Workers are the lowest-level primitive for spinning up a Worker at runtime. Your host Worker (the SIRT app) holds a Worker Loader binding. When the Response Agent needs to run generated code, it calls env.LOADER.load() with the source code, which creates a fresh isolate on the fly. The host sends a request to it, reads the response, and the isolate is discarded.

Key properties:

  • Sandboxed — the Dynamic Worker runs in its own V8 isolate, not in the parent Worker’s process. A bug or infinite loop in generated code can’t crash the host.
  • Constrained bindings — you choose what the Dynamic Worker can access. In our case: nothing. No KV, no D1, no secrets. Pass globalOutbound: null and the Dynamic Worker can’t even reach the network.
  • Ephemeral — load() creates a one-off isolate. There’s nothing to clean up. No deployment artifact lingers after the request completes.

This is not the Dynamic Workers Playground (a persistent deployment tool). We use Dynamic Workers purely as a code-execution substrate: spin up, execute, return, discard.

Dynamic Workers execution flow

flowchart LR
  A[Response Agent] --> B[Generate Worker Code
— LLM —]
  B --> C[Worker Loader
env.LOADER.load]
  C --> D[Ephemeral
V8 Isolate]
  D --> E[Execute]
  E --> F[Result +
cpu_ms + cost]
  F --> G[UI Panel]

The flow

Here’s what happens when the Response Agent decides it needs custom logic:

Response Agent (Workers AI)
    │
    ├── 1. Generates Worker source code (e.g. IOC scorer)
    │
    ├── 2. Calls env.LOADER.load(generatedCode, { globalOutbound: null })
    │
    ├── 3. Sends a request to the Dynamic Worker with incident data
    │
    ├── 4. Reads response + captures cpu_ms from timing headers
    │
    └── 5. Returns result + execution time + cost estimate to UI

The generated code is plain JavaScript — a fetch handler that receives incident data in the request body, runs whatever logic the model wrote (scoring, matching, validation), and returns a JSON response. The model produces the code, but your host Worker controls the execution environment.

Step 1: Add the Worker Loader binding

Open sirt-workshop-app/wrangler.jsonc and add the worker_loaders binding. While you’re there, update STATE to state-7-dynamic-workers:

{
  // ... existing config ...

  "vars": {
    "STATE": "state-7-dynamic-workers"
  },

  "worker_loaders": [
    {
      "binding": "LOADER"
    }
  ]
}

Unlike most bindings, the Worker Loader doesn’t point at an external resource — it provides access to the Worker Loader API, which can create Dynamic Workers on demand.

Step 2: Review the code generation flow

Open sirt-workshop-app/src/agents/response-agent.ts and look for the Dynamic Workers integration. The Response Agent:

  1. Examines the triage card and action plan to decide whether custom logic would help (e.g., scoring IOCs, checking CIDR ranges, validating blocklist entries)
  2. Prompts Workers AI to generate a small Worker — just a fetch handler that performs the specific check
  3. Calls env.LOADER.load() with the generated source and { globalOutbound: null } to block network access
  4. Sends the incident-specific data to the Dynamic Worker as a POST request
  5. Reads the response body, captures execution timing, and computes a cost estimate

The cost estimate uses the published rate card constants: requests * $0.30/million + cpu_ms * $0.02/million_ms. These are displayed in the UI so the analyst sees exactly what the generated execution cost.

Step 3: Deploy and test

Deploy the updated app:

npx wrangler deploy

Open your deployed app and investigate any incident. After the triage card and action plan appear, look for the Generated Worker panel. It shows:

  • Source code — the actual JavaScript the model wrote, syntax-highlighted
  • Execution result — the output (e.g., an IOC risk score, a CIDR match verdict, a blocklist validation result)
  • Execution time — wall-clock milliseconds for the Dynamic Worker invocation
  • Estimated cost — computed from the request count and CPU time

Try investigating different incidents. The malware incident might produce an IOC scorer that rates the C2 indicators. The data exfiltration incident might produce a CIDR matcher that checks whether destination IPs fall within known cloud storage ranges. Different incidents, different generated code.

What you’ve built

With Dynamic Workers, the Response Agent’s action space is no longer limited to a fixed set of tools. It can generate and execute bespoke logic per incident — scoring, matching, validating, transforming — in a sandboxed environment with full visibility into the generated code, its output, and its cost. The analyst sees everything: what code ran, what it returned, how long it took, and what it cost.

This completes the advanced execution layer. In the final lesson, you’ll step back and compare your deployed app against the reference demo, review the five blueprint agents you didn’t build, and explore extension paths for taking this further.

Knowledge check