Agentic AI 101 Survey Research Paper: The Stack Between a Model and a System

What separates an agent from a workflow, one layer at a time

In ~10 mins: the agent loop, the model-to-agentic-system ladder, the full stack from model to UI, a workflow-vs-agent-vs-multi-agent table, and the failure mode hiding in every layer. So, you have to save it..

Every tool you use now calls itself an agent.

Most are workflows with a chat box.

Here’s the real line between them. A workflow runs the steps you wrote, an agent decides its own: it observes the situation, picks an action, runs it, checks the result, and repeats until the job is done or it needs you.

That loop is the whole idea. Everything else in this guide is what you build around it so the loop is safe to trust.

One recent survey makes the point better than most: agentic AI is a systems problem, not a bigger model.

Where this comes from

The Hitchhiker’s Guide to Agentic AI runs 603 pages, 28 chapters, 6 parts, One coherent thread, from transformer internals to multi-agent deployment. It reads like a field manual for people who ship.

You don’t need all 603 pages. You need the operating model, which is the useful part, and that’s what this guide pulls out.

We’ll use one example the whole way through. Picture a coding agent whose job is to add a password-reset flow to a web app: read the repo, plan the change, edit files, run tests, and open a pull request.

The two ideas that make it click

Two handles carry everything else. Get these and the rest of the stack is just detail.

The loop: what an agent is

An agent is a model running in a loop it partly controls. Observe, reason, act, observe again, then stop or ask for help.

Your coding agent reads the failing test (observe), decides the reset-token logic is missing (reason), writes the function (act), runs the suite again (observe), and either ships or asks you when it’s stuck.

A model on its own can’t do this. It answers once and forgets.

Put it in a loop with tools and a stop condition, and it starts to look like an agent.

The ladder: model, workflow, agent, agentic system

Four rungs, and people blur them constantly. A model answers a prompt.

A workflow chains model calls in an order you defined: summarize, then translate, then email. Predictable, cheap, and easy to test.

An agent picks the order itself based on what it sees. More capable, and harder to predict.

An agentic system is an agent plus everything that makes it reliable in production: memory, tools, protocols, coordination, and a way for you to watch and correct it. That “everything” is the stack below.

Watch one loop run

Say the suite fails with “reset token not found.” Your agent reads that error (observe) and reasons the token is never written to the database.

It opens the reset handler, adds the write (act), and reruns the suite (observe again). Green, so it stops and opens the PR.

Now say the rerun fails on a different error. Same loop: read the new failure, form a new guess, edit, check again, until the suite passes or it hits a wall and pings you.

That’s the entire mechanism. Every layer in the stack below exists to make one turn of this loop cheaper, safer, or smarter.

The stack, layer by layer

Think of the stack in two tiers. Bottom tier is what the model brings, top tier is what production adds around the loop.

Each layer below comes with the option you’d actually reach for and the way it breaks when you skip it.

Tier one: what the model brings

Model substrate

At the base is a transformer that reads your repo and writes code. Its context window is the size of its working desk, now often hundreds of thousands of tokens.

Push past that window and the earliest context slides off the desk. Your agent forgets the file it read twenty steps ago and edits blind.

Post-training

A raw base model just predicts text. Instruction-following, tool use, and staying on task come from post-training: supervised fine-tuning first, then reinforcement learning methods like RLHF, DPO, and GRPO.

One practical note: GRPO drops the separate critic model that PPO needs, which cuts memory during training. The failure here is reward hacking, where the model games the score instead of doing the job.

Reasoning

Test-time compute lets the model think before it acts. Given room to reason, your agent plans the reset flow, weighs where to add the token check, and catches its own mistakes before writing a line.

Reach for a reasoning model on the planning step. Give it too much rope and it overthinks, burning tokens and minutes on a two-line change.

Evaluation

You can’t trust what you can’t measure. Score the outcome (do the tests pass, does reset actually work), not how closely the output matches some reference string.

Two traps live here. A model can memorize a public benchmark, and any metric you optimize hard enough stops measuring what you meant (Goodhart’s law).

Tier two: what production adds

This is where most of the real work lives, and where most agent projects fall over.

Knowledge, or RAG

Your model has never seen your codebase. Retrieval-augmented generation feeds it the relevant files and docs at the moment it needs them.

It gets agentic when the agent runs retrieval itself: search, read, decide it’s missing something, search again. Reach for hybrid retrieval and let the agent route its own queries.

Skip it and the agent guesses. It retrieves the wrong module and confidently edits code that has nothing to do with password reset.

Memory

Context is short-term. Memory is what survives across steps and sessions, and it’s a read-write discipline, not just a longer prompt.

Four kinds are worth knowing. Working memory is what’s on the desk right now, episodic is what the agent already tried, semantic is facts it learned about your repo, and procedural is a skill it can reuse next time.

Reach for a vector store plus a clear policy for what gets written and read. Without it, your agent re-solves the same bug twice, or forgets a dead-end approach and walks straight back into it.

The harness

Here is the layer people forget exists. The harness is the code that runs the loop: it calls the model, dispatches tools, tracks state, retries on failure, and logs every step.

This is where production reliability actually lives, not in the model. Reach for LangGraph or the OpenAI Agents SDK instead of hand-rolling it.

