What changed
On August 26, 2026, LaunchDarkly shipped a coordinated set of AgentControl expansions. New Go and Java AI SDKs let server applications resolve AgentControl configs at runtime, including prompts, model settings and targeting variations, while recording generation count, tokens, latency and errors. AgentControl also gained Amazon Bedrock as a provider, EU data residency for prompts/configs/targeting rules, and a Conversations view that stitches multi-step LLM and agent spans into one transcript with tool calls, token use, errors, estimated cost and evaluation scores. The core operating model is that the application still calls the model provider directly; LaunchDarkly supplies and governs the configuration rather than proxying model inference.
Why it matters
AI applications increasingly need to change prompts, models and agent instructions without coupling every experiment or emergency rollback to a software deployment. AgentControl applies LaunchDarkly's familiar targeting, approval and rollout concepts to that layer: a team can serve a model or prompt variation to selected users, change it at runtime, monitor quality and cost, and require human approval before production configuration changes. The August expansion makes that pattern usable in more server stacks and with Bedrock while adding regional-governance and run-level observability. The trade-off is maturity: LaunchDarkly's AI SDK family remains pre-1.0, and the Java SDK is explicitly not generally available, so teams should treat the control plane as evolving infrastructure rather than a frozen API contract.
Prompts and models move out of deployment artifacts
AgentControl configs contain model settings plus messages or agent instructions. Applications evaluate those configs against LaunchDarkly contexts, so different users, organizations or environments can receive different variations. Updating a prompt, model or targeting rule can take effect without rebuilding or redeploying the application.
The August SDK expansion reaches Go and Java teams
LaunchDarkly added AI SDKs for Go and Java on August 26. Both can resolve per-context AgentControl configs and report token, latency, generation and error metrics. The Go SDK is pre-1.0 and LaunchDarkly says the Java AI SDK is not yet generally available, so backward compatibility should not be assumed while these clients mature.
Bedrock keeps inference in the customer's AWS account
AgentControl can now configure Amazon Bedrock models while the application continues to call Bedrock directly using its own AWS credentials. LaunchDarkly manages prompt/model configuration and receives tracked metrics, but it does not proxy or independently invoke the model provider. That separation is useful for teams that want runtime configuration control without moving inference out of their existing AWS boundary.
Governance comes from targeting, approvals and guarded rollouts
AgentControl uses LaunchDarkly's context and segment targeting model. Teams can require approvals before config variations or targeting changes are applied and can use guarded rollouts to expose a new variation gradually while watching metrics for regressions. This turns prompt/model changes into governed releases rather than ad hoc production edits.
Conversation views connect configuration changes to whole agent runs
LaunchDarkly now groups related LLM and agent spans into conversation-level traces. A team can inspect duration, models/providers, token use, estimated cost, errors, evaluation scores and tool-call payloads across a multi-step run instead of reconstructing behavior from isolated spans. That makes it easier to compare what a rollout changed at the task level rather than only at individual model calls.
EU residency expands where the control plane can be used
AgentControl can now operate in LaunchDarkly's EU environment, keeping prompts, configs, variations and targeting rules managed in the EU and restricting model choices to providers approved for that region. Availability remains plan- and account-dependent, so teams with residency requirements need to verify both AgentControl access and their chosen provider path.