Skip to content

No durable storage or restoration for Assets produced during a conversation #1821

Description

@jasperblues

Tool.Result.withArtifact(...) and the Asset model work well inside a live process, but there is no durable story for what they produce once the process ends.

What exists today:

  • Asset (embabel-agent-api/.../chat/Asset.kt), AssetView, AssetTracker, AssetAddingTool
  • AssistantMessage(assets: List<Asset>), which implements AssetView
  • Tool.Result.withArtifact(...), used by ScriptTool, Subagent, AgenticTool, ToolCallSupport

What is missing is persistence and rehydration. ScriptTool returns artifacts whose path points at files in a sandbox working directory; those paths do not outlive the run. On the storage side, embabel-chat-store's MessageData has no assets field, so a persisted session keeps the tool-result text but neither the generated files nor the Asset metadata. Reloading a conversation gives you an AssistantMessage with assets = emptyList().

The workaround this forces: an application-owned artifact store that copies generated files out of the sandbox before it is torn down and stores metadata keyed by conversation ID. That is a fair amount of plumbing, and every application that generates files needs its own copy of it.

Questions:

  1. Is a durable asset/artifact store a planned Embabel abstraction — something like an AssetStore SPI that Asset implementations can be materialised into and resolved from?
  2. If so, should conversation stores persist AssistantMessage.assets as durable references and restore them on load? (Chat-store side tracked at MessageData is lossy for multimodal UserMessage content embabel-chat-store#12.)
  3. Is there an intended lifecycle/retention contract for sandbox-produced artifacts, or is copying them out deliberately left to the application?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions