Brief

The connected systems are named in the privacy notice: Microsoft 365 and Outlook, Google Workspace, Microsoft Teams and Zoom for video, Slack and other messaging platforms, and task services. What Brief takes is specified too: contact details and the contents of communications, plus meeting transcripts, summaries and calendar event details. Nine integration logos on the homepage carry no readable labels.

The agent acts through these systems, and the notice lists the writes scope by scope. Brief creates calendar events when the user schedules something, and it writes shadow events onto a dedicated secondary Brief AI calendar it provisions.

It writes notes to contacts and creates new ones, and it writes back tasks the user creates or completes through Brief. Chat messages are posted back as part of action workflows the user starts, and Gmail drafts land in the user's drafts folder. Creating an event, posting into a Chat space and writing a contact note all change state in systems Brief does not own.

Authentication is OAuth with incremental authorization. A published table maps twelve Google scopes to the feature each serves, disconnecting revokes the token against Google's endpoint, and data from a disconnected connection is purged in a cascade.

One more outbound service is named. Apollo handles contact enrichment, so Brief sends business contact identifiers to a third party in the middle of its work to complete and correct contact records in the account. There is no integrations directory or connector count, and no CRM connection appears on the current site.

Sourcetrybrief.ai/privacy sections 2.C, 4.A, 8.A and 11read 2026-09-12

Brief frames its product as one arc in three stages, Know, Decide and Do: "Every decision has a distance to travel, from the call a leader faces to work that is finished... Brief is the Executive Intelligence platform that closes that whole arc." State carries across real gaps in time.

Brief "tracks every commitment, yours and the ones made to you, catches the ones that drift before the deadline does, and drives each one to done," and for each decision keeps "what was decided, what needs to be decided next, and what commitments now depend on it."

Tying a decision to the commitments that hang off it is a real process structure, and catching drift before a deadline means a long process picking up again from saved state.

The agent also acts. The privacy notice records "taking actions on behalf of authorized users including, but not limited to, automated actions through the use of AI agents," and Chat messages are posted back "as part of action workflows initiated by the user." So this is more than a read only context layer: it takes data in, stages decisions and writes back.

What is missing is the machinery. No page names a runtime, an orchestrator or a workflow builder, and nothing describes handoffs between sub agents, branching or retries. A customer has no surface to define, inspect or change a sequence, and the phrase action workflows appears once, without a definition. The pipeline that is described produces briefings through summarization and extraction, a processing chain rather than an orchestration layer. The app behind the access gate at app.trybrief.ai may show more.

Sourcetrybrief.ai homepage Know, Decide and Do sections with /privacy section 3.Aread 2026-09-12

Context is kept in a model that Brief maintains, not assembled fresh for each run. Brief "keeps a continuously maintained model" of the executive's people, projects and decisions, along with commitments and goals, "so every call you make stands on the full picture, while your source systems stay authoritative." The model is derived; it is not a second system of record.

Brief calls the mechanism a knowledge graph. The privacy notice describes "developing and maintaining a knowledge graph and individual profiles for our customers," and elsewhere "each user's private knowledge graph and world model of work." An investor quoted on Brief's own page describes "a knowledge-centric system that maintains context where today's tools only capture activity."

What goes in, and how, is documented. From Google, Brief ingests Gmail messages, calendar events with attendees and conference links, and contacts, along with Google Chat messages, space membership and Google Tasks. From other providers it takes Microsoft 365 and Outlook mail, calendar and contacts, along with Microsoft Teams, Zoom and Slack. Ingested data is kept while the Google integration stays connected, and push notification subscriptions on Gmail and Calendar keep it current.

The purpose of each read is stated. Gmail is read "to surface action items, pending decisions, and meeting prep context in the daily briefing," Calendar "to populate meeting context (attendees, times, conference links, prep notes)," and Contacts "to resolve names against email senders, recipients, and chat participants." Matching names across sources is a retrieval layer feature, and it is described. Summarization and extraction over this corpus run on Vertex AI.

