On this page

Just-in-Time Tool

Workflow reference | Approved execution environments

Kind: JitTool
Configuration object: jitTool

Use Just-in-Time Tool to expose run-scoped code creation and invocation functions to a connected model. The step registers a capability. Executable work begins only when the model explicitly creates and invokes a tool in an approved environment.

Inputs

The step wraps its incoming task in the capability descriptor. Connect the full descriptor to a Model, Responses, Chat Completions, or Multi-turn step. Preserve its JSON structure when passing it through intermediate steps.

The model receives the tool specification and supplies tool definitions and explicit JSON input objects through the advertised functions. Runtime selection, credentials, subscriptions, and host policy remain controlled by configuration.

Configuration

Property	Default	Usage
`executionProfile`	`""`	Optional host-owned profile name from `Workflow:Jit:Profiles`. Hosts can require a profile.
`subscriptionId`	`""`	Required for unprofiled Functions execution. Use a nonempty subscription GUID or a whole placeholder such as `{{input.subscriptionId}}`.
`location`	`"eastus"`	Azure region for unprofiled execution; a profile supplies its approved value.
`credentialName`	`"AZURE_JIT_TOKEN"`	Runtime Azure credential reference; profiles can select a trusted host identity instead.
`deploymentConsent`	`false`	Explicit approval for billable deployment and trusted-code execution. Required for normal server-side JIT execution. Referenced ACA targets use the Sandbox step's execution approval.
`maximumTools`	`8`	Unique tool-version limit, 1-16. Run-wide tool admission is also bounded.
`invocationTimeoutSeconds`	`1800`	Long invocation limit, 225-3,600 seconds. Effective backend and policy constraints can be tighter.
`contractVersion`	`1`	Tool-definition contract `1` or `2`.
`policy`	Unset	Optional requested restrictions from the table below. Intersected with any trusted profile ceiling.

The node's shared sandboxNodeId can select an ACA Sandbox. A sandbox reference cannot also select executionProfile. The target must be in the same graph or an ancestor graph and becomes an inferred prerequisite.

Requested policy

Defaults below describe a newly configured policy. Omitting both policy and profile preserves the separate legacy Functions policy, which permits all supported languages and long-running tools. Use an approved profile for controlled deployment.

Policy property	Default	Requirement
`allowedLanguages`	`["Python"]`	1-5 unique supported languages: Python, PowerShell, Bash, C#, JavaScript.
`allowLongRunning`	`false`	Permit long tools only when the host ceiling and backend also allow them.
`allowPremium`	`false`	Permit Premium Functions only when independently allowed by the profile.
`requireRootCoordinator`	`true`	In native multi-agent mode, require provider-attributed root authority.
`allowAsyncOperations`	`false`	Expose bounded start, await-many, and cancel operations when permitted.
`returnExecutionErrors`	`false`	Return supported structured execution errors for model repair when permitted.
`maximumInvocations`	`16`	1-6,400 executions, including examples.
`maximumConcurrentInvocations`	`2`	1-8; cannot exceed the invocation budget.
`maximumRuntimeEnvironments`	`2`	1-16. Prepared sessions also require enough environments for concurrency.
`maximumRepairs`	`1`	0-8 replacement versions.
`shortInvocationTimeoutSeconds`	`200`	1-224 seconds; prepared Dynamic Sessions cap this at 200.
`provisioningTimeoutSeconds`	`1800`	1-7,200 seconds.
`leaseLifetimeSeconds`	`3600`	30-21,600 seconds, with host-enforced admission and cleanup semantics.

Profile restrictions are intersected with the workflow request. A model-written tool definition cannot expand them. The run also bounds total tools, executions, retained memory, and concurrent calls.

Tool-definition contract

Version 1 requires exactly four string fields: toolSpecification, toolCodeLanguage, toolCode, and toolExpectedDuration. Duration is short for under 225 seconds or long for 225 seconds and above, subject to effective policy.

Language	Entry point
Python	`def run(tool_input)` returning a JSON-serializable value.
JavaScript	`module.exports = async function(toolInput) { ... }` returning a JSON-serializable value.
PowerShell	Script using `$ToolInput` and emitting one JSON-serializable result.
Bash	Read one JSON value from stdin and write exactly one JSON value to stdout.
C#	Body of `public static string Run(string inputJson)`, returning JSON text and using fully qualified type names.

Version 2 also requires bounded inputSchema, outputSchema, and 1-8 examples, each containing an input object and expectedOutput. Optional replacesToolId registers an immutable replacement. Examples execute and consume the invocation budget before the tool becomes ready. Input schema must declare an object; supported local JSON Schema constraints are validated, and remote schema references are unsupported.

Source is limited to 128 KiB UTF-8. Input-object and output JSON are each limited to 256 KiB. Creation returns tool IDs; invocation requires a returned ID and explicit input. Use actual returned results for subsequent reasoning.

Outputs

The step produces a capability descriptor with:

Field	Meaning
`kind`	`"benchius-jit-capability"`.
`jitToolId`	Run-scoped capability registration ID.
`toolSpecification`	Effective tool instructions and restrictions.
`contractVersion`	Selected definition contract.
`task`	Incoming typed task.
`executionProfile`	Profile reference for a server-side capability.
`resourceGroupName`	Host-generated resource/lease label for server-side execution. A prepared-pool backend does not create a resource group because this field exists.
`backend`, `sandboxNodeId`	Included for a referenced ACA backend, replacing the profile/resource-group fields.

Tool execution results and evidence are delivered through the connected model's tool handoffs and Preview activity. Capability IDs and tool IDs have different roles and are valid only within their parent run.

Example

{
  "id": "compute-tools",
  "name": "Expose approved Python tools",
  "kind": "JitTool",
  "jitTool": {
    "executionProfile": "approved-python-sessions",
    "deploymentConsent": false,
    "maximumTools": 4,
    "contractVersion": 2,
    "policy": {
      "allowedLanguages": ["Python"],
      "maximumInvocations": 16,
      "maximumConcurrentInvocations": 2,
      "maximumRuntimeEnvironments": 2,
      "maximumRepairs": 1,
      "shortInvocationTimeoutSeconds": 200
    }
  }
}

The operator must configure that profile and approve execution before setting deploymentConsent to true. Connect the descriptor to a model; {{input.task}} can select the original task in its prompt while the full incoming descriptor supplies tool authority.

Hosting and cleanup

Normal Azure JIT requires server-hosted Preview or a packaged server host. The browser can edit and export these definitions but cannot perform the Functions/profile deployment path.

Unprofiled Functions execution creates disposable run-owned resources and executes trusted code without the caller's Azure identity. Legacy short and long tools select their supported Consumption and Premium behavior. Approved profiles can select Functions, FlexConsumption, or prepared DynamicSessions within their validated policy. Generated code cannot select a paid fallback.

Prepared Dynamic Sessions use a persistent approved Python pool; workflow cleanup does not delete that pool or its resource group. Referenced ACA tools share a run-owned instance and its filesystem, with serialized access.

The parent run initiates cleanup on completion, failure, timeout, or cancellation. Uncertain remote allocation or release is reported explicitly and can require operator recovery. Review Approved JIT execution environments for preparation, lease storage, identity, execution, and cleanup requirements.