Build your first AI agent: what actually makes one work

An agent is not a chatbot with a better prompt. The difference that matters is structural: a chatbot produces one response, and an agent decides what to do, does it, looks at the result, and decides again. Everything else people call agentic follows from that loop.

If you are about to build your first AI agent, the ideas below matter more than which model you pick or which framework you land on. Here they are, along with the concrete pieces Google’s Agent Development Kit gives you to build one.

The loop underneath every agent

The clearest statement of the idea is still the paper that named it. In ReAct: Synergizing Reasoning and Acting in Language Models, Yao and colleagues showed that interleaving reasoning traces with actions beats either one alone. Their framing is worth quoting because it explains why: “reasoning traces help the model induce, track, and update action plans as well as handle exceptions, while actions allow it to interface with external sources”.

Reason, act, observe, adjust. A model that only reasons is confidently wrong about the world. A model that only acts cannot recover when a call fails or returns something unexpected. Interleaving the two gives it a way to notice and correct, which is the whole reason an agent can handle a task you did not anticipate.

The practical consequence is that your agent’s quality depends less on the model and more on what it can observe. An agent whose tools return opaque success or failure has nothing to reason about. An agent whose tools return specific, readable results can course correct. When an agent behaves stupidly, look at what came back from its last tool call before you look at the prompt.

Three shapes, and how to choose

Agents are usually built in one of three shapes, and picking the wrong one causes more grief than picking the wrong model.

Sequential runs fixed steps in order. Predictable, testable, cheap, and rigid. If the task is genuinely always the same three steps, this is not a lesser choice, it is the correct one.

Reactive decides at each step based on the current state. Flexible, handles surprises, and does not plan ahead, so it can wander or loop on an ambiguous goal.

Planning sketches a plan first, then executes it. Suited to multi-step goals with dependencies, where doing step three before step two wastes work or breaks something. The cost is an extra model call before anything happens, and a plan that can be wrong in ways that are harder to debug than a single bad step.

The honest default is the least dynamic shape that solves your problem. Reach for planning when steps genuinely depend on each other, reactive when inputs are unpredictable, sequential the rest of the time. A lot of production “agents” are sequential pipelines with one model call in the middle, and they work reliably because of that, not in spite of it.

The ADK pieces you need to build your first AI agent

A note on the framework first, because it is young enough that much of what is written about it is guesswork. Google announced ADK at Cloud NEXT on 9 April 2025 and released it under Apache 2.0, so it is properly open source rather than a licensed SDK with a free tier. It ships in five languages now, Python, TypeScript, Go, Java and Kotlin. The Python package needs Python 3.10 or later, and although it is optimised for Gemini, the README describes it as model-agnostic and deployment-agnostic, so adopting it does not commit you to one provider.

Beyond that, ADK gives you a small vocabulary. Four pieces cover most of what a first agent needs.

LlmAgent, often aliased simply as Agent, is a model-backed agent. It takes a name, a model, a description used by other agents to route work to it, and an instruction that carries its actual behaviour.

output_key is the piece people miss, and it is what makes multi-step agents composable. Set it on an agent and, per the documentation, “the text content of the agent’s final response will be automatically saved to the session’s state dictionary under this key”. That is your data bus. One agent writes to a key, the next reads it, and neither needs to know about the other.

LoopAgent runs its sub_agents repeatedly, and this is where the useful pattern lives. Pair a producer with a checker: the producer writes a draft to state, the checker reads it and either approves or returns a specific list of problems, and the loop runs again. You get automatic retry with feedback rather than one shot and hope.

Read the termination rules carefully, because this is the sharpest edge in ADK. The documentation is explicit that “the LoopAgent itself does not inherently decide when to stop looping. You must implement a termination mechanism.” A loop stops when max_iterations is exhausted, or when a sub-agent escalates by setting tool_context.actions.escalate = True. Without an escalate path, a checker that says “looks good” in prose changes nothing and your loop runs the full count every time, burning tokens to produce the same answer.

AgentTool wraps an agent so another agent can call it as a tool. That is how you give a coordinator a small, controlled surface: expose two capabilities as tools rather than letting it improvise across every sub-agent you have built.

Making it reliable

The gap between a working demo and something you can leave running is mostly in three places, none of which are the model.

Validators need to be specific. “Check this is good” produces a rubber stamp. Enumerate the conditions: does it have a title, does it have between four and six sections, does each section have at least one supporting point. A checker that must answer against a list gives you a real signal, and its failure output tells the next iteration what to fix.

Cap everything. Iteration limits, tool call counts, total spend. A retry loop with a validator that never passes is an unbounded bill, and the failure mode is silent because each individual call looks fine.

Log the observations, not just the outputs. When an agent does something inexplicable, the reason is almost always in what a tool returned, not in the final answer. Keep the intermediate results where you can read them.

Start with the smallest thing that runs end to end, then add a validator, then add a tool. Most agent projects that stall did the reverse, building a six-agent architecture before anything worked once. Getting the loop shape right early is the part we usually help teams unpick at NukyLabs, and it is much cheaper to do at the start.

References

1. Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023
2. Agent Development Kit, LLM agents
3. Agent Development Kit, Loop agents
4. Agent Development Kit, Function tools
5. google/adk-python on GitHub (Apache 2.0)
6. Google Developers Blog, Agent Development Kit: Making it easy to build multi-agent applications