Overview
This architecture gets better at a task over time by feeding the outcome of each answer back into the system that produced it. It is step 5 of 5 in a build-up of the full design.
The core is a plain chain: user query, retrieval, prompt assembly, model, response. Four layers sit around it, labelled GEN-1 to GEN-4 on the slide: retrieval, context, memory and feedback. A knowledge graph, new in this step, stores what the feedback layer learns.
This document runs one example throughout: a Martech engineering lead asks for an email subject line to open a conversation with a CMO about digital experience. The example is illustrative and does not come from the slide.
Request path
Every request runs through the same five stages, left to right.
flowchart LR Q["User query<br/>raw, ambiguous"] --> R["Retrieval<br/>rules, persona, SOPs"] R --> P["Prompt assembly<br/>orchestrator / planner"] P --> M["Model<br/>LLM / LRM"] M --> S["Response<br/>answer + decision trace"]
The query arrives raw and often vague, so the earlier stages exist to give the model something better to work from. Prompt assembly combines the query, whatever retrieval returned and the current context into one prompt. The model can be a standard LLM or a reasoning model (LRM). The response goes back to the user together with a decision trace. A dashed path from the response leads into the feedback layer, described below.
Layers around the request path
Five pieces sit outside the main chain. Feedback and the knowledge graph carry a NEW tag and dashed borders on the slide.
| Layer | Slide label | What it holds | Where it connects |
|---|---|---|---|
| Retrieval | GEN-1 | Rules, persona, SOPs | In the main path, right after the user query |
| Context | GEN-2 | What is relevant right now: news and PR, jobs data, trigger events | Reaches the prompt through the orchestrator / planner |
| Memory | GEN-3 | Short-term (this session) and long-term (across sessions) | Feeds retrieval |
| Knowledge graph (new) | none | Archetype ranking and trigger-pain mappings | Dashed link to prompt assembly; the feedback path also reaches it |
| Feedback (new) | GEN-4, closes the loop | Outcome, then signal, then memory update | Takes the response outcome; dashed links run back toward memory and retrieval |
The orchestrator / planner is drawn as a shaded box around prompt assembly. On the slide, context connects to prompt assembly through it. Memory and retrieval feed the prompt earlier, through the retrieval stage.
Full architecture at a glance
Solid lines carry a request forward and bring inputs to it. Dashed lines are the new paths, which carry outcomes back and feed the graph.
flowchart LR Q["User query"] --> R["Retrieval<br/>GEN-1"] R --> P["Prompt assembly<br/>orchestrator / planner"] P --> M["Model<br/>LLM / LRM"] M --> S["Response<br/>+ decision trace"] MEM["Memory<br/>GEN-3"] --> R CTX["Context<br/>GEN-2"] --> P KG["Knowledge graph<br/>new"] -.-> P S -.-> FB["Feedback<br/>GEN-4, new"] FB -.-> MEM FB -.-> KG
The diagram is my reading of the slide, and two edges are assumptions. The slide's dashed arrow ends on the knowledge graph, so I show the graph feeding prompt assembly and the feedback layer writing to it. Feedback writes to memory because its own label says memory update. If either arrow should point the other way, only the dashed edges change.
Agent versus deep agent
A second slide describes two ways to run the model in a loop, and they differ in one step: who decides the next action.
In the agent loop, the orchestrator decides the action and executes it.
flowchart LR U["User"] --> SC["State + context"] SC --> O["Orchestrator<br/>decides action, executes"] O --> OB["Observation"] OB --> SU["State update"] SU --> L["LLM decides again"] L --> D["Delegate when useful"] D -->|"until complete"| O
In the deep agent loop, the main LLM decides the next action and the orchestrator only executes it.
flowchart LR U["User"] --> SC["State + context"] SC --> M["Main LLM<br/>decides next action"] M --> O["Orchestrator<br/>executes"] O --> OB["Observation"] OB --> SU["State update"] SU --> L["LLM decides again"] L --> D["Delegate when useful"] D -->|"until complete"| O
The slide highlights the two phrases that mark the difference: "action (code)" in the agent loop and "LLM" in the deep agent loop. I read the first as program logic choosing the action and the second as a model call choosing it. After that step the loops match: observe, update state, let the LLM decide again, delegate when useful, and continue until the task is complete.
Read against the architecture above, the state and context are what prompt assembly draws on, and the loop repeats the model step until the task is done. That mapping is my reading, not something the slide draws.
Worked example: approaching a CMO about digital experience
This example is illustrative. It applies the same layers to a different task, and the inputs below are assumed, not taken from the slide.
A Martech engineering lead wants to open a conversation with the CMO about improving the digital experience of the company's marketing sites. They type: "Write a subject line for the email I will send to our CMO about improving our digital experience." The request gives no angle, tone or length. The other layers fill that in.
| Layer | What it contributes here |
|---|---|
| User query | Subject line for a CMO, topic: digital experience improvement |
| Retrieval | Standing rules, persona and SOPs for writing to senior stakeholders, such as plain wording and one ask per email |
| Memory | Openers that lead with a business number have earned replies from marketing leaders before. This sender's edit patterns: shortens, drops jargon and adjectives |
| Context | The Q4 campaign launches in six weeks (marketing calendar). Trigger event: key landing pages load in 4.8 seconds on mobile (performance monitoring) |
| Knowledge graph | Archetype ranking and trigger-pain mappings. The output implies a link from this trigger to paid traffic landing on slow pages |
| Prompt assembly | Combines the query, the retrieved material and the context |
| Response | The subject line below, plus a decision trace |
A possible result:
Six weeks before Q4 launch, our key landing pages take 4.8 seconds on mobile
It leads with the two trigger facts from context and lets the reader draw the conclusion, which the body of the email can then spell out. It is short and free of jargon, which fits the sender's habit of trimming drafts.
How the feedback loop closes
The feedback layer turns what happens after a response into an update the next request can use. The slide states it as three steps: outcome, signal, memory update.
flowchart LR A["Response<br/>+ decision trace"] --> B["Outcome<br/>reply or edit"] B --> C["Signal"] C --> D["Memory update"] D --> E["Memory +<br/>knowledge graph"] E --> F["Next request<br/>via retrieval"]
The slide points to two kinds of outcome. One is whether the recipient replies to a given opener archetype. The other is how the sender edits the draft. Reply history is what the archetype ranking is built from, and edits are what the memory layer records as the sender's habits. Because memory feeds retrieval, the next request starts from the updated ranking and the updated habits.
Worked example, day two: what the loop changes
On day one the sender edited the draft and the CMO replied. Those two outcomes are what the next request starts from. As before, the details are assumed.
| Outcome | Signal | Update |
|---|---|---|
| The sender cuts the word "key" before sending | Trimming and dropping adjectives happened again | Memory: the sender's edit pattern gets stronger |
| The CMO replies and asks for a 20-minute call | A number-led opener earned a reply from a marketing leader | Knowledge graph: the archetype ranks higher for marketing titles, and the link from slow pages before a launch to lost campaign traffic gains weight |
Two weeks later the same sender asks for a subject line to a VP of Marketing about site search. Retrieval now returns the sender's edit habits along with the standing rules, and the graph ranks the number-led opener first. Context supplies a new trigger: the Q1 relaunch is eight weeks out and 31% of site searches return no results. A possible result:
Eight weeks before Q1 launch, 31% of our site searches return nothing
The draft arrives short and free of adjectives, so the sender has less to cut. On day one the same layers produced a longer line and the sender did the trimming.
Design notes and open questions
These points are my additions. None of them appear on the slide.
- Arrow direction at the knowledge graph. The dashed arrowhead ends at the graph, so it is unclear whether prompt assembly reads from it, writes to it, or both. Settle this before building, since it decides whether the graph is a lookup or a store.
- Memory versus graph. The slide puts opener-archetype reply history in the memory note and archetype ranking in the graph. A written rule for what belongs where will prevent the same fact living in both.
- Signal timing. Edits arrive within minutes and replies can take days. The signal step needs to say which outcome updates what, and how quickly.
- Decision trace retention. If signals are derived from traces, keep the trace long enough to explain why a ranking changed.