Brief places itself beyond retrieval: "because Brief holds a model of the work, not just a record of it, Brief anticipates and simulates, not just retrieves." The agent reads from this ingested graph, while the commitments and decisions it writes form a separate layer. No page describes chunking, embeddings or citations back to a source document, and answers carry no freshness signal.

Sourcetrybrief.ai homepage Know section with /privacy sections 2.C, 3.A, 8.A and 9read 2026-09-12

The one action Brief will not take on its own is sending email, and it says so in a single sentence. On the Gmail compose scope, the scope table gives the purpose as to "create email drafts in the user's Gmail drafts folder for the user to review and send manually," followed by "Brief does not send email autonomously." The agent writes the draft and stops; a person sends it. For a product pitched on driving commitments to done, it names the one irreversible outbound step and declines to take it, and the hold sits on Brief's own action rather than on a gate that belongs to Google.

The customer also decides how far the agent can go, one feature at a time. At sign in Brief requests only six scopes, all read only or identity: OpenID identity, plus read access to Gmail, Calendar and Contacts. Every other scope is requested later, only when the user turns on the feature that needs it, and a published table maps each scope to that feature. Compose, calendar writes and the other write features stay off until the customer enables them.

The MCP server has its own gate. Write permissions, including "chat with Brief and take actions on your behalf," appear separately on Brief's consent screen, and "none of these is granted unless you approve it." Brief also states that it never starts a connection on the user's behalf or picks the provider.

The product surface matches. The published day view labels items with six actions, Prep, Decide, Draft, Review, Comment and Confirm, marked "needs you now" and "the call is yours." No approval queue, escalation path, confidence threshold or override audit is described, and the hold is set out in a privacy notice rather than in product documentation.

Sourcetrybrief.ai/privacy section 8.A scope table and section 11.3, with the homepage Decide and Do sectionsread 2026-09-12

The controls are deep and specific, and there is no attestation at all.

Storage is encrypted on Google Cloud AlloyDB using "a customer-managed encryption key (CMEK) stored in Google Cloud KMS, controlled by Brief, not by Google's default key infrastructure, and rotated every 90 days." Sensitive user fields are encrypted again in the application layer "using per-user data encryption keys (DEKs), each wrapped by a separate key encryption key in the same keyring, providing defense in depth so that storage-layer access alone is insufficient." TLS 1.2 or higher protects data in transit.

Staff access is limited by design rather than by policy, and Brief argues the point: "Access is engineered down, not promised away... Standing production access carries no key that can decrypt it... This is architecture, not policy. A policy can be rewritten in an afternoon." People read user data only with the user's consent at the time or inside an opt in improvement program, which leaves out Google Workspace data. The only other cases are break glass access on least privilege by a few authorized staff, and security investigation.

Customers get controls of their own. Sign in uses incremental OAuth and asks for six minimal scopes, every further scope is enabled per feature, and MCP scopes get a granular consent screen. Personal access tokens are listed and revocable under Settings, then Developer. Disconnecting revokes tokens with Google, and two documented deletion paths cascade.

Two things are missing. No page on the site shows an attestation of any kind, whether SOC 2, ISO or a trust center, and there is no penetration test statement or report on request. Nor is there access management for an organization: no SSO, SCIM, RBAC, admin console or tenant level roles, and no audit log the customer can see, so an enterprise buyer cannot tell who in their organization can see what. Cryptography and data handling are strong, while access control across an organization is absent.

Sourcetrybrief.ai homepage Private by architecture section with /privacy sections 8.B.4, 8.D and 10read 2026-09-12

What a reader sees is the reasoning behind an output, not a record of what the agent did. Decisions arrive "with the trade-offs and who weighed in," and the published day view annotates items with their supporting state, such as "2 paths · Legal flagged one," "3 weighed in · the call is yours" and "Goal at risk · residency answer at risk." Meeting prep shows the specific items it drew on. A reader can see why an item reached them, which is provenance on the output.

No record of agent activity reaches the customer. The homepage and the privacy notice show no run log, action history, execution trace, replay or export, and no retention control over agent activity, and a customer cannot reconstruct which actions Brief took for a user, when, or under which authorization. Brief writes calendar events, contact notes and email drafts and posts into Chat, and none of those actions appears in a record the customer can open.

