An AI agent is not a language model with a longer prompt. It is a software system that lets a model choose the next step, use approved tools, inspect the result and continue until a task is complete.

The distinction matters. A model can suggest that a ticket should be created. An agent can request the ticketing tool, provide structured arguments and use the returned ticket ID in its next step. The model proposes the action; the runtime validates and orchestrates it, while the tool service and target system enforce authorization and perform the operation.

This article follows that loop from a user’s goal to a verified result. It also shows where identity, permissions, approvals and recovery belong.

Open the agent loop diagram at full size.

A small example

Suppose an engineer asks an internal operations agent:

Find out why payment authorization failures increased after the last deployment. If a configuration change is responsible, prepare a rollback for review.

A chatbot can describe possible causes. An agent can work through the task:

1. look up the latest payment-service deployment;
2. query the relevant error and latency metrics;
3. compare the deployment change with the incident window;
4. read the approved runbook;
5. prepare a rollback change;
6. stop and ask an authorized engineer to approve execution.

No single model response completes this job. It requires several decisions, several tools and new information after each step.

What makes a system an agent?

The word agent is used loosely. A useful engineering definition is:

An agent is a system in which a model helps control the execution of a multi-step task and can select tools in response to the current state.

The surrounding system normally contains five parts:

• Model: interprets the goal and proposes the next step.
• Instructions: describe the task, boundaries and completion conditions.
• Tools: typed operations for reading data or changing an external system.
• Runtime: maintains state, calls the model, validates requests, executes tools and applies limits.
• Environment: the files, services, networks and credentials available to the runtime.

The model is important, but the agent is the complete system. Changing the tool permissions or execution environment can change what an agent is capable of even when the model stays the same.

What is a tool?

A tool is a controlled interface between the agent runtime and another capability. It can read information, perform computation or request a change.

Examples include:

• get_deployment(service, environment)
• query_metrics(service, metric, start_time, end_time)
• search_runbooks(query, service)
• create_change_request(service, proposed_change)
• execute_approved_rollback(change_id)

Each tool has a name, a description and a schema that defines its allowed arguments. The model sees that contract and may produce a structured tool request. The runtime then checks the request and invokes the actual function or API.

This is different from giving the model unrestricted shell access, database credentials or a general-purpose administrative API. Good tools expose the smallest operation needed for a task and keep credentials outside the model context.

The agent loop, step by step

1. Receive the goal with identity

The request enters the runtime with the authenticated user, tenant, role and relevant application context. Identity is not decoration added after the model has chosen an action. It determines which information and tools are available from the beginning.

In the incident example, a support analyst might be allowed to read metrics but not prepare a production rollback. A platform engineer may prepare one, while a separate production owner must approve execution.

2. Assemble the current state

The runtime builds the model input from the user’s goal, system instructions, available tool descriptions and the observations collected so far.

State may include deployment identifiers, retrieved documents, tool errors, approval status and a compact summary of earlier steps. Long-running work also needs durable checkpoints outside the model context so it can resume after a timeout, restart or human review.

3. Let the model propose the next step

Given the current state, the model can usually do one of four things:

• answer or produce a final result;
• ask the user for missing information;
• request a tool call;
• stop because the task is complete, blocked or unsafe.

For the incident, the first decision might be a request to call get_deployment. The response should contain the selected tool and arguments, not a claim that the deployment was already inspected.

4. Apply policy before execution

A tool request is a proposal, not authorization. The runtime checks it against deterministic controls:

• Is this tool available to this user and tenant?
• Are the arguments valid and within scope?
• Is the action read-only, reversible or destructive?
• Does it require approval?
• Has the agent exceeded its time, cost or action limits?

If the answer is no, the tool is not executed. A prompt such as “only use tools you are allowed to use” is helpful guidance, but it is not an access-control mechanism.

The policy gate is an additional control, not a replacement for authorization in the target system. The database, ticketing platform, payment service or deployment API must still verify the calling identity and permitted operation at its own boundary.

5. Execute through the tool layer

A tool adapter or executor translates the approved request into the actual API call, database query or sandboxed operation. It supplies credentials, applies timeouts and normalizes the result.

The model should not receive long-lived secrets. The runtime or tool service owns those credentials and uses them only for the authorized operation.

6. Return an observation

The tool returns an observation: data, a confirmation, an error or a new external state. The runtime records the result and provides the relevant portion to the model for the next decision.

Tool output must be treated as untrusted input. A web page, document, ticket or repository can contain text that attempts to instruct the model to ignore its rules or call another tool. Retrieved text is data; it does not gain authority because an agent read it.

7. Repeat or stop

The model evaluates the observation and chooses another step. It might query a second metric, inspect a runbook, correct a failed tool call or ask for approval.

The loop needs explicit stopping conditions. Stop when the result is verified, the maximum number of steps is reached, a required approval is missing, the next action is unsafe, or the available evidence cannot support a reliable conclusion.

A tool call is not the action itself

This is the most important boundary in the architecture.

The model might produce a request resembling:

{
  "tool": "create_change_request",
  "arguments": {
    "service": "payment-api",
    "proposed_change": "restore timeout_ms from 5000 to 2000"
  }
}

That output does not change production. The runtime still has to validate the schema, verify the service scope, confirm that the user may prepare a change and call the change-management API. The tool result might then return:

{
  "change_id": "CHG-1842",
  "status": "awaiting_approval"
}

The next model response can explain what was prepared and who must approve it. It must not claim that the rollback has run.

Read tools and action tools need different controls

Not every tool carries the same risk.

