What should we do?
Keep io.camunda.agenticai:aiagent:1 and io.camunda.agenticai:aiagent-job-worker:1 operational as a backward-compatibility shim:
- The old
AiAgentFunction and AiAgentJobWorker connector classes stay as thin entry points that read the legacy input shape, rewrite it to the new ProviderConfiguration shape, and delegate to the same internal service the new connector classes invoke.
- Mark both old classes
@Deprecated with a Javadoc note pointing at the new connector types.
- Old element templates stay in place under
element-templates/versioned/ for existing process models. No new feature flags from Phase 2 (Responses API, Anthropic cloud backends via SDK platform-backend modules, custom provider SPI) are exposed on the old templates.
Why should we do it?
Existing customers' processes must keep running after the switch. Routing the legacy input shape through a rewrite step at the connector boundary contains the backward-compatibility cost to one well-tested layer.
What should we do?
Keep
io.camunda.agenticai:aiagent:1andio.camunda.agenticai:aiagent-job-worker:1operational as a backward-compatibility shim:AiAgentFunctionandAiAgentJobWorkerconnector classes stay as thin entry points that read the legacy input shape, rewrite it to the newProviderConfigurationshape, and delegate to the same internal service the new connector classes invoke.@Deprecatedwith a Javadoc note pointing at the new connector types.element-templates/versioned/for existing process models. No new feature flags from Phase 2 (Responses API, Anthropic cloud backends via SDK platform-backend modules, custom provider SPI) are exposed on the old templates.Why should we do it?
Existing customers' processes must keep running after the switch. Routing the legacy input shape through a rewrite step at the connector boundary contains the backward-compatibility cost to one well-tested layer.