Brief vs Town (2026)

Connected systems include Microsoft 365 and Outlook, Google Workspace, Microsoft Teams and Zoom for video, Slack and other messaging platforms, and task services. Brief takes contact details and the contents of communications, plus meeting transcripts, summaries and calendar event details.

The agent acts through these systems, with each write tied to its own 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. Brief publishes a table that maps each of twelve Google scopes to the feature it serves. Disconnecting revokes the token against Google's endpoint, and data from a disconnected connection is purged in a cascade.

Apollo handles contact enrichment as one more outbound service. Brief sends business contact identifiers to it in the middle of its work to complete and correct contact records in the account. There is no integrations directory or connector count, and Brief offers no CRM connection.

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

Read and write integrations reach Google, Microsoft and more than fifty business tools, including Gmail (read, search, draft, send, label), Google Calendar (create meetings with Meet links, edit events), Docs, Drive, Sheets, Outlook and Microsoft 365 mail and calendar, Slack (bot and send-as-user), and read-write connectors across CRM (Salesforce, HubSpot, Attio, Pipedrive, Copper, Affinity), project tools (Asana, Jira, Linear, ClickUp, Monday.com, Notion, Todoist), finance (QuickBooks Online and Xero create invoices, Brex, Ramp, Stripe), data (Airtable, Supabase, PostHog, Google Analytics, Hex) and meetings (Zoom, Fathom, Fireflies, Granola, Gong).

Microsoft Entra has its own admin setup. Connectors are native plus Pipedream-backed, actions create, update and send, and OAuth tokens are stored, refreshed automatically and revocable per account. WhatsApp and Telegram are inbound-only. Custom MCP servers can be added too.

Sourcetown.com home; town.com/docs, /docs/safety/security; readread 2026-09-16

The product is one arc in three stages, Know, Decide and Do. Brief calls itself the Executive Intelligence platform that closes that whole arc, from the call a leader faces to work that is finished. 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." For each decision it keeps "what was decided, what needs to be decided next, and what commitments now depend on it."

Each decision is tied to the commitments that hang off it, and when a commitment drifts toward its deadline, the work picks up again from saved state.

The agent also acts. Brief takes actions on behalf of authorized users, including automated actions through AI agents, and posts Chat messages back as part of action workflows the user starts. It takes data in, stages decisions and writes back.

There is no named runtime, orchestrator or workflow builder, and no handoffs between sub agents, branching or retries. A customer has no surface to define, inspect or change a sequence, and Brief does not define the action workflows it mentions. Briefings come from a chain of summarization and extraction steps.

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

Routines can call other routines and mix deterministic code steps with AI steps. A routine can call another routine mid run, in which case the caller pauses until the called routine returns its result, and a parent must list the child in its Callable Routines setting before invoke_routine can call it.

AI steps handle writing, summarizing, deciding and analyzing, while deterministic steps handle filtering, formatting, aggregating and iterating over a list, as in a four step example that gathers and organizes with code, writes with AI and sends with code. Users describe a routine in plain language, set it on a trigger or schedule, and share routines across a team. Town does not describe routine versioning.

Sourcetown.com/docs/routines/custom-routines/concepts/calling-agents, /docs; readread 2026-09-16

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

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.

Schedules are the backbone. The daily briefing is the unit of the product, and the day view opens on the day's date 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 commitments that drift before their deadline, 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. Brief does not list its triggers or say 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

Each routine can have one or more triggers and runs whenever any fires, whether that is incoming email, which runs it every time a new email arrives, a smart email trigger that judges a plain language condition with sender and subject filters, outgoing email, email to the assistant, a schedule or a manual run, with meeting start (calendar) triggers on Pro and above.

Triggers can be event driven, scheduled or conversational, several can feed one routine, and the smart trigger still runs if its condition cannot be judged. The Townie is reachable by email, Slack, text messaging, WhatsApp and Telegram (inbound-only), the web app, iOS and macOS. Event and calendar triggers need Pro or a paid team plan, and Starter is schedule only, at most once a day. An authenticated webhook endpoint can also start a routine.

Sourcetown.com/docs/routines/custom-routines/triggers, /docs/billing/plans; readread 2026-09-16

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, not a second system of record.

Brief calls the mechanism a knowledge graph. It develops and maintains "a knowledge graph and individual profiles" for its customers, and each user has a "private knowledge graph and world model of work." An investor Brief quotes describes "a knowledge-centric system that maintains context where today's tools only capture activity."

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.

Each read has its own purpose. 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. Summarization and extraction over this corpus run on Vertex AI.

