alfred_

The connector set is the mail and calendar substrate the product runs on, not a catalog of systems the agent reaches beyond it.

Within that substrate the agent writes as well as reads: "alfred_ integrates with Gmail, Outlook (Microsoft 365), Google Calendar, and Outlook Calendar. You can connect one or multiple accounts of each type," authenticated by OAuth 2.0 with scoped permissions covering "read/write email and calendar, read-only contacts, and cloud file access."

The agent archives mail, sends approved drafts, creates calendar events and accepts invites, which are authenticated writes into systems the vendor does not own. Unifying several Gmail and Outlook accounts in one queue is a real capability where most rivals pick a side.

Three further surfaces sit around it: Google Drive and OneDrive file access when file features are used, a documented Zoom connection, and SMS as a two way channel.

The vendor names the gaps in its own comparison: no native Slack, no CRM integrations and no meeting transcription. There is no task tool, ticketing, storage or messaging connector beyond the four mail and calendar endpoints, and no integration marketplace; the /integrations page is titled "Gmail, Outlook & more." A Slack first or CRM centered workflow needs a second product.

Sourceget-alfred.ai/help Getting Started integrations FAQ, get-alfred.ai/security authentication sectionread 2026-09-13

Multi step execution runs unprompted, and the help center lays out the stages as a numbered pipeline: emails arrive and are read and classified by urgency, sender importance and action required; noise is archived automatically; replies are drafted from the user's communication style and full thread context; and everything needing judgment surfaces in the Daily Brief.

Task extraction runs alongside: "alfred_ scans every email for action items: commitments, deadlines, and requests," with tasks created and linked back to the source message automatically. Classification feeding archival feeding drafting feeding a synthesized brief is a chain, not a call.

The scoring step is a real decision procedure rather than a sort. Every message is scored on urgency keywords, action required language, sender importance including VIP status and executive titles, "follow-up count from the same sender," and email age, with revenue critical and chased threads escalated. Follow up state is tracked across threads with escalating urgency (first, second, third plus), so the pipeline carries state between runs rather than deciding each message in isolation.

A second, durable orchestration unit is documented: "Automations you create can send on their own: forwarding rules, scheduled sends, and workflows you set to run automatically," managed in Settings where they can be reviewed, paused or deleted. Customer defined workflows that execute unattended are orchestration that persists beyond a session. Calendar analysis adds a parallel branch: meeting load, conflict detection and focus time scoring that discounts short gaps as context switching.

There is no visual workflow builder, no branching or conditional composition and no multi agent delegation. Multi step execution itself is shipped and documented end to end.

Sourceget-alfred.ai/help Email & Triage, Daily Brief & Tasks and Calendar sectionsread 2026-09-13

Retrieval runs on a named, persistent, embedding based index, described on the security page: "Search index: for subscribers, alfred_ keeps a searchable index of recent email (cleaned message text plus embeddings) so it can answer questions and cite the right message." The FAQ spells out the mechanism: a searchable index of recent mail, "message text with quotes and signatures stripped, plus embeddings that let it search by meaning." Cleaning, chunking and vectorizing a corpus so it can be searched semantically is a maintained index, not context assembled per run.

Citation is part of the mechanism: the index exists so the assistant can "answer questions and point you at the right message," so retrieval is traceable to a source message rather than summarized away.

The lifecycle is governed and published: encrypted, "isolated to your account," never used for training, and "deleted with your account" or on request.

Grounding goes beyond the index. Drafts are written from the full thread context, the assistant "synthesizes information from your email, calendar, and tasks," and cloud files in Google Drive or OneDrive are reachable when file features are used.

The corpus is recent email rather than the full mailbox, and the index is available to subscribers only.

Sourceget-alfred.ai/security search index and FAQ, get-alfred.ai/help Email & Triageread 2026-09-13

