Execution Model

Tentarc runtime does not directly “run a prompt”.
It executes a structured pipeline with strict boundaries.

Stage 1: Normalize ingress

Different channels map to one internal intent format:

{
  "workspaceId": "ws_prod",
  "instanceKey": "ws_prod:session:s_42",
  "intentType": "message|automation|approval|interrupt",
  "idempotencyKey": "sha256(...)",
  "payload": {}
}

This keeps chat/apps/automations on one deterministic path.

Stage 2: Admission gates

Admission runs before any side effect:

• workspace boundary validation
• permission mode validation
• idempotency dedupe
• lane routing (session/task instance)

If a request fails here, data plane never starts.

Stage 3: Instance FIFO execution

After admission, execution enters a per-instance FIFO gate:

• same instanceKey executes serially
• different instanceKeys can run concurrently
• control intents can be projected without corrupting lane order

This is the key to avoiding re-entrancy bugs.

Stage 4: Tool orchestration

Tool calls are unified behind adapters:

• MCP server calls
• REST/API calls
• local filesystem/process operations

The runtime tracks structured tool events so failures are recoverable and auditable.

Stage 5: State projection

Each turn projects:

• state revision delta
• status transition
• resumable cursor/checkpoint

No hidden in-memory-only state is treated as authoritative.

Practical guarantee

Given the same admitted intent stream and initial persisted state, runtime behavior stays predictable enough for production automation and replay debugging.