Was ein System agentenfähig macht

A normal program follows a fixed script. An agentic system is different: you give it a goal, and the model decides the steps to reach it.

Three properties make a system agentic:

• Autonomy — the model chooses what to do next, not your code.
• Tool use — it can act on the world (search, read files, call APIs).
• Iteration — it loops: act, observe the result, decide again.

In the Claude Certified Architect track, these three ideas sit at the center of Agent Architecture & Orchestration, the largest exam domain (27%).

Each call to the Claude API is stateless. The model remembers nothing between turns. You must send the full message history every turn.

A request carries these fields:

• model — which Claude model to use.
• max_tokens — the output cap.
• system — instructions and role.
• messages — the entire conversation so far.
• tools — what the model is allowed to call.

Because there is no hidden memory, you own the loop that grows messages over time. That loop is what turns a single answer into agentic behavior.

The heart of autonomy is simple: the model decides, your code executes.

You do not hard-code 'first search, then summarize, then reply.' You describe the goal and the available tools, and Claude works out the path — including when it has gathered enough to answer.

Reserve hard-coded logic for things you must guarantee (a refund limit, an identity check). Everything else is a model decision. Over-scripting the path defeats the purpose of building an agent at all.

Autonomy is useless if the model can only talk. Tools let Claude take real actions: look up a customer, read a file, run a query.

You declare each tool with a name, a description, and an input_schema. The description is the primary selection mechanism — Claude reads it to decide when the tool applies. Names matter far less.

A good description states purpose, return values, input formats, and edge cases. Keep each agent focused: 4-5 tools per agent is optimal; past about 18 tools, selection reliability degrades.

After every request, Claude returns a stop_reason. This is how the model tells you what it wants to happen next:

• end_turn — Claude is finished. The task is complete.
• tool_use — Claude wants to run one or more tools, then continue.
• max_tokens — the output was truncated by your cap.
• stop_sequence — a custom stop string was hit.

The agentic loop is built entirely around inspecting this field. You never guess what the model meant — it tells you directly.

Put the pieces together and you get the agentic loop:

1. Send the request.
2. Inspect stop_reason.
3. If it is tool_use: run the tools, append the results to messages, and loop again.
4. If it is end_turn: stop — the task is done.

This is iterative decision-making in action. Each pass, the model sees the new tool results and chooses its next move. The conversation history grows until Claude decides it is finished.

This is one of the most tested decisions on the exam. You terminate the loop on stop_reason — never by scanning the model's text for words like 'done', 'complete', or 'finished'.

Why? Text parsing is fragile: the model might say 'I'm not done yet' or 'almost finished', and a naive keyword match would stop early or loop forever. The stop_reason field is the model's explicit, structured signal — it is unambiguous.

Parsing text for completion signals is a classic anti-pattern. If you see it in an answer choice, it is almost always wrong.

It is wise to cap the number of loop iterations — but understand its role. An iteration cap is a safety net that catches runaway loops. It is not the primary way the loop ends.

The primary stop mechanism is always stop_reason == "end_turn". The cap only fires if something goes wrong and the model never converges.

Treating an arbitrary cap (say, 'always stop after 3 turns') as your main control flow is an anti-pattern. Let the model drive; keep the cap as a backstop.

Model decisions are powerful but probabilistic — roughly 90% reliable when steered by a prompt. For anything with financial, legal, or safety consequences, that is not enough.

When you need a 100% guarantee, use deterministic code, not prompt instructions:

• A hook can block a policy-violating action before it runs (e.g. a refund over $500).
• A programmatic precondition can require that a customer's identity is verified before any refund tool runs.

Prompts guide; code guarantees. Knowing which to reach for is core architect judgment.

You can tune how much freedom the model has on any given request with tool_choice:

• "auto" — Claude decides whether to answer in text or call a tool. This is the default and the most agentic.
• "any" — Claude must call some tool. Useful when you want guaranteed structured output.
• {"type": "tool", "name": "X"} — force one specific tool.

An agentic system normally runs on "auto": the model needs the freedom to decide when to act and when it is done. Forcing tools every turn would break the natural end_turn signal.

Once a single agentic loop works, the same ideas scale up. A multi-agent system uses a hub-and-spoke shape: a coordinator decomposes the task, delegates to subagents, and aggregates their results.

One rule is critical for the exam: subagents do not inherit the coordinator's conversation history. Each subagent's context must be passed explicitly in its prompt. There is no shared memory between them.

Each subagent still runs its own autonomous, tool-using, iterative loop — the building block you just learned, composed at a larger scale.

An architect is building a Claude agent that calls tools to resolve support tickets. How should the loop decide when the agent is finished with a request?

You now have the foundation of every Claude agent:

• Autonomy — the model decides the path; your code executes. Reserve hard code for guarantees.
• Tool use — descriptions drive selection; keep 4-5 focused tools per agent.
• Iteration — the loop runs request → inspect stop_reason → run tools → repeat.
• Terminate on stop_reason (end_turn), never by parsing text. Iteration caps are a safety net only.
• State is yours — the model keeps none; send the full history every turn.

Master these and you can reason about any agent on the exam — single-agent or hub-and-spoke multi-agent.