AI Smart Operations

AI Smart Operations brings assistance into the screen where a user is already working. The 2.5 direction is a single contextual AI shell backed by configurable, governed scenarios rather than a separate custom chatbot for every module.

Version scope

The top-bar chat, streaming, threads, attachments, feedback, and contextual SpEL assistance are the tSM 2.4 baseline. The universal business-screen assistant, Assistant Profiles, context providers, and action framework below are targets for unreleased tSM 2.5 and will roll out by scenario.

From 2.4 Chat to the 2.5 Assistant

Capability	tSM 2.4 baseline	tSM 2.5 target
Entry point	AI chat in the top bar	The same AI icon and panel throughout supported screens
Context	SpEL editor context and dedicated integrations	Active screen, business object, selection, role, and scenario-specific server data
Configuration	Dedicated assistant implementation	Versioned Assistant Profile composed from certified providers, tools, and actions
Answers	Streamed text and editor proposals	Answers with evidence, data freshness, and partial-context warnings
Changes	Editor accept/reject and existing API/MCP capabilities	Typed action proposal → preview/diff → confirmation or process approval → deterministic execution
Governance	Application access and assistant-specific controls	Per-profile authorization, data policy, limits, audit, evaluations, and kill switches

The detailed runtime and configuration model is described in Contextual AI Assistant Architecture.

Universal Contextual Assistant

The assistant resolves a profile from the current UI context. The panel must visibly show what it is using, for example Customer C-100045, Ticket TSM-4235, or 12 selected orders. Users can inspect or remove optional context before sending a request.

Typical interactions include:

• On a customer page: summarize the last six months, open issues, contracts, balance, payments, and previous communication.
• On a ticket: explain the escalation, prepare a response, find similar cases, or propose the next step.
• On an order: explain the current fulfilment state, identify a blocking process task, and prepare an approved recovery action.
• In a listing: create and refine a structured filter from natural language or summarize the selected records.
• On a process instance: explain the path, variables, incident, retries, and available operator actions.

Each interaction uses a matched Assistant Profile that defines its context, tools, actions, limits, and the current user's effective privileges.

Configurable Scenarios

Customers create many domain-specific scenarios through configuration. The profile is the main configuration unit shared by the universal AI backend.

Profile part	Example for customer care
Screen match	Customer detail, role CustomerCareAgent
Purpose	Explain customer state and prepare the next communication
Starter questions	“Summarize this customer”, “Why is the balance overdue?”
Required context	Customer, account, open tickets, current balance
Optional context	Payment history, comments, recent orders, project knowledge
Read tools	Similar-ticket search, contract details, process status
Actions	Draft reply, propose comment, create follow-up process
Risk policy	Read immediately; comment after confirmation; financial change through approval process
Evaluation	Role isolation, evidence, missing balance, prompt injection, action confirmation

Business configuration selects providers and tools certified by the platform or project team. Credentials, endpoint routing, Script exposure, and permission rules remain server-controlled configuration referenced by the profile.

Context Composition

The UI sends stable identifiers; the backend loads business data under the current user's identity. Different mechanisms have different roles:

• Public API provides stable, reusable reads and deterministic actions.
• SpEL context providers compose environment-specific read-only data synchronously, such as a customer balance plus recent payments.
• MCP bindings expose narrow, discoverable on-demand tools from certified SpEL scripts or other services.
• Project knowledge supplies procedures and documentation with source links.
• tSM processes handle durable, multi-step work, approvals, waits, retries, and compensation.

The assistant receives a typed snapshot and evidence references. Missing optional data is visible; missing required data causes a safe failure or an explicit request to continue with reduced context.

Answers and Evidence

Answers over business data include an evidence view with the records and providers used, their retrieval time, and any unavailable source. The assistant distinguishes facts, inference, and recommendation. When a provider times out or access is unavailable, the answer identifies the missing source and limits its conclusion accordingly.

For knowledge answers, citations point to the relevant documentation or project source. For data answers, evidence points to accessible tSM objects or a sanitized provider result.

Actions in Chat

The 2.5 target separates conversation from execution:

1. The assistant produces a typed proposal defined by an Action Definition.
2. tSM validates the schema, target object, risk class, and evidence.
3. The UI shows a preview or diff.
4. The user confirms when policy requires it.
5. The server rechecks privileges and calls a deterministic Public API, certified SpEL action, or durable BPMN process.
6. The result, error, approval, and final business effect are audited.

High-impact, bulk, financial, security-sensitive, external, or irreversible writes use a process approval, server-side reauthorization, and an idempotent action contract.

Natural-Language Filtering and Search

2.5 pilot target

Users can describe a listing condition in natural language:

• “Tickets opened in the last 14 days by VIP customers in Germany.”
• “Orders above €10,000 that are waiting for approval.”
• “Only the unresolved incidents assigned to Team A.”

The assistant returns a structured filter proposal. The user sees the interpreted condition and can refine or apply it; the generated filter is validated by the normal listing/TQL layer before it changes the view.

Customer and Ticket Work

Initial business pilot for 2.5

The first read-only profile should focus on a narrow customer-care workflow:

• concise customer and ticket summary;
• contextual Q&A grounded in customer, account, payment, ticket, and process data;
• prepared response or internal note;
• next-best-action recommendation with evidence;
• visible missing/stale data and hand-off to a human specialist.

After evidence quality, data isolation, latency, and user value are proven, the pilot can add a confirmation-gated note action and a durable follow-up process.

Dashboards and Intelligent Reporting

Templates available in tSM 2.4; conversational reporting is a 2.5 target

Planned capabilities include plain-language questions, conversational drill-down, explained anomalies, and reusable dashboard templates. Generated queries and metric definitions remain visible so users can verify how a result was calculated.

Predictive and Proactive Insights

Horizon — delivered only through measured pilots

Candidate scenarios include churn risk, related tickets, SLA breach prediction, process delay risk, and pre-calculated attributes that can be filtered in listings. A prediction must include its model or rule version, timestamp, relevant evidence, and an appropriate fallback. Configured policy and approval determine which action can consume the prediction.

Operational Support and Automation

The same architecture can support L2 operations: correlate incidents and logs, explain a failed process, suggest recovery, or propose a restart. The Process Engine remains the authoritative place for waits, retries, approval, compensation, and audit. An internal Agent Task or Agentic Subprocess runs through the tsm-ai Agent Runtime and its internal Agent Run. An outbound A2A Agent Task delegates work to a remote agent through the tsm-ai Outbound A2A Client Runtime; tsm-ai keeps the durable protocol projection while the process applies configured state mappings and response listeners. An inbound A2A Script Binding publishes tSM capabilities through Gateway and records long-running protocol Tasks in the Gateway-owned ledger. See Process Automation & Agentic Orchestration and the tsm-ai architecture.

2.5 Delivery Gates

1. Universal shell and profile resolution.
2. Server-side context providers with evidence and end-user authorization.
3. Read-only customer-care pilot and offline evaluation set.
4. Typed low-risk proposals with preview and explicit confirmation.
5. Durable approval-gated actions through the Process Engine.
6. Reusable profile administration, telemetry, and controlled module rollout.

Each profile is released separately. A global icon may be visible throughout the application, but unsupported screens use a safe generic profile or clearly state that no scenario is configured.

Success Measures

• answer correctness and evidence coverage;
• time saved per supported workflow;
• recommendation acceptance and subsequent correction rate;
• provider/tool failure and partial-context rate;
• confirmation rejection, rollback, and unauthorized-action rate;
• hand-off rate and reason;
• latency and model cost per successful outcome;
• tenant, role, and entity-boundary evaluation results.