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	Standard valid tSM entity containing a reusable behavioral identity and maximum capability: instructions, model policy, contracts, context/tool policy, and limits. It grants no privilege. A Run pins its UUID and exact JaVers commit.
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 exposed to an Agentic Subprocess and linked to an exact certified 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 operational evidence
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 an agentRunId for this activity attempt and explicit input mapping.
3. Agent Runtime resolves the referenced Agent Profile UUID to its latest currently valid technical state, validates deterministic admission, and pins profile id + JaVers commitId, result schema, model policy, context providers, Tool versions, and effective limits.
4. AgentRunAdmissionResult returns the persisted acceptance or a safe typed rejection. Acceptance creates the Run in QUEUED; an identical redelivery returns the original decision.
5. Runtime checks live identity, tenant, central data policy, and execution budgets before loading context. A failed REQUIRED provider produces BLOCKED context and no model call; an unavailable selected DEFAULT or AVAILABLE provider produces explicit PARTIAL context and a visible warning.
6. It performs the bounded model operation or model-and-tool turn only with FULL or permitted PARTIAL context.
7. Candidate results and Tool Call batches are validated against their schemas, catalog, hashes, and policies.
8. For an Agentic Subprocess, the Process Engine atomically admits the complete proposal and returns one initial disposition per independent call before executing or approving activities.
9. After every call is terminal, the Process Engine returns one complete ordered Tool Outcome vector; only that vector can start the Run's next model episode.
10. Runtime persists the validated final result or failure and publishes a correlated outcome.
11. The Process Engine maps the result and continues, follows a modeled business path, or creates an incident.

The process wait state, request, admission decision, and result are restart-safe. Duplicate delivery resolves to the same recorded transition and never creates another execution attempt or business transition. Kafka acknowledgement alone does not mean that a Run was accepted.

Outbound A2A Lifecycle

An A2A Agent Task follows a separate external lifecycle:

1. The deployed activity identifies the current valid and conformance-verified Agent Registry entry, Skill, mappings, and policy references; tsm-ai resolves and pins its exact JaVers commit, Agent Card hash, interface, and trust policy.
2. It persists a stable a2aInvocationId, outbound messageId, contextId value or absence, canonical payload, and durable request before dispatch. The registry admits the remote target only after onboarding proves idempotent handling of that exact identity and payload.
3. The tsm-ai Outbound A2A Client Runtime pins the registry/card configuration, creates or resumes the invocation, and sends the request to the remote tSM Gateway's A2A 1.0 JSON-RPC HTTPS interface using the existing X-API-Key and X-Tenant-Id contract. The local Gateway is not an egress proxy.
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 restart-safe GetTask polling after 2, 5, and 10 seconds and then every 30 seconds. Each HTTP attempt has a 30-second technical timeout.
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. Once local cancellation is accepted, a later remote success remains audit-only and cannot advance the process; unconfirmed effects require review.

The initial outbound implementation supports SendMessage, GetTask, and CancelTask. If the first response is uncertain before taskId is known, tsm-ai can only retry the exact same messageId, contextId, and payload under the onboarded idempotency guarantee. GetTask becomes the authoritative reconciliation path only after taskId is persisted. ListTasks(contextId), when an approved remote implementation supports it, is auxiliary discovery and not the duplicate- prevention guarantee. Streaming, subscription, and push notifications are later delivery optimizations; they are not required for the durable process lifecycle.

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.
• Required provider failure blocks inference; optional missing context is visible as typed partial context and missing-source evidence.
• 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.

An Agentic Subprocess proposal is an ordered batch of independent Tool Calls. The Process Engine accepts or rejects the batch envelope atomically, persists an initial SCHEDULED, WAITING_APPROVAL, or REJECTED disposition for every call, and confirms this through AgentToolBatchAdmissionResult before dispatch. The business activities then execute in their own transactions; batch admission does not make their side effects atomic.

V1 does not allow a Tool Call to depend on another call in the same batch. Work that needs an earlier result uses another model episode. Runtime starts that episode only after receiving one complete ordered Tool Outcome vector covering every call. Partial progress is operational data and cannot resume reasoning.

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 Tool Call and approval decision. Approval permits execution; denial, expiry, or cancellation becomes a terminal typed Tool Outcome for the original call. An indeterminate mutating effect requires review or an incident and is never automatically fed into another autonomous step.

