Free lesson · Claude Certified Architect - Foundations (CCA-F)
What Makes a System Agentic: Autonomy, Tool Access, and the Action Loop
Start With a Simple Picture
Think about two ways you can ask someone to get you lunch.
The first way: "Walk to the shop on the corner. Buy a sandwich. Come back." You have decided every step. If the shop is closed, the person is stuck, because you did not tell them what to do about that.
The second way: "Get me lunch. Here is some money and here is a phone." Now they decide. If the shop is closed, they walk to the next one, or they order delivery. You did not plan for that. They handled it.
That second way is what we mean by agentic. You give a goal instead of a recipe, and the thing you asked works out the steps by itself.
This sounds simple, and it is. But almost every question in Domain 1 comes back to it, so it is worth being precise about what "agentic" actually requires.
Interactive animation: A recipe fixes every step and stalls at a closed shop; a goal lets whoever does the work adapt.
The Three Ingredients
A system is agentic when all three of these are present. Miss any one, and you have something else.
graph TD
A[An agentic system] --> B[1. Autonomy<br/>The model picks the steps]
A --> C[2. Tool access<br/>It can act on the world]
A --> D[3. An action loop<br/>It runs until done]
B --> B1["You give a goal,<br/>not a recipe"]
C --> C1["It can read, write,<br/>call, search"]
D --> D1["Act, look at result,<br/>decide again"]
This diagram shows the three ingredients of an agentic system branching from a single root. The first is autonomy, meaning the model picks the steps, and you give a goal rather than a recipe. The second is tool access, meaning it can act on the world by reading, writing, calling, or searching. The third is an action loop, meaning it runs until the task is done by acting, looking at the result, and deciding again.
Let us take each one slowly.
Ingredient 1: Autonomy
Autonomy means the model decides the path.
You say what you want. You do not say how to get there. The model looks at the situation, picks a next step, does it, sees what happened, and picks the step after that.
The important word here is decides. If your code contains an if statement that chooses which step runs next, that decision is yours, not the model's. That is still a useful system. It is just not an agentic one.
Tip: Ask yourself one question: who chose the order of the steps? If the answer is "my code, when I wrote it," the system is not agentic. If the answer is "the model, while it was running," it is.
Ingredient 2: Tool Access
A model on its own can only produce text. It cannot look anything up. It cannot save a file. It cannot send an email or query a database.
Tools change that. A tool is a function you write and describe to the model. Once the model has tools, it can affect things outside the conversation.
This is what turns thinking into doing. Without tools, a model can tell you a very good plan for handling a refund. With tools, it can actually issue the refund.
Ingredient 3: The Action Loop
This is the part people forget, and it is the one that makes the other two useful.
An agent does not act once and stop. It acts, looks at what happened, and then decides what to do next based on that result. Then it does it again. And again. It keeps going until the task is finished or until something tells it to stop.
That repetition is the loop. It is why an agent can recover when a step fails - it sees the failure in the result, and its next decision takes the failure into account.
Without the loop, you have a system that can take exactly one action and then goes quiet. That is not much use for real work.
Why All Three Are Needed
It helps to see what happens when one ingredient is missing.
| What you have | What is missing | What you actually built |
|---|---|---|
| Autonomy + loop, no tools | Tool access | A model that reasons in circles but cannot do anything |
| Tools + loop, no autonomy | Autonomy | A workflow - your code drives, the model helps at each step |
| Autonomy + tools, no loop | The loop | A one-shot helper that cannot react to what happened |
| All three | Nothing | An agentic system |
Look closely at row two. That row is not a failure. A workflow is often the better design, and Domain 1 spends real time on when to choose one. The point is only that it is a different thing, and the exam expects you to name it correctly.
Important: "Agentic" is a description, not a compliment. Calling a system agentic does not mean it is better. It means the model is choosing the path. Sometimes that is exactly what you want. Sometimes it is the wrong choice and a plain workflow would be safer, cheaper, and easier to debug.
A Real Example, Walked Slowly
Say you want a system that handles this request: "My order never arrived. Can you help?"
Here is what an agentic system does with that.
graph TD
A["Request arrives"] --> B["Model reads it<br/>and decides: I need<br/>the order details"]
B --> C["Calls lookup_order tool"]
C --> D["Result: order shipped<br/>12 days ago, no delivery scan"]
D --> E["Model decides:<br/>this looks lost"]
E --> F["Calls check_refund_policy tool"]
F --> G["Result: eligible<br/>for replacement"]
G --> H["Model decides:<br/>offer replacement"]
H --> I["Replies to customer"]
This diagram traces an agentic system handling a customer complaint about a missing order. The request arrives and the model decides it needs order details, so it calls a lookup order tool. The result shows the order shipped twelve days ago with no delivery scan. The model decides this looks lost and calls a check refund policy tool. That result shows the customer is eligible for a replacement. The model decides to offer a replacement and replies to the customer.
Now notice what is not in that picture.
Nowhere did anyone write code saying "first look up the order, then check the policy." The model worked out that order was needed. If the lookup had come back saying the order was delivered and signed for, the model would have gone somewhere completely different - maybe asking the customer to check with a neighbour.
That flexibility is the whole benefit of going agentic. You did not have to imagine every possible case in advance.
And that flexibility is also the whole risk. You did not decide what happens. Something else did.
Interactive animation: One request goes round the loop - lookup, no delivery scan, policy check, replacement - and nobody wrote the sequence.
The Trade You Are Making
Every time you choose an agentic design, you are making the same trade. It is worth saying out loud.
Pros:
- Handles situations you did not think of in advance
- Recovers from failures on its own, without new code
- Much less code to write for messy, varied inputs
- Adapts when the world changes without a rewrite
Cons:
- Harder to predict - the same input can take different paths
- Harder to test, because there is no fixed path to test
- Harder to debug when something goes wrong
- Costs more, since each loop turn is another model call
- You must add safety limits yourself, or it can run away
You are trading control for flexibility. That is the trade. There is no version where you get both.
The exam tests whether you understand which side of that trade a given situation needs. A task with a known, fixed sequence does not benefit from flexibility, so paying the cost of agency is a mistake. A task with messy inputs and unpredictable paths does benefit, so paying the cost is worth it.
Warning: The most common mistake with agentic systems is not building them badly. It is building them where they were not needed. If you can write down every step in advance and the steps never change, an agent adds cost and unpredictability and gives you nothing back.
A Quick Test You Can Apply
When you are looking at any system - in a question or in real life - three questions tell you what it is.
Algorithm: Is this agentic?
- Who picked the order of the steps? The model at runtime, or your code when you wrote it?
- Can it do things, or only say things? Does it have tools that touch the outside world?
- Does it keep going after one action? Does it see the result and decide again, or does it stop?
Three yes answers means agentic. Any no means it is something else, and naming that something else correctly is usually the point of the question.
Run this test on the lunch example from the start. Who picked the steps? The person did. Can they act? Yes, they have money and a phone. Do they keep going? Yes, the closed shop did not stop them. Three yeses.
What This Means for the Exam
Domain 1 is 27 percent of your exam - the largest single domain. Almost all of it builds on this topic.
Later topics will ask you to choose between an agent and a workflow, to control the loop so it cannot run forever, and to decide what the agent may do on its own versus what needs a human. Every one of those decisions assumes you can clearly see the three ingredients and say which are present.
Interview: Scenario questions often describe a system without ever using the word "agentic." They will say something like "the model determines which steps to take" or "our code calls the model once per step in a fixed order." Those phrases are telling you the architecture. Train yourself to spot them - they usually decide the answer before you have even read the options.
Exercise: Starter. Write down three systems you have used or built. For each one, answer the three test questions. Name each system correctly: agentic, workflow, or something else.
Intermediate. Take the customer order example above. Write down two different paths the model might take if the lookup tool returned "delivered and signed for" instead. Notice that you did not have to change any code to get those paths.
Advanced. Think of a task at your work that is currently handled by code with lots of
ifstatements. Would making it agentic help, or would it just add cost? Write one paragraph defending your answer using the trade described above. If your answer is "it would just add cost," that is a perfectly good answer - and recognising it is exactly the judgment the exam rewards.
Quiz: Quick check: A team builds a system where their code calls the model three times in a fixed order - first to summarise a document, then to extract fields, then to write a report. The model has no tools. Is this agentic?
A) Yes - it uses a model to make decisions B) Yes - it runs multiple steps C) No - the code picked the order, and there are no tools D) No - but only because there are no tools
Answer: C - two ingredients are missing. The step order was decided in code, not by the model, and there are no tools, so the model cannot act on anything. This is a workflow, and calling it one correctly is often worth a point.