What are LLM-as-judge patterns in memory pipelines?

Short answer: Another model scores an agent’s output against defined criteria to produce automated feedback for learning.

Human review does not scale to thousands of agent actions. A judge evaluates against an explicit standard of good. Passing results can be positive examples; failing ones give concrete gaps for lessons. This does not remove human oversight of criteria and spot checks. Engram can feed judge evaluations into continual learning when volume makes manual feedback impractical.

The previous chapter treated feedback as the raw material continual learning turns into durable, reusable lessons. That chapter left one important question unanswered: what happens when no human is actually available to provide that feedback in the first place? This chapter looks at LLM-as-judge, a pattern for generating exactly this kind of evaluative signal automatically, without a person having to review every single action an agent takes.

Why Would a System Need an Automated Substitute for Human Feedback in the First Place?

Human feedback is genuinely valuable, but it doesn’t scale to the volume most agentic systems actually operate at, an agent handling thousands of tasks a day can’t realistically wait for a person to review each one before any lesson gets extracted from it. Without some automated alternative, continual learning would only ever capture the small fraction of interactions where a person happened to notice something worth correcting, leaving the vast majority of an agent’s actual experience completely unexamined and unlearned from.

What Does It Actually Mean for One Model to Judge Another Model’s Output?

LLM-as-judge uses a separate evaluation pass, typically its own dedicated prompt and sometimes its own separate model, to assess whether a specific action or output actually met some defined standard, independent of whatever process originally produced that action. The judge isn’t guessing at quality in the abstract, it’s checking a specific output against explicit, predetermined criteria, exactly the same way a human reviewer would apply a defined rubric rather than relying purely on unstructured gut feeling. This structure is what makes the judge’s evaluation something a pipeline can actually act on programmatically, rather than an unstructured, hard-to-use impression.

How Does a Team Actually Define What “Good” Means for a Judge to Evaluate Against?

The evaluation criteria live in the judge’s own prompt, encoding whatever specific business rules, quality standards, or domain-specific expectations actually matter for a given task, entirely separate from the logic of whatever process originally produced the output being judged. This separation is genuinely useful: a team can adjust what counts as an acceptable outcome by editing the judge’s criteria alone, without needing to touch or retrain the underlying process actually doing the work being evaluated. Different tasks reasonably call for entirely different judging criteria, and keeping that criteria isolated in its own configurable layer is what makes adapting it practical.

What Actually Happens Once a Judge Produces Its Evaluation?

A passing evaluation, one meeting whatever standard the judge was configured to check for, confirms that a given action was handled well, and that confirmation itself can become a small, positive signal worth remembering, an example of a task done correctly. A failing evaluation is more directly useful for continual learning specifically, since it identifies precisely where an action fell short, giving a transform step exactly the kind of concrete gap a lesson can actually be built around, in the same way a human’s explicit correction would.

Does an LLM-as-Judge Pattern Genuinely Replace the Need for Any Human Oversight at All?

Not entirely, and treating it that way would risk a system quietly drifting away from what actually matters to the people relying on it. A judge’s own criteria still need to be defined and periodically reviewed by a person who actually understands what genuinely constitutes a good outcome for a given task, and a judge itself can occasionally be wrong in ways worth catching through periodic spot-checking. What LLM-as-judge actually removes is the need for a person to review every single individual action, not the need for any human involvement in defining and maintaining the standard the judge applies in the first place.

How Does Weaviate Engram’s Pipeline Let an LLM-as-Judge Evaluation Feed Directly into Continual Learning?

Weaviate Engram’s transform steps can incorporate an LLM-as-judge evaluation directly into the same continual learning pattern covered in the previous chapter, generating feedback memories automatically rather than waiting for a human to supply them. Consider an automated code-review agent, evaluating its own suggested fixes against a defined rubric for whether a suggestion actually addressed the underlying issue correctly:

from engram import EngramClient

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

client.memories.add(
    [
        {"topic": "task_goal", "content": "Flagged a potential null pointer risk in a function and suggested adding a guard clause."},
        {"topic": "actions_taken", "content": "Suggested guard clause checked for null but didn't account for the case where the value was an empty string rather than null."},
    ],
    group="continual_learning",
)

client.memories.add(
    [{"topic": "judge_evaluation", "content": "Evaluation against the defined correctness rubric found the suggested guard clause incomplete, since it failed to handle the empty-string edge case that triggers the same underlying bug."}],
    group="continual_learning",
)

Because the judge’s evaluation was generated automatically against a predefined rubric rather than waiting for a developer to notice and report the gap, this feedback becomes available for the same combining transform step covered in the previous chapter to fold into a durable, reusable lesson:

results = client.memories.search(
    query="What should be checked when suggesting a null-safety guard clause?",
    group="continual_learning",
)

The resulting lesson, that a guard clause meant to prevent this class of bug needs to account for empty-string values alongside actual null values, becomes available to improve every future suggestion this agent makes, generated entirely without a human reviewer needing to catch and report the specific gap themselves. This is exactly the value LLM-as-judge delivers for a use case like automated code review, where the sheer volume of suggestions an agent generates would make manual, human-reviewed feedback on every single one genuinely impractical.

LLM-as-judge patterns let continual learning scale beyond what human feedback alone could realistically sustain. Everything this Part has covered, from extraction through commit and now through continual learning, exists to produce one thing: a memory store that’s actually ready to be searched and used. Our next chapter, How does pipeline output become a queryable memory store?, takes up exactly that final connection.