<h3 style="font-size: 22px; font-weight: normal;">The Architecture of an AI Agent</h3>The structure of an AI Agent is typically composed as follows: User → Orchestrator → LLM → Tools → MemoryYou might understand the other components, but what does the Orchestrator actually do?Simply put, it is the engine that manages the execution of the Agent. While the LLM does the thinking and the Tools perform the actions, the Orchestrator manages the sequence of execution, which tools to call, and when to stop.<h3 style="font-size: 22px; font-weight: normal;">What the Orchestrator Actually Does</h3>In a real-world service, the Orchestrator typically handles these five core roles:<ol class="editorOrderedList"><li class="editor_editorListItem__FKzSL">Request Analysis</li><li class="editor_editorListItem__FKzSL">Agent Loop Execution</li><li class="editor_editorListItem__FKzSL">Tool Call Management</li><li class="editor_editorListItem__FKzSL">Parallel Task Management</li><li class="editor_editorListItem__FKzSL">Result Aggregation and Delivery</li></ol><img src="https://d20jzv1ghtxgkk.cloudfront.net/images_temp/1/image-1777021015562.png" width="90%" draggable="true" style="max-width: 100%; width: 100%; height: auto; cursor: pointer;"><h4 style="font-size: 22px; font-weight: normal;">The Actual Execution Flow</h4>Suppose a user makes this request: "Make a travel itinerary for my Tokyo business trip next week."The Orchestrator typically operates in this order:<ol class="editorOrderedList"><li class="editor_editorListItem__FKzSL">User Request → 2. Planner Execution → 3. Task Creation → 4. Tool Execution → 5. Result Collection → 6. Result Aggregation → 7. User Response Generation</li></ol>Simplified as a code flow:<pre style="display: block; line-height: 1.42857; color: white; word-break: break-all; overflow-wrap: break-word; background-color: black; border: 1px solid rgb(204, 204, 204); border-radius: 4px; max-width: 90%; overflow: auto; padding: 9.5px !important; margin: 0px 0px 10px !important; font-size: 14px !important;"><code>tasks = planner(user_request)
results = []
for task in tasks:
 tool = select_tool(task)
 result = tool.run(task)
 results.append(result)
response = llm.generate(results)</code></pre>(Note: Real-world systems are significantly more complex.)<h3 style="font-size: 22px; font-weight: normal;">Is Tool Execution Always Sequential?</h3>Many examples show tools running one after another, but in actual services, parallel execution is quite common. For a travel itinerary<ul class="editorBulletList"><li class="editor_editorListItem__FKzSL">search_flight</li><li class="editor_editorListItem__FKzSL">search_hotel</li><li class="editor_editorListItem__FKzSL">search_restaurant have no dependencies on each other.</li></ul>Therefore, they are usually executed in parallel. In Python, this structure looks like:<pre style="display: block; line-height: 1.42857; color: white; word-break: break-all; overflow-wrap: break-word; background-color: black; border: 1px solid rgb(204, 204, 204); border-radius: 4px; max-width: 90%; overflow: auto; padding: 9.5px !important; margin: 0px 0px 10px !important; font-size: 14px !important;"><code>results = await asyncio.gather(
 search_flight(),
 search_hotel(),
 search_restaurant()
)</code></pre>This significantly improves response speed.<h3 style="font-size: 22px; font-weight: normal;"></h3><img src="https://d20jzv1ghtxgkk.cloudfront.net/images_temp/1/image-1777021031718.png" width="90%" draggable="true" style="max-width: 100%; width: 100%; height: auto; cursor: pointer;"><h3 style="font-size: 22px; font-weight: normal;">How Tool Results are Delivered to the User</h3>There is another important question here. The execution results of tools are typically structured as follows:<pre style="display: block; line-height: 1.42857; color: white; word-break: break-all; overflow-wrap: break-word; background-color: black; border: 1px solid rgb(204, 204, 204); border-radius: 4px; max-width: 90%; overflow: auto; padding: 9.5px !important; margin: 0px 0px 10px !important; font-size: 14px !important;"><code>{
 "flights": [...],
 "hotels": [...],
 "restaurants": [...]
}</code></pre>However, users do not want to see raw data like this. What the user expects is a human-readable response, such as:<blockquote style="border-left: 5px solid rgb(248, 100, 102); background: white; font-size: 14px; padding: 5px 10px !important; margin: 10px 0px !important;">"The ANA flight departing at 10:30 is the most affordable option from Seoul to Tokyo. For your hotel, I recommend XXX Hotel in the Shinjuku area."</blockquote>In other words, you must transform API Results → User MessageThis role is also usually handled by the Orchestrator.<h3 style="font-size: 22px; font-weight: normal;">The Result Aggregation Phase</h3>The standard structure looks like this:Tools → Raw JSON Results → Result Aggregator → LLM Response GenerationFor example, the Orchestrator collects the results from the flight, hotel, and restaurant APIs and passes them to the LLM in a structured format:<pre style="display: block; line-height: 1.42857; color: white; word-break: break-all; overflow-wrap: break-word; background-color: black; border: 1px solid rgb(204, 204, 204); border-radius: 4px; max-width: 90%; overflow: auto; padding: 9.5px !important; margin: 0px 0px 10px !important; font-size: 14px !important;"><code>{
 "flight_results": "...",
 "hotel_results": "...",
 "restaurant_results": "..."
}</code></pre><code>Create a travel itinerary.</code>The LLM then generates the final response for the user.<h3 style="font-size: 22px; font-weight: normal;">Real-world Services Require UI Updates</h3>When integrating an Agent system into a product, an extra step is added: the UI update step.Example Flow: User message → Agent processing → Tool execution → Intermediate events → UI streamingThe backend orchestrates this by sending events to the frontend (via WebSocket or SSE):<pre style="display: block; line-height: 1.42857; color: white; word-break: break-all; overflow-wrap: break-word; background-color: black; border: 1px solid rgb(204, 204, 204); border-radius: 4px; max-width: 90%; overflow: auto; padding: 9.5px !important; margin: 0px 0px 10px !important; font-size: 14px !important;"><code>event: TOOL_START
event: TOOL_RESULT
event: AGENT_STEP
event: FINAL_RESPONSE</code></pre>The Backend Processing Chain: User → Frontend (React / Next.js) → API Gateway → Agent Service → Orchestrator → Tools → External APIs <img src="https://d20jzv1ghtxgkk.cloudfront.net/images_temp/1/image-1777021064214.png" width="90%" draggable="true" style="max-width: 100%; width: 100%; height: auto; cursor: pointer;"><h3 style="font-size: 22px; font-weight: normal;">Why the Orchestrator is Crucial</h3>The most important component in an Agent system is not the LLM, but the Orchestrator. The LLM thinks, but the Orchestrator handles execution flow, tool scheduling, parallel processing, state management, and UI event delivery.Conclusion: An Agent system is not actually an "LLM Service"—it is a Workflow Engine.<h3 style="font-size: 22px; font-weight: normal;">Will Agents Get Smarter as They Get More Tools?</h3>When you first build an Agent, you focus on adding tools. However, problems arise:<ul class="editorBulletList"><li class="editor_editorListItem__FKzSL">Premature Action: The LLM might try to send_email before any flight data has been searched because it is a probabilistic model, not a strictly logical planner.</li><li class="editor_editorListItem__FKzSL">Tool Selection Difficulty: If tool descriptions are similar (e.g., search_trip vs. search_flightthe LLM often chooses the wrong one. Tool names must be designed to be easily understood by the LLM.</li><li class="editor_editorListItem__FKzSL">Infinite Loops: If the observation isn't clear, the Agent might repeat the same action (e.g., searching for a hotel, finding nothing, and searching again). Therefore, you must implement max_steps and timeout.</li><li class="editor_editorListItem__FKzSL">Hallucinated Tool Calls: The Agent might try to call a tool that doesn't exist (e.g., book_flight). A Tool Validator layer is necessary.</li></ul><h3 style="font-size: 22px; font-weight: normal;">Costs Grow Faster Than Expected</h3>An Agent system is not a single LLM call. One task often involves multiple LLM calls (planning, analysis, evaluation) and multiple API calls. Therefore, real services incorporate:<ul class="editorBulletList"><li class="editor_editorListItem__FKzSL">Step limits</li><li class="editor_editorListItem__FKzSL">Cost limits</li><li class="editor_editorListItem__FKzSL">Caching</li></ul><h3 style="font-size: 22px; font-weight: normal;">The Current Evolution</h3>Experience leads to the conclusion that a fully autonomous Agent is unstable. Modern systems are moving toward controlled Agent systems with strict guardrails: Planner → Task Queue → Executor → Tool Validation → GuardrailsRecently, a new approach has emerged: Agents that manipulate computers directly (e.g., controlling browsers, creating files, running scripts). A representative example is OpenClaw. While more powerful, this structure is also significantly more dangerous. I plan to cover this in more detail in the next post.

Building an AI Agent is Harder Than It Seems - Errors in Planning and Actual Implementation

#AIAgent #Implementation #Errors #ToolSelection #LLM #Cost #OpenClaw #Orchestration #UIRendering #InScreenUpdates

My idea works in the market?