Isolate multiple email agents with inboxes, projects and keys

Separate responsibility before counting addresses

Two workers can share a queue while serving one communication identity, or they can represent different agents with different audiences and policies. Those cases need different designs. A shared support address can work when workers are interchangeable and one durable system assigns each case. Independent purchasing and support agents usually benefit from separate inboxes because their recipients, attachments and review rules differ. Do not use the number of running model processes as the only reason to create addresses. Start with who is accountable for the communication and who may access its context.

Use projects for tenant namespaces

A project contains its own inboxes, threads, drafts, domains, webhooks, lists, metrics and API keys. Use separate projects when your application needs a customer or tenant namespace inside one workspace, then bind each worker to its authorized project or inbox. Org-level routes can span projects for an appropriately authorized operator, while scoped keys remain fenced to their resources. Keep project_id in local queue and case records so a thread ID from one tenant cannot be scheduled under another tenant’s credential. Metadata labels alone cannot enforce this isolation.

Provision with owner authority

Autonomous registration creates a separate bounded workspace and default inbox, but its bootstrap key cannot create more inboxes or mint keys. An owner-authorized credential provisions additional inboxes within the actual plan limits and issues child credentials whose authority cannot exceed the parent. A project key can create inboxes in its own project when permitted; an inbox key cannot create another inbox. Save a stable client_id for each provisioning intent. Do not create extra autonomous workspaces to evade quotas or treat registration as a substitute for deliberate tenant administration.

Coordinate shared work without duplicate replies

If multiple agents process one inbox, assign a durable work-item owner or claim before drafting or sending. Webhook duplication and overlapping polling can otherwise make two workers independently reply to the same message. Use message identity for local work deduplication and an approved send identity for external-action recovery. A custom claimed label can help humans see progress, but it is not a transactional lock. Keep the authoritative claim in application storage and define what happens when a worker dies while holding it.

Plan revocation and handoff

A separate scoped key lets an operator stop one agent without rotating every worker’s credentials. Store credentials by tenant and agent role in a secret manager, never in a shared model prompt. Before moving a case between agents, preserve provenance and confirm the destination agent has authority to see its source data. Durable production organization moves are unsupported; an organization ID is not a transfer mechanism. Your next step is an ownership table mapping each inbox to its project, responsible workflow, delegated key and human reviewer.

Choose a pilot boundary

Try one shared support inbox with a single durable case-claim queue, and a second inbox for a distinct workflow that has different recipients. Compare operational clarity rather than raw inbox count. If a worker can read a customer it does not serve, narrow the key scope before adding more model-level routing rules.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin projects ↗Checked 2026-11-05
• Lupin API-key authority ↗Checked 2026-11-05
• Lupin organization move boundary ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.