LLM & Agentic AI

From Prompt to Action: Anatomy of an AI Agent

See how a proposed tool call becomes an authorized business action through deterministic checks, approval and validated feedback.

Reference architecture - illustrative, not a client deployment

Distinguish model proposals, runtime enforcement and actual business actions.

Complexity
Intermediate
Drawing
Supplied
Listing
Featured
  • Agentic AI
  • Tool Calling
  • MCP
  • Authorization
  • Human-in-the-Loop
  • Enterprise Integration

Overview

This reference architecture is illustrative. It is not a record of a client deployment.

An LLM can propose a tool call; it cannot be the enforcement boundary for its own proposal. The application runtime supplies a bounded task and an allowlisted set of tools, validates the proposed name and arguments, maps the trusted user identity to permissions, and caps steps, time and retries. A low-risk read can proceed when policy permits. A consequential write can require a person to approve the exact operation.

An MCP client/server connection or ordinary API adapter then sends a scoped call to the business API. The runtime validates the observed result before deciding whether to continue or answer. MCP standardizes connectivity and tool exposure, but the protocol does not replace business authorization, approval policy or application-specific safeguards. A timeout is especially important: it does not prove that a write failed, so blind replay can duplicate an action.

A concrete example

A support employee asks an agent to inspect ticket 1042 and raise its priority if the warranty applies. An authorized read retrieves the ticket. The model may propose a priority update, but schema and permission checks run in deterministic code. If policy requires approval, the employee sees the exact fields. Only the approved call reaches the ticketing API, and the response reports the returned state rather than treating the proposal as success.

Common misconception

"An MCP-enabled agent automatically knows which actions are safe." MCP describes how tools are presented and invoked. The host application and downstream service still decide who may do what.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
From Prompt to Action: Anatomy of an AI Agent The model proposes tool calls; deterministic runtime code validates, authorizes and executes them through an MCP or API adapter against a business API, feeding validated results back into a bounded loop. From Prompt to Action: Anatomy of an AI AgentThe model proposes. The runtime enforces. Only the adapter acts on the business. USER REQUEST AGENT RUNTIME EXECUTION BOUNDARY HUMAN User request MODEL LLM tool proposal DETERMINISTIC Runtime +bounded loop DETERMINISTIC Schema +authorization checks HUMAN Approval forsensitive writes EXTERNAL MCP client/serveror API adapter EXTERNAL Business API DATA Validated tool result EXTERNAL Answer or escalation Goal +identity Task + allowedtools Proposedcall Sensitiveactionrequest Approvedaction Authorizedlow-risk read Scoped APIcall Observed outcome Tool result Result summary Approvaldenied Timeout or escalation Legend Data flow Control flow Feedback flow Main path (thick) Alternate path Failure / exit path Guarantees MCP standardizes tool connectivity; it does not authorize or plan. The model only proposes. Deterministic code validates and executes. Bound steps, tokens and retries. Reads are separated from writes. A timeout is not proof a write failed: reconcile, then retry idempotently. After an approval denial, no business API call is executed.

Main walkthrough, step 1 of 6: Receive the goal. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: User request, Runtime + bounded loop

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Receive the goal

    The user submits a goal together with identity context established by the host application.

    Active parts: User request, Runtime + bounded loop

  2. 02Ask the model to propose a call

    The runtime presents the bounded task and allowed tools; the model returns a structured proposal without execution privilege.

    Active parts: Runtime + bounded loop, LLM tool proposal, Schema + authorization checks

  3. 03Enforce policy

    Deterministic checks validate schema, authorization and resource scope, routing writes to approval and permitted reads to the adapter.

    Active parts: Schema + authorization checks, Approval for sensitive writes, MCP client/server or API adapter

  4. 04Authorize consequential writes

    A person approves the exact consequential action before it is released to the execution adapter.

    Active parts: Approval for sensitive writes, MCP client/server or API adapter

  5. 05Execute with scoped credentials

    The adapter invokes the authorized business API and returns the observed outcome for validation.

    Active parts: MCP client/server or API adapter, Business API, Validated tool result

  6. 06Observe, continue or stop

    The runtime uses the validated result to continue within its bounds or return an accurate summary.

    Active parts: Validated tool result, Runtime + bounded loop, Answer or escalation

Connections

  • Goal + identityUser request to Runtime + bounded loopdata
  • Task + allowed toolsRuntime + bounded loop to LLM tool proposaldata
  • Proposed callLLM tool proposal to Schema + authorization checksdata
  • Sensitive action requestSchema + authorization checks to Approval for sensitive writescontrol
  • Approved actionApproval for sensitive writes to MCP client/server or API adaptercontrol
  • Authorized low-risk readSchema + authorization checks to MCP client/server or API adaptercontrol
  • Scoped API callMCP client/server or API adapter to Business APIcontrol
  • Observed outcomeBusiness API to Validated tool resultdata
  • Tool resultValidated tool result to Runtime + bounded loopfeedback
  • Result summaryRuntime + bounded loop to Answer or escalationdata
  • Approval deniedApproval for sensitive writes to Answer or escalationcontrol
  • Timeout or escalationMCP client/server or API adapter to Answer or escalationcontrol

