[jannikluhn]

What this does

The signal worker currently runs one agent task at a time, so one user's task can hold up everyone else. This change lets runs execute in parallel when they use different sessions and resources. Runs that share either still execute in order.

Each handler can list the resources a prompt needs exclusive access to, such as a workspace, an account, or a user's budget. The worker starts a run once no earlier unfinished run uses the same session or any of those resources.

claim signals and call their handlers one at a time, in emission order
  handle(signal) → prompts
  queue the prompts in order
  start each run when no earlier unfinished run shares
    its session or any of its resources
  give each run its own connection to the agent instance
  after all runs for a signal finish
    call post(signal, { failed, limited }), if defined
    release the sessions and resources after post returns

Without any resource declarations, runs in different sessions can run in parallel automatically. Resource names act as exclusive locks: any two runs naming the same resource must wait for each other. There is no configurable concurrency limit.

What a handler gains

 type Prompt = {
   session: string | null
   text: string
   usageLimit?: number
   context?: unknown
+  resources?: readonly string[]   // resources this run needs exclusive access to
+  tag?: string                    // random run tag, also included in the prompt text
 }

Matching an agent server request to its run

With several runs active, the agent server needs a way to tell which run sent a request. The handler generates a random tag, includes it in the prompt text, and tells the agent to send it in the concorde-run-tag header. The worker looks up that tag and sets request.concordeRun to the matching run's metadata.

sequenceDiagram
    participant H as Signal handler
    participant W as Signal worker
    participant A as Agent instance
    participant S as Agent server
    H->>W: Prompt containing the tag in text and tag fields
    W->>A: Start run and register its tag
    A->>S: Request with concorde-run-tag header
    S->>W: Look up tag
    W-->>S: request.concordeRun = { id, signalId, session, context }
    Note over S: Missing, unknown, or expired tag leaves concordeRun undefined
    W->>W: Remove tag when the run ends

Loading

The server never guesses based on which runs are active, even if there is only one. Tags help prevent injected message text from impersonating another run, but they do not provide access control. Runs share the agent instance's filesystem, where another session's tag can be read. This limitation is documented in the architecture guide.

Commits

• Match agent server requests to runs using their tags.
• Allow runs in different sessions to execute in parallel.
• Add optional resource locks to prompts.
• Test request attribution while several runs are active.
• Keep sessions and resources locked until the signal's post callback finishes.

The runtime interface stays the same. Reported validation: npm run check passes. Gateway tests check request.concordeRun through actual HTTP requests; worker tests use a fake runtime with controlled pauses to check ordering and parallel execution.