---
term: 'AI Agent'
seoTitle: 'AI Agent: The Loop, Tools, Reliability, Security'
headline: 'What is an AI Agent?'
slug: ai-agent
category: ai-modern-stack
shortDefinition: 'An AI agent is an LLM-driven system that pursues a goal in a loop: reason, call a tool, observe the result, and repeat.'
relatedTerms:
  - llm-api
  - model-context-protocol-mcp
  - cloud-code-serverless-functions
  - access-control-lists-acl
contrastsWith:
  - llm-api
aboutTerms:
  - 'The Agent Loop (ReAct)'
  - 'Tools & Function Calling'
  - 'Agent Memory'
faq:
  - question: 'What is an AI agent in simple terms?'
    answer: 'A software system that uses a language model to figure out and carry out a multi-step goal on its own — planning, using tools, and taking actions rather than just chatting. The difference from a chatbot is autonomy: it decides its own sequence of steps and acts on the world through tools.'
  - question: 'What is the difference between an AI agent and a chatbot?'
    answer: 'A chatbot replies — it answers a message and stops. An agent acts — it reasons about the goal, decides which tools to use, calls them, observes the results, and continues until the task is done. A chatbot talks about refunding your order; an agent refunds it.'
  - question: 'What is the difference between an AI agent and a plain LLM call?'
    answer: 'An LLM call answers a prompt and returns text. An agent wraps that call in a loop with tools and memory, so the model can act, see what happened, and reason again — turning a one-shot text generator into a system that pursues a goal over many steps.'
  - question: 'How does the agent loop work?'
    answer: 'Receive a goal, reason about the next step, call a tool, observe the result, reason again — repeat until done or a step or cost limit is hit. This reason-act-observe cycle is the ReAct pattern, and it is what makes an agent agentic rather than conversational.'
  - question: 'What are tools and function calling?'
    answer: 'Tools are external functions — API calls, database queries, code execution — the agent can invoke. Function calling is the mechanism: the model emits a structured JSON call naming a tool and its arguments, your code executes it, and the result goes back to the model. The model never runs the tool; it only requests it.'
  - question: 'What is agent memory?'
    answer: 'Two kinds. Short-term memory is what fits in the context window — the recent steps and working state. Long-term memory is knowledge persisted in a database or vector store and retrieved across sessions. The loop needs both: the window to reason now, the store to remember later.'
  - question: 'What can go wrong with AI agents?'
    answer: 'Wrong or hallucinated tool calls, loops that never terminate, runaway token cost and latency, and the security surface — a prompt injection that turns into a real action. And reliability compounds downward: small per-step error rates multiply into large failure rates over many steps.'
  - question: 'Are AI agents reliable and production-ready?'
    answer: 'Single steps are often reliable; long chains are not. If each step succeeds 95% of the time, ten steps succeed about 60% of the time and twenty about 36% — errors compound. Production agents keep chains short, verify results, gate irreversible actions behind human approval, and constrain what tools can do.'
  - question: 'When should you not use an AI agent?'
    answer: 'When the task is deterministic and well-defined, a plain workflow or ordinary code is cheaper, faster, and more reliable. Agents earn their complexity only when the path can''t be scripted in advance — add autonomy when it demonstrably improves the outcome, not by default.'
  - question: 'How does MCP relate to AI agents?'
    answer: 'The Model Context Protocol is an open standard for how an agent discovers and calls tools and data, replacing one-off integrations with a common interface. MCP is the plumbing between the agent and its tools; the tools themselves are still your backend functions, doing the real work.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)'
    url: 'https://arxiv.org/abs/2210.03629'
  - name: 'Building Effective Agents — Anthropic'
    url: 'https://www.anthropic.com/engineering/building-effective-agents'
  - name: 'LLM-Powered Autonomous Agents — Lilian Weng'
    url: 'https://lilianweng.github.io/posts/2023-06-23-agent/'
  - name: 'Confused Deputy Attacks on Autonomous AI Agents — Cloud Security Alliance'
    url: 'https://cloudsecurityalliance.org/'
  - name: 'AI agent — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/AI_agent'
cta:
  title: 'Your backend is the agent''s guardrail'
  text: 'On Back4app, an agent''s tools are Cloud Code functions that run under the user''s session — ACLs decide what the agent may touch, so a hijacked agent can''t exceed the user''s own permissions.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-30'
translationKey: ai-agent
---

