v0.2.0

Released 17 July 2026. This release makes retrieval keep digging until it has the evidence, lets each user connect remote MCP servers under their own identity, opens Deep Research report types to your own definitions, and closes several tool-authorisation gaps that affected 0.1.0.

Iterative retrieval

Retrieval used to make a single pass and answer from it. It now keeps searching in bounded rounds until the evidence is exhausted, and the answering model can search the library again itself when it spots a gap. Across the evaluation set this finds 51% more of the relevant material (mean section recall 0.57 to 0.86), and when the corpus genuinely lacks something the search stops and says so instead of inventing.

One-click MCP connections (OAuth 2.1)

Until now a remote MCP server used one shared credential: an admin pasted a single bearer token or API key and every user of that server connected as that one identity. An admin now registers a server by URL, the platform discovers how it authenticates and, where the server supports it, registers itself automatically, and each user clicks Connect once to authorise under their own account, so that server's tools run with the user's own identity and permissions at the provider and expiry is usually invisible. Discovery is an administrator-reviewed step and every discovered endpoint is validated (https only, cloud-metadata and link-local addresses refused, a cross-origin authorisation server only when the admin declares it), so secrets are posted only to endpoints an administrator approved. Tokens live only in encrypted columns, and a deployment with no encryption key configured refuses to store a token rather than fall back to plaintext.

Custom Deep Research templates

Deep Research shipped with four fixed report types: an exploration brief, a formal report, a literature review and a free-form write-up. You can now define your own on top of those four: duplicate one as a starting point, then set its section structure, per-section guidance, outline mode and writing style. A template shapes a report's structure and voice, not how deeply the research searches, and your templates are private unless an administrator publishes one to the whole deployment.

MCP grant enforcement

In version 0.1.0, assigning an agent an MCP server offered it every tool that server exposed, with no per-tool control: granting one tool effectively granted all of them, and the tool name the model emitted was passed to the server without being checked against what the agent was allowed to call, so a fabricated name could reach a different tool, or a server the agent was never assigned. Anyone running 0.1.0 with MCP servers is affected. Every MCP tool call now passes one authorisation check (the connector enabled, the server active and readable, the specific tool granted and present in the server's approved list) on both the live path and the resume of an interrupted call, so a revoked grant or a quarantined server refuses rather than running on stale state. Agents can now be granted individual tools instead of the whole server, existing agents keep their current access, and every denied call is recorded in the audit log.

Native tool enforcement

Version 0.1.0 shipped the built-in tools and admin-defined custom tools without a common authorisation check on the dispatch path. Two gaps affected anyone running 0.1.0: a built-in tool the agent was never granted could still run if a model named it directly (only the code interpreter was gated), and switching a tool off in the admin settings removed it from the list shown to the model but did not stop it running if the name reached execution another way. Both are now closed: every built-in and custom tool call passes one authorisation check before it runs, an admin-disabled tool genuinely refuses, and document editing now enforces its project write permission on ordinary chat turns as well as inside an agent run. Denied calls are recorded in the audit log, custom tools can now be granted to an agent, and existing agent configurations are unaffected: the changes only tighten what was already permitted.

Enterprise

MCP OAuth tokens under key rotation. MCP OAuth access and refresh tokens are now covered by the deployment's data-encryption-key rotation, so they are re-encrypted along with everything else when a key is rotated.

Fixes

• Internal scaffolding calls (history compaction, skill dry-run, report-to-page rendering) no longer inherit the model's default reasoning effort, which on reasoning-heavy models wasted the token budget, inflated cost and latency, and could return nothing.
• Fixed incremental history compaction silently stopping after the first summary on long conversations.

Upgrade

No action is required. The tool-authorisation changes only tighten what was already permitted; existing agent and MCP configurations are unaffected.