Agent Architecture: Designing AI Systems That Take Actions, Not Just Answers

1. Answering a question and completing a task are different jobs

Our library assistant can now answer "How long can I keep a science book?" correctly, using retrieval to ground its answer, as covered in our RAG system design guide. Now a member asks something harder: "Reserve the next available copy of Planet Atlas for me, and let me know if it's not in stock anywhere nearby."

This is not one lookup. It may require checking the catalog, checking two branches, placing a reservation, and composing a reply that depends on what actually happened. A single model call that only reads a question and writes an answer has no way to check anything or change anything in the world.

An agent, in this context, is a system where a model can choose to call tools — functions the application exposes, such as "search catalog" or "create reservation" — observe the results, and decide what to do next, repeating that cycle until the task is done or it needs to stop. The model is not just producing text anymore; it is making decisions that drive real actions.

All workloads, tool names, and outcomes in this guide are invented teaching examples.

2. The idea in simple words

Think of a new library assistant on their first day, given a phone that can call the catalog desk, the reservation desk, and the branch across town, but no direct access to the shelves. They cannot act by wishing; they must decide who to call, listen to the answer, and decide the next call based on what they heard.

An agent works the same way. It cannot touch a database or send an email directly — it can only ask a tool to do that on its behalf, read the result, and decide the next step. The three moving parts are:

The model never directly executes a tool. It requests one; the application validates and executes it, the same way any other untrusted input would be handled, and returns the result as new information for the next decision.

3. How the agent loop works

flowchart TD
    U@{ icon: "algomi:ext-person", label: "Member request", pos: "b", h: 52 }
    M@{ icon: "algomi:svc-spark", label: "Model decides next step", pos: "b", h: 52 }
    U --> M
    T@{ icon: "algomi:svc-cube", label: "Application executes the requested tool", pos: "b", h: 52 }
    M -->|Needs information or action| T
    Obs@{ icon: "algomi:svc-spark", label: "Result returned to the model", pos: "b", h: 52 }
    T --> Obs
    Obs --> M
    F@{ icon: "algomi:svc-spark", label: "Final answer to member", pos: "b", h: 52 }
    M -->|Task complete or cannot proceed| F

Reading the diagram. It is one circle with two exits. The loop is the middle three boxes: the model decides, the application runs the tool, and the result comes back to the model for the next decision. The loop ends only through the bottom arrow, "task complete or cannot proceed". Notice the model never points at a tool directly; every action passes through "Application executes", which is where all the safety in section 8 lives.

Each pass through the loop is one decision: call a tool, or stop and answer. The application, not the model, is responsible for actually running the tool, checking permissions, handling errors, and enforcing any limit on how many times the loop may repeat. Without a limit, a model that keeps deciding "I need one more piece of information" can loop indefinitely, consuming time and cost with no guarantee of ever finishing.

Here is the smallest agent that works: