Copilot Studio Direct Line Response Differs from Test Panel and activity trace

One additional point I would verify is whether answeredValue is actually mapped to the final message activity returned by Direct Line.

Since the Test Panel and Direct Line are different execution/channel contexts, I would compare the raw Direct Line activity with the Test Panel trace. If the raw Direct Line text already contains the UTC value, the difference is occurring before the UI renders the response. If Direct Line contains the converted value but the UI shows UTC, then the transformation is on the client side.

Also verify Conversation.LocalTimeZone / Conversation.LocalTimeZoneOffset in the published Direct Line conversation and test with a new conversation after publishing the latest changes.

This should help pinpoint whether the discrepancy is in the agent response generation, channel delivery, or UI handling.

The key point is to distinguish the Copilot Studio authoring/test experience from the response that is actually delivered through the published Direct Line channel.

Copilot Studio's Test agent panel is primarily a design-time validation tool. Microsoft notes that the Test panel does not fully reproduce every behavior of a published channel, so the published Direct Line conversation should be treated as the channel-level behavior to validate.

For Direct Line, the practical flow is:

User/UI → Direct Line → published Copilot Studio agent → orchestration/topics/tools → agent response activity → Direct Line → client

Direct Line is the communication channel/API for the published agent; it is not documented as taking an already-generated answeredValue and running it through another generative-AI pass before returning it.

Therefore, I would not assume that answeredValue is the authoritative Direct Line payload unless the implementation explicitly maps that variable into the final message/activity.

The date/time behavior is particularly important. Copilot Studio stores date/time values in UTC, and the documented local-time conversion depends on Conversation.LocalTimeZone. If that value is not available or valid in the published Direct Line conversation, Copilot Studio falls back to UTC.

I recommend testing this explicitly:

In the published Direct Line conversation, log/inspect Conversation.LocalTimeZone and Conversation.LocalTimeZoneOffset.

Confirm that the Direct Line client is actually establishing a new conversation after the latest publish. Published changes can take effect on a new session; an existing persistent conversation can continue using the previous published version.

Capture the complete Direct Line message activity returned by the API, rather than only the text displayed by the UI.

Compare that activity with the Test Panel response:

activity type

  `text`
  
     `value`
     
        any channel data
        
           conversation/session ID
           
           If the Direct Line activity itself contains the UTC value, the discrepancy is upstream of your UI rendering. If Direct Line contains the converted value but the UI shows UTC, the transformation is happening in the client/application layer.
           

For troubleshooting, Microsoft's Copilot Agent Kit can also run tests against the Direct Line API and records the Direct Line conversation ID and response, which can be useful for comparing the published-channel result with the Test Panel result.

So the first thing I would verify is not another hidden generative-AI step, but whether the published Direct Line conversation has the same Conversation.LocalTimeZone context and whether the actual Direct Line message activity already contains the UTC value.

If the trace shows the converted value and answeredValue is correct, while the raw Direct Line activity contains the original UTC value under the same published conversation/context, that would be useful evidence for a Microsoft support investigation because the discrepancy would be occurring between the agent execution result and the channel response.