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.
Typed AI results remain proposals.
OpenAI made the Decisions API generally available on 22 October 2026. It evaluates text, images and JSON and returns a probability, category or score; it currently supports GPT-6 Luna only. For example, a service team now reads each return request and finds its route by hand. In a proposed DataInbox flow, the API could suggest a category from the request and order, while the Inbox checks current order state, authority, return rules and any approval before an action. This could reduce handoffs and correction work, but it is neither a delivered integration nor a measured saving. Pilot measures include routing accuracy, false rejections, handling time, corrections, and total API plus runtime cost.
Decisions has its own pricing basis; the Standard GPT-6 Luna token comparison does not price this API. OpenAI documentation.
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.
Integration to configure and test
Relevant customer context first. Live Shopify data when needed.
Shopify's 13 October Shop MCP release provides product search, carts and checkout. The proposed DataInbox flow starts with your own permitted customer and advice context; it is not a delivered Shopify Companion.
Rules narrow the options
Prepare permitted customer details and wizard answers before the question; apply your own advice rules. Fictional example: a visitor seeks a comfortable padel racket under €180.
AI explains the advice
AI explains the rule-based advice. Shop MCP can also use buyer preferences and retrieve multiple products in one lookup.
Shopify checks the live facts
Retrieve product details, price and availability when needed. Shopify handles cart and checkout after shopper confirmation of the total and payment method. Check the returned order status before follow-up.
Keep your own context and rules; do not cache Catalog search results or images. Compare the same questions for advice quality, data freshness, response time, tool rounds, token use and total cost.
Provider development · 8 October 2026
Reuse CRM tools and skills without losing process ownership.
Microsoft's release confirms generally available CRM skills in Copilot Cowork that use Dynamics 365 MCP tools for customer context and business actions. Dynamics remains the system of action; Autopilot is in private preview. Availability still depends on licensing, administrator configuration and user consent. This does not establish a shipped DataInbox integration.
For a service owner, the current pattern can mean copying case details into a separate agent flow and checking the proposed reply back in CRM. In a proposed DataInbox flow, an authorised Inbox could bring the case event, current CRM context and a task-specific skill together, then record the reviewed reply or action as a traceable result. The CRM would still own its records and business actions.
The possible benefit is less duplicate integration work, fewer manual handoffs and clearer decisions. Test it with case completion time, handoffs, correction rate, approval wait and total provider plus runtime cost. The pilot needs permission mapping, current-record checks, explicit action approval and a result contract. These are DataInbox design hypotheses, not measured outcomes from Microsoft.
Provider development · 1 October 2026
Keep agent memory answerable to current business state.
Telnyx's release note confirms a beta API that stores facts and conversation sources by profile, recalls them across sessions, and supports source or profile deletion. Writes finish asynchronously. This is a provider memory capability; it does not establish that a remembered fact is still true, that an agent may act on it, or that DataInbox has a shipped Telnyx integration.
Consider a support owner handling a returning customer's delivery question. Before: the agent asks for preferences again, then someone checks the current order and delivery rules separately. In a proposed DataInbox flow, the agent could use permitted memory as a lead, while the Inbox checks customer identity, current order state and applicable rules before accepting an answer or action. The request, approval when needed, and outcome would remain traceable business messages.
A pilot could test fewer repeated questions and handoffs, faster complete answers, and easier correction of stale facts. Measure resolved contacts, repeat questions, corrections, approval wait, source retrieval and provider plus runtime cost. It needs reliable identity matching, consent and retention rules, deletion across both stores, an authoritative order source, and a recovery path while the memory API remains in beta. These benefits are DataInbox hypotheses to test, not results reported by Telnyx.
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.