Expose platform environment bindings to deterministic Action handlers

[Divkix]

Problem

defineAgent<TEnv>() initializers and Flue runtime contexts receive platform environment bindings, but ActionContext exposes only harness, log, and optional input.

This prevents a deterministic Workflow Action from calling narrow application-owned capabilities such as a Cloudflare Durable Object binding. Current workarounds are undesirable:

• pass credentials or capability details through serialized workflow input;
• use ambient target-specific context such as getCloudflareContext();
• make a model invoke a tool when deterministic application code should own the call.

A motivating case is a structured AI workflow that produces a recommendation, then invokes an application-owned durable coordinator by stable action ID. The coordinator owns authorization, idempotency, and external-effect attempts. Flue should orchestrate the call, but the model must never receive the binding or its secrets.

Proposed API

Expose platform bindings on Actions:

export default defineWorkflow({
  agent,
  input,
  async run({ env, harness, input, log }) {
    const result = await evaluate(harness, input);
    await env.MODERATION_STATE
      .getByName(input.guildId)
      .executeAuthorizedAction({ actionId: result.actionId });
    return result;
  },
});

Ideally, thread the agent environment type through ActionContext, ActionDefinition, and WorkflowDefinition, so env is typed rather than Record<string, unknown>.

Runtime behavior

A minimal proof works by:

• passing ctx.env into the Action context in executeWorkflowDefinition();
• passing the session's platform env into model-invoked Action contexts;
• documenting that env is trusted application capability state and is never serialized, logged, or exposed to the model automatically.

The capability should behave consistently for inline Workflow Actions, extracted Actions, model-invoked Actions, Node environment values, and Cloudflare bindings.

Non-goals

This does not make Flue responsible for application authorization or effect idempotency, and it does not imply workflow checkpoint/resume semantics. Those remain explicit application concerns.