Inbox boundaries
Each Inbox owns one operating context with its own paths, schemas, identities, references, retention, display, and policy.
Control stays close to the business operation.
Architecture that keeps business authority stable
Let AI, tools, and infrastructure change. Keep the operation under control.
DataInbox makes business operations agent-operable without handing one model, platform, or central database unrestricted control. Every message enters a defined Inbox, meets deterministic conditions, uses only approved capabilities, and returns a traceable result.
- Original message preserved
- Policy before intelligence
- Federated by design
- Providers remain replaceable
One message model
From incoming signal to accountable outcome.
The original event is not overwritten by the logic that follows. DataInbox preserves what arrived, creates governed derived state, and treats every result as the next business message.
- 01
Receive
An API call, event, email, document, form, conversation, or agent result arrives as a business message.
- 02
Preserve
The original message remains available before mappings, rules, enrichment, or AI create derived records.
- 03
Decide
The receiving Inbox resolves schema, identity, purpose, policy, routing, permissions, and required approvals.
- 04
Perform
People, systems, agents, or Companions perform only the work permitted for that message and context.
- 05
Record
The decision, action, result, and next state return as traceable messages for the next explicit rule.
The operating stack
Stable business control around replaceable technology.
DataInbox separates what your organisation means and permits from the providers that perform the work. That distinction is what makes the architecture durable.
Deterministic control plane
Mappings, rules, routes, approvals, and result contracts decide what may happen before replaceable intelligence is invoked.
AI cannot silently redefine business authority.
Agent Runtime
Agents receive bounded context, approved tools, iteration limits, and a defined result contract inside the runtime loop.
Agent work becomes an accountable operation.
Companions are not connectors
Connectors transport requests and results. Companions make approved AI, Payment, Identity, and future Voice or Delivery providers available to authorised Inboxes. They perform permitted operations and return state plus evidence through governed contracts.
Providers can change without owning authority or process state.
Policy before intelligence
Agents never receive the whole company by default.
The Inbox decides which message fields, references, tools, Companions, models, actions, approvals, and output requirements belong to the task. AI can interpret or propose. Deterministic configuration retains authority.
- Purpose-bound context
- Explicit tool eligibility
- Human approval where required
- Accepted result contracts
Federated by design
A dossier without one giant context window.
A Customer Inbox, Order Inbox, Finance Inbox, Legal Inbox, or personal strategy Inbox can each retain its own policy and source context. They exchange only permitted business messages, references, and outcomes.
That limits unnecessary exposure, keeps ownership clear, and lets one operation change without forcing every other department into the same data model.
Customer Inbox
Order Inbox
Finance Inbox
Permitted dossier
References and governed outcomes for this specific decision, not unrestricted copies of every source.
Avoid architectural lock-in
Own the operating conditions, not every provider.
Models, vendors, databases, and tools will change. DataInbox keeps their capabilities behind the Inbox contract so the organisation can choose again without rebuilding its business meaning from scratch.
AI
Select by task, sensitivity, region, output, capacity, or cost.
Capabilities
Connect APIs, MCP services, people, and specialist providers.
Data
Choose location, provider, direct access, recovery, and migration path.
Deployment
Use the managed runtime or agree another regional or controlled arrangement.
Configuration is part of the architecture
Change the operation with evidence.
The Inbox configuration is readable, versionable, and reviewable. Technical teams can use the DataInbox CLI to validate, compare, dry-run, and apply a proposed operating model without placing policy inside an opaque automation screen.
See how rules work- 01
Model
Define messages, paths, references, functions, policies, agents, and permitted capabilities.
- 02
Validate
Check authored configuration against the server-authoritative specification.
- 03
Compare
Review the exact difference from the live operating model before changing behaviour.
- 04
Dry-run
Inspect the intended request and validation result without mutating the live Inbox.
- 05
Apply
Activate the reviewed version and keep configuration and runtime outcomes traceable.
inbox.yamlserver validated
paths:
orders:
received: null
review: null
rules:
- id: route_approved_order
event: { type: Data }
condition:
operator: equal
field: status
value: approved
action:
- move_to: /orders/reviewStart with one operating problem
Bring the message flow. We will map the governed architecture.
In one working session we can identify the first Inbox, its message contract, policies, required context, approved capabilities, and a practical path to a running use case.