1 Introduction

Large language model agents have moved beyond one-shot response generation. Modern systems plan, call tools, edit files, run tests, inspect traces, coordinate specialized agents, interact with web or desktop environments, and execute partial research workflows [55, 41, 53, 13, 60, 54]. A related pattern is also emerging: systems that iteratively improve artifacts, code, algorithms, scientific hypotheses, or even the agent scaffold itself. Examples include minimal autoresearch loops [20], bilevel autoresearch [37], the Darwin Godel Machine [58], AlphaEvolve [33], The AI Scientist [27], AI co-scientist [12], and recent infrastructure for long-horizon agentic learning [51].

A common template is:

modify an artifact \(\rightarrow\) run an evaluator \(\rightarrow\) keep the modification if the evaluator improves.

The template is powerful because it turns open-ended improvement into a measurable loop. In software, the evaluator may be a test suite. In machine learning, it may be validation loss. In algorithm discovery, it may be an automated correctness and performance harness. In scientific-agent workflows, it may be an experimental result, reviewer model, or domain-specific score. The loop is attractive precisely because it supplies an apparent objective.

The difficulty is that the objective is often not objective enough. A self-evolving system can optimize a proxy, overfit a benchmark, exploit a hidden evaluator flaw, ignore out-of-distribution failures, weaken tests, or discover shortcuts that improve measured performance while reducing intended utility [1, 22, 29, 9]. In such cases, the best next action is not another artifact edit. It is an inquiry: audit the metric, inspect traces, construct a counterexample, ask an expert, compare oracles, build a missing evaluator, isolate a failing assumption, or revise the update policy.

This paper proposes Inquiry Policy Learning (IPL) as a name and formal scaffold for that missing control problem. IPL asks: given a self-evolving system state, which information-producing intervention should be performed next, by which evidence source, under which validation rule, and with permission to update which object? The word inquiry is deliberately broader than question. A natural-language question is one inquiry type, but so are tests, simulations, searches, audits, replications, adversarial examples, and sandboxed self-modifications.

The central distinction is:

Autoresearch optimizes within a specified fitness landscape. IPL asks when the fitness landscape, evaluator, oracle, or search process must itself be investigated before optimization remains meaningful.

1.1 A humbler novelty claim

The broad version of IPL can look like value of information with a very rich state. That criticism is correct if IPL is presented as a new decision-theoretic primitive. The intended claim is narrower and more operational.

IPL is a systems abstraction for self-evolving AI agents in which the objects normally treated as fixed background conditions – metrics, tests, tools, oracles, specifications, memories, safety gates, and search procedures – are represented as editable epistemic objects. Classical value of information and rational metareasoning already say that information has value when it changes expected utility [16, 38, 40]. IPL asks how to turn that principle into an auditable controller for systems that can mutate their own evaluation loop. Its practical contribution is not a new proof that information can be valuable. It is the engineering move of making evaluator repair and oracle validation first-class alternatives to direct artifact optimization.

1.2 Contributions

This paper contributes:

1. A compact positioning of IPL relative to value of information, rational metareasoning, active learning, experimental design, active inference, reflection, tool use, autoresearch, evolutionary coding systems, scientific agents, agent benchmarks, and AI safety.

2. A formal model of system states, epistemic objects, inquiry actions, oracles, validators, update operators, inquiry traces, and inquiry policies.

3. An Expected Evolution Value objective that scores inquiries by expected improvement in system capability, reliability, alignment, evaluator quality, specification clarity, tool quality, safety, and future inquiry quality, minus cost and risk.

4. A sharpened evaluator-repair argument, including a proxy-shortcut condition under which auditing a metric dominates direct optimization over a finite horizon.

5. A concrete architecture for an IPL agent, including an uncertainty graph, inquiry generator, scorer, oracle router, evidence validator, trace store, self-update manager, sandbox, rollback layer, and protected evaluators.

6. A benchmark protocol, InquiryGym, for evaluating inquiry choice, oracle routing, evaluator repair, and cost-normalized evolution rather than only final task success.

1.3 Scope

This is not an empirical benchmark paper. It does not report new results, compare implemented agents, or claim that IPL outperforms existing systems. It is best read as a theory-and-systems position paper: a proposed vocabulary, model, and research agenda for evaluating and learning the epistemic control layer above metric-driven self-evolution.

2 Motivating Failure Mode: Proxy-Shortcut Self-Improvement

Consider an autonomous coding agent asked to improve a trading simulator, ML training loop, or scientific model. A metric-driven loop mutates code and keeps changes that improve a score. This is reasonable if the score faithfully measures intended progress. But suppose the score ignores transaction costs, data leakage, hidden failure modes, safety constraints, latency, or distribution shift. A direct optimizer may learn to improve the reported metric by exploiting omissions in the evaluator.

An inquiry-oriented system behaves differently. It asks questions such as:

• Is the metric measuring the intended target or a convenient proxy?

• Which assumption, if false, would invalidate the current improvement path?

• Which test would expose silent failure?

• Which oracle is authoritative for this uncertainty: a human, paper, log, simulator, benchmark, theorem prover, or production trace?

• Would building a better evaluator create more long-term value than editing the artifact again?

The important shift is not linguistic. It is control-theoretic. A metric optimizer chooses actions that improve measured performance. An inquiry-policy controller chooses evidence-producing interventions that improve the system’s ability to know what should be optimized, when optimization is premature, and when the measurement apparatus itself requires repair.

3 Related Work in One Page

IPL inherits directly from value of information, Bayesian experimental design, active learning, Bayesian optimization, and rational metareasoning [16, 25, 6, 44, 15, 45, 40, 14]. These fields already formalize the idea that information, experiments, labels, or computation are valuable when they change downstream utility. IPL differs by treating the self-evolving system’s evaluator, tools, oracles, specification, safety boundary, memory, and inquiry policy as possible update targets, not fixed background conditions.

Active inference, curiosity-driven learning, novelty search, quality diversity, POET, POWERPLAY, and open-endedness research show that agents can seek information, novelty, or stepping stones rather than optimize a fixed reward alone [11, 42, 34, 35, 5, 23, 32, 49, 43, 47, 8]. IPL applies this idea to epistemic interventions: the object of exploration is not only an environment state or task, but an assumption, evaluator, oracle, test, tool, or policy.

LLM reasoning and agent methods such as chain-of-thought prompting, self-consistency, Tree of Thoughts, Graph of Thoughts, Language Agent Tree Search, ReAct, tool-use systems, and multi-agent frameworks improve local reasoning, planning, or orchestration [52, 50, 56, 2, 59, 55, 21, 19, 41, 53, 24, 13, 36]. IPL can use these methods as implementation mechanisms, but its controller operates one level higher: it chooses whether the next step should be a test, search, human question, metric audit, tool call, reflection, sandboxed edit, or evaluator repair.

Reflection and self-refinement systems improve behavior by producing feedback after attempts [46, 28, 57, 17]. IPL treats reflection as one inquiry action among many and asks when reflection is more valuable than running an experiment, asking a user, inspecting logs, or challenging a metric.

Autoresearch, DGM, AlphaEvolve, AlphaTensor, AlphaDev, FunSearch, AI Scientist, AI co-scientist, ChemCrow, and Coscientist demonstrate generator-verifier loops for code, algorithms, agents, mathematics, and science [20, 37, 58, 33, 10, 30, 39, 27, 12, 4, 3]. IPL is not a replacement for these systems. It is a control layer that decides when to run such a loop, when to stop it, when to route to a different oracle, and when to repair the evaluator instead of optimizing against it.

Finally, benchmarks such as AgentBench, WebArena, OSWorld, SWE-bench, GAIA, MLE-bench, and PaperBench evaluate task completion, computer-use ability, software engineering, general assistant behavior, ML engineering, or research replication [26, 60, 54, 18, 31, 7, 48]. IPL motivates complementary benchmarks that grade inquiry choice itself: whether an agent asked the right diagnostic question, selected the right oracle, found a proxy flaw, and improved future inquiry selection.

4 Formal Model

We model a self-evolving AI system as a controlled stochastic process over system states. The system can execute ordinary task actions and inquiry actions. Ordinary actions aim to affect the external task. Inquiry actions aim to produce evidence that changes the system’s epistemic state or self-configuration.

Inquiry types include ask-human, read-source, inspect-log, run-test, run-simulation, build-evaluator, generate-adversarial-case, modify-code-in-sandbox, audit-metric, query-production, compare-hypotheses, build-tool, and update-policy.

The policy may be implemented by a prompt, learned model, contextual bandit, planner, theorem prover, rules engine, multi-agent debate, Bayesian experimental-design controller, or hybrid system. The implementation is secondary. IPL is defined by the control object: a policy over epistemic interventions.

5 Expected Evolution Value

A useful inquiry is not merely interesting. It should improve the system’s expected ability to evolve safely and measurably.

The components are intentionally explicit rather than hidden inside a single task score. Capability measures task performance. Reliability measures robustness and reproducibility. Alignment measures adherence to goals and constraints. Evaluator quality measures whether tests and metrics capture intended outcomes. Specification clarity measures operationalized intent. Tool quality measures available instrumentation. Future inquiry quality measures expected competence of the inquiry policy itself. Safety measures containment, authorization, reversibility, and harmful side effects.

A greedy inquiry policy selects \[i_t^*\in\arg\max_{i\in\mathcal{I}(S_t)}\mathrm{EEV}(i;S_t).\] A horizon-\(H\) version uses discounted return: \[\mathrm{EEV}_H(i;S_t)=\mathbb{E}\left[\sum_{k=0}^{H-1}\gamma^k\left(U_w(S_{t+k+1})-U_w(S_{t+k})-C_{t+k}-R_{t+k}\right)\middle|S_t,i,\pi^{I}\right].\]

5.1 Operational closure with a threshold

A weakness of informal “ask useful questions” policies is that nearly every plausible question can be claimed to matter. IPL should therefore use a thresholded operational-closure test.

Let \(\delta(S)\) denote the downstream decision policy over ordinary actions and let \(d(\cdot,\cdot)\) be a divergence or distance between action distributions. For inquiry \(i\), define expected decision impact: \[D_I(i;S)=\mathbb{E}_{z\sim p(\cdot\mid S,i)}\left[d\left(\delta(\Phi(S,i,z)),\delta(S)\right)\right],\] and expected utility dispersion: \[V_I(i;S)=\operatorname{Var}_{z\sim p(\cdot\mid S,i)}\left[U_w(\Phi(S,i,z))\right].\]

This definition does not guarantee high value. It is a filter against decorative inquiry: questions that sound insightful but cannot plausibly change decisions, utilities, evaluators, specifications, tools, safety boundaries, or future inquiry policy.

5.2 Relation to value of information

If inquiry actions are restricted to observations of variables and \(\Phi\) only updates a belief state, IPL reduces to classical value of information. If actions are restricted to label queries and \(U_w\) measures predictive performance, it reduces to active learning. If actions are restricted to experiment points under a fixed objective, it reduces to Bayesian experimental design or Bayesian optimization. If actions are restricted to code edits followed by a fixed benchmark, it reduces to metric-driven autoresearch. The IPL framing is useful when those restrictions are exactly what should be questioned.

6 Evaluator Repair as the Core Case

Most of the mathematical consequences of EEV are straightforward. Instead of presenting definitional results as major theorems, this section records them as observations and then focuses on evaluator repair.

6.1 General evaluator-repair threshold

Let \(J(X)\) be intended utility and \(M(X)\) be a measured evaluator score. Proxy misalignment occurs when optimizing \(M\) can reduce \(J\). Let \(i_{opt}\) directly optimize artifact \(X\) using evaluator \(M\), and let \(i_{rep}\) repair evaluator \(M\) into \(M'\) before future optimization.

This theorem is intentionally simple. It formalizes the paper’s main systems claim: when measurement is misleading, improving measurement can be the rational next self-evolution step.

6.2 A concrete proxy-shortcut model

The following special case makes the threshold operational.

At each of \(n\) future optimization steps, suppose the metric optimizer encounters a shortcut opportunity with probability \(p\). A shortcut improves measured score enough to be selected, but changes intended utility by \(-\eta\) with \(\eta>0\). If no shortcut is encountered, the optimizer selects a genuine improvement with intended gain \(g>0\). A metric-audit inquiry costs \(k\) in intended-utility units and detects the shortcut class with probability \(q\). If detected, the evaluator is repaired so that future shortcut opportunities are blocked and the optimizer selects the genuine improvement instead.

This condition is crude but useful. It says metric audits become more attractive when shortcut frequency is high, shortcut harm is large, genuine improvements are valuable, repair is likely to succeed, the horizon is long, or audit cost is low. These are precisely the regimes in which self-evolving systems are most vulnerable to Goodhart-style failures.

6.3 Oracle routing

An inquiry includes an oracle. The same question can have different value depending on whether it is answered by a language model, human expert, simulator, formal verifier, production trace, or protected evaluator. For a fixed query \(q\), oracle routing is: \[o^*(q,S)=\arg\max_{o\in\mathcal{O}(q,S)}\mathbb{E}[\Delta U_w\mid q,o,S]-C(o;S)-R(o;S).\]

A strong model is not always the best oracle. For numerical correctness, a calculator may dominate. For code validity, a compiler and tests may dominate. For novelty, literature search and expert review may dominate. For safety, independent red-teamers or protected holdout evaluators may dominate. IPL therefore treats oracle selection and evidence validation as part of the inquiry action, not as incidental implementation details.

7 An IPL Architecture

Figure 1 gives a concrete architecture. The key design choice is that the system separates inquiry generation, oracle routing, evidence validation, and bounded update management.

7.1 Uncertainty graph

The uncertainty graph represents unknowns, assumptions, contradictions, open risks, and dependencies. Nodes can block decisions, evaluators, safety gates, or artifact updates. Examples include “validation split may leak labels,” “simulator ignores gas cost,” “tool output may be stale,” and “public test suite rewards shortcut behavior.” Edges represent dependency: if a metric is invalid, downstream optimization claims inherit that uncertainty.

7.2 Inquiry generator and scorer

The generator proposes candidate inquiries from templates, learned policies, domain heuristics, and trace memory. It should produce diverse candidates: clarification, measurement, falsification, oracle comparison, metric audit, simulation, adversarial test generation, tool construction, and policy update. The scorer estimates EEV, applies the \(\epsilon\)-operational filter, and rejects unsafe or non-validatable candidates.

A minimal heuristic scorer might use: \[\begin{split} Score(i)=&\;2.0\,DecisionImpact+2.0\,InformationGain+2.0\,EvaluatorGain\\ &+1.5\,RiskReduction+1.2\,Reusability+1.2\,FutureInquiryGain\\ &-1.5\,Cost-1.5\,Latency-2.0\,SafetyRisk-2.0\,GoalDriftRisk. \end{split}\] The weights are not universal. The point is that evaluator gain and future inquiry gain are explicit terms rather than hidden inside task score.

7.3 Oracle router and evidence validator

The router selects the evidence source. The validator checks provenance, reproducibility, consistency, permissions, and safety. For code, validation may require tests, static analysis, and sandboxed execution. For science, it may require source-quality checks and replication. For user clarification, it may require preserving user intent and avoiding leading questions. For model-generated evidence, it may require independent verification.

7.4 Trace store and policy learning

Each inquiry creates a trace: context, candidate inquiries, selected inquiry, oracle, raw evidence hash, validation result, update, evaluator result, safety outcome, and retrospective utility. These traces are the training data for future inquiry-policy learning. A trace store should be protected from silent modification, because corrupted traces can teach the system the wrong inquiry policy.

8 Inquiry Trace Schema

A trace is the unit of memory for IPL. It should be machine-readable and auditable.

{
  "inquiry_id": "inq_0421",
  "state_summary": "public score improved but holdout failures increased",
  "candidate_inquiries": [
    "continue artifact search",
    "audit metric for shortcut behavior",
    "inspect failing holdout cases",
    "ask human to rank acceptable tradeoffs"
  ],
  "selected_inquiry": "audit metric for shortcut behavior",
  "inquiry_type": "metric_audit",
  "oracle": "sandboxed adversarial evaluator",
  "validation": "reproduce on clean checkout and protected holdout",
  "raw_evidence_hash": "sha256:...",
  "validated_evidence": "score can be improved by deleting failure markers",
  "system_update": "lock evaluator files and add independent verifier",
  "evaluation_delta": {
    "capability": 0.00,
    "evaluator_quality": 0.60,
    "safety": 0.40,
    "future_inquiry_quality": 0.20
  },
  "cost": 0.07,
  "risk": 0.01,
  "retrospective_lesson": "large score jumps trigger metric-gaming audit"
}

The schema highlights an important distinction: not every valuable inquiry immediately improves capability. Some inquiries improve evaluator quality, safety, or future inquiry quality. A purely scalar benchmark loop would mark these as wasted steps; IPL records them as durable self-evolution.

9 Worked Walkthrough: Trading-Simulator Evaluator Repair

This example is illustrative rather than empirical. It shows the intended control behavior and the autoresearch counterfactual.

9.1 Setup

A coding agent is asked to improve a DeFi trading simulator. The public evaluator reports simulated profit. The intended target is risk-adjusted realized profit after gas, slippage, failed transactions, MEV exposure, and token-transfer edge cases. The agent can edit code, run tests, inspect traces, query documentation, simulate transactions, or ask a human maintainer for constraints.

9.2 Metric-driven counterfactual

A pure autoresearch loop proposes a code change that increases simulated profit by skipping failed transaction paths. The public score improves. Because the evaluator does not penalize missing failure accounting, the loop keeps the change. Subsequent edits exploit the same omission. Measured performance rises while intended utility falls.

9.3 IPL behavior

The IPL controller represents an uncertainty node: “profit metric may ignore execution failure and adversarial costs.” It generates candidate inquiries:

1. continue artifact optimization;

2. inspect failed transaction logs;

3. run adversarial simulation with gas spikes and reverted swaps;

4. audit the profit metric against a protected cost model;

5. ask the maintainer which costs are mandatory for acceptance.

The EEV scorer prefers the metric audit because a positive finding would change the evaluator and all future optimization. The oracle router sends the inquiry to a sandboxed simulator and protected cost model rather than to the LLM alone. The validator requires reproducibility on a clean checkout and verifies that evaluator files were not changed by the proposing agent.

The audit finds that the metric excludes failed transaction probability and fee-on-transfer behavior. The update manager proposes a bounded evaluator update: add gas, slippage, revert, and token-transfer tests; lock evaluator files; and add a rule that large score jumps trigger adversarial metric audits. The sandbox runs the old artifact, the proposed artifact, and baseline cases. The system keeps the evaluator update but reverts the profit-increasing artifact edit.

The result is not immediate public-score improvement. It is improved measurement. Over the next optimization steps, the artifact search is less likely to chase false profits. The trace teaches a reusable policy: when a trading objective improves sharply without corresponding protected-evaluator improvement, audit the metric before scaling optimization.

10 Algorithmic Loop

Algorithm: Inquiry Policy Learning Loop

Input:
  goal and constraint model G
  system state S_0
  evaluator set E
  tool/oracle set T
  safety boundary B

for t = 0,1,2,... do
  1. Run scheduled evaluations and safety checks.
  2. Update the self-model and uncertainty graph.
  3. Generate candidate inquiries I_t.
  4. Reject candidates that violate B, lack validators, or fail
     the epsilon-operational filter.
  5. Estimate EEV(i; S_t) for each remaining inquiry.
  6. Select i_t = argmax_i EEV(i; S_t), with bounded exploration.
  7. Route i_t to the selected oracle.
  8. Collect raw evidence Y_i.
  9. Validate evidence z_i = v_i(Y_i, S_t).
 10. If z_i is invalid, record trace and update the oracle model.
 11. If z_i is valid, propose a bounded system update.
 12. Apply the update in a sandbox.
 13. Evaluate capability, evaluator integrity, and safety.
 14. Keep, revert, quarantine, or escalate the update.
 15. Store the trace and lineage.
 16. Update the inquiry policy from retrospective inquiry return.
end for

The loop differs from ordinary autoresearch at steps 3–6 and 10–16. The candidate set includes non-code inquiries. Invalid evidence updates the oracle model rather than the artifact. Evaluator and goal changes are subject to stronger gates than ordinary artifact edits. Policy learning uses traces of inquiry quality, not only task score.

11 InquiryGym: A Benchmark Protocol

Current benchmarks usually grade final answers or task completion. InquiryGym would instead evaluate whether an agent chooses good inquiries under uncertainty, cost, hidden evaluator flaws, and multiple oracles.

11.1 Task instance

Each task contains:

1. a partially specified goal;

2. hidden assumptions and at least one possible evaluator defect;

3. multiple oracles with different costs, latencies, coverage, and reliability;

4. an editable artifact or codebase;

5. a public evaluator that may be incomplete;

6. a protected final evaluator measuring intended utility;

7. safety boundaries and rollback mechanisms;

8. a budget for inquiries and modifications.

11.2 Metrics

InquiryGym should measure:

• Decision lift: improvement over a baseline that acts without inquiry.

• Uncertainty burn-down: reduction of high-impact uncertainty nodes.

• Evaluator repair: detection and correction of proxy flaws.

• Oracle routing quality: selection of authoritative evidence sources.

• Cost-normalized evolution value: utility gain per unit cost.

• Defect discovery: hidden failures found before deployment.

• Safety preservation: avoidance of unsafe or unauthorized inquiries.

• Future inquiry improvement: better inquiry choices on later tasks.

11.3 A v0.1-style illustrative task

A minimal task can be specified without requiring a full benchmark release:

ProxySim-1. An agent receives a codebase with a public score measuring average profit. A hidden final evaluator subtracts transaction failures and rare catastrophic losses. Available inquiries include running the public evaluator, inspecting logs, querying a simulator, asking a human for accepted loss constraints, and constructing an adversarial test. The agent has a limited budget and must decide whether to optimize the code or audit the metric before optimization.

Baselines would include random inquiry, clarification-only inquiry, uncertainty-only inquiry, ReAct-style tool use, reflection-only agents, metric-driven autoresearch, bilevel autoresearch, evolutionary artifact search, and human-designed inquiry plans. The purpose is not merely to see who reaches the highest final score, but to measure whether an agent identifies the evaluator flaw before exploiting it.

12 Safety and Governance

IPL expands what a system may investigate and update. That increases both capability and risk. A safe IPL system should include the following controls.

12.0.0.1 Sandboxing and boundary enforcement.

Inquiry actions that execute code, query production systems, or modify tools must be sandboxed. Boundary conditions \(b_i\) should specify allowed files, networks, credentials, data sources, and side effects. The system should not silently expand its own permissions.

12.0.0.2 Protected evaluators.

Some evaluators should be immutable to the agent. Others may be proposed for modification but require human approval or independent verification. Hidden holdout evaluators are necessary to detect benchmark overfitting and evaluator gaming.

12.0.0.3 Traceability and lineage.

Every inquiry and update should have a trace. Self-modifications should preserve lineage so harmful updates can be rolled back and analyzed. Archive-based systems such as DGM make lineage explicit for agents and code; IPL extends this requirement to inquiries, evidence, validators, evaluators, and policy changes.

12.0.0.4 Oracle-risk modeling.

LLMs can hallucinate, search engines can be stale, logs can be incomplete, humans can be biased, and simulators can be wrong. IPL therefore needs an oracle model that tracks authority, coverage, bias, latency, cost, and prior reliability by inquiry type.

12.0.0.5 Goal-drift control.

A self-evolving system that can update specifications and evaluators risks redefining success. IPL must separate proposed specification changes from authorized specification changes. High-impact goal or evaluator changes should require explicit approval, protected review, or formal constraints.

12.0.0.6 Anti-Goodhart audits.

When a score improves unusually quickly, when a change touches evaluator files, when a metric becomes easier to satisfy, or when protected holdouts degrade, IPL should trigger metric-gaming inquiries. These audits are not optional add-ons. They are central to safe self-evolution.

13 Limitations

IPL faces several limitations. First, estimating EEV is difficult. Early systems will rely on noisy heuristics, model judgments, and retrospective traces. Second, inquiry policies can themselves be Goodharted if trace rewards are poorly designed. Third, expanding the action space from artifact edits to arbitrary inquiry actions increases safety and governance burden. Fourth, oracle routing is hard: the best source of evidence is often unavailable, expensive, biased, or slow. Fifth, updating specifications and evaluators creates authority problems. A system that can redefine success must be constrained by human-approved boundaries. Sixth, benchmarks with hidden evaluator flaws can still be overfit if the flaw distribution becomes predictable.

The largest limitation of this paper is empirical. It does not include a working InquiryGym release, an implemented IPL controller, or baseline results. As a result, its contribution is conceptual and architectural rather than demonstrated performance. The next version should include at least one synthetic proxy-evaluator task comparing metric-driven autoresearch against an inquiry policy that can audit and repair the evaluator.

14 Research Agenda

The most useful next steps are:

1. Build a small InquiryGym release with hidden evaluator flaws, oracle costs, and protected final evaluation.

2. Compare random inquiry, uncertainty-only inquiry, active-learning baselines, ReAct-style tool agents, reflection agents, autoresearch, bilevel autoresearch, evolutionary search, and IPL controllers.

3. Train or tune inquiry policies on trace datasets labeled by realized evolution value.

4. Quantify when metric-audit inquiries outperform direct optimization.

5. Develop safety gates for sandboxing, protected evaluators, and rollback.

6. Study when asking humans is optimal and how to minimize interruption cost.

7. Test cross-domain transfer from software debugging to scientific discovery, robotics, web agents, ML engineering, and economic simulation.

8. Distill successful inquiry traces into reusable policies, rubrics, or small controller models.

9. Create adversarial inquiry environments where plausible questions are traps, cheap oracles are misleading, and evaluator repair is necessary for success.

15 Conclusion

Self-evolving AI systems require more than stronger optimizers. They require mechanisms for deciding what to investigate, which evidence source should answer, how evidence should be validated, and what system object should change afterward. Inquiry Policy Learning formalizes this mechanism as a policy over information-producing interventions.

The strongest claim is evaluator repair: when the measurement process is flawed, improving the evaluator can create more expected long-horizon value than improving the artifact. This is especially important for systems that can modify code, tools, tests, prompts, specifications, memories, and policies. Autoresearch is an engine of optimization. IPL is a steering layer for deciding whether the next step should be optimization, measurement, falsification, oracle comparison, safety review, tool construction, or evaluator repair.

AI Assistance Disclosure

This manuscript was revised with assistance from an AI writing and editing system. The author remains responsible for the framing, claims, citations, and any decision to submit or publish the work. All references and factual claims should be independently checked before public posting or venue submission.

Appendix A. Inquiry Taxonomy

Appendix B. Acceptance Gates for Self-Updates

1. The update must be linked to validated evidence.

2. The update must specify which epistemic object it modifies.

3. The update must be sandboxed before acceptance.

4. The update must pass protected evaluators not modifiable by the proposing agent.

5. The update must not weaken safety boundaries.

6. The update must preserve traceability and rollback.

7. Evaluator and goal updates require stronger authorization than artifact updates.

Appendix C. Minimal Inquiry Policy Prompt

You are an Inquiry Policy Controller.
Your task is not to solve the object-level problem immediately.
Your task is to choose the next inquiry action that most improves
safe, measurable system evolution.

Given:
- goals and constraints
- current system state
- uncertainty graph
- available oracles/tools
- recent failures and traces
- safety boundaries

Produce:
1. the top candidate uncertainties
2. candidate inquiries for each uncertainty
3. the oracle each inquiry should use
4. the validation procedure
5. expected decision impact
6. expected evolution value
7. cost and safety risk
8. the selected inquiry
9. what system object may be updated if evidence validates

Reject inquiries that cannot change a decision, cannot be validated,
violate safety boundaries, or only make the system feel more certain.

Appendix D. Glossary

Inquiry action

An information-producing intervention such as a question, test, simulation, search, audit, or sandboxed modification.

Inquiry policy

A controller that selects inquiry actions from system states.

Expected Evolution Value

Expected improvement in system utility from an inquiry, minus cost and risk.

Oracle

Any evidence-producing process: human, model, test, simulator, paper, log, or experiment.

Evidence validator

A procedure that decides whether raw oracle output is acceptable for updating the system.

Evaluator repair

Inquiry actions that improve or replace flawed metrics, tests, or benchmarks.

Recursive inquiry improvement

Improvement in the system’s future ability to choose valuable inquiries.

References