Table of Contents

Most enterprise systems labeled “AI agent” are workflow automation with a natural-language front door. The real dividing line is not how smart the language layer sounds — it is where capability lives: enumerated by a builder at build time, or composed by the model at runtime.

The question people are actually asking

“Why does our AI agent feel fake?” usually means: it only does the handful of things someone already wired up, and falls over on anything else. That instinct is correct, and it points at a real architectural fork. There are two different things being sold under the one word “agent,” and they have different capability ceilings.

Two architectures behind the word “agent”

Intent-routing agent. The flow is: classify the user’s utterance → route it to a pre-built action (a flow, a script, a prompt template) → fill in the slots → execute. The natural language is only a surface. The automation underneath is deterministic and was authored in advance. Anything the builder did not build is not “hard” for this system — it is structurally impossible.

Composing agent. The flow is: take a goal → plan → call tools → observe results → re-plan → repeat until done. No single path was scripted ahead of time. Capability emerges from the combination of the tools the agent can reach and the reasoning that sequences them. The same agent answers questions its builder never anticipated, because it assembles the answer at runtime.

A one-line test: an intent-routing agent picks from a menu; a composing agent writes its own order.

Why intent-routing feels fake: the capability ceiling

The defining property of an intent-routing agent is that its capability ceiling equals what the builder imagined. Every path is enumerated by hand. Add a new question and someone has to design, build, and ship a new action for it. The “intelligence” is confined to matching an utterance to one of those pre-made actions — real, but shallow.

This is why these systems feel brittle the moment you step off the script. They are not reasoning about your goal; they are pattern-matching your sentence against a fixed list. RPA with a chat box is still RPA.

The “wow” moment is a shift in where capability lives

Here is the archetype scene where people first feel the difference. Someone asks an open-ended causal question with no pre-built workflow behind it — for example, “why did Q4 sales drop?”

To answer that deterministically, you would have to build a “sales-cause-analysis” workflow in advance: which sources to pull, in what order, how to join them, how to weigh them. Nobody built that. And yet a composing agent goes and does it anyway — it pulls from several data sources on its own (open opportunities, support tickets, account notes, voice-of-customer), joins them, and proposes plausible causes. And the answer is not bad.

That is the moment the “wow” lands. The locus of capability has moved from build-time human imagination to runtime composition. Nobody enumerated this task; the agent assembled it.

How to tell them apart

The cleanest diagnostic is to look at what the system was granted, not what it was told to do.

• An intent-routing agent is granted a list of specific actions (“create case,” “look up order,” “reset password”). Its world is that list.
• A composing agent is granted broad primitive capabilities — read, search, query, look up — and is expected to compose them itself. Ask it what it can do and it enumerates its primitives, not a feature list. For any request, it self-composes: query → explore → join → produce.

This is the same structure as a coding agent that runs on top of grep, read, and run. It was never given a “fix-the-bug” action. It was given raw capabilities and the reasoning to sequence them.

# Intent-routing agent
utterance ──> classify intent ──> match to pre-built action ──> fill slots ──> execute
                                  (capability ceiling = the action list)

# Composing agent
goal ──> plan ──> call primitive tool ──> observe ──> re-plan ──> ... ──> result
                 (capability ceiling = tools × reasoning)

A useful pseudocode contrast:

# Intent-routing: capability is enumerated by hand
ACTIONS = {
    "check_order_status": check_order_status,
    "reset_password": reset_password,
    "create_ticket": create_ticket,
}

def handle(utterance):
    intent = classify(utterance)                 # the only "intelligence"
    if intent not in ACTIONS:
        return "Sorry, I can't help with that."  # off-script = impossible
    return ACTIONS[intent](extract_slots(utterance))

# Composing: capability emerges from primitives + reasoning
TOOLS = [search, read_record, run_query, join, summarize]  # primitives, not tasks

def handle(goal):
    plan = model.plan(goal, available_tools=TOOLS)
    state = {}
    while not plan.done:
        step = plan.next_step()
        result = step.tool(**step.args)     # path was never scripted
        state = model.observe(state, result)
        plan = model.replan(goal, state)    # re-plan from what it just saw
    return model.synthesize(goal, state)

The difference is not the size of the model or the polish of the chat UI. It is whether new capability requires a human to build a new action, or whether the agent can compose one it was never given.

The capability that feels like magic is also the thing you have to govern

There is a catch worth stating plainly. The exact property that made the old, intent-routing agent feel “fake” — every action pre-defined, predictable, auditable, scope-limited — was also the source of its enterprise safety. A composing agent trades that predictability for capability. The wow in the demo is the same unpredictability you now have to operate around in production.

So the real engineering question moves downstream: once an agent can compose actions you never scripted, how do you keep its probabilistic behavior reviewable and reversible? That is its own discipline — confidence routing, reversible operations, and human review of the uncertain cases rather than all of them. See operationalizing probabilistic resolution and human-in-the-loop traceability for AI records.

Frequently asked questions

What is the difference between an AI agent and workflow automation? Workflow automation runs a path a human coded in advance — the model may pick which pre-built path to trigger, but every action was authored ahead of time. A real AI agent is given general capabilities and composes the steps itself at run time, so it can handle requests nobody explicitly built. The tell is where the capability lives: authored at build time (automation) or composed at run time (agent).

Is my “AI agent” actually just automation with a language model on top? If it can only do things someone pre-coded as flows, and the model’s only job is to classify the request and route it to one of those flows, then yes — it’s intent-routing automation, not an agent. The ceiling is the giveaway: ask for something the builder didn’t anticipate and automation structurally can’t respond, while a real agent composes an answer from its capabilities.

Why does intent-routing automation feel fake compared to a real agent? Because the intelligence lives only in the matching step; a human authored every actual capability in advance. You feel the ceiling immediately — it can only do the finite set of things that were built. A real agent feels different because capability moved from a human’s pre-coded list to the agent’s live composition, so it handles things that were never explicitly built.

When should I use workflow automation instead of an agent? When the task is well-defined, repeatable, and needs the same result every time, deterministic automation is the better tool — it’s predictable, testable, and cheaper. Reach for an agent when the space of requests is open-ended and you can’t pre-enumerate the paths. The two aren’t rivals; the design question is how much autonomy each part of the system needs.

Takeaway

The capability ceiling of an intent-routing agent is what its builder imagined in advance. The capability ceiling of a composing agent is tools × runtime reasoning. That shift — from enumerated actions to composed ones — is what people are really pointing at when they ask whether an AI agent is “real.”

A reality note: the line is a spectrum, not a binary. Most production systems sit somewhere in between — a composing core fenced by some pre-built actions for the high-stakes paths. “Real agent” is a direction, not a badge.

Related: for the deeper dive on what tips a system from automation into autonomy, see what makes an AI agent autonomous; for the reverse — when to pull that autonomy back — see when not to use an AI agent.