Agents Architecture Overview

Tentarc is not a “prompt wrapper.”
It is an execution runtime that keeps agent work deterministic, recoverable, and bounded.

Core model

An agent run is split into three planes:

1. Control plane: admission, permissions, approvals, idempotency.
2. Data plane: planning, tool calls, output generation, state projection.
3. State plane: revisioned memory, status transitions, recovery cursor.

This separation removes most hidden coupling that usually causes flaky automation.

Architecture invariant set

Tentarc is designed around explicit invariants:

• Workspace isolation: no cross-workspace state mutation by default.
• Single-writer per instance: one active execution lane per instance key.
• Idempotent admission: same request key is accepted at most once.
• Monotonic state: state evolves by revision, not in-place overwrite.
• Recoverable progress: interrupted execution can continue from persisted checkpoints.

Execution shape

flowchart TD
  A["Ingress (chat/apps/automation)"] --> B["Control Plane"]
  B --> C["Admission + Permission + Idempotency"]
  C --> D["Runtime Lane (instance FIFO)"]
  D --> E["Tool Adapters (MCP/API/Local)"]
  D --> F["State Plane (revision/status)"]
  F --> G["Recovery + Observability"]

Why this matters in real work

Most agent failures are not “model intelligence” failures.
They are systems failures:

• duplicate side effects after retries
• race conditions across tabs/threads
• silent memory corruption after partial failures
• approval flow mixed with execution flow

Tentarc’s architecture addresses those at runtime boundaries, not at prompt level.