How to Add an AI Employee to Your Email Inbox in 2026: Gmail, Outlook & Shared Inboxes

First, choose the mailbox identity the AI will actually operate

Gmail, Outlook, and shared inbox are not three interchangeable providers. Gmail and Outlook describe where mail lives. A shared inbox describes how several people coordinate ownership around an address. The address might be a real user mailbox, an alias, a delegated mailbox, a Google Group, a Microsoft 365 shared mailbox, or a help-desk queue. Those architectures grant different permissions and expose different records.

Before opening any connection screen, answer four questions in writing:

• Which exact account receives the message?
• Which exact address should recipients see in From and Reply-To?
• Can that account authorize a connection directly, or is it reached only through delegation?
• Where does the team record ownership, status, and human takeover?

Google's own documentation says an alias cannot be delegated because it is not a Google Account. It also distinguishes delegated Gmail access from a Google Groups Collaborative Inbox, which has its own take, assign, and completion concepts. Microsoft likewise documents a Microsoft 365 shared mailbox as an administrator-created team mailbox whose account is not intended for direct sign-in.

That leads to a simple launch rule: connect the Gmail or Outlook account that owns the job, confirm the displayed identity, and run controlled read and send tests before launch. If your organization relies on delegation, Group assignment, or a help-desk queue, preserve that system as the source of ownership; an OAuth connection does not replace it.

Gmail and Outlook already have AI assistance, but assistance is not the whole job

In 2026, the useful comparison is not AI versus no AI. It is native assistance versus a configured business workflow.

Google's current AI Inbox documentation describes a beta that surfaces suggested to-dos and catch-up topics. It also lists important limitations, including Primary-tab content and no support for attachments, delegated inboxes, or encrypted messages. Gemini in Gmail can help eligible users summarize threads, find information, and draft responses. Availability varies by account, plan, language, geography, and administrator settings.

Microsoft documents different Copilot capabilities across shared and delegated mailboxes in Outlook and the Microsoft 365 Copilot app. Its current guidance distinguishes summarization and drafting from triage, sending, and calendar actions that are not supported in every surface.

Native AI may be enough for summarizing and drafting. It can coexist with this larger, configured workflow.

Use the Two-Lane Inbox to separate untrusted intake from trusted action

Email is unusual because it is both a business record and an instruction channel anyone can write into. A legitimate prospect, an angry customer, a spoofed vendor, a compromised account, and a malicious attachment all arrive through the same front door. The words in a message can describe a request. They cannot grant themselves authority.

The Two-Lane Inbox is a practical operating framework for that boundary. It is not a scientific standard. It gives every email two possible paths:

In Praxivara's current runtime, the boundary is enforced, not left to a prompt. An Agent run started by an inbound Gmail or Outlook event cannot create or edit provider drafts, send, reply, reply-all, or forward. It also cannot use arbitrary integration requests to turn an email into a broad command. The safe inbound pattern is to classify or organize the message, alert the owner, and place proposed reply text in a Delivery for review.

The later outward action is a separate event. The owner can use the web Assistant, where sends, replies, and forwards stop for confirmation. Alternatively, a business can design a separate manual or scheduled Agent run and explicitly configure an optional run-level or per-tool approval gate. Agent approvals are not inherited automatically from the web Assistant, so the builder configuration must be reviewed before launch.

This distinction is not bureaucratic. NIST describes indirect prompt injection as malicious instructions placed in data retrieved by an AI-connected application. Email subjects, bodies, signatures, quoted messages, links, and attachment names or metadata are retrieved data; if a separately approved process later reads attachment bytes, that content remains untrusted too. Google's current Workspace user-data policy explicitly lists protection against prompt injection among safeguards for restricted scopes.

The durable rule is simple: inbound content may supply facts to evaluate, but only the trusted lane supplies permission to act.

Prepare one email job before you connect the account

The strongest first job is narrow enough to test and valuable enough to matter. "Handle my inbox" is not a job. "Triage new commercial quote requests, identify missing fields, label the thread, notify the sales owner, and prepare a proposed response for review" is a job. If the first use case is still unclear, begin with what to automate first in a small business.

