Approval before customer send
Every reply that reaches a customer waits for a person to review and approve it in the current product.
Security & control
Useful AI.
Clear authority.
InboxOS is designed so you choose the operating boundary: which workflows auto-queue, what stays in human review and who can approve. Every outbound email still requires a person, and consequential steps leave a path people can review.
01 · Authority
You define the operating boundary.
Choose the workflows eligible for automation and set their confidence and risk thresholds. Routine low-risk work auto-queues into the Autonomous Queue, where it stays visible and supervised; uncertain, high-impact and customer-facing actions remain with your people.
Roles you control
Role-based permissions limit who can view or perform sensitive actions, keeping review and approval with the people you designate.
You set the autonomy dial
Keep a workflow almost fully reviewed, allow proven low-risk work to auto-queue, or switch Autonomous Queue off entirely where regional policy or your preference requires every item to stay in human review.
Boundaries proportional to risk
AutonomeX calls this Pragraha: customers decide where autonomy is useful, while policy, traceability and human judgment hold the reins.
02 · Deployment
One organisation. One dedicated setup.
The current deployment model uses one Docker-based instance per organisation. The private demo stays separate and uses fictional offline records.
Dedicated organisation setup
Your current deployment is dedicated to your company rather than mixed into a shared operational workspace with other customers.
Sample before live access
The invited demo uses fictional records. Proof Sprint Discovery begins with a historical sample you choose; your live inbox password stays with you.
A controlled path to production
See the offline demo, inspect a chosen past-mail sample, prove one workflow in a pilot, then move forward when evidence and controls are ready.
Residency is made explicit
Trial and go-live placement is agreed for the engagement. The detailed Security Overview records the posture that applies to that contract.
03 · Evidence
A path people can reconstruct.
Processing, review and send events are recorded so operations, auditors and handovers can follow how a piece of work moved.
Handling history you can follow
The record connects the work, the system’s help and the human review instead of leaving the decision scattered across a thread.
Visible review state
Teams can distinguish work that is prepared, waiting for review and approved rather than treating AI output as silently complete.
Evidence for pilot decisions
Service, risk and control outcomes are judged in pilot evidence. The ROI calculator is limited to a transparent labour-capacity proxy.
Materials for internal review
A detailed Security Overview (shared under NDA) and a Capability Register are available through the demo request path for security and leadership review.
04 · Honest limits
Claims stop where evidence stops.
Trust is weakened by borrowed badges and vague promises. The public site states what is true now; the engagement documents state what is contractually included.
05 · Evaluator questions
The detail a security or ops reviewer asks for.
These sit here rather than on the product page so the buying path stays short. The buyer-facing answers remain on the InboxOS page.
What is the default Autonomous Queue rule?
Confidence at least 7 and low request-type risk. That is the shipping default for work that auto-queues, where it stays visible and supervised. You can tighten or open those thresholds. Autonomous Queue is optional: eligibility is decided per request type in your industry pack, so under the default rule a pack with no request type marked low risk leaves nothing for the queue to hold. Autonomous means internal routing, not unsupervised customer send.
How does priority get decided?
From pack rules plus live signals. Priority rises when the industry pack marks the request type as high priority or when tone and urgency look strained. Those two inputs are the whole of it. Separately, request-type risk comes from the pack rules for that request type.
Can we explain what the system did?
Yes. Processing, review and send are recorded as they happen, so operations and auditors can follow how a piece of work moved.
Who can approve and send?
Available now: edit the draft, then a person with authority approves the send. Roles you control keep review in your organisation. Next on the roadmap, not available today: verified-sender protection on the AI path so unknown senders stay out until policy admits them.
What if mail does not match a known request type?
Available now: unclassified work stays visible for review; those reviews with your team feed pack judgment on the same core. Next on the roadmap, not available today: a scheduled review loop for unclassified request types to refresh workflows and pack coverage.
Do you claim SOC 2 or ISO already?
No. AutonomeX holds no ISO 27001, SOC 2 or equivalent certification today. The Security Overview states current posture, and contract-specific controls appear only when a contract includes them.
Take the next responsible step
See the control plane in the product.
Start with fictional logistics records in a private demo. If the Fit Check is real, a Proof Sprint uses a historical sample you choose and a bounded pilot proves one workflow before Implementation and Annual Platform.