Autonomous services. Controlled operation.

Domain governance is carried out by the Service Agents themselves. They receive the requirements of their service request and apply them when reviewing contributions, making decisions, requesting rework, and escalating. Jadey SI complements this agentic judgement with a customer-controlled technical security framework. The runtime limits permitted actions through identities, roles, and policies; data and model access, events, and interventions remain traceable within the agreed operating framework.

Jadey SI runs as a Managed Runtime in a customer-controlled Kubernetes environment. Your enterprise is responsible for infrastructure, the cloud account, network boundaries, identities, and target systems, and sets data classification, approvals, and operating rules. Jadey takes on the agreed operation of the agent runtime, including maintenance, scaling, and operational runtime mechanisms.

Service Agents use the integrations, roles, and policies approved for each use case. The existing product architecture provides for operation on Microsoft Azure, AWS, Google Cloud, STACKIT, and on-premises. The specific Kubernetes cluster, network connectivity, identity integration, and project security requirements are defined for the customer environment.

Operating environments

• Microsoft Azure
• AWS
• Google Cloud
• STACKIT
• On-Premises

Ongoing requests retain their state, history, and open dependencies through waiting periods and restarts. Processing resumes through the designated responses, events, or deadlines. Approval points, escalation status, and the next action remain in the request context. The Service Agent does not need to block active execution while waiting; it decides the next domain step within its mandate.

The specific use case determines which agents, systems, data, and operating rules are involved.

Every access check considers the identity, requested action, and target role. Delegation stays within the permissions approved for it. Connected business systems also enforce their own access rights.

Bindings assign services to executing Service Agents and roles. The runtime uses technical identities, Entra app roles, and policies with minimal permissions. Approvals and human decisions are integrated through the designated roles and policies. Secrets and keys remain in the customer-approved management system.

Technical detail: During delegation, the immediately calling Service Agent remains distinguishable from the original technical initiator. user_bound additionally checks that initiator's permissions; agent_bound follows the delegating Service Agent. Agent roles map to defined runtime contexts such as OS user, profile, and working directory.

A service may require information from ERP, CRM, document management, ticketing, identity systems, and other business applications. Those systems remain authoritative for their data. Jadey uses the information in the context of the specific service execution.

The information and tools a Service Agent needs are determined by the resolved service contract, service map, and expected contributions. Jadey can use different models for permitted subtasks. Selection and changes are guided by purpose, data class, quality, cost profile, processing location, and contractual and governance requirements. The service request and its outcome accountability remain intact.

Model and integration framework

• ChatGPT / OpenAI
• Claude
• Gemini
• Mistral
• DeepSeek
• Qwen

Using the models shown requires configured access, suitable provider contracts, and approval for the specific use case.

Bring Your Own Key (BYOK) assigns model access to the customer's provider contracts, keys, and billing relationships. Consumption and usage data can be traced for each configured integration and evaluated for model and cost decisions. More capable models can be used for complex clarifications or critical reviews, and efficient models for standardized, high-volume contributions, subject to quality and governance requirements. Model usage and pricing data provide the basis for estimating model costs. Actual billing is handled by the respective model providers.

When external models are used, the respective model provider processes the information sent to it. Processing location, retention, and training-use conditions are defined during model approval.

Jadey documents system actions, model use, status changes, and involved identities in connection with the service request. Decisions, approvals, interruptions, resumptions, and escalations are associated with their execution context. Depending on the use case, the evidence framework includes logs, review decisions, and completion artifacts.

Jadey Atlas connects services and their actual execution with outcomes, defined metrics, costs, resource use, and execution volume—from the business area under review down to individual work steps. Atlas obtains the information through the responsible Jadey agents and respects the applicable access rights.

Your enterprise defines the rules for access to data and outcomes, as well as their storage, retention, export, and deletion.

Independently operating Service Agents must remain manageable through errors, delays, and policy deviations. Jadey records state changes, errors, timeouts, policy conflicts, and escalations so they can feed into existing observability, reporting, and SIEM-related processes.

For each operating environment, it is defined which events are reported where, which severity levels apply, and who responds. Status, incidents, timeouts, policy conflicts, technical cancellations, and escalations are handled through agreed interfaces and operating paths. Incident, change, and review paths follow a clear RACI assignment, including who approves technical changes, investigates incidents, owns restarts, and handles domain escalations.

The operating agreement specifies responsibilities for infrastructure, updates, backups, recovery, response times, and escalation paths.

Service Agents manage domain delivery themselves according to the applicable service and governance requirements. Within their mandates, they can review contributions, request rework, seek human decisions, or escalate. Technically enforced action and role permissions, stops, timeouts, and kill-switch mechanisms complement this independent governance as security boundaries.

When contributions or evidence are missing, policy conflicts arise, or approval is required, the configured review, waiting, stop, and escalation paths apply. Running tasks can be continued or cancelled by authorized actors. Whether domain rework, a human decision, or technical interruption is required depends on the service conditions and execution context.

Cancelling a task does not automatically reverse actions already performed in connected systems.