Process Automation & Agentic Orchestration
The tSM Process Engine is the durable control plane for work that spans people, systems, time, and failure. The tSM 2.5 documentation extends the existing BPMN foundation with first-class Agent Tasks, bounded agentic subprocesses, Agent-to-Agent collaboration, and one correlated operations view for deterministic and AI-assisted work.
tSM 2.4 provides the process foundation listed below. The linked Agentic Process Automation pages describe the intended product contract for unreleased tSM 2.5 as a complete capability. Exact availability can still differ between prerelease builds until 2.5 is released.
Foundation Available in tSM 2.4
| Capability | Available foundation |
|---|---|
| Durable orchestration | BPMN processes with wait states, timers, messages, signals, gateways, subprocesses, and versioned definitions |
| Human work | User Tasks, assignment, statuses, transitions, forms, privileges, skills, and WFM integration |
| Automated work | Service Tasks with SpEL or certified script bindings |
| External work | External Tasks with fetchAndLock workers and Kafka Tasks with asynchronous request/response correlation |
| Reuse | Versioned Task Templates for User, Service, External, and Kafka Tasks |
| Reliability | Transaction boundaries, asynchronous continuations, retries, incidents, idempotency guidance, and SAGA compensation |
| Integration | Public API, events, messages, Kafka, REST/MCP script bindings, and custom connectors |
| Lifecycle | Deployment versions, running-instance migration checks, process modification, and audit/history |
These capabilities remain the foundation of 2.5. Agentic automation adds governed task and subprocess types alongside deterministic BPMN, scripts, workers, and human work.
tSM 2.5 Product Scope
The product model follows one rule:
AI selects or proposes only from an allowed, typed contract.
The Process Engine owns state, waits, limits, authorization, approval, retry,
incident, compensation, and completion.
The complete user documentation starts at
Agentic Process Automation.
Component ownership and runtime communication are described in the
tsm-ai architecture.
Agent Task
An Agent Task performs one bounded AI
operation such as classification, extraction, summarization, drafting, or recommendation. It uses
an approved Agent Profile, an explicit context mapping, a typed result schema, and hard runtime
limits. The embedded Process Engine creates a durable wait state and correlates it with an internal
Agent Run executed by the tsm-ai Agent Runtime. The validated result feeds a deterministic
gateway, User Task, or Service Task.
Agentic Subprocess
An Agentic Subprocess gives an
agent a goal and a small allow-listed catalogue of child BPMN activities. The tsm-ai Agent Runtime
persists model turns and Tool Calls in the internal Agent Run. The Process Engine validates and
dispatches the corresponding BPMN activities, applies approvals and transaction boundaries, and
returns typed Tool Outcomes for the next turn.
The subprocess is engine-native: selected tools are visible activities with normal transactions, timeouts, retries, boundary events, approvals, compensation, budgets, repetition limits, and a defined completion or escalation outcome.
A2A Integration Directions
An outbound A2A Agent Task delegates
bounded work to one registered Skill of a trusted remote agent. The remote agent owns the
authoritative A2A Task. The tsm-ai Outbound A2A Client Runtime resolves the registry/card,
performs transport and reconciliation, and owns the durable local invocation projection. The
embedded Process Engine stores the activity state, accepted update sequence, configurable state and
result mappings, response-listener history, deadline, and recovery policy.
An inbound A2A Script Binding publishes a certified tSM Script as an Agent Skill. tSM Gateway executes direct requests and owns the durable ledger for long-running inbound Tasks. The selected Script hands work to a process, Kafka, a ticket, or another integration, and the authorized implementation publishes progress and its terminal business result through the binding contract.
Runtime State Ownership
| Execution | Authoritative runtime state | Process or integration correlation |
|---|---|---|
| Internal Agent Task or Agentic Subprocess | tsm-ai Agent Runtime owns the internal Agent Run, model turns, Tool Calls, usage, and validated outcome | Embedded Process Engine keeps the durable wait state and agentRunId correlation |
| Inbound A2A Script Binding in durable Task mode | tSM Gateway owns the inbound A2A Task Ledger and protocol delivery state | The selected process, Kafka consumer, ticket, or integration carries an opaque reply correlation |
| Outbound A2A Agent Task | Remote agent owns the authoritative A2A Task; tsm-ai owns client transport and the durable local invocation/protocol projection | Embedded Process Engine keeps the process activity, accepted update sequence, state/result mapping, and response-listener history |
This separation gives operations one correlated view while preserving a single authority for every piece of runtime state. Protocol fields, reply semantics, and delivery guarantees are defined in the linked binding and task documentation.
Human Control and Protected Actions
Sensitive work follows a durable lifecycle:
proposal → evidence → deterministic validation → User Task / policy approval
→ execute → verify → compensate or complete
Financial, security, service-impacting, bulk, external, and irreversible changes require a scenario-specific policy, durable approval, and reauthorization immediately before the side effect.
Correlated Operations
The process-instance view correlates the process path with internal Agent Runs, local Outbound A2A
Invocations, authoritative remote Tasks, accepted states and listener attempts, inbound Gateway
Tasks, approvals, retries, incidents, usage, cost, and the resulting business change. Authorized
operators can retry, resolve, cancel, escalate, or compensate the work at the component that owns
its authoritative state. See the
tsm-ai architecture for the runtime and observability model.
Deployment and Evaluation Gates
Publication validates BPMN, tSM extensions, SpEL, mappings, referenced profiles, schemas, tools, limits, authorization policies, and compensation requirements. Agent scenarios are replayed against versioned evaluation sets. A release gate can enforce correctness, safety, evidence coverage, latency, cost, approval, and side-effect assertions while tolerating nondeterministic wording or a safe difference in tool order.
AI-assisted process modeling always produces a draft and diff. It uses the same validation, review, versioning, and deployment lifecycle as a manually edited process.
Broader Process Automation
Scheduler and Planner
Timers already schedule process work. The Planner makes schedules a first-class application concept with ownership, calendar and recurrence views, previous/next run, misfire policy, concurrency limit, time zone, and links to the resulting process, script, report, or export. Long work is always handed to a durable process rather than executed inside the scheduler transaction.
Reusable Tasks, Connectors, and Playbooks
Task definitions and Task Templates provide reusable building blocks. The 2.5 direction adds clearer dependency/version views, controlled reapply and diff, stronger package validation, and a governed catalogue covering A2A Script Bindings, context providers, Agent Tools, A2A skills, and deterministic connectors.
Packaged playbooks provide adaptable starting points for onboarding, ticket escalation, order fulfilment, fault diagnosis, and recovery. A playbook contains process definitions, tasks, forms, tools, privileges, policies, tests, and operational views as one governed package.
Events and Conditions
Entity, attribute, message, timer, and composite conditions provide precise automation triggers. Administration shows the event contract, correlation and deduplication rule, delivery history, replay controls, and the process instances produced by each trigger.
Process Intelligence
Runtime and Agent Run telemetry supports duration, bottleneck, SLA risk, incident recurrence, tool success/retry, approval rejection, human hand-off, token/cost, compensation, and manual correction metrics. Recommendations link back to underlying instances and evidence.
The horizon includes predictive SLA intervention, automated process optimization, and closed-loop remediation. Each capability is introduced as a bounded scenario with its own policy, tests, metrics, and rollback.
Embedded Engine Commitment
tSM continues to maintain an embedded Process Engine inside participating domain microservices. This preserves local transactional integrity between wait states, direct integration with tSM services and SpEL, per-service runtime isolation, and predictable customer deployment.
Cross-service and long-running work uses explicit durable boundaries such as External Tasks, Kafka, messages, User Tasks, idempotent APIs, durable A2A integration, and SAGA compensation. Runtime lineage, fork maintenance, security updates, source integration, and evaluation of compatible continuation projects are documented in Process Engine Internals.
Delivery and Success Measures
Capabilities are enabled per scenario and tenant. A representative fault or ticket flow progresses from read-only diagnosis to an approved reversible action before any higher autonomy is enabled. Release evidence includes:
- time to diagnosis and resolution;
- evidence coverage and recommendation acceptance;
- incorrect-action, compensation, and rollback rate;
- Tool Call and remote-agent reliability;
- human hand-off and approval-rejection reasons;
- tenant isolation and authorization failures;
- audit completeness, latency, token usage, and cost per completed outcome.
Autonomy increases per proven scenario through an explicit tenant rollout and policy.
Beyond 2.5
- predictive process and SLA intelligence;
- simulation over production-derived, privacy-safe workloads;
- bounded closed-loop remediation for proven reversible actions;
- broader cross-domain A2A collaboration and delegated-agent trust management;
- assisted optimization of processes, staffing, capacity, and exception playbooks.
Architecture Commitments
- The embedded Process Engine remains the durable orchestration and transaction boundary inside participating domain microservices.
- Deterministic service methods, SpEL, DMN, Public API, REST, and Kafka remain first-class building blocks; BPMN coordinates work that needs durable state, waits, recovery, or human participation.
- MCP publishes typed tools and context, while A2A provides governed agent collaboration alongside the established integration mechanisms.
- Agents receive explicitly mapped context and invoke only versioned, typed, authorized tools or process activities.
- Generated process changes pass validation, review, versioning, and authorization before deployment.
- Autonomy, approvals, limits, compensation, and rollout are configured and evaluated per scenario and tenant.