Components

User requesthuman

Captures the user goal with the trusted authentication context.

Responsibilities

  • Captures the user goal with the trusted authentication context.

Inputs

  • User goal
  • Trusted identity

Outputs

  • Task request

Risks

  • Spoofed identity
  • Ambiguous intent
LLM tool proposalmodel

Proposes structured tool calls based on task context and available tools.

Responsibilities

  • Proposes structured tool calls based on task context and available tools.

Inputs

  • Task constraints
  • Tool descriptions

Outputs

  • Proposed tool and arguments

Risks

  • Hallucinated tools
  • Prompt-injected proposals
Runtime + bounded loopdeterministic

Coordinates tool-use rounds, execution limits, state and final response.

Responsibilities

  • Coordinates tool-use rounds, execution limits, state and final response.

Inputs

  • Authenticated request
  • Tool feedback

Outputs

  • Constrained model tasks
  • Response state

Risks

  • Unbounded loops
  • Lost correlation
Schema + authorization checksdeterministic

Deterministically validates tool, arguments, permissions and scope before external execution.

Responsibilities

  • Deterministically validates tool, arguments, permissions and scope before external execution.

Inputs

  • Tool proposal
  • User/resource policy

Outputs

  • Permit, reject or approval requirement

Risks

  • Confused deputy
  • Schema bypass
Approval for sensitive writeshuman

Requests a human decision for consequential actions when required by policy.

Responsibilities

  • Requests a human decision for consequential actions when required by policy.

Inputs

  • Action details
  • Authorizer identity

Outputs

  • Approved/denied decision

Risks

  • Approval fatigue
  • Misleading approval UI
MCP client/server or API adapterexternal

Translates an approved tool request into a scoped external service call.

Responsibilities

  • Translates an approved tool request into a scoped external service call.

Inputs

  • Authorized call
  • Scoped credentials

Outputs

  • Protocol/API invocation

Risks

  • Excessive adapter permissions
  • Untrusted tool descriptions
Business APIexternal

Performs the permitted business operation and returns authoritative status.

Responsibilities

  • Performs the permitted business operation and returns authoritative status.

Inputs

  • Validated request

Outputs

  • Business result / error

Risks

  • Non-idempotent retry
  • Partial execution
Validated tool resultdata

Validates and normalizes observed outputs before feeding them back to the runtime.

Responsibilities

  • Validates and normalizes observed outputs before feeding them back to the runtime.

Inputs

  • API status
  • Result payload

Outputs

  • Structured execution outcome

Risks

  • Untrusted returned instructions
  • Misinterpreted errors
Answer or escalationexternal

Communicates verified outcome, denial, timeout or next required action.

Responsibilities

  • Communicates verified outcome, denial, timeout or next required action.

Inputs

  • Validated result
  • Decision status

Outputs

  • User-visible response

Risks

  • False success claims
  • Hidden uncertainty

Scenario reference

Approval denied

No business API call is executed after denial.

  1. 01Stop before the business API

    The sensitive proposal reaches human review, and denial returns an answer without calling the adapter.

    Active parts: Schema + authorization checks, Approval for sensitive writes, Answer or escalation

Tool timeout

A timeout is not proof that a write failed; reconcile and use idempotency before retrying.

  1. 01Reconcile before claiming success

    The adapter call times out, so the runtime escalates rather than inventing a result or replaying blindly.

    Active parts: MCP client/server or API adapter, Business API, Answer or escalation

Design Decisions

  • Keep schemas, authorization, allowlists, rate limits and credentials outside the model.
  • Separate low-risk reads from consequential writes and display approval arguments clearly.
  • Bound model/tool iterations and reconcile ambiguous outcomes before retrying.
  • Base success on external state or a validated tool response, not generated prose.

Risks & Trade-offs

Prompt injection in user content or tool output can induce unsafe proposals. Overbroad credentials can bypass user scope. Approval fatigue can turn a human gate into a rubber stamp. Non-idempotent retries can duplicate writes, while a timeout can leave the outcome unknown. Logs should tie together the caller, proposal, policy decision, approval and observed result without exposing secrets.

When to Use / Not Use

Use an agent when the task must choose among authorized tools or adapt to observed results. Prefer a deterministic workflow for fixed rules and high-consequence operations where model planning adds little value.

Sources

Related