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. A key with run permission names at least one workflow the product may run; an erase-only or export-only key has no workflow allowlist (see API keys). A memory key stands alone and names the workflows whose memory resources it reaches. Settings does not offer this scope in the create dialog, but its API keys list shows each key's permissions.

5. 5

   Call the workflow from your product

   Send customer messages to POST /api/v1/workflows/{id}/execute with endUser.externalId and message. For a product event that should use the agent's memory without becoming a conversation turn, send mode: "event" and omit message (or include one to rank relevant facts). Both modes share the end user's FIFO; event runs have a shorter active-turn execution limit (five minutes by default), after which a run still holding the turn fails. See the End users API for the request, polling, and error contract.

When the reply block is Agent, Claude Code or Codex CLI, a product can display provisional assistant text as it is generated through the run-status API. Agent blocks retain their configured API model and provider. Resolved credentials are redacted; reasoning and tool output stay private. Provisional text can describe work in progress and does not prove that a record was saved. The completed reply remains the conversation's stored answer. Products can opt into server-sent events on the same authorized status endpoint to receive fragments over a continuous HTTP connection, with JSON status reads available for recovery. This uses the same model, credential and permissions, without another model call. A policy requiring whole-answer classification, schema validation or denial of sensitive output waits for the complete answer; an adapter that has no incremental text also returns its completed answer.

Manage instructions for one customer

In the owner console, open a customer and use Skills for this end user. An explicit workspace Admin or Owner can create, edit, enable, disable and delete these instructions. They apply automatically to that customer's Agent, Claude Code and Codex blocks alongside selected workspace skills, even without a memory resource. The customer, workspace and active generation come from the persisted run; workflow input cannot select another user's skills.

These are instructions you manage, separate from the customer's untrusted conversation and facts. They give the agent no additional tools or permissions. A queued or resumed run loads current enabled skills during preparation; a model or CLI call already in progress keeps its existing instructions. Skills belong to the workspace or to one end user; there is no agency level. Skills explains the editor, size limits and revision conflicts. Export includes enabled and disabled skills; whole-user erasure deletes both.

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. Each fact also says whom it is about, and a run receives only the facts it may use; see Remember customers separately.
• 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.

Fact extraction and conversation summaries run in the background. For a marked Claude Code or Codex reply block, they use that run's pinned provider, model and execution principal in a fresh customer CLI home, without tools. The worker checks the fixed model against the CLI catalog before inference and rejects an unexpected reported response model before saving memory. Only the assistant's answer is used; CLI events are not memory content. The provider must finish its turn successfully with a nonempty answer. Missing completion, malformed or truncated output, and a timed-out call fail the job without saving facts or a summary. No separate hosted AI provider is required for those runs. Other reply blocks use the configured workspace AI provider. The provider must be enabled and its credential available; otherwise that background work is skipped.

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).

Remember customers separately

Some products serve people who work with many clients of their own, such as a real-estate agent using your CRM. There the end user is the agent, and the clients are customers of that agent. Confluye then keeps every durable fact attached to whom it is about, inside the agent's partition:

• Agent: what the agent says about themself, in their own words and in the first person: "I prefer calls in the afternoon". It is given to every request of that agent.
• Customer: what is remembered about one customer your product selected for the request. It is given only when that customer is the one selected. Two customers can hold the same kind of fact, such as a city or a language, at the same time.
• Unclassified: facts saved before this scope existed, and facts Confluye cannot place with confidence, which are stored as proposals. They stay visible to you and to your product for review and in exports, but no run is given them as an agent preference or as a customer fact.

Selecting the customer. Your product sends productContext.selectedCustomerExternalId when it starts the run, from its authenticated backend and after its own check that the person may see that customer. It must be one of the run's subjectExternalIds; that list is the set of people the request touches, which erasure walks, and is never taken as the selection, even when it holds a single ID. Neither a message, the workflow input nor the model can choose or change the customer. A request with no selection, such as one from an older client or a message where no customer is chosen, receives only the agent's own preferences and the work in progress kept for no customer, and no durable fact or work record of any customer. This limit covers customer-scoped durable facts and work records only: the recent conversation and its rolling summary remain agent-wide and may contain customer information, selected or not (see What it does not separate). Removing the customer from a request never carries the previous one over. See the API reference.

What a request receives. With a customer selected, the memory block shows that customer's facts under their own heading, then the agent's own preferences, then the work in progress kept for that customer. It never contains another customer's facts or an unclassified fact. The end_user_memory.search and end_user_memory.propose tools follow the same rule, and a fact proposed during a run with a selected customer is about that customer, still waiting for review.

How facts are placed. The background extractor says whom each fact is about, but that label is only a claim. Confluye checks the quote's sentence and the source message against it. A fact can be stored for the selected customer when the run has a trusted selection, the quote is not the agent's own statement, and the source does not name another person or include another person's reported words. "My client prefers…" or "Mon client préfère…" by itself is not an agent-self statement: a possessive alone ("my", "mi", "mon") never establishes who is speaking. With a selected customer and no other named or reported person in the source, that same kind of customer-labeled fact can remain the selected customer's fact. The selection still comes only from your authenticated backend, never from a name or ID in a message.

The agent's own fact requires a first-person sentence from the agent's message, with no quotation, reported speech or other party in that sentence. Customer screening keeps the full source context, so a named person before an abbreviation, semicolon or reporting line can keep a later quote from being assigned to the selected customer. This can conservatively leave a valid deictic fact as a proposal when an unrelated person appears elsewhere in the same source. Confluye does not map names to the selected ID: "Mi cliente Bruno prefiere…", "Mi cliente Julio prefiere…", "My client X prefers…" and "Ana prefiere… y Luc prefiere…" wait as unclassified proposals. A sentence that points at the current record ("Este cliente busca viviendas en Sherbrooke") names nobody, and a city or language is not a name, so it can remain that customer's fact when the source is otherwise safe. Name detection is conservative and does not understand every language; when in doubt, the fact waits for a person. A fact drawn only from the reply of a turn that read external content still waits as proposed. A person's correction is protected: when an extraction job that began earlier finishes later, it can only leave a proposal linked to the corrected fact.

Correct, classify and delete. An Admin or Owner reviews and edits facts in the owner console, where each fact shows whom it is about. Your product can let the agent do the same from your own screens with a memory key: see what is remembered, correct a value, move an unclassified fact to the agent or to a customer, or delete it. A correction sends the revision that was read; if the fact changed meanwhile, nothing is overwritten and the current value is returned so the person can decide again. A customer's fact is reached only by naming that customer: a correction or deletion that leaves the customer out, or names another one, answers "not found" before any revision or content is compared, so a request cannot change a customer's fact without saying which customer it authorized. The agent's own facts and unclassified facts take no customer. Every change is audited without its content. Classifying a fact keeps the erasure tags it already had and adds the customer you chose, so it is read only as that customer's, but erasing a person the original conversation also named still removes it. When your backend calls this route for a run, it names that run, and only the memory resources the run was admitted with are reached.

A deleted fact stays deleted. Deleting a fact leaves only a fence of IDs and a position in the agent's queue, never the value. A memory job that was queued before the deletion, even one whose reply is recorded afterwards, can no longer write that fact back, a reworded version of it, or the same statement under another scope. A message the person sends after the deletion is a new request and may teach Confluye the fact again.

Erasing a customer. Erasing a subject deletes the facts about that customer wherever they are in the workspace, the work in progress kept for them and the runs that name them, and a memory job queued earlier cannot restore them. A fact is tied to whom it is about, not to everyone a conversation mentioned: the agent's own preference that came from the same turn as an erased customer stays, and so do other customers' facts. They keep the IDs of the turn and run they came from (IDs only, never the erased conversation), so a later erasure that lists that run can still find the facts it applies to. A fact Confluye could not place stays tied to everyone the turn named and is erased with any of them, and so is one a person classified afterwards without changing its text. When an agent created the customer during a turn that named nobody, your backend can list the runs it trusted for that customer in the erasure request (source, see the End users API): the facts that could not be placed and the conversation and work in progress of those runs are erased too, also after the run itself was removed. Listing a run applies the same erasure scope to the facts from that run; it does not delete every fact the run produced, and the agent's own preferences and other customers' facts from those turns stay. Exports show each fact's scope and source IDs.

What it does not separate. The recent conversation and its rolling summary belong to the agent's conversation and can mention several customers; selecting a customer does not filter them. Tables, knowledge bases and attached tools stay shared too, as in the warning above. Treat the selection as scoping what the assistant remembers about each customer, not as a barrier between customers inside the conversation. Facts written before this scope are not moved to an agent or a customer on their own; classify them to use them. The scope has been exercised only with synthetic data; test it with synthetic agents and customers before you rely on it.

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. Confluye identifies an end user only by the external ID your product sends and knows nothing about the channel. A product that sends the same ID for its web chat and for a linked Telegram chat gives both channels one partition, one order and the same remembered facts; a different ID is a different end user, even in the same workspace. 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. These browser tools return text only, with login values redacted. Registered Website routine blocks can separately produce private document references; your backend retrieves the bytes through the run's artifact endpoint, never through a model tool. 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; see Use a saved website login for the member side. A login is a saved session, not automatic sign-in: when it expires, the customer signs in again through a new link.

An error on the site's account page stops execution without treating the saved login as expired. Retry after the site is available again. A signed-out account or a different account still requires reconnection; an unavailable page never proves that the saved account is valid.

If the first Save cannot verify an account because the site is unavailable, reopen the connection and try saving again after the site recovers. The profile is retained; the connection becomes ready only after the account is verified in a fresh browser context.

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. The failed run records no reply, and the next retention sweep deletes the parked turn of a run that ended, so keep the original request in your product and submit it again only after the customer reconnects; reconnecting never replays it for you. See Website login links for polling and timeout handling.

Registered website routines

A Website routine block executes one deployed script by ID, version and validated parameters with the run's own end user login. The script controls its browser steps without model calls per click. An explicit Admin or Owner authorizes this block's website control grant; another block's grant does not carry over. The site's allowed hosts apply to redirects and resources as well as the main page.

Use a separate invoked workflow for these tasks. Your assistant can ask for missing fields before starting it, and ordinary conversations remain usable without that website login. Read, document preparation and sending are distinct routines; the product must obtain approval of the exact content before an external send or change. A routine that reports needs_input has questions to resolve. An in_doubt outcome must be reconciled before retrying a possible external effect.

The worker includes Espace Centris adapters for observed listing status, listing document names and selected document collection, plus a Matrix Concierge queue reader. The queue reports complete coverage only when its unique observed listing IDs match the pending count, or that count is zero; count mismatches and duplicate IDs remain partial. It does not infer unseen overview pages or approve or send selections. A canonical queue not visible initially is searched across at most ten overview pages using supported same-page next links. Unsupported pagination still needs clarification. Listing status comes from the verified listing header; a document title is not evidence of that status. To read a Concierge queue, provide its canonical alert reference and exact contact name. A subject alone returns a question with the references observed on the current overview page, since another page may have an alert with the same subject. Resolve that question before continuing. Purchase-offer preparation version 2 accepts an explicit empty list for inclusions or exclusions; seller-contract preparation version 2 accepts an explicit empty inclusions list. Omitting these required fields still asks a question. Version 1 remains available with its original nonempty-list rules; a request keeps its exact version. Documents, recipients and signers still require at least one selection. These two preparation contracts remain undeployed; this validation change does not create a contract or send a signature request.

Other catalog contracts do not become executable until their adapters are deployed. The browser/RPC tests use synthetic pages; those tests do not certify a real Centris download, Matrix, TransactionDesk or Authentisign. See the block configuration and private document retrieval.

Mailboxes and calendars for end users

Your product can have an end user, for example a real-estate agent using your CRM, connect their own Gmail or Outlook mailbox and calendar to Confluye. Your product asks for a one-use link with the mailbox connect requests endpoint and sends the person's browser to it from inside your own signed-in session. The person needs no Confluye account: they approve read-only access by default at Google or Microsoft and come back to your product.

For business accounts hosted elsewhere, your product can offer another mail provider and collect the provider's IMAP settings over its own authenticated connection. Confluye verifies TLS and credentials before saving the account, then uses the same isolated mailbox, signed deliveries and attachment actions as Gmail and Outlook. Reading uses IMAP on port 993; sending is optional and needs explicit SMTP authorization (TLS on 465 or mandatory STARTTLS on 587), followed by the usual review of each exact draft. This connects mail, not a Confluye account. An IMAP mailbox has no calendar: connect a separate Google or Microsoft account for appointments. See Other mail providers for setup, limits, encrypted credentials and reconnection.

The deployment must have the provider's OAuth application and the requested permissions enabled. If either is unavailable, the product receives a refusal before redirecting the person to a private link. For Google, the deployment administrator must register the OAuth client. Registered clients allow connections by default; an explicitly verification-only client also requires approved scopes or an authorized verification audience. Issuing another link does not change that policy or any restrictions imposed by Google.

• What is read. Mail (inbox and sent) and calendar events, read-only, and only the ones your product's link asked for (mail, calendar or both). Reading access cannot send, change or delete anything. The first read covers the last 90 days of mail (bounded). Calendar sync starts 30 days in the past and reaches 180 days into the future, with at most 500 events in that initial sync. Google and Outlook renew their bounded calendar windows when fewer than 14 days remain, so events farther into the future become available as the window rolls forward. Legacy Google cursors without a recorded window end restart their bounded sync once. Google follows its calendar sync cursor within the initial 30-days-past/180-days-future window. After the initial sync, each provider reports changes within its window.
• Who holds the credential. The sign-in belongs to the end user, not to a workspace member, and is stored encrypted apart from workspace credentials: no workflow block, mail route or integration picker can select it.
• How your product receives it. New mail and calendar changes arrive as signed mail.batch deliveries, confirmed by cursor, to the mail batch URL of your product connection. Confluye reads each message from the provider only when it sends the batch and never stores it. No workflow run, Agent block or model reads the messages.
• If the person withdraws access. The connection moves to needs_reauth: your product sees it and sends a new link.
• Disconnecting. Your product can list a person's mailboxes, see the connected address and state, and disconnect one, for example when it removes a member. Once DELETE completes, no new deliveries will start; a mail.batch delivery already in flight may finish before the response returns. Confluye deletes the address and the cursors, drops what was not yet delivered, and withdraws the grant at Google. The credential is deleted when Google confirms. If Google cannot be reached or does not confirm, the mailbox still reads as disconnected and nothing more is delivered, but Confluye keeps the sealed Google credential, solely to retry the withdrawal with a growing delay (and again on every repeat of the disconnect). It is deleted when Google confirms, or after 7 days at the latest, even if Google never does. Any unfinished reconnect link that names the deleted mailbox also expires, so its callback cannot connect a different account. Erasing the customer deletes the mailbox record together with any credential kept for a retry. Erasure logs an aggregate warning when the provider still has not confirmed withdrawal; the customer can remove Confluye from their provider account. It does not retain the customer's mailbox credential after erasure. If a sign-in the person started finishes just after their erasure, Confluye withdraws that new grant; if Google does not confirm, the sealed credential is kept apart from the erased customer (no ID, address or mailbox) only to retry the withdrawal, and is deleted when Google confirms or after 7 days. The person can also remove Confluye from their Google or Microsoft account at any time, which ends the grant whatever the retries do.

Connected mailboxes appear in a customer's data export as metadata (provider, address, state, dates), and erasing the customer disconnects and deletes them.

Let the agent prepare an email

A product can separately request permission to send from the person's own connected mailbox. Existing connections stay read-only until the person approves that additional permission. Have the assistant prepare an editable draft and return a link to the product's review screen. The person reviews the recipients and message and presses Send; the model never receives mailbox credentials or approves its own draft. The product submits the approved version through the mail sending endpoint. It reports the provider's acceptance or an uncertain result and keeps one durable approval key to prevent duplicate sending after a retry. This permission does not permit changing or deleting existing mail.

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

End-user chats prepare a private copy of the saved AI login, so a long workspace CLI task such as a code review does not hold up their credential preparation or CLI execution when the saved login is current. A login that needs renewal, or whose expiry cannot be established, still uses the workspace lock to prevent competing token renewals. A missing login still blocks the chat. Plan concurrency limits, conversation ordering, current permissions and model checks still apply; this does not guarantee an immediate reply when the model or another required service is busy.

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.

Credentials from a private 1Password vault

A workspace Owner can let a Claude Code or Codex block use a credential stored in one 1Password vault, for an end user's run, without the model, the CLI or the run history ever holding its value. An Owner sets it up in Settings → Environments → Private credentials (1Password); other roles see only a note that it needs an Owner. It has been exercised only against a test fixture, not yet against a live 1Password vault. Check it with a synthetic vault before you rely on it.

1. In 1Password, create a service account that can read only a dedicated vault. Add an item to that vault, and set its website to the API host the credential is for.

2. In Connect a vault, enter a name, the vault ID and the service account token, then choose Connect vault. The token is encrypted and the page clears it as soon as it is saved; it is never shown again, so keep it in 1Password. If saving fails, your entries stay in the form so you can retry. Connected vaults lists each vault ID with whether it is enabled and configured, and lets you disable or enable it.

3. In Grant a credential, choose the vault and the workflow, then enter the 1Password item ID, the field ID (password for the password field) and the end user ID. Use IDs, not names. A grant covers one workflow, one item field and the end user's current generation. Granted credentials then shows the reference, in the form op:<binding>/<item>/<field>, and a Revoke button.

4. In the block, approve hosts for that reference in secretEgressHosts, and write the reference as a placeholder in the prompt. The model sees only the reference.

   { "op:<binding>/<item>/<field>": ["api.example.com"] }
   

   The prompt then uses {{secret:op:<binding>/<item>/<field>}} where the credential belongs.

To call an API without a model in between, use the 1Password block instead: it appears under Developer Tools in the block catalog, lists the credentials granted to the workflow and takes the one allowed host and where the credential goes (a Bearer or Basic Authorization header, a named header or a JSON body field). It does not browse or search the vault and never returns the value. See 1Password (authenticated request). Only an Owner sees the list of granted credentials, which holds references and names and never values; another role can still enter the reference an Owner shares.

Confluye reads the item again for every request and keeps no value between requests, so changes apply to the next call: Revoke removes a grant, and Disable stops every reference through that vault. The vault and the grant are checked again after the request is prepared and immediately before it is sent, so a revocation, a disabled or replaced vault, a new token or an erased end user stops a request that has not been sent yet. A request already on its way is not recalled.

• The request host must be both approved in the block and listed as a website of the 1Password item. An item with no website is refused.
• The other protections of the HTTP tool still apply: HTTPS only, no redirects, and a short or easy-to-guess value is never sent. Failures say only that the credential is unavailable or that the provider did not answer.
• If a block reports that the credential is not available, an Owner checks Granted credentials for this workflow and end user and grants it again if it was revoked or the end user was erased; a disabled vault is enabled in Connected vaults. If the provider refuses its service account, connect the vault again with a new token and grant again.
• Only runs for an end user can use a reference. A schedule or any other run without an end user cannot, because using a shared credential would need a separate service authority that is not available; those runs fail closed rather than fall back to an end user's permission.
• Erasing the end user deletes their grants. An end user who returns with the same external ID starts with none. Grants hold references only, so they are not part of the data export.
• The workspace Owner (manage-secrets) manages bindings and grants. A 1Password binding is not available as an environment secret binding.

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 (with whom each is about, including unclassified ones that no run receives), 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. Wait until all running subject erasures in this workspace finish before deleting memory facts. This also protects revision history that an erasure has not captured yet. 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, website logins in every workflow, connected mailboxes and calendars, and the callbacks and mail batches to your product that were still waiting to be sent. 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.

Your product can also erase through the API every end user of one of its tenants by external ID prefix, after a dry run and a confirmation token, and erase a subject that is not an end user (for example a CRM contact) together with the runs that name it, the memory facts tagged with it or kept for it as a customer, the work in progress kept for it, and those runs' conversation turns and last-written work in progress. The affected agents' rolling summaries are cleared; their other turns and facts remain. Information from runs that did not name that contact cannot be attributed to it. Erasing a customer also erases the runs that name them as a subject, including runs your product started with a workspace key. A product with an export key can read what is stored for one customer: memory, skills and credential-redacted data of their own runs, including event input and optional messages. Subject-only runs expose metadata. Retained operator diagnostics need separate workspace review for an access request. See the erasure and export API.

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