Agent Burger Architecture
Assemble every agent from required components before choosing implementations
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 7
- Confidence
- 99%
The Agent Burger Architecture distinguishes the invariant components of an agent from the interchangeable technologies used to implement them. Like a burger requiring structural categories even when its ingredients vary, an agent needs a language model, tools, knowledge or memory, appropriate input-output capabilities, and guardrails. Around that core sit deployment, testing, and evaluation. Builders first define the problem, then make explicit choices for every required component according to privacy, risk, modality, integration, and performance constraints. This tool-agnostic decomposition makes designs portable across no-code and code platforms. It also exposes omissions early, particularly guardrails and evaluation, which are easy to neglect when a prototype appears functional.
Origin
Extracted from Marketing Against The Grain when Tina Huang used a burger analogy to explain the required components of agentic workflows.
Core principles
- 01Separate required capabilities from interchangeable implementations
- 02Choose each component according to the problem and constraints
- 03Treat guardrails, deployment, testing, and evaluation as core architecture
- 04Remain tool-agnostic by understanding agent fundamentals
- 05Design the full system before building the workflow
How to run it
- 1
Define the Job
State the problem, intended users, inputs, outputs, constraints, and observable success conditions before choosing technology.
Pro tip Describe the current human workflow alongside the desired agent behavior.
Watch out A technically complete architecture cannot rescue an undefined or unnecessary job.
- 2
Choose the Model
Select a language model with the reasoning, modality, latency, cost, and privacy characteristics the job requires.
Pro tip Use the least complex model that reliably meets the evaluation standard.
Watch out Do not select a model based solely on popularity or benchmark headlines.
- 3
Assign Tools
List the actions and data interfaces the agent needs to accomplish its task, and grant only those capabilities.
Pro tip Define tool inputs, outputs, failures, and permissions explicitly.
Watch out Unnecessary tools expand the agent's failure and security surface.
- 4
Design Knowledge and Memory
Specify what reference data the agent needs and whether it requires short-term state, long-term memory, or neither.
Pro tip Document privacy, retention, and retrieval requirements for every data source.
Watch out Do not store sensitive information simply because persistent memory is available.
- 5
Choose Modalities
Add audio, speech, vision, or other interfaces only when they support the real workflow.
Pro tip Keep a text-based fallback where practical for testing and accessibility.
Watch out Extra modalities increase complexity and may introduce new privacy risks.
- 6
Install Guardrails
Define actions, content, data access, and outcomes the agent must avoid, plus escalation paths for uncertain cases.
Pro tip Enforce critical restrictions outside the prompt where possible.
Watch out Prompt instructions alone are not sufficient control for consequential actions.
- 7
Plan Deployment and Evaluation
Specify how the agent will be deployed, observed, tested, evaluated, audited, and improved.
Pro tip Create initial evaluations before exposing the agent to real users.
Watch out A working prototype is only the beginning of a production agent.
In the wild
A retention agent uses an LLM to interpret cancellation emails, email and offer-selection tools to act, approved customer and offer knowledge, workflow state for each case, guardrails against inventing discounts, and evaluations plus audit logs before deployment.
→ The team can change the model or workflow platform without losing the system's required functional categories.
Common mistakes
Building Only the Model Call
An LLM without controlled tools, knowledge, guardrails, and operational support is not a complete agentic system.
Becoming Tool-Dependent
Learning only one workflow interface obscures the transferable architecture and makes migration harder.
Leaving Evaluation Until the End
Without planned success criteria, builders cannot tell whether the assembled system behaves correctly.
Is it for you?
Best for
Teams designing an AI agent before implementing it in n8n, code, or another workflow platform.
Not ideal for
Simple deterministic automations that do not need language-model reasoning or agentic behavior.
From the transcript
“But if you don't have all of these components, you don't really have a burger.”
“For example, the first thing that you must have an agent, you need to have a large language model.”
“And then finally, there's the guardrails.”
From the episode
I Used ChatGPT & n8n to Stop Customers from Leaving
Tina Huang