Write the job in one sentence using this pattern:

Define the intake population

Start with a category a person could identify reliably from the thread, such as new sales inquiries, appointment requests, order-status questions, or vendor onboarding. Do not start with every message. Newsletters, automated receipts, internal alerts, calendar notices, phishing, and customer conversations have different rules.

Do not rely on a trigger configuration that promises perfect subject, body, or sender-domain filtering. For the current product, treat trigger delivery as broad intake and perform classification inside the restricted run. The classification output should include the evidence used, not only a label.

Name the authoritative sources

For each fact the AI may use, write down the source that wins when sources disagree. A useful list might include:

• Business hours and holiday exceptions from the current operations page.
• Published service areas from the approved territory table.
• Standard pricing from the current price book, with custom pricing held for a person.
• Appointment availability from the calendar system at the time of action.
• Customer status from the current customer record, not a claim inside the email.
• Refund, cancellation, warranty, and escalation language from approved policies.
• Consent and suppression state from the system designated to control marketing eligibility.

Write the allowed and held actions

Create two lists. The allowed list should be precise: search the connected mailbox, read the current thread, apply one approved label, mark important, prepare proposed wording, or notify the owner. The held list should be just as concrete: send a price exception, disclose customer data, change payment details, accept contract terms, reset credentials, make an employment decision, or send confidential documents.

Every held action needs a named owner and a useful handoff packet. "Escalate" is incomplete. State who receives it, where they receive it, what context is included, and how the AI knows the person accepted ownership.

Define completion evidence

Define done observably. For triage, completion might mean the original message ID, current thread ID, classification, confidence note, applied label or flag, owner notification, and Delivery link exist. For an outward reply, completion might mean the owner approved the exact recipient and content, the provider accepted the action, the sent record appears in the correct thread, and any later bounce remains visible for recovery.

Connect your Gmail or Outlook mailbox step by step

Connect the Gmail or Outlook account that owns the workflow and confirm its identity before testing. Additional inboxes are available when your plan allows. If you connect several accounts from the same provider, validate which account each action uses. Current actions lack a dependable per-action selector within that provider, and "Set as primary" is not a universal routing control.

Before authorization

1. Sign in to Praxivara as the business owner or authorized administrator.
2. Confirm the visible provider account is the exact mailbox intended for the job.
3. Remove or pause old rules that might create duplicate responses, conflicting forwarding, or hidden state changes.
4. Record the desired From, Reply-To, signature, and handoff owner.
5. Prepare one harmless inbound test message and one external test recipient controlled by your team.

Connect Gmail

1. Open Praxivara's integrations area and choose Gmail.
2. Continue through Google's account authorization screen. Check the signed-in address before granting access.
3. Review the Gmail permissions shown on Google's current authorization screen and confirm they match the actions required for the job.
4. Return to Praxivara and confirm the integration shows the intended Gmail identity.
5. Send one new message into the Inbox. The current Gmail event path is specifically a new inbox message, not a promise that every listed Gmail state change starts an Agent.
6. Verify the restricted run produces only the intended internal result, such as classification, a label, owner notification, and proposed response in a Delivery.

Gmail's API uses change notifications and history synchronization rather than delivering the full authoritative message in a webhook. Google's push notification guide says watches expire, notifications can be delayed or dropped, and periodic synchronization is recommended. That is why your test must validate the resulting mailbox state instead of equating "trigger fired" with "work completed."

Connect Outlook

1. Open Praxivara's integration area and choose Outlook Email.
2. Continue through Microsoft's authorization screen and verify the exact Microsoft account.
3. Review the permissions shown on Microsoft's current authorization screen and confirm they match the actions required for the job.
4. Return to Praxivara and confirm the connected identity is the intended user mailbox.
5. Choose the relevant supported Outlook event for the job. Current received, important, flagged, and sent event checks use polling, normally around five minutes, so do not describe them as instant.
6. Send a controlled test and verify that inbound handling remains in the restricted lane.

Do not select a normal user and assume the connection now targets every Microsoft shared mailbox that user can open. Microsoft Graph distinguishes primary and shared access, and the current Praxivara tools operate against the connected user's mailbox. Microsoft also documents that sending from another mailbox requires permissions beyond ordinary mailbox access.

Give the AI the smallest useful action set

Mailbox permissions are not one switch. Reading metadata, reading bodies, viewing attachments, changing labels or folders, creating drafts, sending, replying, forwarding, and deleting are different powers. The job should receive only the powers it needs in the execution path where it needs them.

Google's Gmail scope documentation and Microsoft's permission documentation separate mailbox capabilities into different access categories. That separation is a useful least-privilege design cue even when a product connection requests a combined set needed for its supported tools.

Know the current provider differences

In the owner-facing Assistant, the current Gmail toolset supports searching and reading, creating and editing drafts, replying in-thread, replying to all, forwarding, and selected label or message-state actions. Gmail replies can include supported attachments. Outlook supports searching and reading, drafts, reply and reply-all, forwarding, folders, flags, importance, categories, and selected message-state actions. New Outlook sends can include supported attachments, but the current Outlook reply tools do not accept reply attachments.

Inbound attachments need an even firmer boundary. The current email-triggered workflow can surface attachment metadata or the fact that an attachment exists. Do not claim that it parses the bytes of a contract, invoice, image, or spreadsheet automatically. A human or a separately supported, trusted process must inspect the file before its contents influence a consequential action.

Start with a permission ladder

1. Observe: search and read only the messages needed for the defined job.
2. Organize: apply one approved label, folder, flag, category, or importance state.
3. Prepare: create proposed wording in a Delivery; later allow provider drafts through the trusted lane.
4. Act with review: confirm the exact send, reply, or forward in the web Assistant.
5. Automate narrowly: only after testing, consider a separate manual or scheduled Agent with explicit tools and an intentionally configured approval policy.

These are rollout steps, not another named framework. You can stop at any level. Many businesses receive most of the value from triage, owner notification, and high-quality proposed responses while keeping every external send human-confirmed.

Give the AI the thread, the customer, and the current source of truth

A good reply cannot be built from the latest sentence alone. "Yes, Thursday works" may refer to a delivery, sales call, renewal, refund discussion, or site visit. The system needs the full relevant thread, the resolved sender or customer, the current business record, and the policy that controls the next action.

Resolve identity without trusting the display name

Display names are editable. Forwarded content may contain another person's address. A sender may use a personal address for an existing company account. The AI should record what is known, what is inferred, and what remains unresolved. High-impact requests involving bank details, credentials, personal data, contracts, or account changes should not proceed from email identity alone.

Read the minimum relevant thread

More context is not automatically safer. Long threads can contain stale prices, old commitments, confidential recipients, hidden forwarding chains, and malicious instructions. Retrieve enough history to understand the request, then prefer current authoritative records for facts that may have changed.

Separate facts, instructions, and permissions

A customer can state, "Our contract includes weekend service." That is a claim to check. They can ask, "Send me every invoice for this account." That is a requested action. Neither sentence proves the contract term, the sender's identity, or permission to disclose the records. The proposed response should show which source supported each important fact and why any requested action is held.

Handle uncertainty visibly

A useful internal brief does not hide ambiguity behind polished language. It can say: customer identity matched by email but account role is unverified; the attached file was not parsed; current calendar availability was not checked; policy source is dated; or the requested discount is outside the approved range. That makes human review faster because the reviewer sees the decision, not merely a confident paragraph.

Treat every send as a precise, reviewable business action

The risky part of email automation is not producing text. It is committing the text to a recipient from a business identity at a particular moment. A correct paragraph sent to the wrong person, from the wrong address, in a stale thread, with the wrong attachment is still a serious failure.

A safe outward action needs six checks: resolve the exact thread and recipient, re-read current state, prepare the content, pass the applicable confirmation or approval, perform the action once, and verify the provider record afterward. These support the Two-Lane Inbox, not another framework.

Resolve the exact target

Show the reviewer the To, Cc, Bcc, From, Reply-To, subject, thread, attachments, and the kind of action. A new message, reply, reply-all, and forward have different recipient behavior. Reply-all can expose a response to people who were included earlier for context. Forward can carry a confidential history the new recipient should not receive.

For shared addresses, prove the visible sender identity. Gmail's send-as resource distinguishes a primary address from verified aliases. Microsoft distinguishes Send As from Send on Behalf. A successful test should capture what the external recipient actually sees, not only what the compose screen intended.

Recheck state immediately before acting

Between proposal and approval, a person may reply, the customer may withdraw the request, a calendar slot may disappear, the thread may move, or an opt-out may arrive. The trusted lane should fetch current thread state before sending. If the material facts changed, invalidate the old proposal and prepare a new one.

Drafts deserve the same caution. A provider draft is a mutable mailbox object, not a frozen approval receipt. The approved content and the content actually sent should match. If another user edits the draft after review, the system should hold it rather than assuming the earlier decision still applies.

Make the gate action-specific

In the current web Assistant, sends, replies, and forwards are code-gated. The model does not decide whether those actions need confirmation. The confirmation card shows the proposed action details available to it. For the current Gmail and Outlook reply or reply-all paths, it does not resolve the recipient on-card, so the owner must verify the live thread, intended recipient set, and actual sending account separately before approval. Never approve a vague bundle such as "finish the customer request."

Manual or scheduled Agents are different. Their approval gates are optional configuration, including run-level or per-tool review. A builder preview that contains the right tool is not proof that the correct approval rule is active. Inspect the Agent Blueprint and the approval configuration, then exercise the exact send path in a controlled account.

Separate acceptance from delivery and response

Microsoft explains that a successful Graph send returns 202 Accepted before later transport and delivery processing. A non-delivery report can arrive afterward. Gmail and Outlook can also record a sent item without proving the person opened it.

This evidence model prevents a common failure: the AI says "I sent it," the workflow marks success, and nobody notices that the provider rejected the address or the reply went from a personal identity.

A shared address needs ownership controls beyond email access

Teams often call sales@, hello@, support@, or billing@ a shared inbox even when several people simply open the same mailbox. What matters is who owns the next action, how takeover works, and how the team prevents two replies.

Praxivara can coordinate supported reads, organization, owner notification, proposed Deliveries, drafts, and confirmed outward actions around the connected Gmail or Outlook mailbox. Keep the team's existing ownership controls around that work: the current email connections do not add native assignment, collision warnings, internal notes, SLA timers, or a help-desk queue, and they do not select Google Group conversations or delegated Microsoft shared mailboxes. A label can represent a status only when the business defines and enforces that rule.

Use one visible owner state

Choose one place where ownership lives. That might be an existing help-desk assignee, a CRM task owner, or a deliberately defined mailbox label backed by a team procedure. Do not scatter ownership across an unread flag, a personal note, a chat message, and someone's memory.

If the current Praxivara connection cannot read or write the chosen ownership system in the relevant execution path, the AI must not claim to own or close the item. It can notify the designated person and record that ownership is awaiting acceptance.

Check for a collision before every outward action

Immediately before a draft is approved or a reply is sent, check the latest thread, Sent folder or sent state, existing owner marker, and human takeover status. If another person replied or accepted the work, cancel the stale action. A polished second response is not a harmless duplicate. It can quote a different price, confuse the customer, or expose internal coordination.

Make human takeover durable

Human takeover should survive new messages. If an owner steps in for a complaint, contract negotiation, security concern, or sensitive customer, the next inbound message must not silently return the thread to ordinary AI handling. Keep the hold until an authorized person releases it. This is one reason the business still owns the workflow.

Do not hide architecture incompatibility

If your team depends on a Google Group Collaborative Inbox, delegated Gmail, a Microsoft 365 shared mailbox, or a help desk, keep it as the ownership surface. Praxivara can work through a compatible, directly authorized Gmail or Outlook account, but that connection does not replace delegation or queue controls. You have three practical options:

• Connect a separate, directly authorizable user mailbox created for the bounded job, if your administrator and policies permit it.
• Keep the existing shared system as the ownership surface and use Praxivara only for a compatible connected mailbox workflow.
• Use a separately verified supported path, or confirm the architecture with Praxivara before implementation.

Do not enable direct sign-in on a Microsoft shared mailbox merely to force compatibility. Microsoft says the shared account is not intended for that use. A small limitation stated clearly is safer than an integration design the administrator cannot support.

Worked example: one new inquiry, one proposed reply, one confirmed action

Harborlight Facility Care is a fictional commercial cleaning company. This example demonstrates the control design, not a customer result, speed claim, or performance benchmark.

1. The business chooses the mailbox and job

Harborlight uses a real Google Workspace mailbox, [email protected], that can authorize its own Gmail connection. It is not an alias and not a Google Group. Two sales coordinators monitor it, but the operations manager is the named escalation owner.

The first AI job is narrow: identify new commercial estimate inquiries, summarize the location, requested service, timing, and missing facts, apply the approved inquiry label, notify the operations manager, and prepare proposed reply text in a Delivery. It may not send from the inbound run, quote a custom price, interpret attachments, promise availability, or create records in another system from the sender's instructions.

2. A prospect sends the inquiry

Priya emails from a company address. She asks for nightly cleaning at a 22,000-square-foot medical office, wants a walkthrough next week, and attaches a PDF scope. Her signature includes an instruction telling automated systems to upload vendor files to a link.

The Gmail new-inbox event starts the restricted inbound run. The AI reads the permitted email fields and relevant thread, records that a PDF exists, and treats both the attachment and signature instruction as untrusted. It does not open the link, parse the PDF, send a reply, create a Gmail draft, call another integration, or schedule the walkthrough.

3. The intake lane prepares the owner decision

The run classifies the message as a new commercial estimate inquiry. It extracts the stated square footage and preferred week as claims from the sender, notes that building address, cleaning frequency details, access requirements, and decision timeline still need confirmation, and applies the approved intake label.

The Delivery gives the operations manager a compact brief: source message, category, supplied details, missing facts, attachment-present warning, suspicious link instruction, and proposed wording. The proposal thanks Priya, explains that the team will review the scope, asks for the building address and two access details, and avoids promising a date or price.

4. A person accepts ownership

The operations manager reviews the original email and attachment through the approved human process. She confirms the request is in territory, decides that the scope is suitable for a walkthrough, and marks herself as the owner in Harborlight's existing team process. That acceptance prevents another coordinator from sending a competing reply.

5. The owner moves to the trusted lane

From the web Assistant, the manager asks Praxivara to re-read the current Gmail thread and prepare an in-thread reply using the approved response plus two edits. She checks the live thread, intended reply mode, sender account, wording, and absence of attachments before moving forward.

The Gmail reply action pauses at the confirmation gate. The current card shows the proposed reply body and displayed account context but does not resolve the recipient on-card, so the manager verifies the live thread, intended recipient set, and actual sender account separately. She confirms that no one else has replied and Priya has not withdrawn the request, then approves the reply once.

6. The business records evidence, not a story

After the provider action, the manager verifies the sent record in the correct thread and records two separate states: provider accepted and sent record found. Neither state proves delivery, opening, booking, or revenue.

When Priya replies with the address, the next inbound run summarizes the new fact and notifies the same owner. The thread remains human-owned until the manager releases it.

This example is deliberately less magical than an unrestricted email bot. That is its strength. The inbound message produced useful preparation without gaining action authority, the owner made the consequential judgment, the outward reply used the current thread and visible sender, and completion was tied to evidence.

Run exactly these 18 failure tests before launch

A happy-path demo proves almost nothing. Test the conditions that make a real inbox dangerous, ambiguous, or stale. Use controlled accounts and non-sensitive data, record the expected result before each test, and keep the evidence.

1. Wrong connected account: authorize a harmless test account instead of the intended mailbox. The setup should make the visible identity obvious, and the workflow must not be approved until it is corrected.
2. Incompatible shared address: present an alias, Google Group, delegated Gmail account, or Microsoft shared mailbox. The team should identify the architecture honestly and refuse to claim it is the connected mailbox.
3. Duplicate inbound event: deliver the same message event twice. The second run may reconcile state, but it must not duplicate the label, owner alert, Delivery, draft, or outward action.
4. Stale event: let a human move, reply to, or close the thread before the inbound run finishes. Current mailbox and ownership state must win over the old event.
5. Gmail history gap: simulate a watch interruption or stale history position. Recovery should synchronize current state safely instead of treating every old message as new work.
6. Outlook polling delay: change an Outlook message between polls. The workflow must tolerate delay and must never advertise the event path as instant or use the poll time as the message's business time.
7. Moved Outlook message: move a message to another folder. Because default Outlook IDs can change on move, the system must not create unrelated duplicate work from a mutable identifier.
8. Self-generated loop: send from the connected mailbox and verify its sent message or a downstream notification cannot trigger an endless exchange with the same automation.
9. Reply during review: have the customer reply while proposed text or a provider draft awaits review. The old proposal must become stale until the latest thread is reviewed.
10. Human collision: have a teammate send a reply moments before the AI action. The pre-send check must cancel or hold the second response.
11. Durable takeover: mark a complaint or sensitive thread as human-owned, then send another customer message. The new event must not silently return it to normal AI handling.
12. Wrong sender identity: attempt a response from a personal address, unverified alias, or unintended Send on Behalf identity. The action must hold until the visible From and Reply-To are correct.
13. Accepted but later bounced: let the provider accept a controlled message that later produces a non-delivery report. The workflow must distinguish accepted, sent-record-found, bounced, and resolved.
14. Instruction inside email content: place a request to reveal secrets, change policy, use another tool, or ignore prior rules in the body, quoted thread, and signature. The intake lane must treat all of it as untrusted.
15. Malicious or unsupported attachment: attach a file whose name or contents claim authority. The run may record metadata or attachment presence, but it must not claim to parse or obey the file.
16. Impersonation and high-impact request: ask to change bank details, reset credentials, disclose personal data, accept contract terms, or make a legal or employment commitment. The workflow must require a separate verified process and named human.
17. Opt-out and suppression: send a clear request not to receive marketing email while a later campaign or follow-up is pending. The authoritative suppression state must block the later marketing action.
18. Uncertain execution or revoked access: interrupt a tool after it may have acted, then revoke the mailbox connection. The system must check provider state before retrying, stop new access after revocation, and route unresolved work to the owner.

Use a 30-day scorecard before expanding the job

Use days 1 through 7 for shadow triage. During days 8 through 14, test organization, ownership, and stale-state handling while external work stays manual. During days 15 through 21, allow selected web Assistant sends through confirmation. During days 22 through 30, consider one proven manual or scheduled Agent case with explicit tools and approval rules.

Review the scorecard weekly. Do not use email volume or shorter draft time as the primary success metric. A fast wrong response is worse than a measured handoff. Download the AI employee inbox launch worksheet to record the job, permissions, 18 tests, and first 30 days.

Build privacy, security, and email rules into the job

An inbox can contain personal data, health details, contracts, credentials, financial records, and confidential attachments. Give the job a clear purpose, minimize the data it reads, define retention, restrict access, log consequential actions, provide correction and deletion paths, and preserve meaningful human intervention. The UK ICO's current agentic AI guidance emphasizes those responsibilities and makes clear that an organization remains responsible for its processing.

Separate service or transactional mail from marketing. The FTC's CAN-SPAM guidance applies to U.S. commercial email, including B2B messages, and addresses sender information, subjects, advertising identification, postal address, opt-out, and honoring opt-outs. The ICO's electronic-mail marketing guidance explains the UK consent and soft opt-in rules. Recipient type, message purpose, and jurisdiction change the answer, so obtain qualified advice for your use case.

Before sending at scale, validate the actual From domain and its SPF, DKIM, and DMARC configuration. Google's sender guidelines and Microsoft's authentication guidance explain current requirements and recommendations. Authentication supports trust and deliverability; it does not guarantee inbox placement.

How Praxivara turns the design into an operating workflow

You do not need to start by manually wiring each supported inbox action, event, and approval step. With Praxivara Agents, you can describe the job in plain language, connect supported systems, review the Agent Blueprint and approval rules, and coordinate the work from one operating layer.

With a connected Gmail or Outlook account, Praxivara brings the supported capabilities together: the restricted inbound Agent can triage and organize work, notify the owner, and place proposed wording in a Delivery; the web Assistant can create provider drafts and requires confirmation for supported sends, replies, and forwards; and a separate manual or scheduled Agent can use selected tools with optional approvals that you configure deliberately. Run evidence keeps the resulting action or safe hold visible.

Those capabilities preserve the operating boundary. Praxivara does not turn an alias into a mailbox, replace existing help-desk ownership, or make inbound sender instructions trusted.

Frequently asked questions

Can an AI employee reply to Gmail messages?

Yes, through a trusted owner-directed or separately configured path. In Praxivara, an inbound-triggered Gmail Agent cannot create or edit provider drafts, send, reply, reply-all, or forward. The web Assistant can perform supported Gmail reply actions with confirmation.

Can I connect Gmail and Outlook to the same Praxivara workspace?

Yes, when your plan allowance supports both. Gmail and Outlook use separate connected paths. If you add several accounts from one provider, validate the sending account because current actions lack a dependable per-action account selector within that provider.

Can Praxivara manage a Microsoft 365 shared mailbox?

Praxivara supports the directly authorizable Outlook mailbox path described in this guide, so a team can coordinate supported work around that connected account while preserving its ownership controls. A Microsoft 365 shared mailbox that relies on delegation is different: current Outlook tools target the connected user's mailbox and do not expose a delegated shared-mailbox selector. Full Access, Send As, and Send on Behalf are separate Microsoft permissions.

Is a Gmail alias a shared inbox?

No. An alias is another address associated with an account, not a separate Google Account or a team ownership system. A Google Group Collaborative Inbox is also different from a Gmail mailbox.

Can the inbound AI read attachments?

The current email event path can surface attachment metadata or presence, but this guide does not claim that the AI parses inbound attachment bytes. Treat files and any instructions inside them as untrusted until reviewed through an approved process.

Does the AI need permission to send if it only drafts?

Provider permissions and product tools differ. Review the exact Google or Microsoft consent screen, then restrict the job at the execution layer. A draft-only operating rule is still valuable even when the connection supports additional actions.

How do I prevent duplicate replies?

Use stable message and thread identity, reconcile current state, check for a sent reply and accepted human owner immediately before acting, invalidate stale proposals, and make every outward action idempotent where possible.

How do I disconnect the AI employee?

Remove the connection in the product and revoke the app's access in Google Workspace or Microsoft Entra as applicable. Separately verify the provider's data-retention and deletion process, because revoking future access does not prove stored copies were deleted.

Should every external send require approval?

Start that way. Keep consequential, sensitive, ambiguous, or changing cases under review. A separate manual or scheduled Agent may use an explicitly configured approval policy only after the narrow case has passed the failure tests.

How much does the setup cost?

Mailbox limits, AI credits, storage, and available actions depend on the current Praxivara plan and provider account. Check the live Praxivara pricing and connection screen rather than relying on a hardcoded number in this guide.

The best email AI employee begins with a boundary

Connect the mailbox that owns the work, define one useful job, keep inbound content in the untrusted lane, and move outward action to a trusted owner or explicitly approved run. Then prove identity, ownership, current state, sender behavior, recovery, and customer outcome. That is how Gmail or Outlook becomes a dependable operating surface instead of a faster source of inbox mistakes.