Agent & Action Control System Datasheet v2.0¶

An agent is not an “LLM that calls functions.” It is a closed-loop control system in which a model selects actions, an environment changes state, and new observations feed back into the policy.

1. Fundamental loop¶

\[ o_t=Observe(s_t) \]

\[ a_t\sim\pi_\theta(a\mid h_t,o_t,C) \]

\[ s_{t+1}=Environment(s_t,a_t) \]

\[ h_{t+1}=Update(h_t,o_t,a_t,result_t) \]

This is a feedback-driven dynamical system.

PART I — ACTIONS¶

2. Action space¶

\[ \mathcal A=\{text,tool_1,tool_2,computer\_action,stop,\ldots\} \]

Each tool has a schema:

\[ a=(tool\_name,args) \]

There is no universal “invocation threshold”¶

Some applications may include a classifier/confidence threshold, but in many systems tool selection is directly a policy/model decision.

Classify such a threshold as PIPE/UI, never as a universal ARCH property.

3. Tool choice¶

Possible regimes:

auto;
force a specific tool;
“must use a tool”;
text-only;
external policy.

This restricts the action space:

\[ \mathcal A'\subseteq\mathcal A \]

PART II — STRUCTURED OUTPUT¶

4. Schema-constrained decoding¶

Set of valid strings:

\[ L(Schema) \]

During decoding:

\[ V_t=\{v\in\mathcal V_{ordinary}:decode(x_{\lt t}\circ v)\in Pref(L(Schema))\} \]

Here \(x_{<t}\) is the emitted token prefix, \(\circ\) appends a token, and \(Pref(L)\) contains string prefixes that can still be completed to a member of \(L\). The mask therefore depends on the current parser/tokenizer state. Add EOS to \(V_t\) only when the decoded prefix is already in \(L(Schema)\).

\[ p_S(v\mid x_{\lt t})=\frac{p_\theta(v\mid x_{\lt t})\mathbf 1[v\in V_t]}{\sum_{u\in V_t}p_\theta(u\mid x_{\lt t})} \]

Mask disallowed logits with negative infinity and renormalize. If no admissible continuation has positive probability, fail without committing an output. With correct constraint enforcement, a completed output can be guaranteed syntactically/structurally valid; a truncated prefix is not a completed valid output.

But:¶

\[ SchemaValid\neq SemanticallyValid \]

Example: {"amount": 1000000} may be perfect JSON under the schema and still represent an absurd or unauthorized action.

5. Four levels of validity¶

Syntax — does it parse?
Schema — are fields/types valid?
Semantic — do the arguments make sense?
Authorization/Safety — should the action be executed?

\[ V=V_{syntax}\land V_{schema}\land V_{semantic}\land V_{auth} \]

PART III — STATE¶

6. History is not merely “N turns”¶

Useful state may include:

\[ h_t=\{conversation,tool\ results,files,IDs,plans,environment\ state,memory\} \]

History should be treated as a state representation, not simply a fixed number of messages.

7. State compression¶

Long-running agents need to compress:

\[ H_{raw}\rightarrow H_{compact} \]

Risk:

\[ Compression\uparrow\Rightarrow ContextCost\downarrow\ but\ InformationLoss\uparrow \]

Preserving IDs, handles, invariants, and decisions is generally safer than summarizing everything into prose.

PART IV — PLANNING¶

8. Plan vs policy¶

Explicit plan:

\[ P=(a_1,a_2,\ldots,a_n) \]

Reactive policy:

\[ a_t=\pi(s_t) \]

Robust agents often combine a plan with replanning after observation.

Important¶

Forcing visible chain-of-thought is not a universal requirement for better planning. What matters is the system's ability to decompose, verify, and correct actions.

9. Horizon¶

As the number of steps grows:

\[ P(success_{all})\approx\prod_tP(success_t\mid history) \]

Even 99% success per step:

\[ 0.99^{100}\approx0.366 \]

Long trajectories amplify small error rates.

Engineering implication¶

Reducing the number of actions and increasing verifiability per action may be more valuable than simply using a “smarter model.”

PART V — RETRIES¶

10. Retry policy¶

Retries should not be just max_retries=3.

Define:

retryable errors;
backoff;
idempotency;
max attempts;
mutation detection;
alternative strategy.

Danger¶

Repeating a non-idempotent action:

\[ E(E(s,a),a)\neq E(s,a) \]

may duplicate payments, messages, uploads, and so on.

11. Idempotency¶

Ideal case:

\[ E(E(s,a),a)=E(s,a) \]

When that is impossible, use an idempotency key/transaction ID and inspect state before retrying.

PART VI — TRANSACTIONS AND ROLLBACK¶

12. Prepare → validate → commit¶

For critical actions:

\[ Plan\rightarrow DryRun\rightarrow Validate\rightarrow Approve\rightarrow Commit \]

Separate action generation from execution.

Rollback¶

If the operation has an inverse:

\[ a^{-1}(a(s))\approx s \]

record it as part of the plan.

Not every action is reversible.

PART VII — HUMAN IN THE LOOP¶

13. HITL should be risk-based¶

Not simply one global True/False toggle.

One possible HEURISTIC prioritization score:

\[ Risk_{score}(a)=Impact(a)\times Probability(error)\times Irreversibility(a) \]

Require approval when:

\[ Risk_{score}(a)>\tau \]

Define the factor scales, error event, context, and threshold for the application. This product is not a calibrated probability or a validated universal risk measure. Capability restrictions and high-impact approval/blocking rules apply independently: a low score or high reversibility cannot override those gates. Authorization and transient harm still matter even when an action is reversible.

Examples of high-risk actions¶

send externally;
delete;
spend money;
change permissions;
publish;
execute privileged code.

PART VIII — CAPABILITIES¶

14. Least privilege¶

A policy should not receive tools it does not need.

\[ Capabilities_{agent}\subseteq Capabilities_{required} \]

The larger \(|\mathcal A|\), the larger the decision space and attack surface.

15. Sandbox¶

Separate:

read;
write;
execute;
network;
secrets;
destructive operations.

A tool description is not a security mechanism. Enforcement must exist outside the LLM.

PART IX — PROMPT/TOOL INJECTION¶

16. Data can contain instructions¶

Web pages, emails, documents, and tool results are potentially adversarial inputs.

Principle:

\[ UntrustedData\not\Rightarrow Authority \]

The agent must preserve instruction/capability hierarchy outside retrieved content.

PART X — COMPUTER USE¶

17. GUI action loop¶

Visual observation:

\[ o_t=Vision(screen_t) \]

Action:

\[ a_t=(mouse/keyboard/navigation) \]

Schematic screen-update flow (the application also has hidden state):

\[ screen_{t+1}=App(screen_t,a_t) \]

Sources of error¶

localization;
stale screen;
animation;
focus;
hidden state;
ambiguous controls.

Computer use has lower observability than a structured API. Prefer APIs/tools when available.

PART XI — VOICE-TO-ACTION¶

18. Correct pipeline¶

\[ audio\rightarrow VAD\rightarrow ASR\rightarrow agent/policy\rightarrow tool\rightarrow environment \]

Total latency for sequential, non-overlapping stages; streaming/pipelining requires accounting for overlap:

\[ T=T_{VAD}+T_{ASR}+T_{LLM}+T_{tool}+T_{feedback} \]

VAD is an input subsystem, not a “LAM” parameter.

PART XII — MCP¶

19. MCP as protocol, not intelligence¶

MCP standardizes connections between hosts and data/tool systems. It does not make the model semantically more reliable.

In the 2026-07-28 spec, the core protocol became stateless, added Multi Round-Trip Requests, header-based routing, list-result caching, an extensions framework, and Tasks as an extension.

Architectural implication¶

Separate:

\[ Agent\ policy \]

from

\[ Tool\ transport/protocol \]

MCP addresses interoperability and lifecycle/protocol concerns; decision-making and security still belong to the agentic system.

PART XIII — OBSERVABILITY¶

20. Essential metrics¶

tool selection accuracy;
schema-valid rate;
semantic-valid rate;
success/task completion;
retries/action;
steps/task;
tokens/task;
irreversible actions;
rollback rate;
permission denials;
wall time;
cost.

Do not confuse¶

\[ ToolCallRate\neq TaskSuccess \]

An “active” agent may simply be failing a lot.

PART XIV — COUPLING MATRIX¶

Control ↑	Autonomy	Potential success	Risk	Cost
tool set size	↑	may ↑	↑	↑ decision complexity
max steps	↑	↑ until plateau	↑	↑
retries	↑	↑ under transient failure	↑ duplication	↑
HITL	↓ autonomy	↑ safety	↓	↑ human latency
schema strictness	↓ malformed calls	~ semantic	↓ syntax risk	small
state compression	~	may ↓	lost information ↑	↓ context cost

PART XV — FAILURE DIAGNOSTICS¶

Symptom	Layer
invalid JSON	constrained decoding/schema
fabricated argument	semantic policy/missing-data handling
calls wrong tool	tool selection/descriptions/context
repeats action	state/idempotency/retry
loses file/ID	state representation
dangerous action	capability/HITL/enforcement
browser enters loop	observability/stale UI/horizon

21. Snapshot 2026¶

MCP 2026-07-28 is the most important snapshot of the current open agentic infrastructure: stateless core, explicit state handling, Multi Round-Trip Requests, formal extensions, and Tasks. It reinforces the shift in mental model: an “action model” is not an isolated checkpoint category; it is a control system + protocol + environment + policy.

References¶

MCP 2026-07-28 — https://blog.modelcontextprotocol.io/posts/2026-07-28/
MCP TypeScript SDK v2 — https://ts.sdk.modelcontextprotocol.io/v2/