Building AI agents: from task to working system

Development Route

First define the task outcome and test whether an ordinary program is sufficient. Conditional branches, multiple sources and error handling also occur in deterministic workflows. An agent is useful when model-selected actions or clarifying questions add value and that choice can be checked and bounded.

In this section, we consistently examine four levels. First, architecture: how to build a controlled graph instead of an infinite loop. Then, tools: how to describe them so the model makes fewer mistakes. Next, memory: how to distinguish thread state from long-term storage. Finally, production: how to turn a prototype into a reliable service.

As a running example, we use a fictional task: a customer asks why their order is delayed. This is not a real case but a training situation that conveniently illustrates all stages of development.

• Script or workflow — when the sequence of steps is known in advance.
• Agent — when model-selected actions are useful; dependencies between steps alone do not require an agent.
• Graph — a way to make the agent controlled and predictable.
• Tools — the bridge between the model and the external world.
• Memory — the difference between dialogue state and long-term facts.
• Production — reliability, observability, and security.

What You Will Learn

Each chapter contains concrete decisions, error walkthroughs, and checklists. You will not just read about patterns but will be able to apply them to your own task.

We deliberately avoid generic statements. Instead of 'use the right tools', you will see how to describe a tool contract so the model makes fewer mistakes. Instead of 'add memory', you will learn how to choose between a checkpointer and a separate store.

• Architecture: StateGraph, conditional edges, HITL, subagents.
• Tools: schemas, validation, idempotency, MCP.
• Memory: checkpointer, store, RAG, reranking, data freshness.
• Production: FastAPI, streaming, observability, metrics, pilot.

Running Example: Delayed Order

Imagine a customer writes to support: 'Where is my order? I ordered a week ago.' This is a fictional scenario, but it perfectly illustrates all stages.

In the architecture chapter, we will design a graph that decides whether to clarify the question, search for information in the database, or answer immediately. In the tools chapter, we will describe functions for checking status and history. In the memory chapter, we will show how to save facts about the customer between sessions. In the production chapter, we will wrap it in an API and ensure reliability.

• Architecture: a graph with nodes for clarification, search, and answer.
• Tools: get_order_status, get_order_history.
• Memory: thread_id for dialogue, store for customer preferences.
• Production: FastAPI, streaming, observability, metrics.

Practical Task

Go through the chapters sequentially and build your own agent for processing order status requests. Start with a simple graph, then add tools, memory, and finally wrap it in an API.

Do not try to build a perfect system right away. First, make a minimal working prototype, then iteratively improve it using the checklists from each chapter.

• Design a graph with conditional transitions.
• Add tools with validation and error handling.
• Implement memory using a checkpointer and store.
• Run the agent via FastAPI and add observability.