The gate is real, on by default, and stated three times in the vendor's own words: "Every draft waits for your approval before it goes out. A draft never sends itself. You stay in control of your voice." Drafts appear "ready for you to review, edit, and send with one tap," and the security FAQ repeats it: "Drafts are only sent when you approve them." That is a shipped, unconditional review and approve step on the highest consequence action.

Calendar works differently. The help center says "creating calendar events or sending scheduling emails from chat is confirmed with you first," but also: "By default alfred_ also handles routine calendar responses for you, such as accepting an invite that fits; you can switch to suggest-only mode in settings at any time." Routine calendar responses are autonomous by default, with an opt in gate.

The second carve out is user authored: "the only mail alfred_ sends on its own comes from automations you set up, such as a forwarding rule or a scheduled send," which the user creates and can review, pause or delete. A gate the customer deliberately removes is still the vendor's gate.

Taken together, the vendor ships an unconditional gate on sending, a confirm step on calendar creation, a documented setting extending the gate to routine calendar responses, and one click dismissal of wrongly extracted tasks. Oversight is a designed surface across every action class.

There is no admin policy engine, approval queue or per action risk tiering, which a single seat and small team product with no administrator role does not need.

Sourceget-alfred.ai/help Email & Triage and Calendar sections, get-alfred.ai/security FAQread 2026-09-13

The security page is detailed, which makes its gaps telling.

alfred_ holds no attestation of its own, and every compliance claim on the page belongs to a supplier. Data sits on Supabase hosted PostgreSQL "in SOC 2 compliant data centers," which is Supabase's attestation, not alfred_'s. Payments are "processed by Stripe (PCI DSS Level 1)," which is Stripe's. The vendor's own posture is stated as "GDPR-friendly" and "aligned with GDPR principles," a hedge rather than a certification. A supplier's certificate covers the supplier, not alfred_.

Nothing on access is customer facing either. No SSO, SAML, SCIM, roles, permission model or customer visible audit log is published, though the pricing page is detailed enough to itemize a two seat minimum. The team tier sells "simple seat management," which is billing administration, not access governance.

What sits under the page's Access control heading is user level isolation at the database layer, session expiry, and "Admin access: internal access to production data is strictly limited, logged, and requires multi-factor authentication." Internal staff controls and tenant isolation are the vendor's own housekeeping, not a surface a buyer operates.

OAuth 2.0 is how alfred_ authenticates into Gmail and Outlook. Encryption at rest and in transit is table stakes.

Sourceget-alfred.ai/security, get-alfred.ai/help Privacy & Security, get-alfred.ai/pricingread 2026-09-13

The user is told what the assistant did, never why it decided, and there is no record to go back to.

The Daily Brief does report agent actions, not just a citation attached to one answer. The help center defines it as what alfred_ prepares each morning: emails that need judgment, draft replies ready to send, tasks due today, the calendar, and "patterns alfred_ has noticed." The product pages describe a brief covering "what alfred_ handled overnight."

A user can see that newsletters were archived, which threads were escalated and what tasks were extracted, with each extracted task "linked back to the source email" so an action can be traced to its trigger. Follow up state is shown as first, second and third plus, and task aging as stale and critical, so the agent's ongoing judgments are visible.

There is no decision log, no reasoning trace and no explanation of why a message scored as it did; the five scoring factors are published, but no per message breakdown is shown. There is no run history beyond the current morning's brief, no searchable record of past agent actions, no export and no retention statement. The one thing called logging is internal: "Admin access: internal access to production data is strictly limited, logged, and requires multi-factor authentication," which is the vendor auditing its own staff.

Sourceget-alfred.ai/help Daily Brief & Tasks and Email & Triage sectionsread 2026-09-13

No memory component is documented. Three features come close, and none of them is a memory store.

Communication style is absorbed learning. Drafts are "based on your communication style," and the vendor elsewhere describes the system learning stakeholder hierarchy from email patterns and getting "more accurate over the first week." A model conditioned on the user's corpus is not a store anyone can point at, inspect or edit.

