---
url: >-
  https://adk.nht.io/api/@nhtio/adk/forge/type-aliases/ArtifactConstructorResolver.md
description: >-
  A zero-arg function that returns the {@link
  @nhtio/adk!SpooledArtifactConstructor} the consumer should use when wrapping
  this tool's serialised output into a `ToolCall.results` field.
---

# Type Alias: ArtifactConstructorResolver\<A>

```ts
type ArtifactConstructorResolver<A> = () => SpooledArtifactConstructor<A>;
```

Defined in: [lib/classes/tool.ts:32](https://github.com/NHTIO/ADK/blob/v1.20260609.0/src/lib/classes/tool.ts#L32)

A zero-arg function that returns the [@nhtio/adk!SpooledArtifactConstructor](SpooledArtifactConstructor.md) the consumer should
use when wrapping this tool's serialised output into a `ToolCall.results` field.

## Type Parameters

| Type Parameter                                                                       | Default type                                                           |
| ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| `A` *extends* [`SpooledArtifact`](../../spooled_artifact/classes/SpooledArtifact.md) | [`SpooledArtifact`](../../spooled_artifact/classes/SpooledArtifact.md) |

## Returns

[`SpooledArtifactConstructor`](SpooledArtifactConstructor.md)<`A`>

## Remarks

Why a resolver (and not the constructor itself)? `tool.ts` participates in a module-load
cycle with `spooled_artifact.ts` and `artifact_tool.ts` (`ArtifactTool extends Tool` closes
the loop). Any eager value-level reference to `SpooledArtifact` in `tool.ts` would crash the
cycle with a TDZ error. A resolver lets `tool.ts` validate "is a function" at module-load
time and defer the actual constructor check to validate-time (which always runs after every
module body has executed). Wrap-sites invoke `tool.artifactConstructor?.() ?? SpooledArtifact`
to obtain the final constructor.