An AI agent is a system that uses a model to choose and perform actions toward a goal. It can call tools, inspect results, update its plan, and continue until it finishes or reaches a limit.

A single LLM call maps one input to one output. The surrounding application decides what happens next. An agent adds a loop and gives the model some control over the next step.

That flexibility helps with tasks whose steps cannot be fixed in advance, but it adds cost, latency, and risk. Use an agent only when dynamic decisions improve the task. Keep permissions, budgets, approvals, and stopping rules in deterministic code.

The loop begins with a goal and the current state. The model decides what information or action is needed, then returns either a tool request or a final answer.

The runtime validates any tool request, executes it, and sends the result back as an observation. The model uses that new evidence to choose another action. This repeats until the task succeeds, the model stops, or the runtime reaches a turn, time, or cost limit.

Reasoning may be hidden or summarized. The important audit trail is observable: input, tool request, policy decision, result, and state change. A failed tool should become a clear observation, not a claim of success.

Tool use lets a model request a function through structured output. The application describes available tools and their argument schemas. The model selects a tool and proposes arguments, but the application performs the real action.

Tools connect a model to live data and capabilities such as search, databases, calculators, code execution, and business APIs. Without them, the model can only generate content from its context.

Tool use is foundational because agents learn from results and decide what to do next. Every request must still pass validation, authorization, timeouts, and approval rules. A model-generated tool call is untrusted input, not permission to execute.

The application sends messages plus tool definitions containing names, descriptions, and argument schemas. The model returns a structured request with a tool name, arguments, and a call ID.

The runtime validates the schema, authenticates the user, checks policy, and executes the function. It records the outcome and sends a tool-result message linked to the same call ID. The model then uses that result to answer or request another tool.

If execution fails, return a safe, useful error instead of pretending the tool succeeded. Side-effectful tools should accept an idempotency key. Log the proposal, policy decision, execution, and response as separate events.

A deterministic workflow follows steps chosen by application code. Branches may depend on known rules, but the model does not decide the overall path. An agentic workflow lets a model choose actions based on the current state.

Deterministic workflows are easier to test, secure, predict, and price. Agentic workflows handle ambiguous tasks and unexpected intermediate results, but their paths vary and may loop or choose a poor tool.

Use fixed code when the process is known, especially for permissions, payments, and compliance. Add agentic decisions only where the next step truly depends on language understanding or open-ended evidence. Many reliable systems combine a deterministic shell with a small agentic step.

ReAct is an agent pattern that interleaves reasoning and actions. The model considers the current problem, chooses a tool, observes the result, and continues with updated information.

The pattern was influential because it connected language-model reasoning with external evidence and actions in one understandable loop. It reduced the need for a complete plan before any real information was gathered.

Modern tool APIs may hide private reasoning and represent actions as structured calls, but the core loop remains. Production versions need stronger controls than the original prompting pattern: typed tools, permissions, step limits, idempotency, error handling, and traces of observable actions.

The system prompt defines the agent's goal, scope, behavior, and tool policy. It can explain when to use tools, when to ask for clarification, when approval is required, and how to handle missing information.

Keep the prompt concise and consistent with tool descriptions. State stopping conditions and require the agent to report failures honestly. Mark external content and tool results as untrusted data.

The prompt guides the model but cannot enforce security. Authentication, authorization, spending limits, sandboxing, and approval gates belong in the runtime. Test conflicts and injection attempts because an agent may read hostile documents while holding useful tools.