**An AI agent is an LLM-driven system that pursues a goal in a loop: reason, call a tool, observe the result, and repeat.** A plain [LLM call](/glossary/llm-api/) answers and stops; an agent wraps that call in a control loop with **tools** (functions it can invoke), **memory** (state across steps), and enough **autonomy** to choose its own sequence of actions. The load-bearing shift for a backend developer is the plainest and least-said fact about agents: **an agent's "tools" are your backend endpoints** — when an agent "uses a tool," it is calling an API you wrote, which makes your backend, not the prompt, the place where safety actually lives.

## Key takeaways

| Question | Answer |
| --- | --- |
| The loop | Reason → act (call a tool) → observe → repeat until done (ReAct) |
| The four parts | Model (reasoning) · tools (actions) · memory (state) · orchestration (the loop) |
| vs. a chatbot | A chatbot *talks* about the task; an agent *does* it |
| The hard truth | Reliability compounds *downward* — 95%/step is ~60% over 10 steps |
| The safety boundary | The backend enforces what tools can do — not the model's good behavior |

## How an AI Agent's Reasoning Loop (ReAct) Works

```text
GOAL: "Refund my last order and email me the confirmation"

  ┌────────────────────────────────────────────────┐
  │ 1 REASON   model: "I need the user's last order" │
  │ 2 ACT      call tool: find_orders(user, last=1)  │
  │ 3 OBSERVE  result: order #1187, $42, delivered   │
  │ 4 REASON   "eligible — refund it"                │
  │ 5 ACT      call tool: refund_order(1187)         │◄─ each ACT hits
  │ 6 OBSERVE  result: refunded                      │   YOUR backend
  │ 7 REASON   "now email the user"                  │
  │ 8 ACT      call tool: send_email(...)            │
  │ 9 REASON   "done" → final answer                 │
  └────────────────────────────────────────────────┘

The model never runs a tool. It REQUESTS one (name + arguments);
your code executes it and feeds the result back for the next reason step.
```

The tools in that loop, on the backend — scoped, permissioned, running as the user:

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const order = await new Parse.Query('Order').get(req.params.orderId);
  // beforeSave/ACL checks apply: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save();
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

## The Four Core Components of an AI Agent

```mermaid
flowchart LR
  accTitle: The four components of an AI agent
  accDescr: An AI agent combines a language model for reasoning, tools it can invoke to take actions, short-term and long-term memory for state, and an orchestration loop that cycles through reasoning, acting, and observing until the goal is reached. The tools are backend functions and APIs.
  M["Model<br/>(reasoning core)"] --> O["Orchestration loop<br/>reason → act → observe"]
  T["Tools<br/>(your API / functions)"] --> O
  MEM["Memory<br/>short-term (window)<br/>long-term (database)"] --> O
  O -->|"tool calls"| BE[("Your backend<br/>+ data")]
  BE -->|"results"| O
```

