End users and memory

End users let a product you build on Confluye — a Telegram bot, an app, or a website — serve many external customers with the same workflow. Your product identifies each customer with its own ID. Confluye keeps that customer's conversation, facts, work in progress, and website logins separate from every other customer, and the customer never needs a Confluye account.

How it fits together

The connection between a memory resource and a workflow is the scope: a workflow reads and writes only the resources connected to it. Connecting a resource takes effect from the next run. A run records its turn only into the resources that were connected when it started and are still connected when it finishes, so disconnecting a workflow stops access right away; the memory itself is kept. Memory never crosses workspaces.

Deleting a memory resource deletes every end user's conversations, facts, and work in progress stored in it. While the resource is still being summarized or analyzed, the delete waits a few seconds; if that work has not finished, nothing is deleted and you see a message asking you to try again in a minute.

Set up a workflow for end users

1. 1

   Create a memory resource

   Open Settings → Integrations → End users and memory → Manage end users and memory, then choose Memory resources. Create a resource and connect it to the workflow, or connect it from the workflow editor. The console opens inside the active workspace, keeping its navigation and theme. Existing /end-users links redirect to that workspace's console.

2. 2

   Mark the reply block

   Open the block that answers the customer (usually an Agent, Claude Code, or Codex block). In End user memory, turn on This block's output is the reply to the end user. A workflow can have only one reply block. A workflow connected to memory refuses end user runs until one block is marked.

3. 3

   Test as an end user

   In the same section, choose New test end user, write a message, and select Run as test end user. The run uses the current draft and a test end user with its own memory; real customers can never be selected here. Only an explicit workspace Admin or Owner can create test end users and run as one.

4. 4

   Create a product gateway key

   An Admin or Owner creates the key with the API keys session endpoint, naming the workflows the product may run (see API keys). Settings does not offer this scope in the create dialog.

5. 5

   Call the workflow from your product

   Send each customer message to POST /api/v1/workflows/{id}/execute with endUser.externalId and message. See the End users API for the request, polling, and error contract.

What the agent receives

Before any block runs, a run for an end user reads that customer's partition in every connected resource. Agent, Claude Code and Codex blocks receive it automatically — the model does not have to call a tool:

• Recent conversation: the latest turns verbatim plus a rolling summary of older turns. When more than 12 turns are waiting to be summarized, a background job folds the oldest ones into the summary and keeps the 4 newest.
• Facts: short durable details extracted in the background from the customer's own messages and the agent's replies. A fact is kept only when a quote from those messages supports its value. Page text and tool output are never used as a source. When the turn could have read external content (every Claude Code and Codex reply block, and Agent blocks with a website, tools, or a special operation), facts drawn only from the reply wait as proposed until an Admin or Owner reviews them. Fact names should be generic labels such as preferred_city. The platform filters names that look like personal data, but this is a heuristic: it can miss a lowercase customer name. Fact values are encrypted; fact names are stored in plaintext. Automatic extraction can also replace an existing fact under a different name when the model selects the same memory slot; that selection does not prove the two facts mean the same thing. A fact you wrote or edited is never overwritten by extraction. When the customer directly confirms the same value under the same fact name, an automatic proposal becomes active.
• Work in progress: what the customer asked for, where it stands, and what is still missing.
• Site notes: owner-approved notes about operating the website the block is set up for.

The whole block has a hard size budget shared across connected resources: older turns go first, and when needed the summary, work in progress, and even the newest turn are shortened to fit. Before a turn is stored, credential-like text (password phrases, including the whole of a quoted multiword passphrase, cloud access keys, private keys, web tokens, and long random-looking tokens) is replaced with a marker.

The conversation, facts, and work in progress travel as untrusted data, never as instructions. Agent blocks running on Agent Runtime V2 can also search the customer's facts (the values found also come back as untrusted data), propose a fact, update the work in progress, and propose a site note. Fact search includes older facts beyond the newest 500, and repeated concurrent proposals of the same value create one proposal. A work-in-progress update commits across all admitted, still-connected resources together; if a write fails, none of that update is saved. None of these tools accepts a customer, resource, or workspace argument. An Agent block set up with a website also needs Agent Runtime V2 for end user runs; on the legacy or shadow runtime the run fails with an error instead of opening the customer's login.

While an end user is present, an Agent block does not get the member feature tools: private memory (memory.*), the member's saved-browser tools, subagents, and the platform tools for mail, files, documents, and workspace changes are all absent. A run for an end user never reads or writes the private memory of the workspace member who owns the workflow (see Private agent memory).

One turn at a time per customer

Runs for the same end user start in the order your product sent them: a customer's next turn starts after the previous one has recorded its reply, so it sees that reply as context. Different customers run in parallel. A turn that waits for an approval or a timer does not block the customer: the next turn runs and sees the waiting message marked as pending. A turn can hold the order for at most 30 minutes by default. When a waiting turn resumes, the blocks after the wait receive the original outputs of earlier blocks, including credential values; those outputs are stored encrypted with the paused turn and stay redacted in its steps, logs, and output.

Website logins for end users

A workflow can use each customer's own login to a website, such as a real-estate portal. In Websites and notes, define the website (its login page, account page, and allowed hosts). In the block's End user memory section, choose the End user website, save the block, and select Authorize end user logins for this block. Agent blocks can read pages with the login; Claude Code and Codex blocks control a browser with it. Browser results carry text only: screenshots, PDFs, and other images are never returned, and login values are redacted from the text. The browser does not run web workers or service workers, because their traffic could carry login values past redaction. Pages that need them may not work, and if a worker runs anyway, the browser result is withheld. Only an explicit workspace Admin or Owner can define websites and authorize or revoke a block's end user logins; other members see a notice instead of these controls.

