End-to-End Claude Architecture: Input, Processing, Output and Feedback Loops

1.From business requirement to the simplest design that works

An end-to-end architecture starts with a requirement, not a pattern. Anthropic's guidance is to find the simplest solution that works and add complexity only when it is needed. Sometimes that means not building an agentic system at all. Complexity has a price: agentic systems often accept extra latency and cost in exchange for better task performance. So the architect's first job is to decide whether the requirement justifies that trade.

The basic building block is the augmented LLM: a model enhanced with retrieval, tools and memory, which it can use on its own initiative. For many applications, one well-optimized call to an augmented LLM is the whole architecture. Retrieval and in-context examples are often enough. Some tasks need no tools at all. The tool-use documentation says summarization, translation and general-knowledge questions do not need a tool round trip.

When more complexity is justified, the next choice is between a workflow and an agent. A workflow fits a well-defined task, because its fixed code path gives predictable and consistent results. An agent fits when you need flexibility and decisions made by the model at scale. If you use a framework such as the Claude Agent SDK, make sure you understand the code underneath. Frameworks can add layers of abstraction that hide the actual prompts and responses.

Sources12

2.Input → processing → output: the agent loop

Once a design includes tools, every request goes through the same loop. On the input side, Claude receives more than the user's prompt. The system prompt, the tool definitions and the conversation history are assembled around it. That assembled context is everything the model knows when it decides what to do.

Processing is a cycle. Claude evaluates the current state and replies with text, one or more tool-call requests, or both. The tools run, and each set of results goes back to Claude for its next decision. Each full cycle is one turn, and turns repeat until Claude replies without calling a tool. Your application can also step in during the loop: hooks can intercept, modify or block a tool call before it runs. On the output side, the SDK emits a final result message containing the answer, token usage, cost and session ID. These are the figures you need to judge the design against its business targets.

If you call the Messages API directly instead of using the SDK, you write this loop yourself. It is keyed on stop_reason. As long as the reply comes back with "tool_use", you run the tools and continue the conversation. Any other stop reason ("end_turn", "max_tokens", "stop_sequence" or "refusal") ends the loop, and your application has to handle it.

Sources3

3.Tool execution: who runs the code, and when tools belong in the design

Tool use is a contract. You declare which operations exist and what their inputs look like, and Claude decides when to call them. The model never executes anything itself. It emits a structured request, something else runs the operation, and the result comes back into the conversation. Claude sees only the schema and the result, never your implementation. The main architectural question is therefore where the code runs, because that decides what your application must build.

Server tools run their own loop on Anthropic's infrastructure, and that loop has an iteration limit. If the model hits the limit while it is still working, the response comes back with stop_reason: "pause_turn" instead of "end_turn". The work is unfinished, so you re-send the conversation to let it continue. Control also returns to you early when Claude calls a server tool and a client tool in the same parallel group.

Tools belong in a design when the model cannot do the job from text alone. That covers actions with side effects, fresh or external data, outputs that must have a guaranteed structure, and calls into existing systems. They do not belong when every call adds a round trip whose cost outweighs a trivial task. One sign is reliable: if you are parsing free-form output to recover a decision, that decision should have been a tool call.

Sources2

4.Closing the loop: feedback and iterative refinement

An end-to-end design does not stop at the first output. A feedback loop sends an assessment of that output back to the model so it can improve the work. The basic pattern is evaluator-optimizer: one LLM call generates a response, and another evaluates it and gives feedback, in a loop. It fits when two things are true. First, there are clear evaluation criteria. Second, iterative refinement adds measurable value. In practice, a response must improve when someone articulates feedback, and an LLM must be able to give that feedback itself.

Claude Managed Agents builds this loop in as outcomes. You describe what 'done' looks like and supply a rubric, which is required. The harness then sets up a grader that scores the artifact against the rubric and returns its explanation to the agent for the next iteration. The grader runs in a separate context window, so the main agent's implementation choices do not influence it. Write each rubric criterion so it can be graded on its own. For example, 'The CSV contains a price column with numeric values' works, but 'The data looks good' does not.

client.beta.sessions.events.send(
    session_id=session.id,
    events=[
        {
            "type": "user.define_outcome",
            "description": "Build a DCF model for Costco in .xlsx",
            "rubric": {"type": "text", "content": RUBRIC},
            # or: "rubric": {"type": "file", "file_id": rubric.id},
            "max_iterations": 5,  # optional; default 3, max 20
        }
    ],
)

Sources14

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.With server tools such as web_search, your application still has to build and send a tool_result block after each call.Why is that wrong?

   Anthropic runs server tools and loops over them itself. You enable the tool and read the results. The exceptions are a pause_turn response and a turn that also calls a client tool.

   Covered in Tool execution: who runs the code, and when tools belong in the design

2. 2.A short, holistic rubric such as 'output is high quality' is enough for a grader-driven feedback loop.Why is that wrong?

   The grader scores each criterion separately, so vague criteria produce noisy feedback. Write criteria that are explicit and can each be graded.

   Covered in Closing the loop: feedback and iterative refinement