Early work with large language models (LLMs) often felt like “vibe coding.” You’d tweak a prompt, run it, and hope the vibe was right. If the output was off, you’d adjust the wording and try again. This is prompt engineering, and while it's a useful skill, it's not a reliable way to build complex, production-grade systems.

Agentic engineering moves beyond this. It treats the LLM not as a conversational partner but as a core component of a larger system, a reasoning engine that can be guided with structured, repeatable patterns. Instead of relying on a single, perfect prompt, we build systems that allow the model to think, act, and even correct itself over multiple steps.

This approach helps us distinguish between two types of systems: deterministic workflows and autonomous agents. A workflow is a fixed sequence of steps. For example: summarize this text, then translate the summary into French, then extract key entities. Each step feeds into the next in a predictable chain. It's reliable but rigid.

An agent, on the other hand, is dynamic. Given a goal, it decides which steps to take. It might summarize a document, realize it needs more context, search for a related article, and then integrate that new information into its final summary. The path isn't predetermined. Agents can adapt, but this flexibility comes with trade-offs in cost, speed, and predictability.

The foundational concept behind many agentic systems is the ReAct loop, which stands for Reason and Act. It’s a simple but powerful idea that allows an LLM to interact with its environment.

Building on the ReAct loop, several key design patterns have emerged for creating robust agentic systems. These aren't mutually exclusive; complex agents often combine them.

1. Tool Use LLMs are powerful reasoners, but they have limitations. They can't browse the web, run code, or access a specific database. Tool use solves this by giving the agent access to external functions or APIs. The LLM's job is to reason about which tool to use, with what inputs, to achieve its goal.

For example, if asked, "What's the weather in Tokyo right now?" an agent with a weather tool would reason:

• Thought: The user is asking for current weather. I have a tool called get_current_weather(city) that can help.
• Action: Call get_current_weather with the input city='Tokyo'.
• Observation: The tool returns a JSON object with temperature and conditions. I will format this into a natural language response.

Designing good tools is critical. They should be reliable, well-documented (so the LLM understands them), and perform a single, clear task.

2. Reflection Reflection is the pattern of making an agent critique its own work. After generating a response or a plan, the agent is prompted to review it for flaws, missing information, or potential improvements. This self-correction loop can dramatically increase the quality of the final output.

Imagine an agent tasked with writing a Python script. Its first attempt might have a bug. A reflection step would involve showing the agent its own code and asking, "Does this code correctly solve the problem? Are there any errors? Could it be more efficient?" The agent can then identify the bug and generate a corrected version.

3. Planning For complex, multi-step tasks, an agent can first create a plan. Instead of acting immediately, it breaks the problem down into a sequence of smaller, manageable sub-tasks. It can then execute this plan step-by-step, updating it as new information becomes available.

For a goal like "Plan a weekend trip to San Francisco for two people on a $500 budget," the agent might generate a plan:

1. Research affordable flights and accommodations.
2. Find free and low-cost attractions.
3. Create a sample itinerary with estimated costs.
4. Summarize the final plan.

This makes the agent's behavior more predictable and easier to debug. If a step fails, you know exactly which part of the plan went wrong.

4. Multi-agent Collaboration Just as in a human team, complex problems can be solved by assigning different roles to specialized agents. One agent might be a "researcher" that gathers information, another a "writer" that synthesizes it into a report, and a third "critic" that reviews the final draft. A fourth "orchestrator" agent manages the workflow, passing tasks between the specialists.

This pattern allows you to use different models, prompts, and tools for each role, optimizing for each specific sub-task. The researcher might use a model good at web browsing, while the writer uses one known for creative text generation.

Adopting these patterns requires a mental shift. You are no longer just writing prompts; you are designing a system where an LLM is the central processing unit. Your job is to provide this CPU with the right tools, memory, and feedback loops to guide its reasoning.

This approach introduces new trade-offs. Agentic systems can be more powerful, but they are also more complex, slower, and potentially more expensive to run due to the multiple LLM calls. The key is to know when a simple, deterministic workflow is sufficient and when the dynamic, goal-driven power of an agent is truly needed.

By understanding these core patterns, you can move from simply talking to an AI to building robust systems around its reasoning capabilities.