Brief names one gap itself: "Brief does not currently offer an in-product list of connected AI assistants; to have a connection revoked on Brief's side, contact us." To learn which outside assistants hold live scopes over their executive context, a customer has to email support.

The logging that does exist is internal. Brief keeps LLM audit and usage records, a log of which prompts ran against Vertex AI used for cost and quality monitoring, for 90 days, along with operational and usage records of MCP requests. A prompt level audit trail exists, but it serves Brief rather than the customer.

Sourcetrybrief.ai homepage Decide section with /privacy sections 9 and 11.5 and 11.6read 2026-09-12

Two stores are published separately. The knowledge graph is ingested from the customer's source systems, which stay authoritative. The commitments and decisions layer is written by the agent as a result of its own runs.

That second layer is concluded, not ingested. Commitments, decisions, topics, open questions and disagreements, along with meeting prep and task suggestions, are objects Brief derives and maintains. The privacy notice keeps them apart from ingested data throughout, describing "deriving insights and other information about individuals for our customers" and, in the MCP scope list, "the items Brief has derived from them" as a category distinct from the source records. Brief does not read a commitment out of Gmail; it concludes one and records it.

It is kept per user: "each user's private knowledge graph and world model of work," with personalization refined only for "the individual user whose data was used," and Google Workspace data kept out of any improvement program across customers.

It has a published lifetime and a way to purge it. Retention is stated per data class, and derived and ingested state is kept while the integration stays connected. Deleting the integration connection "cascades through the database," and account deletion "cascades through every foreign key referencing that user, purging every row of user data Brief holds, across all integrations." Backups roll off on their own after a 14 day point in time window and roughly 14 weeks of weekly snapshots. A written deletion route exists at contact@trybrief.ai with a 30 day service level.

It can be read and edited through a surface Brief publishes. The MCP server exposes named scopes over briefings, tasks, commitments, decisions, topics, open questions, disagreements, meeting prep and task suggestions, each listed separately on the consent screen, and an assistant may "create and update your tasks, mark your commitments complete, and update the state of your commitments, questions, and suggestions."

Behavior matches the design. The published day view shows a pricing decision annotated "Conflicts · floor set May 12," a decision recorded in May constraining one faced in September. For each decision Brief keeps "what was decided, what needs to be decided next, and what commitments now depend on it," and it tracks commitments made to the user as well as by them. The CTO states the design position: "Most AI tools use the language model as the memory layer. That is the wrong design. Brief separates those responsibilities."

Brief also trains and refines personalization models, which is learning held inside a model and separate from this stored state. The read and write surfaces are set out in a privacy notice rather than product documentation, and no memory view inside the product can be seen from outside the access gate.

Sourcetrybrief.ai/privacy sections 3.A, 8.B.5, 9, 10 and 11.2-11.3, with the homepage Decide and Do sectionsread 2026-09-12

Storage stays in the United States, with no choice offered: "The Services are offered for use in the United States, and Brief stores personal information in the United States."

Processing reaches further. Brief adds that "some processing occurs outside the United States: Brief's AI model provider currently serves text generation from a global endpoint that may process requests in any region," and that messaging subprocessors may process transmitted content outside the United States. A global inference endpoint is the opposite of a localization guarantee, and Brief discloses it rather than hiding it.

Hosting is on Google Cloud Platform, which runs compute and storage, PostgreSQL on AlloyDB and Pub/Sub, and production backups also sit on AlloyDB. No customer supplied project, VPC deployment or single tenant tier appears anywhere on the site, and neither does an on premises or self hosted option.

On the published terms, an executive at a firm with an EU or UK data residency obligation cannot keep either storage or inference in region. Brief describes executive context as "more sensitive than passwords or documents," names investment management, venture capital and private equity as its buyers, and uses an open EU data residency question as the sample decision in its own product illustration.

Sourcetrybrief.ai/privacy sections 6 and 4.Aread 2026-09-12