Your product asks for a one-use login link per customer and site with the connect requests endpoint. The customer signs in to the website only; the link never grants a Confluye session. The viewer adapts to desktop or mobile and accepts direct typing and scrolling. Enter the website credentials manually; the viewer does not provide Confluye password autofill. Human login can follow public HTTPS SSO and MFA redirects; private networks remain blocked. Saving verifies the requested website, keeps its configured domains' session data and closes the viewer. Agent browsing then uses the website's domain allowlist and block grants. A member's saved browser connection never serves an end user run.

When the customer's login is missing, expired, rejected, or revoked, or the block has no authorization, the run ends as failed with connectionRequired and a reason your product can act on.

For a missing, expired, rejected, or disconnected login, the product can send a new website login link automatically when the customer's request needs that website. Retain the request and poll the new link's status between durable Wait steps. After the customer signs in and saves access, submit the retained request again. A new link creates a fresh connection; it never reopens the disconnected login. A missing block authorization still requires an Admin or Owner. See Website login links for polling and timeout handling.

Site notes

While helping a customer, an Agent block can propose a short note about how to operate a website, such as where a form field lives. Proposed notes are stripped of personal data and checked for secrets and instructions. Agents receive a note only after an Admin or Owner approves it in Websites and notes, and only in blocks set up for that website. Approval is available only in the app; no API or MCP tool can approve a note. A note that shows Unreadable with current keys can be approved only after you replace its text with Replace text to approve; otherwise, reject it.

Claude Code and Codex for end users

Each end user run gets a fresh, private CLI home and working directory, so one customer's session never contains another's. While an end user is present, a Claude Code or Codex block always runs without its shell, file, and web tools: runs share one server account, so those tools could reach another run's credentials. Claude Code keeps only the MCP tools you attach, and Codex runs read-only. A block saved earlier with Keep shell, file and web tools for end user runs turned on refuses end user runs until you turn it off in its End user memory section. A block that runs for an end user also cannot open a managed project workspace, use Claude Code's bypassPermissions mode, or use Codex's danger-full-access sandbox, and it never resumes an earlier session. Any credential value the run has resolved is replaced in the prompt before the CLI receives it, even when it arrives through another block's output.

When a Claude Code or Codex block lists approved hosts for its credentials (secretEgressHosts), the CLI sees each credential only as a {{secret:name}} placeholder and calls APIs through Confluye's http_request tool, which inserts the value only in HTTPS requests to a host approved for that credential and hides it from the response. Because the tool hides every run secret the server echoes back, a guessed value that comes back hidden would confirm the guess. Use long random tokens, such as API keys of 16 or more random characters, with this tool:

• A credential that is short, or that contains a short token, password, or JSON field (such as ["1234"] or {"pin": 1234}), is never sent.
• A credential that is easy to guess, such as an ordinary password like password1 or words with a year or a few digits, is never sent.
• While the run holds any short or easy-to-guess secret, including one resolved by another block or read from a saved website login, the tool refuses every request. The error does not say which secret caused it.

Review and erase an end user

An end user run started by a workspace member runs only while that member is still an explicit Admin or Owner; if they lose that role, the run is refused when it starts or resumes.

End users and memory lists your end users, newest first, 200 at a time; choose Load more end users to see older ones. Admins and Owners can open one to read their conversation, facts, work in progress, and website logins; edit or delete a fact or a turn; revoke a website login; or choose Erase end user. A fact value can have at most 300 characters; a longer value is refused rather than shortened. Owner edits containing credentials, cookies, authorization headers, sensitive URL parameters, or browser login links are refused. Every content read is recorded in the audit log; audit events name the internal end user ID, never the external ID or the content. Organization-derived access does not grant content access. While an erasure is in progress, the console shows the end user as being erased and no longer shows their content.

Erasing a customer — from the console, the erasure API, or the end_users.erase tool — cancels their open runs and deletes their conversation, memory, work in progress, pending site notes, and website logins in every workflow. Their past runs can no longer be re-run. Approved site notes that came from the customer are kept and marked for your review. If your product later sends the same external ID, it starts a new end user with no history, even when it repeats an earlier idempotency key.

If extraction or compaction is still processing that customer's memory, erasure is temporarily refused before it starts. Wait for those jobs to finish and retry. Once erasure starts, those workers cannot admit new provider calls; cleanup includes jobs whose conversation turns were already deleted.

Retention

Expired data is removed in batches. Each sweep deletes at most 200 recorded conversation turns across all customers; larger backlogs drain over subsequent sweeps.

Runs that are not end user runs

Only a product gateway key can name an end user. Schedules, webhooks, A2A calls, MCP publications, and ordinary workspace keys never create an end user or read customer memory, even when their input contains an endUserId field.

Manage end users with MCP and Command Center

With end users enabled, the platform MCP server and Command Center offer end_users.list, end_users.get, end_users.update_fact, end_users.delete_fact, end_users.erase, memory_resources.list, memory_resources.create, memory_resources.connect, memory_resources.disconnect, memory_resources.delete, site_notes.list, and site_notes.get. See the Platform MCP reference.

Next steps