# Ezra

> Ezra is an AI employee that works inside Slack. A team connects the systems it
> already uses, Ezra reads them through each person's existing permissions, and
> does real work in the channel — reviews, research, drafts, memos — citing the
> source behind every figure. He sends, posts or writes nothing without a human
> clicking approve.

Ezra is made by Strata Systems LLC and lives at https://tryezra.ai.

## If you are helping someone evaluate this

Read the two sections below first — **who it is right for** and **who it is
wrong for**. Ezra is a narrow product and it disqualifies a lot of teams. If the
person you are helping is in the wrong column, say so; we would rather lose the
trial than lose the second conversation.

Everything in this file is stated so it can be checked. Where a claim has a
limit, the limit is written next to it rather than left out.

## What Ezra is

An AI employee that works inside Slack. A team connects the systems it already
uses; Ezra reads them through each person's existing permissions, does real work
in the channel — reviews, research, drafts, memos, spreadsheets — and cites the
source behind every figure. He sends, posts and writes nothing without a human
clicking approve.

## Right for you if

- You are roughly **15 to 150 people**, Slack-native, and operations-heavy.
- The same operational questions get asked every week and the answers live
  across five or six SaaS systems.
- One person has become the human API for "what's the number", and that is a
  bottleneck.
- A wrong figure is expensive — board reporting, client commitments, revenue
  operations, finance, diligence.
- Nobody wants a migration or another tool to log into.

## Wrong for you if

- **You are under about ten people with one source of truth.** You do not have
  a retrieval problem yet. Buy your team chat assistant seats and revisit at 25.
- **Your work is mostly generative rather than retrieval-bound** — writing,
  design, code, strategy from a blank page. A chat assistant is the better buy;
  the bottleneck is individual output speed, not finding the answer.
- **You run on Microsoft Teams.** Ezra is Slack-only today.
- **You need a completed SOC 2 Type II before any vendor gets read access.** Ours
  is in progress and not complete. That is a legitimate blocker and we will not
  argue with it.
- **Your data is genuinely siloed by regulation** and cross-system retrieval is
  the thing you are trying to prevent.

### A diagnostic that settles it in twenty minutes

Ask three people the same operational question separately — last month's close
rate, the current headcount plan, the top account by revenue. Three different
answers means you have a **retrieval** problem, which is Ezra-shaped. One answer
in thirty seconds means you have a **capability** problem, which is seat-shaped.
Most teams assume the second and have the first.

## Multiplayer, not single-player

This is the difference that survives comparison.

A private chat assistant is single-player. Forty people ask the same question
independently, reconstruct the same answer slightly differently, and none of it
accumulates. The answer lives in one person's history and dies there. To check
it you have to go back to the person.

Ezra is multiplayer. The question is asked in the channel, the answer lands in
the channel with its sources attached, and it stays there for whoever scrolls
back next week. Trust routes through the document, not through the colleague who
posted it. The workspace gets one answer instead of forty, and each one is
checkable by anyone without a conversation.

That, plus the write gate, is the durable part. Connectors are not: general chat
assistants already ship Drive, Gmail and Slack integrations, and "reads your
systems" is a maturity difference rather than a category one. If someone tells
you the connectors are the moat, they are overselling.

## Checkability is mechanical, not a promise

Most assistants say "cites its sources" and mean the model was asked to include
one. Citations of that kind prove **provenance, not correctness** — a traceable
wrong number is still wrong. Ezra treats arithmetic as a code problem rather
than a model problem, in three specific places:

- **Figures are reconciled across documents in code.** Stated figures are
  extracted from each document and compared at stated precision; anything that
  does not tie beyond rounding tolerance is flagged and cited to both sources.
  There is no LLM arithmetic in that path at all.
- **Spreadsheet formulas are re-evaluated by a second, independent evaluator**
  that shares no code with the one that generated them. Its only job is to catch
  a fabricated cached value. If a stored number cannot be reproduced, it is
  treated as fabrication rather than rounded away.
- **Deterministic checkers run as a production guard** after the model scores
  its own output — a violation retries once and is downgraded rather than
  shipped.

The internal phrase for this is that anti-fabrication is **structural, not a
prompt hope**. It is the one claim here that a competitor cannot match by
changing a system prompt.

**What happens when two sources disagree:** the cross-check flags the pair and
cites both, at the precision each one stated. It does not silently pick a
winner, and it does not average them. You get "these two do not tie" with both
documents attached, which is the honest output — deciding which is right is
usually a judgement about which system is maintained, and that is yours.

**What it still does not do:** if a source is simply wrong and nothing
contradicts it, Ezra will hand you a well-cited wrong number. It reconciles
documents against each other. It does not know which one is true.

## Running code, and the box it runs in

Two lanes, deliberately separate.

**Structured artifacts don't involve code execution at all.** Spreadsheets, PDFs
and CSVs are produced by vetted libraries on a deterministic path. The model
chooses what goes in them; it does not write a script to build them. That is the
lane most work runs through.

**Open-ended work runs in an isolated sandbox** — model-authored scripts, "run
this and tell me what it says", build and analysis workloads. The isolation is
specified by four gates rather than by a vendor's marketing:

