I’ve spent the better part of a decade fixing broken WooCommerce checkouts and untangling legacy PHP spaghetti. Lately my desk has been covered in a different kind of mess: Agentic Architecture. The standard playbook in the AI space is to hand an agent a “toolbox” of pre-defined functions: a search tool, a calculator, maybe a database connection. That works fine right up until it doesn’t.
Pre-built toolboxes assume you already know every problem your agent will run into. With complex supply chains or messy enterprise data, you don’t. So stop treating agents as tool users and design them as tool creators.
Where static toolkits fall apart
Most architectures today have an LLM pick from a hard-coded list of functions, and that list is the bottleneck. A client asks for a spatial analysis of their SKU distribution, you never built a “SpatialAnalysisTool,” and the agent is stuck. It fails, or it hallucinates a result, which is worse.
I hit this myself. I built a RAG-based assistant for a logistics firm and gave it access to their API. Then a user asked for the correlation between “production anomalies” and “sales z-scores,” and the agent couldn’t do the math because no endpoint existed for it. The fix was never going to be more endpoints. It was a more flexible Agentic Architecture.
I made the same argument in my earlier piece on Building Robust WordPress AI: the architecture matters more than the individual API calls.
The plan-code-execute pattern
Plan-code-execute moves the burden off the developer and onto the LLM. Rather than picking a tool, the agent writes the tool it needs in Python, runs it in a sandbox, and reports back. In production, a working Agentic Architecture splits into five roles:
- The Analyst: the grounding layer. It reads the raw data, CSVs and database schemas, so nothing downstream has to guess at a file name.
- The Planner: it turns a request like “Why are sales down for SKU-X?” into a JSON dependency graph of steps.
- The Coder: it takes that plan and writes standalone Python scripts, imports and error handling included.
- The Executor: the sandbox. It runs the script, captures stdout and stderr, and hands failures back to the Coder to fix.
- The Reporter: it reads the artifacts, charts and cleaned data, and explains them in plain English.
Implementing the planner logic
If you build this in Python, the Planner has to be strict. You are not asking for a chat response, you are asking for a software specification. Here is roughly how I shape that prompt so the output is usable by the next agent in the chain.
def create_plan(user_prompt, data_schema):
system_prompt = f"""
You are a Senior Architect. Break the user request into a JSON list of steps.
Each step must be either "CODE" or "TEXT".
DATASET AVAILABLE:
{data_schema}
Output format:
[
{{"step_id": 1, "name": "Load Data", "type": "CODE", "desc": "Load nodes.csv..."}},
{{"step_id": 2, "name": "Report", "type": "TEXT", "desc": "Summarize findings..."}}
]
"""
# Logic to call Gemini or GPT-4o goes here
return responseOn a real SKU health analysis, the one covered in this deep dive, the same setup traced production anomalies that lined up with a 29% drop in sales, with no pre-built “Analysis Tool” anywhere in the loop.
A war story: when the coder hallucinated a file
Early on, the Coder agent started referencing a sales_data.csv that was not there. The Planner had guessed the file naming convention and the Coder went along with it. The script crashed on the first run.
That is why the Analyst Agent is not optional. Make the agent discover its environment first and build a schema out of what it actually finds, and the rest of the Agentic Architecture stays tied to reality. It is the difference between a junior dev guessing at a database table name and a senior dev checking the wp_options table before writing the query.
I wrote more about running these workflows safely in my guide to Pragmatic AI Workflow Automation.
Pragmatic takeaway
Bigger tool catalogs are not where this is going. The useful part is an agent that works out what needs to exist before it writes anything. Treat generated code as disposable and you stop maintaining a library of brittle tools, and start maintaining one code-generation pipeline instead.
If the Agentic Architecture side of this is burning your dev hours, hand it over. I have been wrestling with WordPress since the 4.x days.
Ship better code
If you are building complex data integrations, stop hard-coding functions and put a plan-code-execute loop in front of them. It is harder to debug at first, and it is still the only way I have found to scale without the codebase turning into a graveyard of one-off tools. With models like Gemini 2.0, the reasoning is finally good enough for this to hold up.
