Platform architecture
One kernel and one Action contract for people, workflows and agents
Every One3 app is planned to be built from 14 kernel primitives. Every change goes through a typed Action that is permissioned, audited and honest about whether it can be reversed.
A kernel plus eight layers
One3 is designed as a Layer 0 Kernel with eight layers above it and a self-improvement flywheel beside them.
The Kernel is the only thing every layer depends on. It is where most engineering quality goes. If a feature cannot be expressed with the kernel primitives, the kernel is changed deliberately through a recorded architecture decision (ADR). One-off bolt-ons are not allowed.
The flywheel runs alongside the AI layers: traces become evals, evals become datasets, datasets feed tuning, and tuned models are promoted only after review.
The layers
| Layer | What it holds |
|---|---|
| L0 Kernel | Objects, Actions, Events, Workflows, Policies, Tenancy |
| L1 Experience | Web app and generative UI, mobile and offline, WhatsApp and voice, external AI via MCP, portals and sites |
| L2 Packs (apps) | Growth, Work, People, Finance and ERP, Industry OS |
| L3 Creation | Apps Builder, Automations, Forms and Survey, Studio and Video, Factory |
| L4 Intelligence | Knowledge and RAG, Context Graph, BI and Semantic Layer, Decision Engine, Forecast, Simulation and Twin |
| L5 AI Workforce | Copilot, Agents, Digital Employees, Agent Squads and Rental, Goals and Autopilot, Memory and Skills |
| L6 AI and Data Infrastructure | Model Hub and Router, Context Engine, Data Fabric, Event Bus, MCP/A2A Gateway |
| L7 Control Plane | Identity for humans and agents, Policy and Governance, Observability, AI FinOps and the Investment & ROI Ledger, Audit and Trust |
| L8 Ecosystem | Marketplace, Developer Platform, Partners, Templates |
The kernel in numbers
- kernel primitives
- 14
- core primitives
- 8
- loop primitives
- 6
- risk tiers, R0 to R4
- 5
- reversibility classes
- 5
- apps planned as Packs
- 200
The 8 core primitives
| Primitive | What it is | Example |
|---|---|---|
| Object | A typed, tenant-scoped record defined by metadata: schema, fields, validation, lifecycle states | Contact, Deal, Ticket, Invoice, Employee, Agent |
| Relation | A typed edge between objects that feeds the Context Graph | Contact works_at Company |
| Action | A typed verb with schemas, permission, risk tier, idempotency key, side effects, reversibility class and emitted events | crm.deal.move_stage, acc.invoice.send |
| Event | An immutable fact emitted by Actions or connectors, in CloudEvents format | crm.deal.stage_changed |
| Workflow | A durable orchestration of Actions, triggered by Events, schedules or humans, compiled to Temporal | Lead nurture, invoice dunning |
| Policy | A declarative rule for who or what may do which Action on which Object, and when | Agents may send discounts up to 10% without approval |
| View | A declarative UI surface bound to Objects and Actions | Deal Kanban, Ticket inbox |
| Goal | Objective to KPIs to plan to Actions to measured outcome | Increase Chennai sales 20% in Q3 |
The 6 loop primitives and their planned waves
| Primitive | Why it is in the kernel | Planned wave |
|---|---|---|
| Actor | One identity model for every doer (human, agent, service, external org agent): permissions, budgets, audit, reputation | W0 |
| Decision | Records options, rationale, chosen action, and expected and actual outcome. Feeds calibration. | W2 |
| Outcome | A verified business result linked to Actions and Decisions. The basis of the Investment & ROI Ledger. | W2 |
| Budget | Money, compute and time allowances, enforced at the Action Bus | W1 for agent budgets, W2 kernel-wide |
| Agreement | A contract or SLA between actors, such as a rental contract | W2 for rental, W6 for cross-company |
| Signal | A detected change or anomaly, such as KPI drift or ROI below threshold, that triggers loops | W2 |
How an Action runs
The UI, API, workflows, agents and MCP clients all call the same Action. The planned flow is the same for each caller.
- 1
Invoke
The caller sends the action, input, actor, an idempotency key and a reason.
- 2
Validate
The Kernel Action Bus checks the schema and resolves the tenant and the actor, human or agent.
- 3
Authorise
The Policy Engine checks actor, action, object, context, risk tier and budget. The request is allowed, denied with a reason, or sent for approval.
- 4
Approve if needed
A human sees a diff preview, the AI rationale and the risk, then approves, rejects or edits.
- 5
Execute
The Pack's handler runs in a transaction with an outbox and returns a result, events and a reversal or compensation token.
- 6
Record
Events, an audit record, a cost record and a trace id are appended to the event log.
Risk tiers
| Tier | Meaning | Default gate |
|---|---|---|
| R0 | Read-only | Permission check only |
| R1 | Reversible internal change, such as updating a field | Allowed, reversal available |
| R2 | Reversible and visible to others, such as assign or schedule | Allowed with notification |
| R3 | External or customer-facing, such as sending a WhatsApp message or publishing | Approval unless autonomy has been earned |
| R4 | Irreversible, financial or legal, such as payments, deletion or payroll | Always human approval plus a second factor |
Reverse or compensate: the five reversibility classes
| Class | Meaning | What the UI promises |
|---|---|---|
| fully_reversible | Internal state can be restored exactly | Reverse |
| compensatable | Cannot be undone, but a compensating Action limits the impact, such as a credit note | Compensate |
| externally_irreversible | The effect has left One3: a message sent, a post published, ad spend incurred | Cannot be reversed. Follow-up options available. |
| legally_irreversible | Creates a legal or statutory effect, such as a signed contract or filed return | Legally binding. Only formal correction applies. |
| privacy_impact_irreversible | Personal data was disclosed or exposed | Disclosure cannot be withdrawn. Incident process applies. |
Honest status for external Actions
A payment gateway or messaging provider cannot join One3's local transaction. So external Actions declare their provider protocol: idempotency, receipt, observation and degraded mode.
If a provider call times out, the Action moves to an unknown remote state. One3 is designed never to retry blindly from there. The user sees "delivery status unknown, checking with the provider", not "sent" and not "failed". A human decides before any irreversible resend or charge.
Untrusted content such as inbound email or web pages may propose a value, but it can never authorise an Action.
Packs: how 200 apps become feasible
A Pack is a versioned bundle of objects, relations, actions and handlers, events, workflows, policies, views, dashboards, agent skills, evals, seed data, migrations and translations, described by a pack.yaml manifest.
First-party Packs
Written by One3 as TypeScript handlers and manifests. The target is that most code is generated from the manifest, measured per Pack in CI.
Tenant Packs
Built in the no-code Apps builder or with AI, for example a dealer management system.
Marketplace Packs
Come from partners and must meet the Marketplace Trust Standard before listing.
Safe upgrades
A 3-way merge of base Pack, new version and tenant customisations, tested on a synthetic sandbox before applying.
Generated interfaces
Each Action's description and examples are designed to generate API docs, MCP tools, Copilot skills and eval cases.
Agent templates too
Digital Employee templates follow the same versioned model, built by the Role Factory from reusable packs.
The closed loop
The 14 primitives connect into one loop:
Signal → Goal → Decision → Workflow → Action → Event → Outcome → back to Decision.
Every Action is taken by an Actor, within a Budget and Policy, under any Agreements that apply. Outcomes feed back into Decisions, so the system can see what worked. The loop primitives are designed from the start, even where they are implemented in later waves.
Questions about the kernel
Why is the Action the core primitive?
Agents create value only through Actions. One typed, permissioned contract for humans, workflows and agents avoids brittle prompt-to-API glue and gives one place for policy, audit and cost.
Can a Digital Employee send a payment on its own?
No. Payments are R4 Actions. They always need human approval plus a second factor.
Does One3 offer undo for everything?
No. The UI says "reverse" only for fully reversible Actions. Sent messages, filed returns and disclosures get compensation or formal correction processes instead.
Can external AI assistants use One3?
The plan publishes One3 as an MCP server. External assistants would call the same Actions, under the same One3 policies and audit.
Are all 14 primitives built in Year 1?
No. Actor is planned for W0, agent Budgets for W1, and Decision, Outcome, Signal and rental Agreements for W2. Cross-company Agreements are planned for W6.
Explore the architecture with our team
Talk to us about the kernel, the Action contract and how Packs will fit your workflows.