Tale v0.4.2

0.4.2 is a feature and fix release on the 0.4 line — an in-place update: tale update, then tale deploy. No data migrations ship with it. One default behaviour change is listed below — read it if you want to know what knowledge your agents can reach.

Highlights

Pick the provider that serves an agent's model. The agent dialog's Model field is now a searchable picker with one entry per (provider, model) pair, the serving provider named under every option — with an Anthropic subscription broker and an OpenRouter key configured side by side, claude-sonnet-5 — Anthropic · Subscription and anthropic/claude-sonnet-5 — OpenRouter are two distinct, honest choices. A picked model is pinned: the run resolves exactly that provider and fails with the reason if it can't, instead of silently serving (and billing) through whichever connector matched first. Task agents can now also run on subscription credentials (e.g. an Anthropic subscription driving Claude Code) — flat-rate vendor serving with no per-token metering. (#2959)

Agents come with organization knowledge built in. Task-agent and automation runs now carry rag_search and rag_fetch by default, so a managed run can search organization knowledge and read a matched document or crawled page in full — no per-agent tool configuration. Access follows the run's binding: a project-bound run reads its project, shared team libraries, and the org hub; an org-level automation run reads the hub only. (#2957)

Plus: an automation run whose output is null or a bare value now shows that value instead of an ERROR placeholder — the same fix covers every JSON panel (run input/output, step detail, effects, approvals) (#2958); and a UI polish pass tightens the export-chat dialog, adds a way back from the shared-chat preview, sits the archive banner and sidebar section flush, and drops the redundant "Suggested follow-ups" label (#2960).

Behaviour changes

• Task and automation agents can retrieve organization knowledge by default. Every managed run now holds rag_search + rag_fetch, scoped to what its binding already sees (project + shared team libraries + hub for project-bound runs, hub only for org-level automations) — no wider than the humans in the same scope, but agents that previously had no knowledge access now do. (#2957)
• A newly saved model pick is pinned to its provider, fail-closed. If the pinned provider's credential is later removed, the run fails with that reason rather than falling back to another connector. Existing agents keep the previous resolution until they are re-saved with a pick from the new picker. (#2959)

Migration notes

No new data migrations in 0.4.2 — tale deploy is an image update only. Updating straight from 0.4.0 applies the four 0.4.1 migrations automatically on the way.

Upgrading

tale update    # a 0.4.x CLI stays on the 0.4 line and picks up 0.4.2
tale deploy    # pulls the 0.4.2 images

On 0.3.x? The 0.3 → 0.4 cutover is a fresh deployment, not an upgrade — read the v0.4.0 release notes and Upgrades → 0.3 → 0.4: breaking cutover before moving.

What's Changed

• feat(platform): grant task and automation agents baseline knowledge tools by @larryro in #2957
• fix(platform): render non-object JSON values as text in JsonViewer by @larryro in #2958
• fix(platform): ui polish — archive, chat, dialogs, form hints by @AdeolaAdekoya in #2960
• feat(platform): pin task-agent models to their serving provider by @larryro in #2959

Full Changelog: v0.4.1...v0.4.2