APPSS · Application server for AI-native business

    You want to become an AI-native organisation, right?

    A customer asks where their order is. A supplier confirms a different date. Finance spots an invoice discrepancy. APPSS connects your systems, people and agents around the same business rules and makes the agreed tasks available as services.

    One idea, your name and email. Then we get to know each other.

    Explore everyday business tasks
    Simpler work
    People and agents work from shared business knowledge and agreed goals.
    Reduce costs
    Build on the same APPSS engine, with data storage included. Fewer separate solutions to maintain.
    Better communication
    Service sees the current order. Purchasing reviews a changed delivery date and Finance sees which invoice needs attention.

    Which business task would you like to improve?

    Start with work that comes up every day. Connect the systems and people needed to complete the task.

    Van Donzel

    Check order status

    DataInbox looks up the current order status in iONE. A staff member takes over if the available information is insufficient.

    Mertens

    Release an order

    The order from the ERP system and the customer record from the CRM come together. The order can proceed once all required checks have passed.

    Xenos

    Post and track a transaction

    Rabobank transactions from all stores are posted to the relevant general ledger accounts in AFAS. Processing is auditable from transaction to ledger entry.

    Browse all business tasks

    Trust by design. Your business rules define who can do what.

    You define the data and actions that people and agents need for each task. The APPSS server applies those rules. To answer a delivery question, for example, an agent receives the order status and delivery date. Payment details stay out of the conversation.

    From configuration to daily work

    Configure and test with agents on the left. Choose your interface above the APPSS runtime. Use your template library and swappable AI models for your business context on the right.

    Configure with agents

    Your business rules, privacy agreements and AI policy become testable configuration.

    Agent roles with skills and project context

    • DexPrepare configuration
    • TessTest and compare
    • SamReview permissions and controls

    Your chosen AI tools help configure

    • Codex
    • Claude Code
    • Gemini
    • App skills
    • CLI
    • MCP
    • API

    GDPR · AI Act · your own policy

    Validate, test and compare. Your authorised team approves changes.

    Execute on the runtime

    • Your AI interface
      ChatGPTClaudeGemini
      Talk to APPSS, ask questions and create reports.Through configured MCP tools
    • Webchats and messagesDataInbox
    • Your frontendWeb, app or portal
    • Authorised executing agentsFollow-up work within your agreements

    APIs and configured MCP tools

    APPSS runtime
    application server

    Your data, business rules and process state remain the basis for every action.

    • Identity
    • Permissions
    • Rules

    The runtime checks every action. Human approval where agreed.

    Templates and model choice

    Your template library

    Start with a template from your existing library and configure it for your business process.

    • Sales
    • Service triage

    Hot-swappable AI models

    Choose one or more models for your business context.

    • Cloud
    • Private
    • Local

    Change the model connection, keep your business rules. Suitable models and connections are configured and verified for each application.

    Your interface, templates and model choice grant no additional permissions. The runtime still checks every business action.

    Configuration agents help define and test your agreements. Authorised executing agents do follow-up work within those same agreements.

    Where do GDPR and the AI Act fit?
    • Define purpose, data use, access and retention. Translate relevant privacy agreements into configuration and control points.
    • Assess the AI use case and its risks. Define the required transparency, human oversight and responsibilities.
    • Test configured rules, exceptions and permissions. Review changes and retain appropriate evidence.

    Applicability, legal assessment and the required technical and organisational measures are defined and verified for each application.

    How do agents already help test through the CLI?
    • chat validateChecks a dialogue suite locally without sending messages.
    • chat runRuns agreed test dialogues on an explicitly selected channel and records replies. This is a live test that can activate agents and tools.
    • chat compareCompares two test reports as a packet for review. It does not automatically approve content.

    These are existing Datainbox CLI capabilities for the chat layer. Agents help review the results. APPSS business rules, the frontend and real effects also need their own project tests; a chat report does not establish those.

    New AI. Same way of working?

    A new connection does not transform an organisation.

    You give an agent a task. It uses a connection and returns an answer. But who shares the context, reviews exceptions and looks after the whole process? Without clear answers, your team keeps switching between isolated requests and systems.

    Start with one process. Your people and our domain experts make goals, business knowledge and responsibilities explicit. The agent team helps configure and test the application on APPSS. Your people review how it works; together, we decide the next step.

    Which situation do you recognise?

    Your question for our expert team

    Service needs customer data. Do we need another custom API for that?

    An example of how our AI specialists discuss the configuration, guided by our experts.

    1. Finn · The questioner

      Which customer data does Service need, for what purpose and from which system? I make the question and source agreements explicit.

    2. Ari · The architect

      I model the customer, request and permitted actions on the existing server. The required API follows the agreed model contract.

    3. Sam · The guardian

      I define which fields Service can read and which actions need approval. The server enforces those permissions.

    4. Dex · The builder

      I configure this model and the agreed integration. The ERP keeps doing its existing job; we add the service function where it is needed.

    The first step with APPSS

    A focused service function alongside your existing systems, with agreed data and permissions.

    Your question for our expert team

    Sales has already recorded the customer. Why does Finance have to enter the same details again?

    An example of how our AI specialists discuss the configuration, guided by our experts.

    1. Ravi · The data doctor

      We choose one authoritative customer record and agree what its fields mean. Your CRM can remain that source, or it can move to APPSS through a tested replacement.

    2. Ari · The architect

      Sales, Service and Finance use those customer details for their own tasks. I connect the customer to agreements, service requests and invoicing, with appropriate read and change permissions.

    3. Lou · The steady hand

      We configure data exchange for the systems you keep. Missing or conflicting values go to the designated owner.

    4. Tess · The challenger

      I test a new customer, an address change and duplicate records. Your colleagues check that the next department receives the right details.

    The first step with APPSS

    Record the customer once, with the same agreed details available to the next department.

    Your question for our expert team

    Orders are in the ERP. We still approve exceptions by email and track them in a spreadsheet.

    An example of how our AI specialists discuss the configuration, guided by our experts.

    1. Noor · The organiser

      We start with that one exception, an owner and a clear outcome. Replacing the entire ERP is not a prerequisite.

    2. Finn · The questioner

      Which conditions apply, who decides and when can the order proceed? I capture the rules in your people’s own words.

    3. Dex · The builder

      I configure the supported rules and actions on the existing engine, with the agreed connection to the order.

    4. Tess · The challenger

      I test missing information, duplicate requests and unauthorised approval. Your experts judge whether the configuration matches the real process.

    The first step with APPSS

    A manageable approval route around your existing order process, with a visible decision and next step.

    Your question for our expert team

    The agent knows what needs to happen. Why must someone still look everything up and retype it?

    An example of how our AI specialists discuss the configuration, guided by our experts.

    1. Ari · The architect

      I connect the required data and business actions to the application server’s agreed API, CLI or MCP contract.

    2. Sam · The guardian

      APPSS checks each access and action against configured permissions, state and business rules. An agent can use only the data and actions you have authorised, with human approval where required.

    3. Bo · The guide

      I make it clear to the user what the agent prepares, what has been carried out and where a human decision is still needed.

    4. Pip · The designer

      We choose an interface that fits: your portal, a business application or the optional Web Chat SDK. The same business agreements still apply.

    The first step with APPSS

    From a standalone AI answer to a permitted business action within your configured process.

    Your question for our expert team

    Can we replace our service package and keep our own customer portal familiar?

    An example of how our AI specialists discuss the configuration, guided by our experts.

    1. Noor · The organiser

      We map the service work, data and agreements. Keep what works; the selected package can make way for your own application.

    2. Ravi · The data doctor

      I examine the export, customer identifiers, history and integrations. We agree which record becomes authoritative after the switch.

    3. Pip · The designer

      Your own portal need not be redesigned if it can connect to the agreed APPSS APIs. Your colleagues try familiar tasks against the new behaviour.

    4. Lou · The steady hand

      After a working proof and approval, we make the switch. Data transfer, operations, support and recovery are part of that step.

    The first step with APPSS

    A targeted system replacement, designed around familiar work and shared data.

    Your data in sync. No separate synchronisation fee.

    We keep the agreed data in sync between your applications, with no additional APPSS synchronisation charge. We define the authoritative source for each data item, so copies do not become competing systems of record.

    Setup, access, synchronisation frequency and any external costs are agreed in advance.

    Explore the pricing terms

    Your own portal can stay familiar.

    A different server need not mean a new way of working. A suitable portal or app you control can stay while APPSS takes over the business model behind it. We test the connection and daily tasks with your people.

    Your people define the permissions and business rules. APPSS enforces which data agents may access and which actions they may carry out. Our experts review and guide the agent team. You decide what goes into use.

    How people and agents work from the same agreements

    Start with your everyday work.

    Bring one task that still takes manual coordination or retyping. Together, we create a working proof your people can review.

    Discuss your first step