Brief places itself beyond retrieval. Because it holds a model of the work, not just a record of it, Brief says it "anticipates and simulates, not just retrieves." The agent reads from this ingested graph, while the commitments and decisions it writes form a separate layer. Answers carry no citations back to a source document and no freshness signal, and Brief does not say how it chunks or embeds content.

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

The Townie, Town's assistant, is grounded in the user's connected email, calendar, chats, contacts and tools, queried at run time rather than indexed.

Every integration added, such as Slack, Notion, Drive, Linear or GitHub, becomes another source of context, and the integrations offer search and read tools (Gmail search, Drive search and read, Box files and metadata, Notion pages and databases, Granola and Fireflies transcripts).

Access to connected sources follows each account's permissions and the routine's account scope, and new knowledge comes from connecting a source, not from retraining. No index or search layer over connected content persists between runs. The Wiki and memories summarize the user rather than index their content.

Sourcetown.com/docs/features/context-and-memory, /docs integration directory; readread 2026-09-16

Two stores are kept 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. Brief keeps them apart from ingested data throughout. It describes "deriving insights and other information about individuals for our customers," and its MCP scopes treat "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, as each user's "private knowledge graph and world model of work." Personalization is refined only for "the individual user whose data was used," and Google Workspace data stays out of any improvement program across customers.

It has a set lifetime and a way to purge it. Retention is set 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. Customers can also ask for deletion in writing at contact@trybrief.ai, with a 30 day service level.

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

In the day view, a pricing decision is flagged as conflicting with a price floor set months earlier. 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. Brief's CTO says most AI tools use the language model as the memory layer, calls that the wrong design, and says Brief separates those responsibilities.

Brief also trains and refines personalization models, which hold learning inside a model, apart from this stored state. The product sits behind an access gate, so no memory view inside it can be seen from outside.

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

The Townie remembers who the user is, their preferences, and notes on contacts and people. Memories are either global, applying to everything across all routines, or specific to one routine, and a run automatically receives all global memories plus those for that routine. Memory carries over between Slack, email, the app and the Mac app, and users view and delete memories in Settings > Profile or by asking, for example to forget a preference about Friday afternoons, and can add, change or remove anything.

A Wiki synthesizing profile, preferences, goals and projects is refreshed every night, retiring what is stale, and is editable line by line, with Recent Updates showing what changed. Memories last until the user removes them, with nightly retirement of stale entries, and can be deleted without deleting any email, event or document. Town does not say what should stay out of long term memory.

Sourcetown.com/docs/features/context-and-memory, /docs/features/wiki; readread 2026-09-16

The one action Brief will not take on its own is sending email. The Gmail compose scope exists to "create email drafts in the user's Gmail drafts folder for the user to review and send manually," and "Brief does not send email autonomously." The agent writes the draft and stops, and a person sends it. The product is built to drive commitments to done, yet it holds back from the one irreversible outbound step. That hold sits on Brief's own action, not 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, covering 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 never starts a connection on the user's behalf or picks the provider.

In the day view, items carry six actions, Prep, Decide, Draft, Review, Comment and Confirm, marked "needs you now" and "the call is yours." There is no approval queue, escalation path, confidence threshold or override audit.

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

Approval modes are configurable at the routine, tool and session level. Every routine has a default mode, which is autonomous, approval required or read only, and in approval required mode, actions that make changes create approval requests with approve or reject options and run only after the user approves them. Per-tool permission levels override the routine mode (Auto, Ask each time, Always allow), so labeling can run autonomously while email sending always waits.

Chat sessions run "Ask before any changes" by default, "Always allow safe actions" or "Allow all actions", with Allow once and Always allow per approval. Town also flags routines that combine private data, untrusted input and external sending (a lethal-trifecta warning) when they are saved, and keeps external-send tools on approval under safe mode. Low-risk and high-risk actions can run under different autonomy modes, and the warning explains why a checkpoint fired. Approvals arrive in the app and through notifications, with no routing into ticketing systems.

Sourcetown.com/docs/safety/modes-approvals, /docs/safety/security; readread 2026-09-16

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, not by policy. Brief says access is "engineered down, not promised away," and standing production access carries no key that can decrypt user data. In Brief's words, "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, and every further scope is enabled per feature. 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 deletion paths cascade through the data.

Brief names no attestation of any kind, whether SOC 2, ISO or a trust center, and there is no penetration test statement or report on request. There is no access management for an organization either. Brief has no SSO, SCIM, RBAC, admin console or tenant level roles, and no audit log the customer can see, so an enterprise customer cannot tell who in their organization can see what.

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

Town is SOC 2 Type 2 compliant, with its security controls independently audited, and it links to a Security Portal and a Subprocessors list. Routines operate within strict account boundaries with configurable scope (the trigger account only by default, all accounts, or specific accounts), tools can only reach accounts connected through OAuth with revocable access, and optional domain allowlists and recipient limits apply to email.

