Beemy · beemy.co
Printed from beemy.co/lexicon/
Plain English
Every term this site uses more than once, defined in one place. That includes words we coined or borrowed and bent. A Beemy silo is one example. It is not the industry's kind.
An inbox Beemy has earned the right to act in: read-only until trust is proven, then given autonomy one category at a time.
The trusted inbox is the whole loop in one phrase. Gmail and Google Calendar connect read-only first. Beemy learns who you talk to and how you sound. Only then does it start to draft and act, one approval at a time.
We say "trusted" and not "automated" on purpose. Building trust is the point, ahead of speed. See the autonomy ladder for how that trust is earned.
Reading, classifying and prioritising incoming email by relationship and urgency, before Beemy drafts or sends anything.
Triage is the first job Beemy does, and everything else builds on it. Beemy reads every message. It scores who the message is from and how urgent it is. It then sorts the message, so your inbox is not one undifferentiated pile.
Triage is a sorting job, not a decision job. Beemy separates what needs you now from what can wait. It never decides what to say for you without a draft you can review first.
The single triage-draft-approve cycle that runs across every connected surface, instead of a separate tool for each inbox.
"One loop" is shorthand for Beemy's whole approach. Beemy does not use one assistant for Gmail and another for the next tool. One loop runs the same way everywhere it is connected. It reads, triages, drafts and waits for your approval.
The loop is live today across Gmail and Google Calendar. It extends to each new surface next. Each surface must first clear its own safety gate.
A single tuned roll-up of what needs your attention, compiled from every source Beemy follows, rolling out next.
You get one digest at the cadence you set, daily or weekly. It replaces fifty open tabs and a dozen unread newsletters. It pulls from every connected source and ranks items the way triage ranks your inbox.
The digest is not live yet. It sits on the roadmap's next lane. It arrives once feeds, newsletters and RSS clear their own safety gate.
Not this: It can look like a generic "AI summary" added to an inbox. It is the output of the same triage engine, compiled and timed.
Recurring status reports, such as KPIs and team updates, compiled from your connected tools and sent on schedule, rolling out next.
Report automation turns the context Beemy already reads for triage into a recurring report. Examples are monthly stats, KPIs and a team update. Beemy compiles the report. Once you allow it, Beemy sends it on schedule. You do not assemble it by hand.
The roadmap scopes and sequences this in its next lane. It does not ship today, and this entry does not claim otherwise.
An industry productivity goal, an empty inbox, that Beemy deliberately does not optimise for.
Inbox zero treats an empty inbox as the win. That rewards speed: you archive, delete or file anything to lower the number. Beemy aims for a different result. The right messages reach you at the right time. Beemy handles everything else quietly in the background.
An inbox that is quiet because someone made judgement calls is a better result. An inbox that is empty because everything was triaged away is not.
Not this: This is a productivity idea from elsewhere that is decades old. This site argues against it. We do not claim it as a Beemy feature.
A cognitive-psychology term for the measurable cost of switching away from an unfinished task, sourced on /the-numbers and not ours.
Attention residue names a research finding. Part of your attention stays on a task you left unfinished. That measurably hurts your performance on the next task, even minutes later.
It explains why a quiet inbox matters more than a fast one. Every unresolved thread costs you something, even after you stop looking at it. The full citation and caveats are on The Numbers.
Not this: This is a third-party research term from cognitive psychology. We cite the study behind it here. We did not coin the phrase.
The three-rung path by which Beemy earns the right to act on its own: read-only, approve-before-send, then a dial you control.
Every category of task climbs the same ladder at your pace. Beemy starts read-only. It then drafts things for your one-tap approval. It acts unsupervised in a category only after you turn that dial yourself.
Autonomy is never assumed and never inherited. Trust earned on one surface does not carry over to another. See the safety gate for what a new surface must clear before it joins the ladder.
The default for anything Beemy drafts: it waits in your drafts folder for a one-tap review before it sends.
Approval-first means the default answer to "will this go out on its own?" is no. That stays true until you say otherwise for that category. A draft is a proposal that waits for you. It is not an action already taken.
It is the second rung of the autonomy ladder, and most people stay on it the longest. You save the time a ready draft gives you, and you keep the final word.
The starting posture for every new connection: Beemy reads and learns before it can draft, send or file anything.
Connecting an account does not hand over control. Beemy starts read-only. It watches how you work and how you write before it may act for you. This is the first rung of the autonomy ladder. It is not a formality.
The same posture applies to every new surface as it comes online. It applies the moment you make a connection, with no exceptions.
Beemy surfacing something to you with a plain-language reason, instead of guessing what to do with it.
When something is ambiguous or high-stakes, Beemy does not quietly pick a side. It escalates to you. It attaches a "why this reached you" explanation, so the interruption carries information.
Zero interruptions is not the goal. An inbox that never escalates anything is a sign that triage has broken down. Escalation is the release valve that makes the rest of the autonomy ladder safe to climb.
The bar a new surface must clear before Beemy may act there unsupervised, covering security, reliability and product fit.
Every surface Beemy touches must clear the same safety gate. Only then does it go from read-only to acting for you. It is one bar, applied the same way every time, for every connection.
This is why "next" on the roadmap does not mean "soon and unverified". A surface clears its safety gate, or it stays read-only until it does.
One move that drops every category, in every connected silo, straight to read-only.
The kill switch is the blunt end of the autonomy ladder. It turns every category down, in every silo, in one move.
Nothing wakes up again until you grant it back. Any team member can pull it, with no reason needed.
Destroying the encryption key that guards a silo, so its data becomes unrecoverable even though the key never touched the data itself.
Beemy does not hunt down and overwrite every copy of your data to delete it. It destroys the key that unlocks the data. Once the key is gone, every version of every row it protected is unreadable. This holds for everyone, including Beemy.
This step makes a delete final. Beemy also purges the rows. Destroying the key is what makes deletion irreversible.
The audit record a completed deletion writes, naming every table checked, whether the key was destroyed, and when.
Deleting a silo makes a claim: the data is gone. The erasure proof is the evidence. It records the row counts after the purge. It also records whether the key can still be opened.
The record is built to outlive the data it describes. The proof of your erasure must survive the erasure. If it does not, it proves nothing.
A per-silo chain of audit rows, each hashing its own fields and the previous row's hash, so a row with stale links is detectable.
Every event in Beemy's audit log carries a seq number, its own hash and the previous row's hash. Beemy recomputes each hash in order and checks it against the stored one. This detects a row whose links were not recomputed. Examples are a careless direct insert, a gap or a reorder.
The database already blocks an in-place UPDATE or DELETE on this table. The hash chain detects the other kind of tamper: a row inserted outside the normal path. The hash takes no secret key. It cannot rule out a writer who recomputed every link after the row they added.
The audited event written every time Beemy decrypts a silo's key, so that Beemy, or a person with database access, can read that silo's encrypted contents.
Opening a silo means unwrapping its encryption key through the key-management service. That unwrap writes a key_unwrap row to the audit log before the key becomes usable. Every read of a committed message body leaves a trace.
No route to a committed message body skips this event. This holds for Beemy's own systems and for a person with direct database access. It does not cover everything about a message. Mail still in intake sits under a separate per-user key. Opening that key writes no row. The names extracted from a message sit in a plain column. Reading them unwraps no key and writes no row.
An architectural wall between contexts that no reply can cross by accident, such as work and personal, or one team member's data and another's.
Beemy keeps personal, work and, for teams, shared context in separate stores. No path leads between them. A work reply cannot reference something from your personal inbox, and the reverse is also true. A filter might catch a stray message after the fact. Here, no route exists for the message to travel.
This is the most used word on this site. It is also the word most likely to be misread at first, so the note above explains it.
Not this: This is not the usual industry meaning. Elsewhere a "data silo" is an accident: information trapped where it should be shared. A Beemy silo is the opposite. It is a deliberate wall, because some things must never cross.
Drafts written to match how you write, with your work voice and your personal voice kept apart, not one generic AI tone.
Beemy drafts replies in your voice. It learns from your sent mail. It keeps your work voice and your personal voice apart. It does not use one house style for everyone.
Every edit you make teaches it. You review each draft before it goes out.
Two things on this site: Beemy's blog, and the shared context that a team's members can use across each other's work.
As a noun about writing, the Hive is beemy.co/blog. It holds the essays behind the product, on email overload, trust and assistant design.
As a noun about a team, the Hive is the shared layer teammates can use. Nobody has to re-explain that context to their own assistant. The wall around each personal silo does not move. Both senses share one idea: many people, or one publication, hold something in common on purpose.
A browsable library of concrete jobs that people hand to Beemy, across both work and personal life.
/features describes capabilities. The Playbook describes jobs. These are the recipes people use Beemy for. Examples are triaging an inbox before a trip, drafting the awkward follow-up and tracking a reimbursement.
You can filter by category and by silo. A work recipe and a personal one never appear side by side. That would wrongly suggest that one assistant instance handles both with no wall between them.
A connected app or channel, such as Gmail, Google Calendar or whatever comes next, treated as its own trust boundary with its own autonomy dial.
This site says "surface" and not "integration" or "channel" when the point is trust, not connection. Each surface Beemy touches must clear its own safety gate. Each earns its own autonomy, independent of any other surface.
A grant on one surface never carries over to another. Turning up autonomy on one connected app says nothing about what Beemy can do unsupervised anywhere else.
Single sign-on: employees sign in through your existing identity provider instead of a separate Beemy password.
SSO over SAML 2.0 or OIDC uses your existing identity provider. Add or remove someone there, and their Beemy seat follows automatically. You manage no separate account.
SSO pairs with SCIM for provisioning. Together they are the access-control half of Beemy's enterprise story. The isolation half is the silo model that every tenant gets by default.
The provisioning standard that keeps who holds a Beemy seat in step with your identity provider, automatically.
SCIM provisioning adds and removes seats the moment someone joins or leaves in your IdP. No manual offboarding step exists for Beemy. No seat stays active after access elsewhere is revoked.
SCIM is the automation layer under SSO. SSO handles authentication. SCIM handles who exists at all.
Beemy's plain status: the controls SOC 2 Type II evidences are built and enforced, but the audit's observation window has not happened yet.
SOC 2 Type II is an auditor's opinion. The auditor watches a company's controls in practice over a window of months. It is not a one-time paperwork exercise. Beemy's silo isolation, encryption, audit logging and deletion controls are built and enforced. We still need to engage an auditor and complete the observation window.
We say "readiness-stage" and do not claim the audit outright. The gap between "built" and "audited" is the kind of overstatement this site's honesty gates exist to catch.
Not this: This is not a claim of certification. We say "readiness-stage" plainly. We do not round a built but unaudited architecture up to a badge we have not earned.
Keeping a region-pinned tenant's data, encryption keys and model inference inside that region, for enterprise customers who require it.
With data residency, an enterprise tenant can require that its data stays in region. So do its encryption keys and the inference calls made on its content. The EU is one example. The data does not sit wherever the nearest server happens to be.
It sits beside SSO/SCIM and SOC 2 Type II readiness as one of the three enterprise commitments this site names. It is an enterprise-deployment capability. We scope it in a direct conversation. It is not a default that is switched on for every account today.
A third-party vendor Beemy relies on to help provide the service, such as hosting or model inference, disclosed by name on a dedicated register.
A sub-processor is any outside vendor that touches user data as part of running Beemy. A hosting provider and an AI model provider are examples. Beemy names every one on a dedicated register. A passing mention in the privacy policy is not enough.
Naming them costs nothing, and hiding them would cost real credibility. It is the same principle behind every other honesty gate on this site.
A vendor agreement under which a model provider keeps no copy of a message once the call it answered has finished.
Zero data retention is a term in the agreements Beemy has signed with OpenAI and Anthropic. Each provider sees only the message content of the one inference call it handles. It keeps none of it once that call ends. Neither provider trains its models on that content.
Beemy also enforces this in code. An allowlist checks every model call against a fixed list of endpoints cleared for zero retention. Beemy refuses any endpoint that fails the check. See the full register for both providers' own data-processing terms.
Read next
Beemy is in private beta. We send invites in rolling batches. We cannot promise a date. When your invite arrives, connect Gmail. Beemy sorts your inbox in that first session.
You're in the hive. You get no email now. We write to you once, when your invite is ready.
While you waitLast updated
Links do not work on paper. Open the address above to follow them.
To join the waitlist, go to beemy.co/waitlist.