An agent can use AgentID to sign in to Supermemory with its own AgentMail inbox identity. That gives its memory workflow an account separate from a person's login, and the sign-in disclosure carries two different addresses: the agent's, which identifies the inbox it uses, and the owner's, which identifies the human behind the AgentMail organization.
In short
- AgentID supplies a verified inbox identity through OpenID Connect at sign-in.
- The agent address and the owner address are distinct fields with distinct jobs.
- Disclosure alone does not establish which policies Supermemory applies to either.
- Account login does not configure memory access, retrieval, or runtime credentials.
- The workflow below is proposed. Confirm current requirements with Supermemory.
Why does a memory service need a consistent account identity?
Consider a research agent that revisits the same topic each week. It needs to find earlier material, distinguish old findings from new ones, and keep enough context to avoid repeating the same work.
Supermemory provides storage and retrieval for information an agent needs beyond a single conversation. A memory service can support that application, but the account behind it needs continuity too. When the agent returns, it should enter the account holding its configured access, rather than borrow a person's browser session each time.
AgentID is AgentMail's sign-in service for AI agents. It lets a participating app recognize an agent through a verified inbox identity using OpenID Connect, and the inbox remains usable for account email. Using the same inbox preserves the identity the service receives on later sign-ins.
How do you verify who owns an agent when the account uses a different email address?
This is the question the Supermemory sign-in makes concrete, because the disclosure carries both addresses at once.
The AgentID option starts at Supermemory's console. The sign-in disclosure requests the agent's name and email and the owner's name and email.
The two addresses have different purposes, and conflating them is the mistake worth avoiding.
The agent's address identifies the inbox it uses. It is the account's own address, the one the agent can read and reply from, and the thing AgentID derives the stable identifier from. It is deliberately not a person's address.
The owner fields identify the human behind the AgentMail organization. They exist so the receiving service is not left with an account it cannot attribute to anyone. This is why an account created with an address that is not a person's does not have to be an anonymous account.
Disclosure is not the same as policy. Supermemory receiving those fields tells you the fields were requested and approved. It does not establish which internal policies Supermemory applies to them, and this article does not claim it does. If you need to know how a service treats owner data, ask the service.
Owner disclosure also needs the matching permission on the AgentMail credential authorizing the sign-in, so it is a deliberate grant rather than something that happens by default.
Who controls what
| Stage | AgentID | Supermemory |
|---|---|---|
| Identity at sign-in | Supplies verified agent email and stable identifier through OpenID Connect | Accepts the sign-in, runs account setup |
| Owner disclosure | Supplies owner name and email when the credential permits it | Requests the fields, applies its own policies to them |
| Returning to the account | Same inbox returns the same identifier | Restores the account |
| What memory is stored and retrieved | Not involved | Owns storage and retrieval |
| Memory collections and scope | Not involved | Configured by the application |
| Runtime and MCP credentials | Not involved | Documents and issues them |
| Account notifications | Provides the inbox behind the identity | Decides which messages it sends |
What does account login not decide?
After sign-in, follow Supermemory's setup instructions for the memory interface your application will use. Account login does not decide which documents belong in a memory collection, configure retrieval, or supply a provider credential to the agent's runtime.
AgentID extends the agent-native experience to sign-in, so an agent can identify itself before its application configures memory access. Supermemory manages memory storage and retrieval.
For a first application check, use a harmless note with a fact you can recognize. Store it through the configured memory interface, then ask the application to retrieve it in a later session. This is a suggested validation exercise, not a reported benchmark.
How does the agent stay reachable?
An agent-owned account still needs an address for account communication. AgentMail provides the inbox behind AgentID, so the agent has a way to receive messages addressed to it. Supermemory controls its own notifications and account requirements.
Start at Supermemory and use the AgentID sign-in guide to prepare the inbox. If your agent uses MCP, follow Supermemory's MCP documentation for that interface's authentication and setup.