Advanced
ProcessorsPremium
Processors are lightweight LLM steps that run before or after your agent on every message. Use them to add reasoning, planning, or quality checks without changing your agent's core instructions.
Overview
Every conversational agent can have one or more processors attached to it. On each incoming message, Meebly runs your processors in order — pre-processors first, then the agent itself, then post-processors — before returning a response to the user.
- 1. User sends a message.
- 2. Pre-processors run (in order). Their output is injected as hidden context into the agent.
- 3. The agent responds using its instructions and any context from pre-processors.
- 4. Post-processors run (in order). They can approve the response or signal the agent to try again.
- 5. The final response is returned to the user.
Pre-Processors
A pre-processor runs before the agent sees the user's message. Whatever it produces is injected as a hidden system-level context block that the agent can read during its response — similar to how semantic memory recall works.
Common uses:
- Generate a step-by-step plan before the agent calls any tools.
- Analyse intent or extract key entities from the user's message.
- Inject dynamic instructions based on the conversation so far.
- Append a static prefix to the system prompt (system-prompt mode).
Post-Processors
A post-processor runs after the agent has produced a response. It sees the full conversation — including the agent's latest reply — and can decide whether the response is good enough or whether the agent should try again.
Common uses:
- Quality-check the response and loop if something was missed.
- Enforce a specific output format or tone.
- Verify that all required fields were addressed.
When a post-processor signals CONTINUE, the agent receives a note describing what to fix and runs again. The client's streaming buffer is automatically cleared so only the final response is shown to the user.
System Prompt vs LLM Node
Each processor has a mode that controls how it runs:
| Mode | What it does | When to use |
|---|---|---|
| system-prompt | Appends the processor's instructions directly to the agent's system prompt. No extra LLM call. | Static rules or guidelines you always want the agent to follow. Zero latency overhead. |
| llm-node | Invokes the agent's primary model with the processor's instructions and the user's message. The response is injected as hidden context. | Dynamic reasoning, planning, or quality checks that need to think about the specific message. |
Loop Configuration
Post-processors in llm-node mode can be configured to loop — meaning they can send the agent back to retry if the response isn't satisfactory. Two fields control this:
| Field | Description |
|---|---|
| continueSignal | A string the processor must include at the start of its response to trigger a retry. Everything after the signal is sent to the agent as a correction note. Example: CONTINUE: |
| maxIterations | Maximum number of retry loops (1–3). The agent always gets at least one attempt; this caps additional retries. Defaults to 2. |
If the processor's response does not start with the continue signal, the loop ends and the current response is delivered to the user.
llm-node mode.Built-in Templates
Meebly ships three ready-to-use processor templates you can add to any agent with a single click:
| Template | Type | Mode | What it does |
|---|---|---|---|
| Reasoning | Pre | llm-node | Analyses the user's request and produces a concise hidden analysis — what the user really wants, which tools are needed, and what format would be most helpful. The agent uses this to respond more accurately. |
| Planning | Pre | llm-node | Generates a numbered action plan — which tools to call and in what order — before the agent acts. Particularly effective for multi-step tasks that need several tool calls. |
| Quality Check | Post | llm-node | Reviews the agent's response and loops back with a specific correction note if something was missed. Signals COMPLETE when the response is comprehensive, or CONTINUE: [note] to retry (up to 2 times). |
Templates are fully editable — you can customise the instructions after adding them, or build your own processor from scratch.
Execution Order
Processors run in the order they appear in the list. Pre-processors all run before the agent; post-processors all run after. You can reorder them by dragging the handle on the left of each processor card.
Processors can be individually toggled on or off without deleting them — useful for testing the impact of a specific processor.
llm-node processors adds one LLM call per processor per message. For latency-sensitive agents, prefer system-prompt mode for static augmentations and reserve llm-node for processors where dynamic reasoning is essential.Viewing in Traces
Each processor appears as its own node in the LangSmith trace for a conversation. Pre-processors show as pre_processor and post-processors as post_processor. The agent node itself is labelled agent, and the initial setup step (which runs before any processor) is labelled setup.
A typical trace with a Planning pre-processor and a Quality Check post-processor looks like:
setup → pre_processor → agent → post_processor → (agent → post_processor)? → ENDThe bracketed segment only appears if the post-processor signals CONTINUE and the agent runs again.