A reference architecture connects Kiro CLI, AWS DevOps Agent, and LaunchDarkly into a closed-loop system that automates the full experimentation lifecycle: a team states an improvement goal, and agents generate a hypothesis, create a feature flag, implement the code change via Kiro CLI, run a release readiness review, deploy through GitHub Actions and AWS Amplify, run a 50/50 experiment, ramp a Guarded Release with automatic rollback on guardrail breach, and feed outcomes into the next iteration. A custom Experiment MCP Server built on FastMCP and deployed to Amazon Bedrock AgentCore exposes tools for code implementation, PR merging, and deployment triggering that LaunchDarkly's hosted MCP server does not cover. In a demo run, a simulated error-rate spike triggered automatic rollback, and a subsequent iteration lifted add-to-cart conversion from 20.1% to 37.9%.
Table of contents
IntroductionPre-requisitesSolution overviewPlan / Prove / IterateExtending the agent with a custom MCP serverHow the agent worksProving the changeSafety boundariesGetting startedConclusionAuthorsQuestions this post answers
How do I connect AWS DevOps Agent to LaunchDarkly's MCP server?
Register LaunchDarkly's hosted MCP server at the AWS account level from the DevOps Agent console's Capability Providers page, using endpoint https://mcp.launchdarkly.com/mcp/launchdarkly and OAuth 3LO (Three-Legged OAuth) for authentication. After registration, add the server to a specific Agent Space through the Capabilities tab and choose to allow all tools or allowlist specific ones, then validate by asking the agent to list feature flags in a project. Teams wiring agent orchestration into feature-flag workflows can track integration patterns like this on daily.dev.
What is the difference between a LaunchDarkly experiment and a Guarded Release in an automated rollout pipeline?
An experiment measures whether a change improves a goal metric, running a 50/50 split across a percentage of traffic until statistical significance picks a winning variation, while a Guarded Release measures whether that winning variation is safe at scale, ramping traffic from 20% to 30% to 40% to 100% while monitoring operational guardrails like error rate and page-load-time-p95, with automatic rollback if a threshold is breached. Developers deciding how to structure safe rollouts can follow feature-flag and experimentation practices on daily.dev.
Why can't error rate be used as the primary success metric in this LaunchDarkly-based experimentation agent?
Error rate is reserved exclusively as a safety guardrail during the Guarded Release phase and cannot be selected as the primary goal metric, because the system needs an independent operational signal separate from the business KPI to decide whether a winning variation is safe to scale to full traffic. Valid primary metrics include add-to-cart rate, checkout conversion, bounce rate, and page-load-time-p95. Engineers designing guardrail metrics for automated rollouts can compare approaches like this on daily.dev.