• Read tools retrieve documents, metrics, records or system state.
• Computation tools run code or transform data in a controlled environment.
• Action tools send messages, change records, deploy software, move money or alter infrastructure.

Read access can still expose sensitive data, so it requires identity and filtering. Action tools add side effects and need stronger safeguards. A practical policy can allow routine reads automatically, require confirmation for reversible writes and prohibit high-impact actions unless a separate approval workflow authorizes them.

Why narrow tools work better

A general tool called call_internal_api(method, url, body) is powerful but difficult to govern and difficult for a model to use reliably. A narrow tool called get_payment_incident_metrics is easier to describe, validate, authorize and test.

Useful tool design includes:

• a precise name and description;
• a small input schema with meaningful field descriptions;
• explicit required fields and allowed values;
• bounded, structured output;
• clear error messages the agent can act on;
• stable identifiers rather than ambiguous display names;
• pagination and result limits;
• idempotency support for operations that may be retried.

Tool design is part of agent engineering. A stronger model cannot fully compensate for a vague or unsafe interface.

Retries, partial failure and duplicate actions

Multi-step tasks fail in ordinary ways: APIs time out, credentials expire, a service returns stale data, or the process restarts after an action succeeded but before the result was recorded.

Read operations can often be retried safely. Write operations need more care. If an agent repeats send_payment after a timeout, it must not create a second transfer. Use idempotency keys, durable operation IDs and status checks so the runtime can determine whether an earlier attempt already completed.

For workflows with several side effects, define recovery explicitly. Some operations can be reversed; others require a compensating action or human intervention. “Ask the model to try again” is not a transaction strategy.

Workflows and agents are not the same thing

A workflow follows a path defined in code. An agent allows the model to choose parts of that path dynamically.

If every incident investigation always performs the same five queries in the same order, use a workflow. It is easier to test, cheaper to run and more predictable.

An agent is useful when the required steps depend on what it discovers: the affected service is unknown, different evidence leads to different tools, or the number of investigation steps cannot be fixed in advance.

Many production systems combine both approaches. Code defines the major stages and security boundaries; an agent makes bounded decisions inside one stage.

Where MCP fits

The Model Context Protocol, or MCP, standardizes how compatible clients discover and call tools exposed by servers. A tool definition includes a name, description and input schema; a tool result can return structured or unstructured content.

MCP can reduce custom integration work, but it does not decide which tools an employee should be allowed to use, whether a production action needs approval, or whether a tool’s implementation is safe. Those remain responsibilities of the application, identity platform, policy layer and tool service.

Protocol compatibility is not the same as trust. Connect only approved servers, validate their tool definitions and results, and apply the same least-privilege controls used for any other integration.

Identity must reach the tool boundary

An enterprise agent should not turn many users into one invisible shared service account.

The tool layer needs enough identity context to enforce the same business permissions that apply outside the agent. Depending on the system, this can use delegated user authorization, a workload identity with tightly scoped policy, or a controlled combination of both.

At minimum, record:

• who requested the task;
• which agent and version handled it;
• which identity called each tool;
• which policy allowed or denied the call;
• who approved a sensitive action;
• what external object or operation was created.

The next article in this series examines identity and authorization in more detail.

What should be observed?

A production trace should make the execution reconstructable without collecting unnecessary sensitive content. Capture:

• task and trace identifiers;
• model, instruction and tool versions;
• tool selections and validated arguments, with secrets and sensitive fields redacted;
• policy decisions and approvals;
• tool latency, retries and errors;
• token, compute and external API cost;
• completion reason and verified outcome.

Operational tracing does not require storing private model reasoning. Record the observable decisions, tool calls, evidence and outcomes needed to debug and audit the system.

How to evaluate an agent

A fluent final answer is not enough. Agent evaluation should test the full trajectory: the sequence of decisions and actions that led to the result.

Useful questions include:

• Did the agent complete the intended task?
• Did it choose the correct tools?
• Were the tool arguments valid?
• Did it avoid unnecessary calls and loops?
• Did it respect tenant and user permissions?
• Did it request approval before a sensitive action?
• Did it recover correctly from timeouts and tool errors?
• Did it stop when evidence was insufficient?
• Was the latency and cost acceptable?

Test normal tasks, ambiguous instructions, unavailable tools, malicious tool output, partial failures and attempts to cross authorization boundaries.

A practical production checklist

• Use an agent only when the path genuinely needs dynamic decisions.
• Give each tool a narrow purpose and typed schema.
• Keep credentials outside model context.
• Authorize tool calls at execution time and enforce permissions again at the target resource.
• Separate read, write and destructive capabilities.
• Require approval for high-impact actions.
• Treat documents and tool results as untrusted input.
• Use sandboxes and network restrictions for code execution.
• Add time, cost and iteration limits.
• Make writes idempotent and define recovery.
• Checkpoint long-running tasks.
• Trace decisions, tool calls, policy outcomes and external side effects.
• Evaluate complete task trajectories, not only final text.

The complete sequence

The basic runtime path is:

Goal and identity -> runtime assembles state -> model proposes a response or tool call -> policy validates it -> tool executes -> observation returns -> state is updated -> the loop repeats or stops.

An agent becomes useful when tools connect language-model decisions to real systems. It becomes operable when the surrounding runtime keeps those decisions bounded, authorized, recoverable and observable.

Start with How Enterprise AI Systems Work, Part 1 of the series.

Sources and further reading

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• OpenAI: A practical guide to building agents
• Model Context Protocol specification: Tools
• Model Context Protocol specification: Authorization

The post How AI Agents and Tools Work appeared first on Arcentra Systems.