Feature Request: preserve structured entities in prompts and responses

No files or tests are named. Start by locating the session prompt and response entry points, then trace how entity annotations and capabilities could travel from host to session to response. Done means typed entities survive the round trip, supported types are discoverable, agent references are addressable, and unsupported types fail explicitly.

Problem

Prompts and responses are treated as plain text or Markdown. When a host application passes in a message that contains structured entities — references to users, groups, other agents, or platform-specific objects — those entities are flattened to text. Their identity is lost, so the agent cannot act on them reliably.

The same limitation applies in reverse. The agent cannot emit a structured reference that the host application can render as a real, functional entity. This prevents workflows in which the agent should notify a specific owner, hand off to another agent, or link a platform object when work is blocked or complete.

What is missing

• Inbound structured entities are not exposed to the session with stable identity metadata.
• There is no supported way for the agent to emit a structured reference in its response.
• There is no capability negotiation, so a host cannot discover which entity types are supported.

Proposed behavior

• Prompts can carry typed entity annotations — an identifier, a type, and a display name — alongside their text representation.
• The agent receives those entities as structured data rather than only as rendered text.
• Responses can include structured references that the host application renders natively.
• Unsupported entity types produce a clear capability error rather than silent flattening.

Example scenarios

Notifying a human owner. A host application passes a message that references a specific user as the owner of a component. The agent completes an investigation and returns a response that references that same user as a structured entity, so the host can render it as a real reference and notify them.

Agent-to-agent communication. A chat channel has several agents installed: the Copilot agent plus one or more custom agents that hold domain knowledge, such as a service-ownership agent or a telemetry agent. Partway through a task, the agent determines it needs information only one of those other agents can answer. It should be able to address that agent as a structured entity in its response, so the host platform delivers the question to it and the reply returns to the same conversation. Today the agent name is flattened to plain text, so the other agent is never invoked and the handoff silently fails.

Acceptance criteria

• Typed entities survive the round trip from host to session to response.
• Supported entity types are discoverable through capability negotiation.
• Agent-to-agent references are addressable, not merely rendered as text.
• Unsupported types fail explicitly.