An AI agent is just an LLM,
some functions, and a loop.

Every second sales deck in 2026 has the word "agent" on it, priced like it's alien technology. So let's ruin the mystique: an AI agent is a language model, a list of functions it's allowed to call, and a while loop. That's the whole trick.

We run one in production. It's written in plain PHP — no framework, no orchestration platform, no "agentic mesh". Once you see the three parts, you'll be able to judge every agent pitch you hear, including ours.

The three parts

That's genuinely it. The model never touches your database. It can only request one of the functions you defined, with the arguments it thinks are right. Your code runs the function — or refuses to — and hands the result back.

What one turn of the loop looks like

Say a parent messages your support inbox: "I paid yesterday but my child's subscription still shows expired." A chatbot would generate a sympathetic paragraph. The agent does this:

// turn 1 — the model reads the task and your function list, then answers with:
{ "call": "find_payment", "args": { "parent_id": 4182, "days": 2 } }

// your code runs find_payment(), returns the result to the model:
{ "status": "captured", "subscription_updated": false, "webhook_received": false }

// turn 2 — now it knows the webhook was missed, so it answers with:
{ "call": "replay_webhook", "args": { "payment_id": "pay_9f3k..." } }

// turn 3 — replay succeeded, subscription now active. Model drafts the reply,
// which queues for human approval because outbound messages are gated.

Three turns. The model diagnosed a missed webhook and fixed it — not because it's magic, but because you gave it a diagnostic function and a repair function, and the loop let it use one after the other.

The whole loop, honestly

while ($steps++ < $max_steps) {
    $reply = call_model($conversation, $available_functions);

    if ($reply->is_final_answer) break;          // done — respond to the user

    if (needs_approval($reply->call)) {
        queue_for_human($reply);                   // payments, deletions, outbound
        break;
    }

    $result = run_function($reply->call);          // your ordinary code
    log_action($reply->call, $result);             // every step, with reasoning
    $conversation[] = $result;                     // feed it back, loop again
}

Fifteen lines of pseudocode. Our production version is longer only because of what surrounds it — and that surrounding part is where agents actually succeed or fail.

The parts that actually matter

The loop is a weekend project. These four things are the engineering:

When you don't need an agent

Here's the part vendors skip. If the steps are known in advance, you don't need an agent — you need a script. "Every night, pull unpaid invoices and send reminders" has a fixed path; a cron job does it deterministically, for free, forever.

An agent earns its cost only when the path is different every time — support triage where every complaint needs different lookups, research where the next step depends on what the last one found. We wrote a whole post on drawing that line: Do You Actually Need AI, or Just a Cron Job?

So why hire anyone, if it's this simple?

Fair question, since we just gave away the architecture.

Because the loop was never the product. The product is: functions that expose enough to be useful and little enough to be safe, an approval queue your staff will actually use, evaluation that catches the model confidently doing the wrong thing, and the judgement to say "this part shouldn't be an agent at all." That's engineering and taste, and it's the part that takes the weeks. The same architecture described here runs inside a patent-filed platform live on both app stores.

Frequently asked questions

Keep reading