The version pinning approach for existing tasks is a pattern I've found really useful in practice. When you're building document processing workflows (transcripts, reports, etc.) the ability to iterate on your agent logic without retroactively breaking existing user sessions is underrated.
One question: for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger? E.g. if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks.
> for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger
Yes, we support manually migrating tasks using "tu tasks migrate".
> if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks
In this case the better pattern is to create new tasks against those old workspaces on the fixed version. You could do this on behalf of your users.
One question: for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger? E.g. if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks.