Use Fyxer with AI, safely

Fyxer works on the user's own connected accounts: inbox (Gmail or Outlook), calendar, meetings and documents. Most bad results come from searching the wrong account, picking the wrong tool for the question, or assuming a draft has been sent. Settle scope first, then choose the narrowest tool that answers the question.

1. Confirm the account and what is connected

Before the first lookup in a conversation, establish:

• Which Fyxer account is signed in. The user may use a different email for Fyxer than for their AI tool. If results look like someone else's meetings or contacts, stop and ask which account is connected.
• Which inbox and calendar are connected. The docs say meeting search and transcripts need a connected calendar, and email context needs a connected Gmail or Outlook inbox. If a meeting tool returns nothing for a meeting the user is sure happened, check whether its calendar is connected before concluding it never occurred.
• Which time window the user means. "Last week", "this quarter" and "the Q3 call" are different filters; restate the window you used in the answer.

If the user needs a different account or calendar, that is a setup change in Fyxer itself. Tell them how to reconnect and do not guess at a workaround.

2. Pick the narrowest tool

Use this as a routing guide, not a list to run in order:

• A broad question across sources ("what action items came out of my meetings", "what did we agree about pricing"): start with search_context. It covers emails, meetings and documents, so it is the widest net and the wrong starting point for a single known meeting.
• Finding a meeting by topic or attendee ("meetings with Sarah this month"): search_meetings to get candidates, then narrow.
• A summary of one known meeting: get_meeting. Use this before the transcript; the summary is far smaller.
• Exact wording, a quote, or who said what: get_transcript. Transcripts are long, so only pull one when the summary is not enough.
• Someone's name or email address: resolve_person. Use it before drafting to any person.
• Writing an email: draft_email. It produces text in the chat only.

Two or three targeted calls usually beat one broad search followed by a flood of results. When a search returns many candidates, ask the user to choose or narrow by date or attendee rather than summarising all of them.

3. Keep results from flooding the context

• Ask for the time window and attendees up front when the request is open-ended.
• Report at most about five matches unless the user asks for the full list, and say how many were found in total.
• Do not pull transcripts for every meeting in a list. Pull summaries first and transcripts only for the one the user cares about.

4. Email is draft-only

draft_email writes the draft in the chat. Fyxer does not send mail. Saving to Outlook or Gmail is a separate step the user performs with the "Open in Outlook or Gmail" control, and then they review and send. Never tell the user an email has been sent, scheduled or saved to their inbox unless they have confirmed they did it themselves.

Any action that would change data, state or the account (saving a draft to an inbox, switching the connected account or calendar, reconnecting a service, sharing a transcript) requires the user's explicit yes first, and you wait for that yes. Read-only lookups never need approval.

5. Handle errors, empty results and limits

• Empty result from a search: widen the window, drop one filter, or try the other tool (a name that fails in search_meetings may succeed in resolve_person). Only then say nothing was found, and list what you tried.
• Rate limit: the docs say limits are per user. Tell the user to wait briefly and retry; do not loop calls.
• Permission or connection error: most often a missing connected inbox or calendar, or the wrong signed-in account. Name the likely cause and the fix, and stop there rather than retrying the same call.
• Partial data (a meeting with a summary but no transcript): report what exists and what does not, without filling the gap from inference.

Common patterns and traps

• Assuming Fyxer sent the email. It did not. Re-read the draft-only rule before saying anything about sending.
• Searching a broad source when a known meeting exists. Going straight to search_context for a meeting the user named wastes calls and mixes sources; use search_meetings or get_meeting.
• Treating "no results" as "it never happened". Check the calendar and the time window first.
• Quoting a transcript from a summary. The summary is a condensation; verbatim quotes need get_transcript.
• Guessing an email address. Use resolve_person and confirm the address with the user if more than one contact matches.
• Retrying a permission error in a loop. One clear explanation to the user is better than repeated failing calls.

Output

Account and scope: <signed-in account; inbox/calendar used; time window>
Tools used: <tool names and why each was chosen>
Result: <what was found, with counts; what was not>
Limits hit: <rate limit, permission gap, or "none">
Drafts: <drafted in chat, not saved or sent; user action needed, if any>
Not established: <what could not be confirmed and why>

Rules

• Do not read or summarise another person's data beyond what the connected account legitimately holds.
• Never state or imply that an email was sent or saved to the user's inbox; drafts stay in the chat until the user acts.
• Do not switch the active account, reconnect a service or change calendar connections without the user's explicit yes; wait for it.
• Do not pull full transcripts unless the user needs verbatim wording or the summary is insufficient.
• Do not retry a rate-limited or permission-blocked call in a loop; explain and wait.

Done when

• The signed-in account and time window are stated in the answer.
• The tool chosen matches the question, and every result count is reported.
• Any draft is labelled as unsent, and any unverified or missing data is listed under "Not established".