Beyond Harness²: GEPA, DSPy, ADAS, Reflexion and ReAct — How Agent-Optimisation Methods Compare, and What Each One Means for Security

Google’s Harness² put a name on something teams were already doing piecemeal: making an agent better by improving the scaffolding around a fixed model rather than retraining the model. But Harness² is one point on a spectrum. GEPA, DSPy, ADAS and Reflexion all improve agents without touching weights — and they differ sharply in what they change, what they cost, how mature they are, and what they do to your security posture. This is a leader’s comparison: what each method optimises, and what each one means for governance.

Analysis for CISOs, AI-platform and GRC teams. Primary sources are linked throughout. Where a method’s details are uncertain, or a name is ambiguous, we say so rather than fill the gap — see the note on "PRISM" below.

Two companions to this post: the Harness Designer walks through defining and bounding an agent’s harness, and the Harness Comparator lets you line these methods up against each other on the axes below.

First, the one thing none of these do

None of these methods retrain the model. They all optimise the scaffolding around fixed weights — so none is an "AI rewriting itself" event in the frightening sense. What differs is which part of the scaffolding each one rewrites, and therefore how much of your agent becomes a moving target. That is the axis that matters for security, so it is the axis we sort them on.

ReAct — the baseline, not an optimiser

ReAct (Yao et al., 2022) interleaves reasoning (the model thinks in text) and acting (it calls a tool and reads the result), looping until done. It is not an optimisation method — it is the control-flow pattern that almost every agent, and every method below, assumes underneath. We include it because it is the honest baseline: before you adopt any optimiser, measure what a plain ReAct agent already does on your task. What it optimises: nothing automatically — a human writes the prompt and picks the tools. Data needed: none beyond tools and a prompt. Maturity: ubiquitous. Security: the ordinary tool-use surface — prompt injection through tool observations is the main concern; there is no self-modification.

GEPA — reflective prompt evolution

GEPA ("Genetic-Pareto," Agrawal et al., 2025; accepted as an ICLR 2026 oral) optimises prompts/instructions. Instead of a numeric reward, it feeds the full execution trace back into an LLM reflection step that proposes a natural-language edit to the prompt, and keeps a Pareto frontier of candidate prompts rather than a single best-so-far. Its claim to fame is sample efficiency — the authors report outperforming reinforcement-learning approaches with far fewer rollouts (treat the specific multipliers as the paper’s figures, to check at source). What it optimises: prompts. Data needed: a small evaluation set and a metric, plus the traces GEPA generates. Cost/complexity: low to moderate; much cheaper than RL. Maturity: active; shipped as an optimiser inside DSPy (dspy.GEPA). Security: low-risk — it emits prompts, which are text artifacts you can diff, review, version and roll back. No new executable surface. Review the final prompt as you would any instruction change.

DSPy — a compiler for LM pipelines

DSPy (Khattab et al., Stanford, ICLR 2024) is less a single algorithm than a programming framework: you declare an LM pipeline in modular terms, and DSPy’s optimisers ("teleprompters" — BootstrapFewShot, MIPROv2, and GEPA among them) tune the prompts and few-shot demonstrations against a metric you define (and can optionally finetune weights). The appeal is that improvement becomes a repeatable compile step rather than hand-tuning. What it optimises: prompts and few-shot examples, via a chosen optimiser. Data needed: training/validation examples and a metric. Cost/complexity: moderate — you have to express your task as a DSPy program, but the optimisation is cheap and reproducible. Maturity: mature and widely adopted. Security: low-risk and auditable — the outputs are prompts and demonstrations; the compile step is deterministic given inputs; artifacts are reviewable and versionable. The main hygiene point is treating the optimised prompts/demos as change-controlled config.

ADAS — a meta-agent that writes new agents

ADAS ("Automated Design of Agentic Systems," Hu, Lu & Clune, 2024) goes a level up: a meta agent programs new agents in code, iterating via its "Meta Agent Search" algorithm over an archive of previously discovered agents, and the discovered agents reportedly transfer across domains and models. What it optimises: the agent’s topology, control flow and building blocks — expressed as executable code. Data needed: evaluation tasks, a coding-capable meta agent, and an archive. Cost/complexity: high — this is a search over programs. Maturity: research-grade. Security: this is the heaviest of the set. A method whose output is executable agent code is arbitrary code execution by definition — the discovered programs must run in a sandbox, behind an egress allow-list, with human review before anything reaches production. The upside (novel architectures) comes with the strongest isolation requirement.

Reflexion — runtime verbal self-reflection