Durability, Incidents, and Operations

Agent Run states

State	Meaning
QUEUED	Agent Runtime admitted durable work, or persisted a safe provider retry, and the Run becomes claimable at its configured time.
RUNNING	One runtime worker owns a time-bounded lease and is executing the current model episode.
WAITING	Runtime released its worker and is waiting for one or more persisted process activities, approvals, or external observations.
TERMINAL	Exactly one typed outcome and reason were persisted. The Run is immutable and can never be reopened.

The Operations view may display WAITING_TOOL or WAITING_APPROVAL; these are derived from the pending operation, not additional Run states. A terminal outcome is separately classified as RESULT, REQUIRE_REVIEW, REJECTED, LIMIT_EXCEEDED, AUTHORIZATION_REVOKED, FAILED, or CANCELED.

The Agent Run, episodes, individual provider attempts, pending operations, semantic events, and message inbox/outbox are stored by tsm-ai in its ai schema. The Process Engine stores the BPMN activity attempt, backoff, incident, and aggregate retry budget in its own schema. These schemas may share the platform PostgreSQL database, but neither service changes the other's records directly.

Retry or recovery	Owner	Identity behavior
Kafka redelivery	Receiving service	The inbox recognizes the message; no new attempt or Run is created.
Provider failure or expired runtime lease	tsm-ai	The same Run continues; a provider retry creates a new Provider Attempt within the same model episode and original budgets.
Agent Tool activity retry	Process Engine	The same Agent Run and Tool Call remain waiting for the final Tool Outcome.
Retry of a terminal Agent Task or whole Agentic Subprocess	Process Engine	A new agentRunId is created with a higher activity attempt and links to the previous/root Run.

tsm-ai persists provider backoff and the next runnable time before retry. Kafka may wake a worker, and a periodic reconciler recovers due Runs or expired leases from PostgreSQL. An activity-level attempt, time, and cost ceiling spans all linked Runs, so a new Run cannot reset the business retry budget. Process cancellation stops queued work where possible and records late responses without advancing the canceled activity.

Deadlines and simultaneous completion

The Process Engine owns an optional absolute activityDeadline. A designer may explicitly choose UNBOUNDED for genuinely open-ended remote or human work, but only with visible status, privileged cancellation, and an escalation/incident path; unbounded waiting is never an implicit default. Agent Runtime admission separately pins the most restrictive maxActiveDuration and token, turn, tool, and cost budgets. Active duration is consumed by model episodes, provider calls, and inline Tools, not by QUEUED, durable backoff, or WAITING.

The Process Engine enforces a configured BPMN activity deadline plus process Tool and approval deadlines. tsm-ai enforces active-work, finite provider/inline-call, and local outbound A2A limits. Each owner persists its timer or explicit unbounded choice and uses reconciliation after restart; Kafka delivery is only a notification. Work claim, resume, and result application recheck every applicable budget and deadline, so a delayed timer does not accept late work.

Unknown-duration work returns an operation correlation and waits durably; it is never held as an unbounded synchronous Tool call. Every inline Tool and context/provider call still has a finite technical timeout and fences a late result.

Result, cancellation, and timeout can cross in transit. Each owner keeps its first committed terminal transition. The Process Engine consumes an Agent outcome only while the matching activity attempt is waiting. If the activity already timed out or was canceled, a later result is visible in audit but cannot move the BPMN token. Likewise, a provider response received after a terminal Run cannot replace its outcome or start another model episode.

Incident category	Examples	Recovery
Configuration	Missing/invalid profile, schema, provider, Tool, or remote Skill	Correct and save the profile or certify the missing component, 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	Before taskId, retry only the exact idempotent Message; after taskId, 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. The dedicated Agent Runs UI additionally provides a tenant-scoped listing, event timeline, and read-only execution diagram linked from the process instance. 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 certified component configuration and central 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 a hard active-work budget and finite synchronous-call timeouts; choose a bounded activity deadline or explicitly governed UNBOUNDED wait, plus 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.
• Reference the Agent Profile UUID; verify that admission pins its current valid JaVers commit and all certified model, schema, Tool, and remote Agent Card/Skill versions.
• Test successful, invalid, delayed, duplicate, interrupted, canceled, and restart scenarios.
• Record delivery acceptance against a versioned scenario set; this is project evidence, not a separate profile publication or evaluation lifecycle.

Related Documentation

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