Summary
Declaring "protocol": "HTTP" on a runtime in agentcore.json is accepted by the schema but silently never applied: the CDK construct only forwards protocolConfiguration to the L1 CfnRuntime when the declared protocol is not HTTP. The deployed runtime ends up with protocolConfiguration unset, and there is no way to explicitly assert HTTP on the deployed resource.
Where
@aws/agentcore-cdk 0.1.0-alpha.48 (also verified on alpha.45), dist/cdk/constructs/components/primitives/runtime/AgentCoreRuntime.js:
const protocolMode = agent.protocol ?? 'HTTP'; // line 246
...
// CfnRuntime.protocolConfiguration is typed as `string | undefined` in the L1,
// so passing 'MCP', 'A2A', or 'AGUI' directly is correct per the CloudFormation spec.
...(protocolMode !== 'HTTP' && { protocolConfiguration: protocolMode }), // line 261
So 'MCP', 'A2A', and 'AGUI' pass through, but a user-declared 'HTTP' is indistinguishable from not declaring anything.
Why it matters
- Least surprise: a value the user explicitly wrote into
agentcore.json is dropped with no warning. agentcore status / the deployed runtime then show no protocol configuration, which reads as "not configured" rather than "configured as HTTP".
- It blocks controlled experiments. We were investigating an idle-session-reaping/billing problem where one hypothesis (from a colleague's test) was that the presence or absence of
protocolConfiguration on the runtime affected idle-session reaping. There was no declarative way to deploy the "explicitly HTTP" arm — the construct makes that state unreachable. (For the record, our controlled experiment showed reaping works fine with protocolConfiguration unset once the agent's /ping stops re-stamping time_of_last_update; the hypothesis was a confound. But we had to establish the deployed state by inspecting the construct source rather than by declaring it.)
Expected behaviour (either is fine)
- Pass the declared protocol through unconditionally — if
CreateAgentRuntime/CloudFormation accepts HTTP as an explicit serverProtocol, declaring it should set it; or
- If HTTP is deliberately omitted because unset means HTTP service-side, document that in the
agentcore.json schema description for protocol (and ideally have the CLI note it at deploy/diff time) so a declared HTTP isn't mistaken for a deploy bug.
Environment
@aws/agentcore CLI 0.27.0 (which pins the construct; also reproduced reading alpha.48 from npm)
@aws/agentcore-cdk 0.1.0-alpha.45 and 0.1.0-alpha.48
- Runtime deploys verified in eu-west-2
🤖 Generated with Claude Code
https://claude.ai/code/session_01CiwESpXfsVS2dBrSnMosei
Summary
Declaring
"protocol": "HTTP"on a runtime inagentcore.jsonis accepted by the schema but silently never applied: the CDK construct only forwardsprotocolConfigurationto the L1CfnRuntimewhen the declared protocol is not HTTP. The deployed runtime ends up withprotocolConfigurationunset, and there is no way to explicitly assert HTTP on the deployed resource.Where
@aws/agentcore-cdk0.1.0-alpha.48(also verified on alpha.45),dist/cdk/constructs/components/primitives/runtime/AgentCoreRuntime.js:So
'MCP','A2A', and'AGUI'pass through, but a user-declared'HTTP'is indistinguishable from not declaring anything.Why it matters
agentcore.jsonis dropped with no warning.agentcore status/ the deployed runtime then show no protocol configuration, which reads as "not configured" rather than "configured as HTTP".protocolConfigurationon the runtime affected idle-session reaping. There was no declarative way to deploy the "explicitly HTTP" arm — the construct makes that state unreachable. (For the record, our controlled experiment showed reaping works fine withprotocolConfigurationunset once the agent's/pingstops re-stampingtime_of_last_update; the hypothesis was a confound. But we had to establish the deployed state by inspecting the construct source rather than by declaring it.)Expected behaviour (either is fine)
CreateAgentRuntime/CloudFormation acceptsHTTPas an explicitserverProtocol, declaring it should set it; oragentcore.jsonschema description forprotocol(and ideally have the CLI note it at deploy/diff time) so a declared HTTP isn't mistaken for a deploy bug.Environment
@aws/agentcoreCLI 0.27.0 (which pins the construct; also reproduced reading alpha.48 from npm)@aws/agentcore-cdk0.1.0-alpha.45 and 0.1.0-alpha.48🤖 Generated with Claude Code
https://claude.ai/code/session_01CiwESpXfsVS2dBrSnMosei