28 things Qvrone does that a chat model with tools does not, labelled plainly with what is running, what is being built and what is still research. We promise zero unverified actions, not zero mistakes.
Every run goes door → understand → plan → gate → hands → check → record → learn. Models fill the neural steps; rules, schemas, graphs and read-backs fill the symbolic ones.
why › The model never holds the authority to act, approve or declare success.
A model's plan is compiled against a content-hashed task spec before anything runs: allowed tools, dependencies, budgets, approvals and a required verify contract.
why › A model cannot widen its own tool list or turn an unknown prerequisite into success.
Company rules live in decision tables evaluated at the one gate every tool call passes through.
why › Rules are enforced by code, not requested in a prompt.
An autonomy ladder from observe to high-impact. Terminal actions like pay, refund, deploy and sign always need a human.
why › Autonomy is earned with evidence, per action type, and never skips the top rung.
An approval is bound to one tool, its arguments and the policy version, re-checks who you are, and works once.
why › A changed argument needs a new approval; a replay is refused.
Every write is read back from the system it touched and reported as confirmed, refused, blocked or unknown.
why › Unknown is never reported as done. Enforced today for approvals; rolling out to every tool.
Each tool call is recorded with the authority and policy decision that let it run, in a tamper-evident signed chain.
why › You can prove after the fact what ran, and why it was allowed to.
A check counts only after it has been shown to fail when the behaviour it guards is broken on purpose.
why › A test that cannot go red does not count, for connectors and for the factory.
Five-tier memory with provenance. The agent states as on file only what a person actually said.
why › Remembered facts carry where they came from.
Row-level security inside the database fences every workspace, with separate roles for requests, workers and migrations.
why › Isolation is enforced by the database, and every policy is sabotage-tested.
API or MCP first, code for computation, computer use only where no API exists.
why › The most checkable path is always tried before the least.
Software is read as named elements from the accessibility tree or the page, not pixels. A gate checks each action before it runs and verifies the effect after.
why › It fails closed where pixel-clicking agents fail open, and you can write rules about it.
A vision model may only propose a point. A live hit-test supplies the element's identity, a one-use receipt authorises the click, and an independent re-read verifies it.
why › The model cannot supply identity, approval or success.
Your agents share your browser logins, files and a governed terminal, each on its own leased screen, with chats and memory kept private.
why › Agents work in your real tools without passwords handed to a model.
Pair your own machine to the workspace with a signed key, so agents can use it under the same gate.
why › Bring your own machine; nothing about the gate changes.
Show a task once. It becomes a draft skill, is replayed on a held-out case, and is published only when you approve.
why › A demonstration becomes a reviewed, repeatable skill, not a recording.
Persistent, named agents, each with its own conversations, memory and responsibilities, with progress you can watch and stop.
why › Work does not end when the chat does.
Ask in chat; the agent schedules the work and posts the result back to that conversation.
why › No workflow builder, no dashboard: the conversation is the interface.
Sales, support, operations, finance, project management, research and development, each a set of skills capped at eight tools.
why › Small, reviewed tool sets per role instead of one agent with everything.
A run that has been verified enough times replays without a model, still through the gate. Two failed checks demote it.
why › Repeated work gets cheaper and never silently worse.
Before any model call: rule, then recipe, then cache, then a small model, then a big one, inside token, step and cost budgets.
why › A request a rule can answer spends no model tokens.
A small calibrated decision model for typed questions, such as when to hand a conversation to a person, in any language.
why › It may add friction. It may never remove it.
People reach people through their agents: calls, live hand-off and consented call summaries.
why › The agent connects humans; it does not replace them.
Answers missed calls, press-to-talk, a thumb approval signed with the device key, a three-second kill switch, consent mode by default.
why › An approval tap the model cannot fake.
HDMI in, USB keyboard and mouse out: an agent can operate any computer with nothing installed, every action approved.
why › For machines nothing may be installed on.
Speech in Indian languages, WhatsApp, Razorpay, Zoho and Tally, built for how Indian businesses work.
why › Local channels and payments first, not as an afterthought.
Every connector ships with signed doors, scoped credentials, default rules, limits, a verify step for every write, and an explain trace.
why › Certified only when each check has been broken on purpose and seen to fail.
Claude, ChatGPT and Codex can call Qvrone's governed tools under the same gate, approvals and ledger.
why › Bring your favourite assistant; the rules still apply.