Platform · AI OS
An AI layer that is measured, governed and cheap to run
One3's AI platform is designed to route every task to the right model, give agents only the context they need, and gate every action through policy, approvals and evals.
Why One3 treats AI as an operating system
Most business software adds AI as a chat box on top. One3 is designed the other way round. The AI platform sits inside the kernel, so every model call and every agent step goes through the same policy, audit and cost controls as a human user.
The architecture is built so that swapping a model is a config change plus an eval run, never a code change. Open-weight models change every few months. One3 is planned to pick models by measured eval scores, not by reputation.
The platform has six parts:
- Interfaces: Copilot and command bar, WhatsApp and voice, MCP clients and an Agent API.
- Workforce: a goal planner, an agent orchestrator, agents and Digital Employees, and skills built from Actions, prompts and evals.
- Context: the Context Engine, hybrid retrieval, a context graph, memory, a semantic metrics layer and a Company Constitution.
- Models: the Model Hub with local models, frontier APIs, BYOK and per-tenant adapters.
- Control: guardrails, policy and approvals, traces, evals, cost and budgets.
- Flywheel: traces and feedback feed curation, prompt optimisation, fine-tuning, an eval gate, canary and promotion.
Model Hub and router
The Model Hub is planned on LiteLLM, an OpenAI-compatible proxy, with a thin One3 Router on top. It decides which model handles each call. Aggregators such as OpenRouter are planned only as one provider behind it, for non-restricted workloads.
Task-class routing
Each Action declares a task class such as classify, extract, summarise, draft, reason, code, plan, vision, embed, rerank, speech or image.
Data classification first
Data marked restricted routes only to local or in-region models, following tenant policy.
Measured, not assumed
Routing uses eval scores per task class and model from the eval harness.
Confidence cascade
Try the cheapest qualifying model first. Escalate if output fails schema validation, a self-check or a confidence threshold.
Per-tenant semantic cache
Answers are cached per tenant with a TTL and never shared across tenants. Provider prompt caching is used where supported.
BYOK and fallbacks
Tenants can bring their own API keys. Fallback routes cover rate limits and provider outages.
Batch queue
Non-urgent jobs can run in a batch queue, for example overnight on local GPUs.
Per-call cost records
Every call writes a cost record that flows into the FinOps ledger.
Agent runtime
An agent in One3 is a defined object, not a loose prompt:
Agent = Identity + Role + Goal types + Skills (Actions) + Knowledge scopes + Memory policy + Model policy + Budget + Autonomy level per skill + Approval policy + Evals + a human Owner.
- Durable runs. Each agent run is designed as a Temporal workflow. Crashes, retries, long waits for an approval or a customer reply, and scheduled follow-ups survive restarts.
- Bounded loop. Plan, act, observe, reflect, with hard limits on steps, budget and time.
- Tools are One3 Actions. Typed Actions plus approved external MCP tools. Every tool call goes through the Kernel Action Bus for policy, audit and cost.
- Privileged planner, quarantined reader. The model that reads untrusted content such as emails or web pages cannot invoke R3 or R4 Actions. It returns structured data to the planner.
- Shared work board. A manager agent breaks a goal into tasks and assigns them to specialist agents or people through the Projects task model, so human and AI work sit on one board.
- Agent-to-agent. Internal through the event bus; external through A2A and MCP, planned for W5+ for cross-company use.
Autonomy levels A0–A4
| Level | Name | Behaviour | Default promotion rule (tenant-configurable) |
|---|---|---|---|
| A0 | Observe | Watches events and produces insights only | — |
| A1 | Suggest (shadow) | Proposes Actions; a person executes; agreement is scored | At least 50 decisions with at least 90% agreement → A2 |
| A2 | Draft | Prepares the Action for one-click approval | At least 200 approvals with at most 3% edits and zero critical errors → A3 |
| A3 | Act & notify | Executes within budget and policy; a person can reverse or compensate per the Action's reversibility class | Weekly sample audit passes |
| A4 | Autonomous | Executes and optimises within the goal boundary | Only R1–R3 Actions; R4 never above A2 |
Autonomy is earned per skill, and it can be lost
Every promotion also requires the skill's Eval Coverage Score to meet the minimum for the target level, with zero critical failures. Actions that are externally, legally or privacy-irreversible keep an approval gate at any level. Demotion is automatic on an incident, an eval regression or a policy violation.
Context Engine: minimum sufficient context
| Context source | What it holds | Store |
|---|---|---|
| Object context | The record, related records one or two hops away, and recent events | Postgres + Relations |
| Knowledge | Documents, wiki, SOPs and contracts, chunked and cited | Hybrid index: BM25 + vectors + reranker |
| Context Graph | Entities and relationships across apps and connectors | Relations table, graph DB later |
| Metrics | Governed KPIs through a semantic layer | Cube over ClickHouse/Postgres |
| Memory | Session, entity, organisational and procedural memory | Postgres + vectors, with TTL and provenance |
| Constitution | Policies, brand voice, delegation of authority | Versioned document + Cedar policies |
How retrieval (RAG) works
Knowledge answers are designed to be permission-aware and cited. One3 prefers "I don't know" over guessing.
- 1
Ingest and parse
Detect the type and parse PDF, Office, HTML and images with OCR.
- 2
Classify
Tag PII and confidentiality before anything is indexed.
- 3
Chunk with structure
Split along headings and tables, and add contextual chunk summaries.
- 4
Embed and index
Multilingual embeddings into a hybrid index, stamped with the source's access rights.
- 5
Retrieve with permissions
Rewrite and decompose the query, then run permission-filtered hybrid retrieval and rerank. A user or agent never retrieves what they cannot open.
- 6
Answer and check
Answer with citations, run a groundedness check and capture feedback. Per-collection evals run nightly.
Guardrails, in order
Guardrails run at five points on every agent action.
- 1
Input
Resolve tenant and actor, detect and mask PII, screen for prompt injection, and tag tainted sources.
- 2
Planning
Check the tool allow-list, the budget and the autonomy level.
- 3
Output
Validate JSON schema and business rules (Cedar), run a safety classifier, check groundedness and check the Constitution for external content.
- 4
Action
Apply the risk-tier gate, ask for approval if needed, execute, audit and issue a reversal or compensation token.
- 5
Post
Sample for human review, watch for drift, run the incident workflow, and keep a kill switch.
Provenance travels with the value
A value lifted from an email or a web page can still reach a privileged planner. So provenance is attached to each high-risk Action argument, not only to the model.
Untrusted content may propose, never authorise
It cannot set policy, change tools, alter recipients, redirect a payment or approve spend.
Trusted source or human confirmation
Required for bank and payout details, price overrides, recipient audiences, credential changes and any R3/R4 Action.
Fixed at approval, rechecked at dispatch
Recipient, channel, consent basis, amount and final text are bound at approval and re-verified before the external effect.
Secrets never enter context
Credentials stay with the connector worker. The model sees references, not secrets.
Every decision recorded
Actor, mandate, Action version, input and provenance hashes, policy version, budget, risk tier, decision and reasons. Logging does not depend on the model.
Evals are built before the agents
| Eval type | Example | When it runs |
|---|---|---|
| Unit evals per skill | Extract GSTIN, amount and due date from real invoices | On every prompt or model change (CI) |
| RAG evals | Recall@10, groundedness, citation accuracy | Nightly per collection |
| Trajectory evals | Did the agent choose the right Actions in the right order? | CI and nightly |
| Safety / red team | Injection in emails, exfiltration attempts, jailbreaks | Weekly and before promotion |
| Business outcome evals | Ticket resolved without reopen; invoice paid | Continuous, from the event log |
| Tenant golden tasks | Cases written by the tenant | Before promoting autonomy or a model |
| Cost and latency | Cost per successful task, p95 | Continuous |
AI FinOps: cost per business outcome
Every model and tool call is designed to write a trace span through OpenTelemetry into Langfuse and ClickHouse. The span records the tenant, the actor, the goal, workflow and Action, the model and provider, prompt version, tokens, cache use, latency, cost in INR, eval scores and guardrail events.
An attribution ledger joins cost to Actions to outcome events such as an invoice paid, a deal won or a ticket resolved. That lets One3 report AI cost per business outcome, enforce budgets and support outcome-based pricing.
The release rule: no prompt, model, adapter or agent version reaches production unless it beats the current version on its eval suite, or matches it at lower cost.
The AI platform in plan numbers
- autonomy levels, A0 to A4
- 5
- guardrail stages on every action
- 5
- eval types gating releases
- 7
- self-improvement loops
- 4
- context sources in the Context Engine
- 6
Questions about the AI platform
Is my data used to train shared models?
No, not by default. Tenant data is never used to train shared models unless the tenant opts in under a contract clause. Per-tenant adapters use only that tenant's data.
Can I bring my own model provider keys?
Yes, BYOK is part of the Model Hub design. Tenants with BYOK or contractual provider requirements keep direct provider paths.
Can an AI agent send a payment or change bank details on its own?
R4 Actions never run above A2, so a person always approves them. Bank and payout details also need a trusted source or human confirmation. A bank change quoted in an email is treated as evidence for a proposed change, never as the change itself.
How does One3 stop prompt injection?
In layers: injection screening on input, a quarantined reader that cannot invoke high-risk Actions, provenance on high-risk arguments, an allow-list of tools, and red-team evals before any promotion.
Which models will One3 use?
Model choice is decided by evals per task class, not by reputation. The plan lists open-weight candidates and frontier APIs, and treats model names and licences as items to verify, because they change often.
Can I see what the AI costs?
That is the aim of AI FinOps. Every call records its cost, and the attribution ledger is designed to report AI cost per business outcome.
See how governed AI fits your operations
Talk to us about the AI platform, autonomy levels and how One3 plans to keep agents under your team's supervision.