What is an 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 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

How an AI Agent’s Reasoning Loop (ReAct) Works

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 — 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 — 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.

// 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.

// 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

The canonical decomposition 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, long-term in a database or vector store — and the orchestration loop ties them together, based on the ReAct pattern of interleaving reasoning and acting.

Agent vs. chatbot vs. LLM call vs. workflow

The distinction that matters most, and that almost no glossary draws: a workflow is orchestration through predefined code paths; an agent lets the model direct its own path. Anthropic’s guidance 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ⁿ.

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 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 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.
• Scheduling and coordination — goals spanning several systems, each reached through a scoped tool.

Should you build an agent? A decision matrix

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, and because they run under the calling user’s session, the platform’s ACLs and class-level permissions 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; standardize the tool surface with 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.