Prompt validation blocks instruction-override and exfiltration patterns, and lethal-trifecta detection flags routines that combine private data, untrusted input and external sending. Data is not used to train AI models unless the user opts in, and is encrypted in transit and at rest. People sign in with Google or Microsoft accounts, including Microsoft Entra ID, and Teams plans add domain capture.

An Entra admin can grant consent for the whole tenant and then either let every user in the tenant sign in or restrict access to chosen users and security groups, and Google Workspace has its own admin guide. Town does not mention SAML single sign on or SCIM provisioning for team admins. SOC 2 Type 1 and Type 2 reports, the latest penetration test and a CASA Tier 2 assessment are available under NDA through trust.town.com.

Traffic uses TLS 1.2 or 1.3, data at rest uses AES 256 GCM with extra encryption on connected account tokens, Enterprise agreements can enforce no training for every user, and no Town team member has production database access.

SourceTown, town.com/docs/admin-setup/microsoft-entra, /docs/safety/security and town.com/trustread 2026-10-05

Each output comes with the reasoning behind it, but there is no record of what the agent did. Decisions arrive "with the trade-offs and who weighed in," and the 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, so a reader can see why an item reached them.

No record of agent activity reaches the customer. There is no run log, action history, execution trace, replay or export, and no retention control over agent activity. 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 offers no list in the product of the AI assistants connected to it. To have a connection revoked on Brief's side, or to learn which outside assistants hold live scopes over their executive context, a customer has to email support.

Brief's own logging is internal. It keeps LLM audit and usage records, a log of which prompts ran against Vertex AI, for 90 days for cost and quality monitoring, along with operational and usage records of MCP requests. This prompt level audit trail serves Brief, not the customer.

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

