Agentic Process Automation

Agentic Process Automation combines durable BPMN orchestration with bounded AI execution. The process remains the authoritative business lifecycle: it defines the goal, available data and capabilities, approval points, limits, deadlines, recovery paths, and the typed result that may continue the flow.

tSM provides three agentic process elements:

• an Agent Task for one bounded AI result;
• an Agentic Subprocess for a controlled model-and-tool loop;
• an A2A Agent Task for work delegated to a registered remote agent.

Inbound agent capabilities are published independently as A2A Script Bindings. A binding can start a process, create a ticket, publish Kafka work, or call another integration; it is a protocol entry point rather than a BPMN element.

Concepts

Concept	Meaning
Agent Profile	Published, versioned behavioral identity and runtime ceiling containing instructions, model policy, contracts, context/tool policies, required privileges, limits, data/evidence policy, and evaluation gates. It grants no privilege.
Agent Runtime	The execution capability in the tsm-ai microservice that resolves an Agent Profile and performs bounded model work for Agent Tasks and Agentic Subprocesses.
Agent Run	Durable record of one internal agent execution, including pinned configuration, inputs, evidence, turns, tool calls, approvals, usage, attempts, and outcome.
Agent Task	BPMN wait state that requests one typed result from Agent Runtime.
Agent Tool	Child BPMN activity explicitly published to an Agentic Subprocess and linked to an exact canonical Tool Definition code@version, with typed input/outcome, authorization, risk, retry, and idempotency policy.
Tool Call / Tool Outcome	Validated proposal made by the agent and the structured observation returned by the executed BPMN activity.
Agentic Subprocess	Bounded ad-hoc scope where Agent Runtime may propose from the currently enabled Agent Tools until a typed completion contract is satisfied.
A2A Agent Task	BPMN wait state that delegates work through the outbound A2A client in tsm-ai to a registered remote agent. The remote A2A Task is authoritative for that execution.

An Assistant Profile configures how the universal AI shell appears on a UI surface and refers to an Agent Profile for runtime behavior. A process uses the Agent Profile directly because its scenario goal, input mapping, compatible contract refinements, and outcome handling are defined by BPMN rather than by a screen. The Agent Profile still supplies the required base input/result contracts and the maximum runtime capability.

Choosing the Process Element

Requirement	Use	Result and lifecycle
One classification, extraction, summary, draft, recommendation, or structured decision	Agent Task	One local Agent Run and one schema-validated result
Several dynamically selected diagnostics or business activities inside one governed scope	Agentic Subprocess	One local Agent Run containing bounded turns and Tool Calls
A known deterministic rule or sequence	DMN, Service Task, or standard BPMN	Deterministic execution without an agent
A separately operated agent owns the work and exposes A2A	A2A Agent Task	Local process correlation plus the remote server's A2A Task
A separately deployed worker owns a technical integration	External Task or Kafka Task	Durable worker or message correlation

Prefer the smallest element that represents the business requirement. A fixed sequence with one uncertain decision usually needs one Agent Task, while an Agentic Subprocess is reserved for cases where observations genuinely determine the next permitted activity.

Runtime Ownership

Component	Authoritative responsibility
Embedded Process Engine	BPMN instance, local transaction, activity wait state, mappings, approvals, retries, incidents, cancellation, compensation, and process history
tsm-ai Agent Runtime	Agent Profile resolution, authorized context, model turns, result validation, internal Agent Run, usage, and evaluation data
tsm-ai Outbound A2A Client Runtime	Agent Registry resolution, remote transport, Outbound A2A Invocation, update normalization, verified protocol projection, and reconciliation
tSM Gateway	Inbound Script MCP and A2A server adapters plus the server-side Task Ledger for inbound TASK A2A Script Bindings; it is not used for outbound A2A
Remote A2A agent	Execution and authoritative A2A Task state for an outbound A2A Agent Task

Agent Run, inbound Gateway Task, local Outbound A2A Invocation, and outbound remote Task are intentionally distinct records. The Operations view correlates them with the process instance and business object while preserving their individual owners and state models.

See tSM AI and Agent Runtime for deployment and service boundaries.

Internal Agent Lifecycle

Agent Task and Agentic Subprocess use the same durable execution foundation:

1. The Process Engine reaches the agent activity and commits its wait state.
2. It emits an idempotent run request containing a stable agentRunId and explicit input mapping.
3. Agent Runtime intake creates or resumes the Agent Run in QUEUED, then a worker claims it.
4. Agent Runtime pins the published Agent Profile, result schema, model policy, context providers, and tool versions.
5. Runtime checks identity, tenant, data policy, and execution budgets before loading context.
6. It performs the bounded model operation or model-and-tool turn.
7. Candidate results and Tool Calls are validated against their schemas and policies.
8. The Process Engine executes approved BPMN activities and returns typed Tool Outcomes when the run uses an Agentic Subprocess.
9. Runtime persists the validated result or failure and publishes a correlated outcome.
10. The Process Engine maps the result and continues, follows a modeled business path, or creates an incident.

The process wait state, request, and result are restart-safe. Duplicate delivery resumes the same logical Agent Run and never creates a second business transition.

Outbound A2A Lifecycle

An A2A Agent Task follows a separate external lifecycle:

1. The deployed activity identifies the approved Agent Registry entry, Skill, mappings, and policy references; tsm-ai resolves and pins the effective Agent Card, interface, and trust policy.
2. It persists a stable a2aInvocationId, outbound messageId, and durable request before dispatch.
3. The tsm-ai Outbound A2A Client Runtime pins the registry/card configuration, creates or resumes the invocation, and sends or streams the request to the selected remote interface.
4. A direct Message completes short work; a returned Task supplies remote taskId, contextId, state, and Artifacts to the durable invocation projection.
5. The process waits while tsm-ai normalizes, deduplicates, persists, and publishes updates from streaming, authenticated push, or polling.
6. The Process Engine applies the configured state mapping and optional State Response Listener. A terminal remote state and its Artifacts are verified before the activity continues.

