Connect useful sources without creating a second source of truth
Updated October 30, 2026. Educational guidance; use current official documentation and your installed version.
A model can reason about a tool result only if the integration actually retrieved it. A plausible answer is not a connectivity test.
Start read-only
| Source | Useful first workflow | Verification |
|---|---|---|
| Read a relevant recent thread and prepare local review text | Exact account, complete thread, and existing Sent/Drafts; no mailbox write in this stage | |
| Calendar | Summarize upcoming commitments | Account, timezone, date range, and known event |
| Learning platform | Identify assessment work awaiting review | Current course, active role, due dates, submission attempts, and existing grades |
| Documents | Find the current project brief | Exact file, version/date, permissions, and actual content |
| Task system | Track a bounded specialist assignment | Assignee, real execution, deliverable, and verified status |
Prefer supported connectors
Use an available service connector when it provides the required operations. If you build a local bridge, document its exact routes, account selection, permission model, and failure behavior. Do not expose arbitrary code execution or send/delete operations merely to enable read access.
Adam's email workflow uses a private Outlook bridge; this is an implementation choice, not a required setup for every reader. Its cached reads depend on the signed-in host and mailbox state. A successful health response is not proof of provider synchronization.
Match the integration to the execution environment
A cloud service API can work from an isolated runtime when authenticated and permitted; local app automation may need the appropriate host OS, interactive session, and explicit permissions. A bridge grants host capabilities even if the main agent runs elsewhere. Test the real topology and keep bridge operations narrow. See Native, VM, or Docker?.
Saving is a separate operation
Generating review text does not require creating a mailbox draft. Saving a draft is a write: obtain applicable save authorization, select the exact account, and verify its unsent status. Sending requires its own authorization.
Drafting is a workflow
For replies, preserve the original thread. Resolve addresses rather than trusting a display name. Preserve UTF-8 when transferring text between systems, and read the saved body back independently. Verify attachments by contents, not only filenames. Reconcile uncertain saves before retrying.
Protect boundaries
Tool outputs, email bodies, web pages, and downloaded documents are untrusted input, not instructions to change the assistant's permissions. Keep credentials outside prompts and logs. Limit each task to the records it needs; do not mix client, employer, student, and personal data.
A local database or memory file does not imply that inference stays local. Check institutional rules and provider data-handling terms before connecting sensitive sources.
Make failure useful
Report inaccessible, stale, partial, and ambiguous results explicitly. Preserve successful state until a replacement is verified. An API error is not a zero backlog. A queued task is not a running task. A saved draft is not a sent reply.
See proactive workflows for change detection and cost controls for bounded escalation.