How is the trace ID set when invoking Bedrock AgentCore harness from a Step Function

In addition to the other answer .... , there is a architectural reason for this behavior. The Trace ID in "CloudWatch GenAI Observability" is not generated by Bedrock in isolation; it is inherited from the standard AWS X-Ray trace context (specifically the X-Amzn-Trace-Id header) passed by the calling service.

Because your execution chain starts upstream (S3 -> EventBridge -> Step Functions -> Bedrock), the trace context is being propagated through the events. If tracing is not explicitly configured to generate a new context per execution, downstream services like Bedrock will fall back to grouping invocations under an incomplete, default, or reused trace context.

To resolve this and force a unique Trace ID for every single Bedrock invocation, you must enable Active Tracing (AWS X-Ray) directly on your Step Functions State Machine.

When Active Tracing is enabled, Step Functions acts as the trace generator. It automatically creates a strictly unique X-Amzn-Trace-Id for every distinct state machine execution and propagates it to all supported AWS service integrations, including Amazon Bedrock. Bedrock's GenAI Observability will consume this inherited ID and correctly split the traces per execution.

You can verify the requirements and behavior for Step Functions trace propagation in the official AWS documentation here: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-xray-tracing.html

Based on the available documentation, the trace ID in Amazon Bedrock AgentCore is automatically generated by the system and is not directly configurable by users. The trace ID serves as a unique identifier for grouping related trace events together.

While you can access and use the runtime session ID in your agent code (either through context.session_id in the Bedrock AgentCore SDK or via the X-Amzn-Bedrock-AgentCore-Runtime-Session-Id HTTP header for custom runtime servers), the trace ID itself is a separate system-generated identifier that's managed internally.

The behavior you're experiencing - where multiple invocations appear to share the same trace ID - suggests that the trace ID may be tied to something other than the individual invocation or session. Unfortunately, the current documentation doesn't provide details on the specific logic used to generate or assign trace IDs, nor does it offer a way to manually set or override them.

For your use case where you want to track separate Step Functions invocations independently in CloudWatch GenAI observability, you might consider using the session ID you're already setting (based on the execution name) as a correlation mechanism in your own logging and monitoring, even though it won't change how traces are grouped in the native observability interface.

If you need more specific guidance on trace ID behavior or potential workarounds for your observability requirements, I'd recommend reaching out through the AWS Support Center at https://console.aws.amazon.com/support/ where the support team can investigate your specific setup and potentially provide more detailed information about trace ID assignment logic.
Sources
Troubleshoot AgentCore Runtime - Amazon Bedrock AgentCore