Follow up count is the product's own tracking state ("alfred_ monitors every thread for response status"), which is the scoring pipeline's data model. A product database is not agent memory.

Stored chat is a transcript, not a store, and it is the closest of the three: "Your chat conversations with alfred_ are stored so you can pick up where you left off." It is persistent and per user, but it is a log of what was said; nobody curates it, and the assistant does not consult it as authored guidance.

There is no named, addressable store, writable in natural language, that the assistant reads as context to decide. The security page lists what the vendor stores (OAuth tokens, tasks, notes, preferences, chat history and the search index), and preferences are settings the product applies as rules. There is no per user scope model beyond the account, no published lifetime, no expiry or purge path for memory separate from deleting the account, and no read or write surface. The searchable email index is a retrieval structure rather than memory.

Sourceget-alfred.ai/security data privacy and AI processing sections, get-alfred.ai/helpread 2026-09-13

alfred_ runs as cloud SaaS and claims no residency at all: not a country, not a region, not an EU option.

What is published is a hosting stack, not a topology: "production database hosted on Supabase with enterprise-grade PostgreSQL infrastructure," with encrypted storage volumes and daily backups. The only locational statement anywhere is that data sits "in SOC 2 compliant data centers," a compliance description rather than a place. A buyer cannot learn which country their mail is indexed in, and there is nothing to choose.

No alternative topology exists: no self hosting, no private or dedicated tenancy, no bring your own cloud, no region selection, and no enterprise tier for such an option to be sold in. The published plans are a single individual seat and a team tier with a two seat minimum.

The architecture makes the absence structural. The product syncs a customer's Gmail or Outlook mailbox into the vendor's own Supabase estate and builds a searchable embeddings index there, with inference sent to Anthropic, OpenAI and Google APIs.

Row level security, per account isolation, AES-256 and TLS 1.3 protect the data but do not change where it lives.

Sourceget-alfred.ai/security infrastructure and FAQ, get-alfred.ai/pricingread 2026-09-13

alfred_ ships one assistant. Triage, drafting, task extraction, calendar analysis, the Daily Brief, Kanban and Notes are features of that single product, not units a buyer selects among; remove any one and what remains is the same assistant with a feature missing.

The vertical pages are marketing surfaces, and the navigation says so. For Founders, For Real Estate, For Lawyers, For Educators & Coaches and For Accountants sit under "Solutions > Built for," alongside a Compare menu. They are landing pages addressed to audiences, not configured agents a customer adopts. Nothing indicates a lawyer's alfred_ behaves differently from an accountant's, and no page offers one to install.

No catalog of any kind exists: no gallery, template library, starter pack, agent directory or marketplace. The one composable thing a customer can build, automations such as forwarding rules and scheduled sends, is authored from scratch; a blank authoring surface is the opposite of a pack.

The published tiers are an individual seat at $29.99 and a team seat at $34.99 with a two seat minimum, and the vendor states the team tier is "everything in alfred_" plus billing administration. Two tiers of the same product is a pricing structure.

Sourceget-alfred.ai/pricing plan comparison, get-alfred.ai/help navigation and guides indexread 2026-09-13

Three distinct trigger classes are documented.

Inbound event: "Emails arrive: alfred_ reads and classifies every new message," with archival and drafting following automatically and no person present.

Scheduled: the overnight run is the product's core promise. "Connect your Gmail or Outlook account... by the next morning, your inbox is triaged, draft replies are queued, and tasks have been extracted," alongside an optional 7am SMS carrying the day's calendar and tasks, a clock driven run with its own delivery channel.

State change detection: "alfred_ monitors every thread for response status" and flags follow ups with escalating urgency, and task aging is watched the same way, with tasks older than seven days flagged stale and tasks overdue by three or more days marked critical and escalated. Those fire on the absence of an event over time, which no inbound message and no clock tick would produce alone.

Customer defined scheduling exists too: automations include "scheduled sends" and "workflows you set to run automatically," so the buyer can add triggers rather than only consume the vendor's.