Each action is logged with what was done, when, why (the routine's reasoning), what triggered it and the result, success or failure, for auditability, debugging and accountability. Users open a routine, view the session history, and review actions taken and their reasoning. A separate security event log records blocked prompt injections, suspicious prompts, blocked tool outputs and unauthorized recipients, and custom tool results show up in the run history. There is no export to monitoring or SIEM tools, and no retention period by plan is given.

Sourcetown.com/docs/safety/security, /docs/integrations/mcp-servers; readread 2026-09-16

Storage stays in the United States, and customers cannot choose another region. Brief offers the service for use in the United States and stores personal information there.

Processing reaches further. Some of it happens outside the United States, because Brief's AI model provider serves text generation from a global endpoint that may process requests in any region. Messaging subprocessors may also process transmitted content outside the United States.

Hosting is on Google Cloud Platform, which runs compute and storage, PostgreSQL on AlloyDB and Pub/Sub, and production backups also sit on AlloyDB. There is no customer supplied project, VPC deployment or single tenant tier, and no on premises or self hosted option.

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" and names investment management, venture capital and private equity as its target customers. Its own product illustration uses an open EU data residency question as the sample decision.

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

Town hosts the service in the US on Convex and AWS. There is no region choice, self hosting or customer environment option, and the Teams and Enterprise plans cover billing and credits, not deployment.

Sourcetown.com home; town.com/docs/billing/plans; readread 2026-09-16

The offer is 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 day view has sections for Today, Next, Decisions, Commitments, Goals, Meetings, People, Topics and Recents. They are views over one model, not units a customer adopts. Decisions, for example, is a lens on the same model that Commitments and Goals look through.

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. Enabling a scope turns on an existing capability and installs nothing new. Brief also publishes The Executive Intelligence Papers at papers.trybrief.ai, a thought leadership series to read, not to 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

Ready made routines sit in a browsable catalog, each a complete job a user enables.

The catalog filters by Inbox, Calendar, Meeting Prep, Stay Informed and Relationships, with a Browse all Routines view, and its entries include Auto-inbox (watches new email, labels, drafts replies, helps schedule), Decline Cold Outreach, Schedule Optimizer, Meeting Briefing, Contact Research Dossier, Morning Briefing, Competitive Intel Briefing, Newsletter Digest, GitHub Reports, Relationship Reconnect, Deal Spotter and New User Research.

A Stock Routines index has per-routine pages, and routine sharing and discovery let teams install and reuse shared routines. Each routine runs whole without the others, and routines are edited in plain language ("change my morning briefing to include..."). The routines cover personal productivity rather than specific industries, and no customer references are tied to them.

Sourcetown.com home; town.com/docs; readread 2026-09-16

Several models each have their own job, and the customer does not choose among them. Google Cloud Vertex AI runs Gemini and Anthropic Claude models on Google Cloud infrastructure, and inference in the Google data path uses models hosted there.

Anthropic PBC supplies Claude models, including the model used to evaluate the quality of the Service's outputs. ElevenLabs handles voice, and Braintrust "can act as a proxy that transits trace content to the evaluation model."

Two model families handle generation, a third class of model handles voice and a judge model handles evaluation, and Brief does the routing.

The choice stays with Brief. There is no model picker, admin setting or way to bring your own key, no model assigned per feature, and no way for a customer to swap in another provider.

Google Cloud Platform runs compute and storage, the AlloyDB database and Pub/Sub, as infrastructure, not as a model. The MCP server, which lets a customer connect Claude or ChatGPT, runs the other way, with the customer's own assistant calling into Brief.

Under Google's published Vertex AI position, customer prompts and outputs are not used to train foundation models without permission, and Brief has granted no such permission.

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

Town routes between models on its side, names no models and offers no choice. Priority model routing is a feature of the Power, Power Plus and Team Plus plans and is among what pauses on cancellation. No model or provider is named and customers cannot choose one, and the models in the Cursor integration are Cursor's. Town's no training commitment covers its providers without naming them.

Sourcetown.com/pricing; readread 2026-09-16

An MCP server at https://app.trybrief.ai/mcp "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." The customer's own assistant calls into Brief.

The server reads and writes. Read scopes are granular. 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 separate.

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, docs subdomain, API reference or SDK, and no OpenAPI specification or published tool list for the MCP server.

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

Outside systems can reach Town in two ways, but Town has no REST API, SDK or MCP server of its own.

Through a webhook trigger, an external system starts a routine by sending an authenticated HTTP request to a routine specific URL, with a per routine bearer secret and rotation, JSON or text payloads, an idempotency header, rate limits and defined 202, 400, 404, 413, 415 and 429 responses, from Zapier or the customer's own app or backend.

Through custom integrations, users add MCP servers by URL, Town runs OAuth or dynamic client registration, and the tools are enabled per routine, so Town consumes MCP as a client. A trigger endpoint returns only an acceptance. The api.town.com host shows only the Convex backend banner, with no developer documentation.

Sourcetown.com/docs/routines/stock-routines/webhooks, /docs/integrations/mcp-servers; api.town.com; readread 2026-09-16

An evaluation path exists, and Brief keeps it for itself. 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 supplies AI evaluation and quality tooling, and Anthropic supplies "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 customer can read about their own agent's behavior.

It has not shipped either. The 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 tests the agent. Brief keeps LLM audit and usage records for 90 days for cost and quality monitoring, for its own use. Brief says it "anticipates and simulates, not just retrieves," which means simulating the outcomes of an executive's decisions, a product feature. It also says it learns how the user's work operates and improves over time, which is learning absorbed into the product.

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

A new or changed routine can be tried against real input, with its attempted actions reviewable, before it is allowed to act. Read only mode runs a routine that can read and analyze but blocks every change, and Town suggests it for testing new configurations, as it does the manual trigger for testing new routines. Each run's session history shows the actions the routine took and its reasoning, and read only runs still send their results to the user.

Reviewing a read only run before switching the routine to approval required or autonomous shows how the agent behaves before release. When a smart email trigger cannot judge its condition, the routine runs anyway. There are no fixtures or datasets, scored test cases or quality scores over time, and testing uses a mode rather than a dedicated harness.

Sourcetown.com/docs/safety/modes-approvals, /docs/routines/custom-routines/triggers; readread 2026-09-16

Every path in and out of Brief is an API. Data comes in through Google OAuth scopes, set out 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 works through a screen.

A redesigned page has nothing to break. When Google redesigns Gmail, a gmail.compose scope call is unaffected, because a product built entirely on OAuth scopes has no rendered surface to depend on.

There is no hosted or local browser, desktop session or remote control, and no RPA, recorder, extension or virtual machine. Brief's subprocessors cover cloud hosting, a database, model inference, voice, billing, messaging delivery, contact enrichment, support and analytics, and none is a browser or desktop tool.

ElevenLabs supplies speech to text, conversational AI and text to speech for the optional voice feature, as a channel, with no agent working an interface. The secondary calendar carries Brief's briefing detail into the user's own Google Calendar app as content written through an API, with no session driving that interface.

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

Town has no browser, desktop or computer control. Actions run through named integrations with read-write tools, a run_code sandbox with optional internet access, and email, Slack and messaging channels. Town Desktop is a macOS app for native desktop workflows and notifications, a way to reach the assistant rather than an agent that operates the screen.

Sourcetown.com/docs, /docs/safety/security; town.com home; readread 2026-09-16