Build integrations around the same domain contracts

The daemon owns canonical originals, stable occurrences, authorization and durable operations. Provider adapters translate actual provider protocols; they do not become alternative owners of the database. Shared processing can support search, reading evidence, annotations, discussion and optional analysis across mail, SMS and reports without pretending every source supports every mail operation.

Preserve the distinction between an original and a readable projection. An exact report JSON payload and the mail-shaped presentation generated from it are different representations. The projection makes common reading useful, while the original preserves provenance and fields that may not be displayed. Updating a projection must not silently replace the original, invent a new source occurrence or claim that unseen fields were read.

Use the native MCP surface when an assistant needs discoverable, typed tools. Use authenticated HTTP when your program needs explicit request and response handling, and the operator CLI for administration and scripted workflows covered by its documentation. These surfaces lead into the same domain responsibilities; choosing one should not widen the caller’s authority or create a second persistence path.

Discover the actual tool catalogue from the connected server and use the matching contract reference. For HTTP, consult the OpenAPI shapes and the runbook’s headless-client boundary. Public MCP OAuth credentials, private daemon credentials and provider tokens serve different purposes. A browser session or a Google access token cannot be substituted for a daemon bearer simply because all of them authenticate something.

Tenant lineage and a personal SP-Workspace are separate concepts. The authenticated context pins the user, workspace, application and issued agent identity as applicable. Labels, model names, reported authors or request headers must not select a different owner. Use the documented identity or authority-context read to verify who the service believes is calling before accessing business data.

Effective access combines current user grants, workspace assignments and captured assistant delegation, with collection access where required. Topic membership is an additional context, not permission to read every source attached to it. Use one issued identity per logical assistant so private reading evidence and work state remain attributable. A new credential can preserve an identity; a new display name cannot prove continuity.

Tools perform defined operations such as search, retrieval, discussion or status inspection. Metadata describes records: a category, tag, display status or advisory score has its own meaning and audience. Setting an importance flag does not approve an external action. Likewise, explanatory tool metadata helps an assistant choose a tool, but it cannot override server authorization or transform a write operation into a read.

Return stable source references and enough coverage information for the caller to know what was presented. A summary, a body range and an extracted attachment are different evidence. Use the contract’s explicit read acknowledgment when recording presented coverage, and keep that separate from task completion. Do not infer full-body reading from search results or copy one agent’s work state to another.

For an external report producer, enroll the documented receive-only source and choose a destination account whose audience may receive the reports. Use that source’s credential, not an owner or MCP token. Preserve the producer’s stable event identity across retries and treat changed content as a correction with its own appropriate identity. A reported model, author or confidence value remains attributed content rather than authentication.

Separate receipt, original custody, normalization, publication and indexing observations. Accepted but unpublished material can explain why a source list is incomplete. A private requested result needs an audience-compatible publication choice before becoming account-readable content; a private annotation cannot make an otherwise shared original private. Source capabilities should be explicit, rather than inferred from a generated sender address or a mail-like storage shape.

Event delivery tells a client something happened; invoking an assistant asks it to do work; collecting a result preserves what came back. Keep those contracts separate. Configure only supported events, filter them by the current audience and preserve stable delivery identities. A receiver should deduplicate repeated delivery and recheck its authority before retrieving more information or taking an action.

The daemon owns durable scheduling, backoff and recovery, while a transport adapter makes one bounded attempt and reports the outcome. An unknown external invocation outcome must not be blindly replayed as if it were a failed notification. Comments can attract attention, but continuation also requires a configured subscription and authorized client behavior. Vendor-specific callback authentication and event rules must come from that vendor’s actual contract.

First, name the source, intended audience and one user outcome. Provision a restricted identity, verify the returned context and perform a known permitted lookup. Then inspect a deliberately excluded item to confirm the boundary. Retrieve a summary and the relevant original representation, preserve references and record one authorized discussion result. Use the documented schema rather than inventing a generic endpoint for a design concept.

Next, exercise pagination, unavailable sources, expired credentials and a repeated request. Distinguish an empty result from authoritative completeness, and retain safe operation identifiers without logging secrets or unnecessary content. Add automated continuation only after manual retrieval and discussion work. This sequence gives you a reviewable integration slice while leaving deployment policy, model spending and consequential external effects under their own controls.