The comparison
An orchestrator runs tasks. An Angel runs a relationship.
An Angel is a per-family guardian. It lives under the family's own domain, it is watched by its own Guardian, it is built fail-closed, and it has no single point of failure. Nothing is shared between families. This page shows, in plain terms and in depth, why that is different from a shared-agent setup or a generic multi-tenant assistant.
No login, no form, no payment on this page. We will never ask for your password. If a page wearing this name does, it is not us.
Side by side
See the difference in one view.
Task runners are real and useful. They sequence tools and finish work. An Angel is built to keep one family safe for years, so the comparison is not feature by feature, it is about who owns the relationship, who watches it, and what happens when something breaks.
| Capability | Angel a per-family guardian | Shared-agent orchestration one agent for everyone | Generic multi-tenant assistant a shared SaaS chatbot |
|---|---|---|---|
| What it is | A guardian that carries one family's relationship across years, sovereign under that family's own domain. | One shared agent that runs tasks for many people from a single account. | A chat assistant that many tenants share on the vendor's cloud. |
| Tenancy and isolation | REAL Share-nothing. Each tenant owns its identity, email, phone number, brain key, gate worker, storage, DNS, and certificates, all under its own domain. Isolation is an allowlist over the whole manifest, so anything that does not resolve under the tenant fails to provision. IN PROGRESS Known legacy shared resources are being removed, tenant by tenant. | One agent, one account, one phone number, shared across everyone. | Logical separation inside the vendor's shared database and shared model. |
| Who watches it | REAL A separate Guardian per Angel watches for intrusion and for the wrong controller, with a one-command response that is reversible and never locks the family out. IN PROGRESS Boxes do not grade their own homework: a GREEN verdict needs facts the box cannot forge. | Logs and alerts you read after the fact. | The vendor's internal monitoring, which you do not control or see. |
| How your profession's data is handled | REAL Built to each profession's own standard, on a commodity with at least two providers, US data residency by default for regulated data. For medicine the default is PHI-never. DESIGNED The full control set per profession is the gated path, with a Risk Analysis and signed BAAs first. | One general configuration for everyone, regardless of profession. | The vendor's standard terms, the same for every customer. |
| Single point of failure | DESIGNED No single leg. Stateless read and health paths run active-active, and exactly one writer acts at a time per archangel, arbitrated by a consensus log with a fencing token enforced at the resource. IN PROGRESS Every layer (DNS, registrar, email, brain, control, secrets) runs on at least two independent providers with tested failover. | The one shared account, number, or worker is the whole system's choke point. | The vendor is the single provider for everything. If it is down, you are down. |
| If the model goes down | IN PROGRESS The brain falls back: a cloud model, then a second model, then a local model on owned hardware. Less capable on fallback, never dead in the water. | Tied to whatever model the shared account points at. | Tied to the vendor's model, with no fallback you control. |
| Control model | IN PROGRESS The boss proposes but cannot act alone. A proposer role holds no key that can authorize a tenant and no tenant secret. Each family's manager verifies a signed record before it converges, and the workers are disposable and fenced. | One operator account can act directly across everyone. | The vendor's platform team holds the keys. |
| Who owns it | DESIGNED The family. Their domain, their accounts, their keys. They can rename the Angel and take it with them. | The operator who runs the shared agent. | The vendor. You rent a seat. |
| Failure default | REAL Fail-closed. Unknown or ambiguous input resolves to the most restrictive outcome, so regulated data cannot reach a free model even on a detector error. | Usually fail-open, to keep tasks moving. | The vendor's default, typically tuned for availability over refusal. |
| What it asks you for | An email. No login, no form, no payment on this page. | Onboarding into the shared account. | An account, often a credit card, and your data on their cloud. |
Tags are honest. REAL ships in a tested module today, IN PROGRESS is partly built and under review, DESIGNED is specified and not yet shipped. What each tag means.
Why an Angel
Five things a task runner cannot give a family.
-
Nothing is shared between families
Each family or firm is a self-contained tenant under its own domain. Identity, email, phone number, brain key, gate worker, storage, DNS, and certificates all belong to that tenant. We enforce it as an allowlist over the whole manifest: anything that does not resolve under the tenant's own namespace fails to provision, so isolation is the default, not a setting.
We name our own former shared resources and are removing them, tenant by tenant. A shared resource is a defect to fix, not a convenience to keep.
-
A separate Guardian watches every Angel
One Guardian per Angel asks three questions without pause: is anyone attacking the box, can only the right controller control this family's Angel, and are the families safe. If the answer is no, the response is a single command that is reversible and never locks the family out. Secrets are read by name and one-way hash, never by value.
Boxes do not grade their own homework. A GREEN verdict requires facts the box cannot forge, corroborated by independent observers.
-
Your profession's data, held to your profession's standard
A doctor's, a lawyer's, an accountant's, and an engineer's data each carry different rules. Your Angel is built to the standard that governs your work, on a commodity with at least two providers, with US data residency by default for regulated data. For medicine the default is PHI-never: the safest record is the one that never exists to leak.
-
No single thing whose failure takes you down
Stateless read and health paths run active-active. Exactly one writer acts at a time per archangel, arbitrated by a real consensus log that issues a lease and a fencing token enforced at the resource, so two regions can never both write. A warm standby is already running, never spun up after an outage.
The brain never dies. A cloud model, then a second model, then a local model on owned hardware. Less capable on fallback, never dead in the water.
-
A chain of command where the boss cannot act alone
The operator holds offline keys, split so no single key is enough. The proposer can ask but holds no key that can authorize a tenant and no tenant secret. Each family's manager checks every order against a signed record before it follows it. The workers that do the tasks are disposable and tightly fenced.
Your data
How your data is protected, in plain terms, for your profession.
Pick your profession. Every panel follows the same shape: the plain default, the standard we build to, the gated path before any real regulated data flows, and what we do not claim yet.
Doctor
In plain terms REAL
By default your Angel is built so no patient health information ever lands anywhere a person could read it. We call this PHI-never. The safest record is the one that does not exist to leak, and the system fails closed, so on any error it refuses rather than exposes.
The standard we build to DESIGNED
Your Angel is designed to the HIPAA Security Rule (the administrative, physical, and technical safeguards), to California's Confidentiality of Medical Information Act, and to 42 CFR Part 2 for addiction care. The brain that handles regulated data is designed to run on a host covered by a signed business associate agreement, on a major cloud, never on a free or consumer model.
Before any real regulated data flows DESIGNED
A written Risk Analysis comes first. Then a signed business associate agreement with every subprocessor that could see PHI. Real PHI does not flow until those are in place. This is the gate, by design.
What we do not claim yet DESIGNED
We do not call the platform "HIPAA compliant" today, we do not claim the operator cannot read PHI, and we do not claim tamper-evident logging as shipped. Those are the path we are building to, gated on the Risk Analysis and the agreements above. SOC 2 and HITRUST are on the assurance roadmap, described as goals, not as certifications we hold.
Lawyer
In plain terms REAL
Your client confidences and privileged material stay inside your own tenant, under your own domain, never pooled with anyone else's. The system fails closed, so unknown or ambiguous content is refused rather than sent.
The standard we build to DESIGNED
Your Angel is designed to preserve attorney-client privilege and to handle legal holds, so material under a hold is retained and not altered, with US data residency by default for regulated matters.
Before any real regulated data flows DESIGNED
The handling rules for privileged material and legal holds are reviewed and set per firm before that data is trusted to the system.
What we do not claim yet DESIGNED
We do not claim any bar or court certification. We describe the standards we build to, and we label what is designed versus what ships today.
Accountant
In plain terms REAL
Your clients' financial records stay isolated under your firm's own domain, never shared with another firm. The system fails closed, so regulated data is refused rather than exposed on an error.
The standard we build to DESIGNED
Your Angel is designed to handle SOX controls, to safeguard nonpublic personal information under GLBA, and to handle cardholder data to PCI expectations, with US data residency by default for regulated data.
Before any real regulated data flows DESIGNED
The control mapping for SOX, GLBA, and PCI is set per firm before that data is trusted to the system.
What we do not claim yet DESIGNED
We do not claim a SOC 2 report or any AICPA attestation as held today. We describe the standards we build to. SOC 2 is on the assurance roadmap, as a goal, not a badge.
Engineer
In plain terms REAL
Your source, your designs, and your trade secrets stay inside your own tenant, under your own domain. The system fails closed, so controlled material is refused rather than sent where it should not go.
The standard we build to DESIGNED
Your Angel is designed to protect intellectual property and to handle export-controlled technical data, so controlled information is not sent to a destination or a model that should not receive it, with US data residency by default for controlled data.
Before any real regulated data flows DESIGNED
The IP boundaries and export-control rules are set per company before controlled data is trusted to the system.
What we do not claim yet DESIGNED
We do not claim any export-control certification as held today. We describe the standards we build to, and we label designed versus shipped.
Architecture
A chain of command where the boss proposes but cannot act alone.
Think of it as a clear chain of command. A person at the top holds the only keys for big changes, and those keys are split so no single one is enough. A proposer can ask for a change but cannot carry it out, because it holds no key that can authorize a family and no family secret. Each family has its own manager that checks every order against a signed record before it acts. The workers that do the actual tasks are disposable and tightly fenced, so a single job can never reach beyond itself.
Expand each layer for the detail.
-
Operator IN PROGRESS
The human at the top. Holds offline hardware keys in a k-of-n split, so authorizing a change needs several keys, not one, and none of them sit online.
-
Proposer (Motlaq) IN PROGRESS
A proposer role. It emits declarative proposals only. It holds no key that can authorize a tenant and no tenant secret, so it can ask for a change but cannot make one happen on its own.
-
Consensus log DESIGNED
An independent, ordered record that agrees on what was proposed before anything acts on it. It issues the writer lease, a monotonic epoch, and a fencing token, so exactly one writer can act at a time.
-
ArchAngels IN PROGRESS
One per tenant. The always-on owner of that family's domain. It pulls proposals, verifies a per-tenant signed hash-chain, and converges itself, so it follows an order only after it has checked the order against a record it can verify.
-
Angels IN PROGRESS
Per-project executors under the ArchAngel. They hold short-lived capabilities, so authority expires quickly and does not pile up.
-
Disposable workers IN PROGRESS
The hands. Sandbox-confined, Linux only, thrown away after the job. A single task cannot reach beyond its own fence.
One declarative engine converges a tenant idempotently.
angel up <tenant> brings a tenant to its declared state,
angel down <tenant> takes it back down, and running it twice does
the same thing as running it once.
IN PROGRESS
Honest by default
We label every claim, so you can tell what runs now from what is on the way.
- REAL
- ships in a tested module today.
- IN PROGRESS
- is partly built and under review.
- DESIGNED
- is specified and not yet shipped.
We describe the standards we build to, including HIPAA, SOC 2, and HITRUST. We do not claim them as badges we hold, and you will not find a certification logo or a trademark we do not own on this page. Where a regulated claim depends on a signed Risk Analysis or a business associate agreement, we say so and we mark it DESIGNED until it is in place.
Get in touch
Building an Angel for the people you protect?
Tell us who you protect and what needs to stay safe. We reply by email. There is no form, no account, and no payment on this page.
No form, no account, no payment. We reply by email only, and we will never ask for your password.