01
Receive the business message
The right Inbox receives a message with its source, identity, schema, and operating context.
Core platform runtime
Business messages arrive. The runtime makes permitted work happen.
DataInbox Agent Runtime coordinates the context, deterministic policy, approved capabilities, people, agents, and results around every operation. Intelligence can change. Business authority stays with the Inbox.
- Message-native execution
- Deterministic authority
- Replaceable Companions
- Federated policy boundaries
The runtime loop
From message to action, without losing the conditions.
The runtime does not hand raw company data to an agent and hope for the right outcome. It prepares a governed task, resolves authority, and captures the result as the next business message.
02
Resolve authority
Deterministic policy decides which context, tools, Companions, approvals, and actions are permitted.
03
Perform permitted work
A person, system, agent, or Companion investigates, proposes, prepares, or performs the allowed task.
04
Return a governed result
The result becomes a traceable business message that can update state or trigger the next explicit rule.
One runtime, three planes
Stable business control around changing intelligence.
Models, tools, and providers will keep changing. The message contract and business conditions should not have to change with them.
Deterministic control plane
Schemas, identities, purposes, permissions, rules, approvals, retention, and result contracts remain explicit and versioned.
AI cannot silently redefine policy.
Replaceable intelligence plane
Approved AI Companions can be selected by task, data sensitivity, region, output requirement, capacity, or cost policy.
The business contract stays provider-independent.
Federated operating plane
Independent Inboxes exchange only the messages and results their own policies permit. No single Inbox needs every source record.
A dossier can exist without one central data lake.
Federation, not centralisation
A complete dossier does not require one Inbox to own everything.
Customer, order, payment, consent, and case information can remain inside separate operating and security boundaries. Each Inbox contributes only the reference, message, or result the current operation is permitted to use.
- Independent schemas and permissions
- Purpose-bound context exchange
- Separate retention and residency
- One traceable operational dossier
Participants, not owners
Let every capability contribute through the same boundary.
The runtime coordinates who or what may participate. None of them receives broader authority merely because it can produce an answer or perform an action.
AI agents
Use governed context and return proposals or results through a defined contract.
Companions
Make approved AI, payment, identity, and future communication or delivery providers available to authorised Inboxes under company-defined conditions, with state and evidence returned.
Systems and MCP
Expose approved APIs, tools, and MCP capabilities without bypassing the receiving Inbox.
People and approvals
Review exceptions, apply judgment, approve material actions, and remain part of the same evidence trail.
Controlled configuration
Change behaviour with evidence before impact.
Runtime configuration follows a predictable path. Teams can inspect validity and intended differences, simulate the change, and only then apply it.
01Validate
02Compare
03Dry-run
04Apply
Dry-run makes intended runtime behaviour reviewable before live messages are affected.
Deployment control
The policy boundary travels with the operating context.
The managed SaaS runtime is currently configured on DigitalOcean. Shared platform and infrastructure controls support the Inboxes that run there.
Other regional, data-centre, or customer-controlled arrangements are architecture and service-scope decisions. They are evaluated against residency, network, identity, availability, and operational requirements.
Agent Runtime FAQ
Is Agent Runtime an agent framework?
It solves a different layer. An agent framework helps define agent behaviour. DataInbox Agent Runtime governs the business messages, context, permissions, capabilities, approvals, results, and evidence around that work.
Does an AI model make the final policy decision?
No. AI may interpret input or propose work, but deterministic configuration and rules decide which context may be shared and which action may proceed. Human approval can remain mandatory where judgment is required.
Can external agents and MCP services participate?
Yes. They participate through defined message and capability contracts. The Inbox determines which context may leave, which capability may be invoked, and what result is accepted back.
Does federation require one central Inbox?
No. Each Inbox remains a separate policy boundary. A dossier can be assembled from permitted references, messages, and results while source data remains with the Inbox that owns its operating context.
How are runtime configuration changes controlled?
Configuration can be validated, compared, dry-run, and then applied. This makes the intended change visible before it affects live message handling.
Where does the managed runtime run?
The managed SaaS runtime is currently configured on DigitalOcean. Other regional, data-centre, or customer-controlled arrangements depend on the agreed architecture and service scope.
Make AI operational on your terms.
Start with one business message, one operating context, and the conditions that must remain authoritative.