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.
Provider development · 13 October 2026
Keep the purchase decision with the shopper and the order record with the merchant.
Shopify's Shop MCP release lets MCP-compatible agents search products, build carts, and complete checkout after the shopper confirms the total and payment method. Signed-in shoppers can use Shop Pay and retrieve orders. Shopify says orders appear in the merchant's admin; checkout status must be polled because launch has no webhooks. This is Shopify's released capability, not a shipped DataInbox integration.
For a commerce service owner, a shopper may currently ask an agent about stock, then leave for checkout, while support later reconciles the order and its status. In a proposed Companion flow, an Inbox could hold the service request, eligible product and order context, and an explicit purchase approval boundary. Shop MCP would handle its own cart and checkout; the merchant would remain the order authority. DataInbox would record only the permitted request and returned status, then reconcile completion before any follow-up action.
A pilot could test fewer handoffs, faster complete responses, and easier explanation of failed or changed checkouts. Measure completed orders, abandoned or corrected carts, approval and polling time, support contacts, and total provider plus runtime cost. This requires shopper identity and consent, current price and stock checks, payment handling through the provider, and a recovery path for uncertain checkout status. These are DataInbox design hypotheses, not Shopify-reported savings.
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.