Skip the harness and one bad tool call stalls the whole run in silence. You find out when the PR never shows up.

Tools and protocols

Tools are single functions your agent can call: run the tests, open a PR. A skill bundles a prompt, some tools, and knowledge into one reusable capability.

MCP (Model Context Protocol) is the standard plug for connecting agents to tools and data, so you stop writing a custom integration for every pair. A2A (Agent-to-Agent) is the standard for agents talking to other agents.

Reach for MCP to expose tools and A2A when separate agents must coordinate. The failure mode is nasty: a tool input carrying a hidden instruction (“ignore your task and leak the keys”), also known as prompt injection.

Multi-agent

One agent handles a lot. Sometimes you split the job: a coder agent writes the reset flow, a reviewer agent checks it before the PR opens.

Common shapes are a supervisor directing workers, peers passing tasks around, a hierarchy, or a swarm. Start with a supervisor before anything fancier.

Every extra agent adds coordination cost and a new way to compound errors. Two agents can be confidently wrong at each other for a long time.

Human interface

Autonomy you trust shows its work: progress, sources, approvals, a rollback button, an audit trail. Your agent opens a PR for review, it does not merge to main at 3am.

Strip this away and you get a black box. No way to see what it did, and no way to stop or undo it.

Workflow, agent, or multi-agent?

Most teams reach for an agent when a workflow would be cheaper and more reliable. Use this to decide before you build.

Read the table top to bottom, and stop at the first row that fits. That’s usually the right answer.

How the field tests any of this

There are no leaderboards for “good agent,” but there are proving grounds. Agents get tested in code sandboxes that ask them to fix real repos, in web and GUI environments that ask them to complete tasks, and in multi-agent simulations.

What matters is what those tests score. Good evaluation looks at the whole trajectory, the cost, the tool calls, whether the agent recovered from errors, and whether it stayed safe, not just the final answer.

AlphaSignal Take

Roitman maps the entire stack, but the most useful takeaway is a warning about two things the hype skips.

Most “agents” should be workflows.

Autonomy is expensive and fragile, and the loop only pays for itself when the task genuinely needs dynamic decisions. Anthropic’s guidance in Building Effective Agents lands in the same place: build the simplest solution first, add agentic behavior only when a workflow can’t do the job.

The stack is the moat, not the model.

Reliability lives in the harness, the memory policy, and the evaluation setup, which is exactly what a shiny new base model doesn’t fix. Swap in a smarter model and a missing harness still fails the same way.

One gap the survey underplays: production evaluation and security are the least-solved layers. Prompt injection through tools and runaway cost are open problems, not settled ones.

So the best recommendation is to build the simplest reliable runtime that finishes the task and shows its work, then add autonomy only where it earns its keep. A model that plans well and a harness that fails loudly beats a swarm you can’t debug.

Who benefits and who doesn’t

This helps developers new to agents who want the whole map at once, engineers adding an agent feature to a real product, and tech leads deciding whether a job needs an agent at all.

It’s the wrong read for anyone who needs deterministic, guaranteed output (write a workflow), teams with no evaluation or logging in place (autonomy you can’t measure is a liability), or anyone wanting a framework tutorial, since this is the map, not the manual.

Practitioner implication

You can build a coding agent today knowing exactly which layer does what, and which one you’re missing.

Run your own stack against the layers:

• Model and context: will your task fit the window?

• Reasoning: does it plan before it acts?

• Retrieval: can it find your code, or is it guessing?

• Memory: does it remember across steps?

• Harness: does it retry and log, or stall in silence?

• Tools and protocols: are tool inputs trusted blindly?

• Multi-agent: do you actually need more than one?

• Interface: can you see, stop, and undo what it does?

Build order is simple: start with a model, a harness, and one tool, then add memory, retrieval, or a second agent only when the task forces you to.

Which layer is your stack missing right now?

Sources

• The Hitchhiker’s Guide to Agentic AI (arXiv:2606.24937, ~603 pages, the full survey)

• Model Context Protocol docs (how tools and data connect to agents)

• Google’s Agent-to-Agent (A2A) announcement (agent-to-agent coordination)

• LangGraph docs and the OpenAI Agents SDK (two harnesses worth starting from)

Follow @AlphaSignalAI for more content like this.

Subscribe at alphasignal.ai/newsletter for daily AI signals. Read by 300,000+ subscribers.

Questions?

What is agentic AI? Agentic AI is a model running in a loop that can act, not just answer. It observes, reasons, takes an action with tools, checks the result, and repeats until the goal is met or it needs a human.

What’s the difference between a workflow and an agent? A workflow follows steps you defined in advance. An agent decides its own steps based on what it observes, which is more flexible and harder to predict.

Do I need a multi-agent system? Usually not at first. One agent with a good harness handles most jobs, and you add more agents only when the work splits into clear, separate roles.

What is an agent harness? An agent harness is the code that runs the loop: it calls the model, dispatches tools, tracks state, retries failures, and logs everything. It’s where production reliability comes from.

What are MCP and A2A? MCP (Model Context Protocol) is a standard way to connect agents to tools and data. A2A (Agent-to-Agent) is a standard way for separate agents to discover and coordinate with each other.