support for type descriptors $type

[FB (grtc-group-florinbugan)]

Does the Agent Framework support type descriptors during deserialization within the function tools mechanism (e.g., preserving polymorphic types or using metadata such as $type for correct object reconstruction)?

[T (cookesan)]

Not as a general function-tool argument feature.

The repo does use $type-style discriminators in specific internal serialization paths, such as durable agent state. I could not find the same contract for function-tool argument deserialization. Function tools are described from the tool signature/schema, and arguments are reconstructed into the declared parameter types rather than treated as arbitrary polymorphic payloads with $type metadata.

For function tools, I would model the discriminator explicitly in the tool schema, for example kind, type, or a tagged object shape, and dispatch inside the tool. If this is .NET code and you control an outer serialization boundary, custom JsonSerializerOptions or converters can still be used there, but I would not rely on $type being honored automatically by the function tool mechanism itself.

[chetantoshniwal]

Can you explain a bit more on the exact use-case and why you need to ser-deser ?

[FB (grtc-group-florinbugan)]

For example, I have the following classes:

[JsonPolymorphic(TypeDiscriminatorPropertyName = "$type", IgnoreUnrecognizedTypeDiscriminators = false)]
[JsonDerivedType(typeof(GeometryCircle), typeDiscriminator: "circle")]
[JsonDerivedType(typeof(GeometryRectangle), typeDiscriminator: "rectangle")]
[JsonDerivedType(typeof(GeometrySquare), typeDiscriminator: "square")]
public abstract class GeometryBase
{
}

public class GeometryCircle : GeometryBase
{
public double Radius { get; set; }
}

public class GeometryRectangle : GeometryBase
{
public double Width { get; set; }
public double Height { get; set; }
}

public class GeometrySquare : GeometryBase
{
public double Side { get; set; }
}

I also have the following function exposed as a tool:

List < GeometryBase > GetGeomDetailsById(List ids)

The returned list actually contains instances of GeometryCircle, GeometryRectangle, and GeometrySquare.

However, when serializing List < GeometryBase > to JSON, the result contains only empty GeometryBase objects, without any of the derived type properties.

As a workaround, I changed the return type from List to List and performed the serialization manually before returning the result.

[Denis Samatov (denis-samatov)]

The empty derived objects are a serialization-boundary problem, not a failure of the polymorphic classes themselves. When a function is declared as returning List, a serializer that only has metadata for the base type can emit the base properties and drop derived members. JsonPolymorphic/JsonDerivedType attributes help only when the exact serializer options and type metadata used by AIFunctionFactory include them.

For a tool contract, the most portable fix is an explicit tagged DTO rather than relying on .NET type metadata:

public sealed record GeometryDto(
    string Kind,
    double? Radius = null,
    double? Width = null,
    double? Height = null,
    double? Side = null);

// return IReadOnlyList<GeometryDto> from the tool

The model-facing schema now contains a stable discriminator (circle/rectangle/square), and the application can map the DTO back to GeometryCircle/GeometryRectangle/GeometrySquare after the tool call. If you keep the polymorphic return type, pass serializer options with a resolver/type-info configuration that registers every derived type to AIFunctionFactory.Create and verify the generated function schema; do not assume the attributes are picked up by a different default options instance.

Manual serialization to JsonElement is a valid workaround when you need an open-ended payload, but it gives up useful schema validation. For tools, an explicit kind field plus nullable shape-specific fields is usually easier to validate, trace, and keep compatible across providers.