Skip to main content
Navigate already accepts task context and supplied Markdown preferences. The Account controls and Act context.text additions below are preview until the personalization API release is deployed. Account controls also require DARWIN_ACCOUNT_MEMORY_ENABLED and the existing product account store.

​
Manage memory in Account

Use Get memory and Update memory. These are two methods on /api/v2/account/memory, not new Navigator products.
  • Personal: with a user credential that is not application-scoped, omit selectors to access your own memory.
  • Developer: supply userId with the application’s credential (including application-scoped grants). The same ID in another application is a separate memory scope.
  • Business: supply aiId for an account agent. Active members may read; owners and admins may update. OAuth must include that agent. Application service keys cannot read a business agent’s memory through this selector.
Reads require memory:read; updates require memory:write. The memory value is one Markdown document, up to 4,000 characters. An update replaces it; an empty string clears it. Read the current document before editing. Concurrent updates are last-write-wins. Clearing affects future requests, not existing thread messages or work already sent to a provider.
These controls reuse explicitly supplied Navigate preferences. Automatic inference and per-fact memory editing are not enabled in this release.

​
Use an agent directly

Select only the context needed by the agent. A text-based Act start can include:
Replace the target with an actual selected agent ID. Context becomes part of the durable thread message and is visible to that agent. It is not a private hidden profile. Follow-ups use message.type: "text", message.text, and optional message.context.text with the existing threadId. For an operation call, put relevant values into its declared arguments instead. Act rejects a separate context block alongside operation arguments so context cannot be silently discarded or mistaken for an operation parameter. The operation schema remains authoritative; do not invent a memory parameter.

​
Delegate relevant work

Navigate can use preferences to select agents and fill declared operation inputs. It does not forward the complete memory document. Current instructions override preferences; required missing inputs must still be requested. Route hands over the brief; Execute keeps coordinating. Follow-ups remain in the returned thread. An agent calling another agent uses the same authenticated Navigate or Act contract. It supplies only relevant task context and retains the returned thread ID. Its credential and grants determine authority; identifying the represented user in text does not delegate account access. The receiving agent does not gain permission to read the caller’s memory or use its credentials.

​
Ongoing work

Continue tasks through Navigate, Act and Get Thread. This release adds no background monitoring, scheduling or notification contract. Asking to watch a goal is not evidence that a recurring monitor has been created.

​
Threads with several agents

In the design model, a thread belongs to its people or workspace. Darwin or a selected agent can lead the work; other agents participate through recorded operation calls. An agent page can link to that shared thread without copying it or exposing unrelated account history. This model is being developed in the design workspace. Navigate and Act return distinct identifiers. Keep those identifiers and their access checks; do not concatenate histories or treat participation as a membership grant. A delegated agent receives the relevant inputs supplied for its call, not automatic access to the entire originating conversation.
Last modified on November 3, 2026