Reflexion (Shinn et al., NeurIPS 2023) is different in kind: it improves the agent at runtime, within a task, by having it generate a verbal self-reflection after a failed attempt and store that reflection in an episodic memory the agent reads before its next try. No weights change and no prompt set is pre-optimised — the "learning" is in-context and ephemeral-to-persistent memory. What it optimises: the agent’s own behaviour across attempts, via reflective memory. Data needed: a feedback or reward signal to reflect on (even a simple success/failure). Cost/complexity: low; it is a loop, not a training run. Maturity: well established and widely cited. Security: no code generation, so the blast radius is smaller — but persisted memory is a poisoning surface: a bad or injected reflection can survive and steer later runs, so provenance and review of what gets written to memory matter.

Harness² — recursive harnessing of the whole scaffold

Harness² (Google Cloud AI Research and Northwestern University, arXiv 2610.14224) is the most expansive. It rewrites the entire harness around a fixed model — described as eight components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins — through a Propose–Probe–Compose loop (propose harness edits, probe their effect on the same task, compose a refined harness from the contrast) plus a persistent "improvement harness" that carries evidence-backed lessons to future tasks. It reports gains on the professional-work benchmarks it uses. What it optimises: all of the scaffolding, recursively, across tasks. Data needed: tasks to optimise against (the per-task probe needs no ground-truth answer). Cost/complexity: high — it is a recursive optimisation loop over a large surface. Maturity: new/experimental. Security: the broadest governance surface here. Because it can rewrite tool guidance, plugins, scripts and guardrails, a self-editing harness can change what the agent is allowed to do without a human in the loop — and the paper itself warns that its executors run with unrestricted network access and the Codex executor with its sandbox disabled. It needs human-gated change control for privileged edits, non-self-expandable least privilege, provenance and rollback for adopted harnesses and lessons, and sandboxed executors behind an egress allow-list. (We covered this at length in our dedicated Harness² governance piece.)

Side by side

How to choose

1. Start with ReAct and measure. You cannot tell whether an optimiser earns its risk until you know the baseline.
2. Want better, auditable behaviour cheaply? DSPy and GEPA. Text artifacts, reviewable, versionable, low blast radius. This is where most teams should spend first.
3. Need in-task adaptivity from the agent’s own mistakes? Reflexion — but govern what gets written to memory.
4. Exploring novel agent architectures? ADAS — in a sandbox, behind an egress allow-list, with human review of generated code before it runs.
5. Want the scaffold itself to self-improve across tasks? Harness² — the frontier option, and the one that most expands your change-control and attack surface. Adopt it with the controls, not before them.
6. See "PRISM" (or any unfamiliar name)? Pin the exact paper before you rely on it.

The governance throughline

Read the table top to bottom and the pattern is clear: risk rises with how far a method self-modifies and how close it gets to generating executable code or new capability. Prompt-only optimisers emit reviewable text. Memory-based methods add a poisoning surface. Code-generating and self-rewriting methods change what the agent can do — and need the full kit: human-gated change control for privileged edits, non-self-expandable least privilege, provenance and rollback for every adopted artifact and memory, and sandboxed executors behind an egress allow-list. None of these methods is dangerous by nature; all of them are safe to run inside bounds you set deliberately. Pick the method for the job, and size the controls to where it sits on that spectrum.

Where this plugs into what you already run

Whatever method you pick, the governance questions are the same ones your existing programs answer — just pointed at the scaffold. "Who may change what, and is it evidenced?" is change-control and AI-management discipline (AI Governance Board lab). "What components and provenance does this agent actually carry?" is an AI Bill of Materials question. "What is this specific agent’s blast radius?" is a threat model (LLM Threat-Model Generator). And to design and bound the harness itself before you let an optimiser near it, the Harness Designer and Harness Comparator are the companions to this post.

Sources & credit

• Harness² — arXiv 2610.14224 (Google Cloud AI Research and Northwestern University); verify specific score figures against the primary source.
• GEPA — arXiv 2507.19457 ("Reflective Prompt Evolution Can Outperform Reinforcement Learning," Agrawal et al., ICLR 2026 oral); also shipped as dspy.GEPA.
• DSPy — arXiv 2310.03714 ("Compiling Declarative Language Model Calls into Self-Improving Pipelines," Khattab et al., ICLR 2024).
• ADAS — arXiv 2408.08435 ("Automated Design of Agentic Systems," Hu, Lu & Clune).
• Reflexion — arXiv 2303.11366 ("Language Agents with Verbal Reinforcement Learning," Shinn et al., NeurIPS 2023).
• ReAct — arXiv 2210.03629 ("Synergizing Reasoning and Acting in Language Models," Yao et al.).
• "PRISM" — name is ambiguous across several unrelated papers (post-training without verifiable rewards; a Propose-Review-Integrate multi-agent reasoning framework; an evolutionary memory substrate). Pin the exact arXiv identifier before relying on it.

Published 19 Oct 2026. Primary sources are authoritative where they differ from this summary. Specific performance multipliers reported for any method are that paper’s own figures and should be verified at source before quoting.