Users reach the assistant through the web app, SMS as both an alert channel and an instruction channel, and the Daily Brief. There is no webhook, inbound API or external work queue, which fits a product with no developer surface.

Sourceget-alfred.ai/help Getting Started, Email & Triage and Daily Brief & Tasks sectionsread 2026-09-13

More than one model is in use and the customer chooses none of them. The security page names the providers: "Model providers: AI processing uses the Anthropic (Claude), OpenAI, and Google (Gemini) APIs under commercial API terms. Your content is sent for inference only." That is three named frontier providers, disclosed by the vendor as what its own processing runs on.

The routing between them happens on the vendor's side. No model picker, per request selection, admin entitlement or bring your own key is published.

This is not a subprocessor list. The heading is "Model providers," the three named are all model vendors rather than infrastructure, and the sentence describes what performs the inference rather than who stores the data.

Sourceget-alfred.ai/security AI processing sectionread 2026-09-13

There is no public API, SDK, developer portal, MCP server, webhook or CLI on get-alfred.ai, no developer section or subdomain, and no docs or dev host referenced from any page or help article.

Every documented surface points inward. alfred_ calls Gmail, Outlook, Google Calendar, Drive and OneDrive through OAuth, and calls Anthropic, OpenAI and Google model APIs for inference. Nothing lets an outside system call alfred_. The nearest things to a programmatic surface are inbound only or third party: SMS as an instruction channel for a person, a Stripe billing portal, and PostHog analytics the vendor runs on itself.

The customer cannot extend it either. alfred_'s automations (forwarding rules, scheduled sends, workflows set to run automatically) are configured inside the product from fixed options; no code, callback or custom tool can be introduced. The vendor confirms the posture in its own comparison: no native Slack or CRM integrations, a closed product rather than a platform.

Sourceget-alfred.ai/help full navigation and guides index, get-alfred.ai/securityread 2026-09-13

No way for a customer to evaluate a change is published: no test harness, scored cases, dry run, preview mode, regression check, A/B comparison or published quality metric.

The absence matters on this product. The triage engine archives mail autonomously on a five factor score the customer cannot inspect per message, tune, or test against past threads before it runs. A misjudged VIP weighting can silently bury a client thread, and the only feedback loop documented is noticing afterwards. Customer created automations (forwarding rules and scheduled sends) have the same shape: they are authored in Settings, and the first time they run is against live mail.

Some features look like evaluation but measure nothing. The approval gate on drafts is per output oversight; it gates each message, not a change to how the agent behaves. Dismissing a wrongly extracted task with one click corrects one item rather than measuring anything. The ROI Calculator on the marketing site computes claimed hours saved from the buyer's own inputs before purchase and tests nothing about the agent.

Nothing is measured and published either: no accuracy figure for triage classification, no benchmark and no draft acceptance rate, even in the vendor's extensive comparison content.

Sourceget-alfred.ai/help Email & Triage and Daily Brief & Tasks, get-alfred.ai/pricingread 2026-09-13

None of the three modalities is documented: no hosted or local browser session the agent drives, no desktop control, and no remote or local computer control. The security page settles it by listing every external interface the product touches.

The product is entirely API mediated. alfred_ reaches Gmail, Outlook, Google Calendar, Outlook Calendar, Drive and OneDrive through OAuth 2.0 with scoped permissions covering "read/write email and calendar, read-only contacts, and cloud file access," and reaches Anthropic, OpenAI and Google through their APIs. Every system it touches has a programmatic interface, so nothing renders a page and clicks it.

The vendor's own data access statement confirms the boundary: "What we don't: nothing outside the accounts you connect. No browsing history, no location, no data brokers."

Cloud file access to Drive and OneDrive is an API read, not an agent operating a file manager. On device speech recognition ("speech recognition runs on your own device and only the text reaches us") is local processing of the user's voice, an input channel.

Sourceget-alfred.ai/security authentication, data privacy and AI processing sectionsread 2026-09-13