The Process Engine owns the BPMN activity and mapped business state. tsm-ai owns the local Outbound A2A Invocation; the remote server owns its Task. An internal Agent Run is created only when tSM Agent Runtime performs local model work.

Context, Results, and Evidence

• Input is deny-by-default and selected by explicit variable, field, or context-provider mapping.
• Agent Runtime receives stable identifiers and small typed values instead of unrestricted entities or a complete process-variable map.
• Context providers run with the effective tenant, identity, privileges, and data-egress policy.
• Credentials, tokens, protected routing values, and internal runtime state remain server-side.
• Tool output and remote-agent content are treated as untrusted input, including prompt injection.
• Values used for a business decision carry a source and retrieval time when evidence is required.
• Process variables store the typed business result and stable artifact references; large content stays in governed AI or document storage.

Every result that drives a gateway or side effect is validated against a published Form/JSON Schema. Explanatory text may accompany the result, but process conditions use validated enums, booleans, numbers, or identifiers.

Tools, Approval, and Autonomy

An agent proposes a Tool Call; the Process Engine decides whether and when the corresponding BPMN activity runs. The engine validates the Tool ID, typed arguments, authorization, risk class, remaining budgets, repetition policy, concurrency group, and idempotency key.

Autonomy level	Process behavior	Typical use
Read-only	Execute authorized read tools and collect evidence	Diagnosis, search, summary
Draft	Store a proposed artifact for a following task	Reply, plan, configuration proposal
Confirmed action	Wait for explicit user confirmation before a reversible action	Comment, classification update
Approved process action	Create a User Task or policy approval before protected work	Financial, security, bulk, or service-impacting action
Bounded closed loop	Execute a narrow set of reversible tools with verification and hard limits	Qualified operational remediation

Approval is bound to the exact Tool Call hash, target, arguments, profile, and tool versions. Changing any protected value creates a new approval decision.

Durability, Incidents, and Operations

Agent Run states

State	Meaning
QUEUED	Agent Runtime admitted the durable request and it is waiting for a worker.
RUNNING	Runtime is resolving context, calling the model, or validating a response.
WAITING_TOOL	An Agentic Subprocess is waiting for one or more BPMN activities.
WAITING_APPROVAL	A protected Tool Call is waiting for its modeled approval.
SUCCEEDED	A validated AgentOutcome.RESULT was persisted and delivered.
REVIEW_REQUIRED	A typed AgentOutcome.REQUIRE_REVIEW handover was persisted and delivered.
REJECTED	Published policy returned AgentOutcome.REJECTED.
LIMIT_EXCEEDED	A hard budget produced AgentOutcome.LIMIT_EXCEEDED.
AUTHORIZATION_REVOKED	A live authorization recheck produced the corresponding outcome before further work.
FAILED	Retry or repair policy was exhausted and AgentOutcome.FAILED was delivered.
CANCELED	The process canceled the work; any late result is retained as ignored evidence.

Retries reuse the logical agentRunId, idempotency key, deadline, and aggregate token/cost budgets. Each attempt remains visible. Process cancellation stops queued work where possible and records late responses without advancing the canceled activity.

Incident category	Examples	Recovery
Configuration	Missing profile, schema, provider, tool, or remote Skill	Correct and publish configuration, then retry or migrate according to process policy
Context or policy	Provider unavailable, access denied, data-egress rejection	Restore the provider or route to the modeled human path
Model or result	Provider timeout, invalid structured result, exhausted repair	Retry within the original limits or resolve the incident
Tool or approval	Tool failure, expired approval, resource conflict	Retry the activity, collect approval, compensate, or escalate
Remote A2A	Transport uncertainty, interrupted state, invalid Artifact, remote failure	Reconcile with GetTask, continue the modeled interaction, or cancel/escalate

The process-instance Operations view joins the BPMN path with Agent Run IDs, remote A2A IDs, Tool Calls, approvals, attempts, incidents, evidence, usage, and business outcomes. Operator actions are privileged, audited, and preserve the original correlation and limits.

Enforced Guarantees

• Authorization, tenant routing, credentials, target hosts, tools, models, and data policy are selected by published configuration and server policy.
• Hard limits are checked before every model call and activity dispatch and after usage is recorded.
• Protected writes pass through a deterministic approval and idempotency boundary.
• Model proposals never activate arbitrary BPMN elements or platform APIs.
• A process transaction is never held open while waiting for a model, remote agent, user, or external system.
• A2A identifiers are opaque correlation values and never establish identity, tenant, or access.

Design and Deployment Checklist

• Choose Agent Task, Agentic Subprocess, or A2A Agent Task according to who owns the execution.
• Publish typed input, result, Tool, and Artifact contracts.
• Map only required context and define evidence and data-retention rules.
• Configure hard time, turn, tool, token, cost, retry, repetition, and concurrency limits.
• Add human review for uncertainty and approval for protected effects.
• Define timeout, cancellation, compensation, business-error, and incident paths.
• Pin Agent Profile, model policy, schemas, tools, and remote Agent Card/Skill versions.
• Test successful, invalid, delayed, duplicate, interrupted, canceled, and restart scenarios.
• Evaluate the published version against a versioned scenario set before promotion.

Related Documentation

• Agent Task
• Agentic Subprocess
• A2A Agent Task
• A2A Script Bindings
• tSM AI and Agent Runtime architecture
• Subprocesses
• Process Transactions
• Process Engine Internals