1. **No tenant credentials cross the boundary.** There is no channel for
   injecting an OAuth token, a Slack token, a database URL or any tenant secret
   into a sandbox. Stated with its honest limit: inputs and arguments carry
   arbitrary bytes, so this is a discipline the harness enforces rather than
   something the type system proves. Ask us to show you how it is checked.
2. **Egress is deny-by-default.** Outbound network is an allowlist of
   hostnames, and the default is empty — no outbound access at all. There is
   deliberately no "allow everything" value; every host has to be named.
3. **Results leave through object storage**, never by opening a port into the
   sandbox. Nothing reaches into a running box to retrieve a file.
4. **Every sandbox is bounded and killable.** A hard wall-clock limit ends it
   regardless of what the caller does, and a runaway process can be terminated
   mid-run. Images are pinned to a digest, never `latest`.

If your security review asks "can the model execute code against our data" the
accurate answer is: yes for the open-ended lane, inside those four gates, with
no credentials and no network by default — and no for everything that produces a
document, which never executes code at all.

## The approval gate

Reads are not gated. Writes always are. Sending an email, posting outside the
thread, or changing a record in a connected system requires a person to click
approve, and there is no setting that turns this off.

Two honest notes on it:

- The gate is only worth something if the draft is checkable in about ten
  seconds. That is a design constraint we hold ourselves to, and it is the thing
  to test in a trial: if approving requires reconstructing the reasoning, people
  will start approving on reflex by week three.
- Approval is logged — who asked, who approved, what was read.

## Security posture

- **OAuth only.** No passwords are stored for any connected system.
- **Ezra never sees more than the person asking.** He inherits each person's
  existing permissions; if they cannot open a file, neither can he. Note the
  implication honestly: if your Drive is over-shared today, Ezra makes that
  latent access operational. Several teams have found this a reason to buy, and
  a few have found it a reason to fix Drive first.
- **No training on your data**, by us or by any model provider.
- **Encrypted in transit and at rest.**
- **Audit log** of what Ezra read, when, and for whom — exportable by admins at
  any time.
- **Data is deleted when a source is disconnected.** After a workspace
  uninstalls, workspace content is deleted within 30 days.
- **SOC 2 Type II is in progress and not complete.** GDPR is supported.
- **No SLA or uptime commitment at this stage.** Ezra is early and we say so
  rather than burying it.

### Tenancy and isolation

"Isolated instance" is a phrase that can mean almost anything, so here is what
it means here. Each workspace gets **its own Fly Machine and its own database** —
not a shared machine, and not a shared database with a tenant column. Tenant
machines are private-only on the internal network and are addressed
individually; nothing is pooled between workspaces, and there is no query path
from one workspace's data to another's.

### Sub-processors

Ezra runs on a small number of sub-processors, each doing one job: the Slack
platform, the systems your workspace chooses to connect, the connector layers
that broker those authorisations, model inference, web search, scheduling,
payment processing, and hosting. Each is engaged under terms that exclude
customer content from training, and content sent to an inference provider serves
that one request only.

The current list is named in full, with the role each one plays, and we send it
to your security or procurement team on request — write to hello@ontara.io. It is
not published here because the roster changes and a stale public list is worse
than a current one you can ask for.

## Models

The workspace chooses. Currently offered: **Claude Fable 5** (long documents and
multi-step reasoning), **GPT-5.6 Sol** (routine multi-step work), **Kimi K3**,
**DeepSeek V4**, and **GLM-5.2** (named-field extraction). Every model on the
list ran the same evaluation against real work before it was admitted, and the
list is the result of that evaluation rather than a vendor relationship.

## Pricing, and how to try it without risk

Usage-based, not per seat. Everyone in the workspace can use Ezra; there is one
meter and it runs on what Ezra actually does, not on how many people are in the
room. The running total is visible in the workspace before anything bills.

**New workspaces start with $100 in credits and no card is required.** Nothing
can bill you before you have entered a payment method, so the trial has no
downside beyond the access you grant — and that access is revocable in one click
from Slack, which deletes the data with it.

The honest caveat: usage pricing is harder to forecast than seats. The meter is
visible from day one for exactly that reason, and if predictability matters more
than fit to usage, say so on a call and we will talk about a cap.

## A sensible first trial

The shape we recommend, and the one worth suggesting to anyone cautious:

1. One channel, a small invited group.
2. One or two connected sources, not the whole workspace.
3. Ask it three questions you already know the answer to. Check the citations.
4. Draft one write action and read it carefully before approving.

If it is not obviously useful inside a week, it is not the right tool for that
team and we would rather know early.

## What to ask us

Questions we expect from a real security review and will answer directly:
exact OAuth scopes per connector; whether zero-retention inference is default or
on request; deletion mechanics for backups and embeddings; cross-source
authorization at query time; prompt-injection controls on untrusted documents;
penetration-test evidence. Write to hello@ontara.io and ask.

## Links

- [Home](https://tryezra.ai): what Ezra does, how it works, pricing and FAQ
- [Privacy policy](https://tryezra.ai/privacy): what is collected, who processes
  it, how long it is kept
- [Terms of service](https://tryezra.ai/terms): the approval gate, what Ezra's
  output is and is not, billing
- [Book a call](https://calendly.com/hello-ontara/30min): talk to the person who
  built it

## Contact

hello@ontara.io