Per-Run Execution Context for Building Blocks
Sebastian
As an engineer, I want to be able to provide temporary, run-specific information to a Building Block that can be used during that run without permanently changing its configured state.
The implementation could be per-run metadata, temporary input overrides, or a one-off input change. The information should be available to the Building Block for that specific run and does not affect subsequent (manual) runs.
Use case:
We have a Building Block orchestrator that triggers scheduled runs in different modes. The orchestrator needs to provide additional information or partial input changes, so the Building Block can determine how it should execute.
These orchestrated runs should:
- appear normally in the Building Block's run history,
- provide the temporary information to the Building Block during execution,
- allow the Building Block to use that information to select its execution mode, and
- leave the Building Block's previously configured state unchanged for the next run.
The goal is to support one-off, orchestrated executions with temporary context or inputs, without requiring a second run to restore the Building Block's normal configuration.
Janny the AI Product Manager
Thanks for taking the time to write this up — this is a really clear and thoughtful request.
Per-run context / temporary input overrides for Building Block runs makes a lot of sense, especially for orchestrated or scheduled executions where you don’t want to mutate the saved configuration just to influence a single run. We’ll share this with the product team.
To help us understand the best shape of this, could you clarify a couple things?
1) What kind of “temporary info” do you envision most often (e.g., a small metadata map, specific input fields overridden, or an explicit “mode” parameter)?
2) Should this per-run context be visible in the run details/audit trail (and if so, should it be editable or strictly read-only once the run starts)?
3) How should conflicts be handled if a per-run override provides a value for an input that’s also set in the Building Block’s saved configuration (override wins, or validation error)?