Brief is one product, not a catalog. It presents a single Executive Intelligence platform, shaped as one arc of Know, Decide and Do, for one persona. There is no second agent, agent gallery or marketplace. Nor is there a template or skill library, an industry or role pack, or a way to contribute one.

The published day view has sections for Today, Next, Decisions, Commitments, Goals, Meetings, People, Topics and Recents. They are views over one model, not units a buyer adopts: remove Decisions and nothing separable is left, because Decisions is a lens on the same model that Commitments and Goals look through.

Two features come close and are something else. Incremental authorization lets a customer switch on Compose Email, Calendar writes, Contacts write back, Tasks and Chat one at a time, each behind its own scope, but enabling a scope grants an existing capability rather than installing a unit. And papers.trybrief.ai publishes The Executive Intelligence Papers, a thought leadership series meant to be read rather than run.

The app at app.trybrief.ai sits behind an access gate and cannot be seen from outside.

Sourcetrybrief.ai homepage day view and full site navigation, with /privacy section 8.Aread 2026-09-12

Delivery runs on a schedule and on events, across several channels.

The channels are named in the subprocessor disclosure rather than claimed in marketing. SendGrid carries transactional and notification email. WhatsApp and RCS deliver "briefing content and conversational agent responses to the channel you choose," so the customer picks. ElevenLabs runs speech to text, conversational AI and text to speech for the optional voice feature, and a voice session the user starts is served by a short lived token.

The web app is at app.trybrief.ai. Brief also "provisions a dedicated secondary Brief AI calendar onto which Brief writes shadow events that surface Brief's briefing detail directly inside the user's Google Calendar app," and it posts into Google Chat. Briefing content that reaches the executive inside their own calendar is an unusual delivery choice.

Schedules are the backbone. The daily briefing is the unit of the product, and the published day view opens "Today: Thursday, July 2" with counts of meetings, decisions, commitments and goals at risk. Meeting prep is tied to dated calendar events.

Changes in state trigger work as well. Brief "catches the ones that drift before the deadline does," marks a goal as off pace and at risk, and flags items that need the executive now. Ingestion runs on events too: Gmail and Calendar push subscriptions bring new mail and calendar changes into Brief without polling. The MCP surface also has a device notification scope.

Messaging and voice are optional features the customer turns on, so coverage depends on what is enabled. No page lists the triggers or says whether a customer can define their own conditions.

Sourcetrybrief.ai/privacy sections 4.A, 8.A and 9, with the homepage day view and Do sectionread 2026-09-12

More than one model is disclosed, each with its own job, and the customer does not choose among them. Under AI and machine learning inference and evaluation, the subprocessor list names "Google Cloud Vertex AI (Gemini and Anthropic Claude models), which runs on Google Cloud infrastructure" and "Anthropic PBC (Claude models, including the model used to evaluate the quality of the Service's outputs)."

It adds ElevenLabs for voice and Braintrust, which "can act as a proxy that transits trace content to the evaluation model." Section 8.C confirms that "inference in the Google data path uses models hosted on Vertex AI," naming Gemini and Anthropic Claude models. Two model families handle generation, a third class of model handles voice and a judge model handles evaluation, all disclosed, with the routing done by Brief.

The choice stays with Brief. There is no model picker, admin setting or bring your own key path, no model assigned per feature, and nothing suggests a customer can swap in another provider. The disclosure is a privacy register, not a selection surface.

Google Cloud Platform also appears, for compute and storage, the AlloyDB database and Pub/Sub, but as infrastructure rather than a model. The MCP server, which lets a customer connect Claude or ChatGPT, runs the other way: the customer's own assistant calls into Brief.

Brief cites Google's published Vertex AI position that customer prompts and outputs are not used to train foundation models without permission, and states that it has not granted any such permission.

Sourcetrybrief.ai/privacy sections 4.A and 8.Cread 2026-09-12

Brief runs an MCP server at a named endpoint, https://app.trybrief.ai/mcp. Its purpose is stated plainly: it "lets you connect Brief to a third-party AI assistant of your choosing, such as Claude or ChatGPT, so that the assistant can answer questions using your Brief data." This is the customer's own assistant calling into Brief.