The [canonical decomposition](https://lilianweng.github.io/posts/2023-06-23-agent/) is model + planning + memory + tool use, but the operational version is simpler: a **model** reasons, **tools** act (and they are backend functions), **memory** holds state — short-term in the [context window](/glossary/llm-api/), long-term in a [database or vector store](/glossary/vector-database-embeddings/) — and the **orchestration loop** ties them together, based on the [ReAct pattern](https://arxiv.org/abs/2210.03629) of interleaving reasoning and acting.

## Agent vs. chatbot vs. LLM call vs. workflow

| | Plain LLM call | Chatbot | Workflow | AI agent |
| --- | --- | --- | --- | --- |
| Does | Answers once | Converses | Runs fixed steps | Chooses its own steps |
| Control flow | None | Turn-taking | **Predefined code paths** | **Model-directed** |
| Takes actions | No | No | Yes, scripted | Yes, decided at runtime |
| Predictable | Per call | Somewhat | **Deterministic** | **Probabilistic** |
| Right for | Q&A, extraction | Support chat | Known processes | Open-ended goals |

The distinction that matters most, and that almost no glossary draws: **a workflow is [orchestration](/glossary/api-orchestration/) through predefined code paths; an agent lets the model direct its own path.** [Anthropic's guidance](https://www.anthropic.com/engineering/building-effective-agents) is blunt about the consequence — most tasks that *look* like they need an agent are better served by a deterministic workflow, and you add agency only when the path genuinely can't be scripted.

## Reliability: errors compound downward

The honest section the vendor pages avoid. Agents are impressive per step and fragile per chain, because **success multiplies**: if each step succeeds with probability *p*, an *n*-step task succeeds with roughly *pⁿ*.

```text
per-step success   10 steps   20 steps
     95%            ~60%        ~36%
     90%            ~35%        ~12%
     85%            ~20%         ~4%

A demo that nails one impressive step is not a system that nails twenty.
Multi-step, cross-system agent success in the wild is frequently 20–40%.
```

This math dictates the production playbook: **keep chains short**, **verify results** between steps rather than trusting them, **gate irreversible actions** (send, delete, charge, publish) behind human approval, and **cap the loop** with step and cost limits so a confused agent fails cheap instead of expensive. Reliability isn't a model property you wait to improve; it's an architecture you impose.

## The security surface

An agent that can *act* can be *tricked into acting*, which makes it a genuinely new attack surface. **Prompt injection** turns instructions in the model's input into real actions — and the dangerous variant is *indirect*: a poisoned web page, email, or support ticket the agent reads can carry instructions it then executes with your credentials. **Confused deputy** is the shape of the damage: an agent holding broad permissions, manipulated into misusing them on an attacker's behalf. The mitigations are old security discipline aimed at a new actor — **least-privilege, user-scoped credentials** (never hand the agent more than the task's user already has), **deny-by-default, narrowly scoped tools**, sandboxing, and human gates on anything irreversible. The single most important framing: **the backend, not the prompt, is the security boundary.** A prompt can be injected; a server-side [permission check](/glossary/access-control-lists-acl/) cannot be talked out of enforcing itself.

## Designing tools an agent can't misuse

Because the tools *are* your backend, tool design is backend security with the volume up. Make each tool **idempotent** where possible (a retried refund shouldn't double-refund), **narrowly scoped** (one clear action, not raw database access), **permissioned** (it runs under the user's identity and their [ACLs](/glossary/access-control-lists-acl/) apply), and **schema-clear** — the descriptions the model reads to decide *whether* and *how* to call a tool deserve as much care as your prompts, because a vague tool description is a bug the model will find. Expose *actions*, not tables: `refund_order(id)` with its own checks, never `run_sql(query)`.

## Common use cases

- **Customer operations** — an agent resolving a support goal end to end via permissioned tools, human-gated on refunds and cancellations.
- **Coding assistants** — reading a repo, running tools, iterating toward a change under review.
- **Research and synthesis** — multi-step retrieval and summarization where the path isn't known in advance.
- **Data workflows with judgment** — steps that need reasoning between them, not just a fixed [pipeline](/glossary/api-orchestration/).
- **Scheduling and coordination** — goals spanning several systems, each reached through a scoped tool.

## Should you build an agent? A decision matrix

| Situation | Reach for |
| --- | --- |
| The steps are known in advance | A [workflow](/glossary/api-orchestration/) — deterministic, testable |
| A single question or extraction | A plain [LLM call](/glossary/llm-api/) |
| Open-ended goal, path decided at runtime | An agent — its home |
| Irreversible actions in the loop | An agent *with human approval gates* |
| Many reusable tools across agents/models | Standardize them via [MCP](/glossary/model-context-protocol-mcp/) |
| Reliability is safety-critical | Short chains, verification — or don't automate it |

## Limitations and trade-offs

- **Autonomy trades reliability for capability.** The freedom that lets an agent handle open-ended goals is the same freedom that compounds errors — bound it deliberately.
- **Loops cost money and time.** Every iteration is more model calls; agents are slower and pricier than a single call by design — cap and monitor both.
- **Non-determinism resists testing.** You unit-test a workflow; you *evaluate* an agent statistically, over many runs, because the same input can take different paths.
- **The blast radius is your credentials.** An agent is only as safe as the narrowest permission you gave its tools; over-broad access is the incident waiting to happen.
- **Impressive ≠ dependable.** A compelling demo is one lucky chain; production is the boring work of guardrails, gates, and short paths.

## AI agents on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The "tools are backend functions" thesis is the whole integration: an agent's tools are [Cloud Code functions](/glossary/cloud-code-serverless-functions/), and because they run under the calling user's session, the platform's [ACLs and class-level permissions](/glossary/access-control-lists-acl/) gate every read and write the agent attempts — as the code tabs show, a hijacked or prompt-injected agent *cannot exceed the user's own permissions*, because the confused-deputy blast radius is capped by access control rather than by the model behaving. The rest follows: expose scoped actions (`refundOrder`), not raw data; hold the [model key server-side](/glossary/api-key-security/); standardize the tool surface with [MCP](/glossary/model-context-protocol-mcp/) when several agents share it; and let the backend say no. The agent proposes; the backend disposes — which is exactly where the safety of an autonomous system should live.