It reads and writes. The read scopes are granular and listed one by one. Source records cover emails, calendar events, contacts, tasks, sent invitations and chat messages from Slack, Google Chat and Microsoft Teams. Derived items cover briefings, commitments, decisions, topics, open questions, disagreements, meeting prep and task suggestions. Company records come through the contacts scope. Write scopes are listed separately.

An assistant may "create and update your tasks, mark your commitments complete, and update the state of your commitments, questions, and suggestions," and two further permissions, which Brief flags as broader than editing records, let it "chat with Brief and take actions on your behalf" and "register a device for notifications." An outside caller can change state in Brief and set off actions, not just read.

Both ways in start with the customer. An assistant can request scopes through OAuth, which the user approves on Brief's own consent screen, or the user can create a personal access token with scopes chosen at creation. Each voice session also gets a short lived token. Personal access tokens are listed and revocable in Brief under Settings, then Developer, the developer entry point inside the product.

There is no separate developer site. The navigation and footer link to pages such as How it works, Papers and Support, but not to a docs subdomain, API reference or SDK, and there is no OpenAPI specification or published tool list for the MCP server. The surface is real and described in contract terms in the privacy notice, but it is not documented for a builder.

Sourcetrybrief.ai/privacy sections 11 and 8.Eread 2026-09-12

A real evaluation path exists, and it is Brief's own. The privacy notice states that "Brief operates an evaluation and quality-assurance path that scores the quality of the Service's outputs," routing trace content through Braintrust's evaluation proxy to an Anthropic Claude judge model. Braintrust is listed as AI evaluation and quality tooling, and Anthropic as supplying "the model used to evaluate the quality of the Service's outputs."

It is Brief's internal quality program, not something the customer gets. There is no test environment or sandbox, no dry run or holdout, no A/B comparison or versioning of agent configuration, and no score a buyer can read about their own agent's behavior.

It is not shipped either. Brief states: "Today this path runs only in Brief's development environment; in production it would run only for content a user expressly opts in to provide under an optional improvement program."

Nothing else on the site tests the agent. The LLM audit and usage records, kept for 90 days for cost and quality monitoring, are Brief watching itself. The homepage claim that Brief "anticipates and simulates, not just retrieves" is about simulating the outcomes of an executive's decisions, a product feature rather than a test of the agent. And Brief's statement that it learns how the user's work operates and improves over time describes learning absorbed into the product, not a way to evaluate it.

Sourcetrybrief.ai/privacy sections 4.A, 8.C and 9read 2026-09-12

Every path in and out of Brief is an API, and the privacy notice lists them. Data comes in through Google OAuth scopes, published in a twelve row scope table, through connections to Microsoft 365, Teams, Zoom and Slack, and through Gmail and Calendar push subscriptions. Actions go out the same way, through calendar event creation, contact and task write back, Chat message posting and Gmail draft creation. Outside callers reach Brief through an MCP server at a named endpoint, and delivery runs through SendGrid, WhatsApp, RCS and an ElevenLabs voice path. None of these is a screen.

So a redesigned page has nothing to break. Google redesigning Gmail does not touch a gmail.compose scope call, and a product built entirely on OAuth scopes has no rendered surface to be brittle against.

No hosted or local browser, desktop session or remote control appears on the homepage, the privacy notice or the site navigation, and neither does RPA, a recorder, an extension or a virtual machine. The subprocessor list is the strongest place to check, because a browser automation or virtual desktop component would have to be disclosed there as a processor. Its entries are cloud hosting, a database, model inference, voice, billing, messaging delivery, contact enrichment, support and analytics, and none is a browser or desktop tool.

Two related features are not computer use either. ElevenLabs supplies "speech-to-text, conversational AI, and text-to-speech for the optional voice feature," which is a channel rather than an agent working an interface. And the secondary calendar that carries Brief's briefing detail into the user's own Google Calendar app is content written through an API into someone else's interface, not a session driving it.

Sourcetrybrief.ai/privacy sections 4.A, 8.A and 11, with the homepageread 2026-09-12