agentic-solution-search

name

agentic-solution-search

description

Run a methodological agentic loop for exploring a solution space, simulating alternatives, testing hypotheses, pruning weak paths, and converging on a verified answer or implementation. Use when the user asks for an agent to solve an ambiguous, open-ended, multi-step, research, design, engineering, debugging, planning, optimization, or strategy problem where multiple approaches are possible; when they ask to search the solution space, think agentically, run iterative trials, compare candidate solutions, or avoid premature convergence; or when the task needs explicit loop state, evidence, decision criteria, and stop conditions.

Agentic Solution Search

Use this skill to make exploration deliberate. The agent should maintain a live search state, generate and test candidate paths, and converge only when evidence supports the chosen path.

Core Loop

Repeat the loop until the goal is achieved, the search budget is exhausted, or a blocker is proven.

1. Frame

   • Restate the goal as a testable objective.
   • List constraints, success criteria, known facts, unknowns, and available tools.
   • Decide the search mode: breadth-first exploration, depth-first execution, beam search, adversarial review, experiment loop, or hybrid.

2. Map the space

   • Identify 3-7 plausible solution families.
   • For each family, name the central bet, expected payoff, risk, cost, and evidence needed.
   • Read references/search-patterns.md when choosing the search mode or branching strategy.

3. Choose a frontier

   • Keep a small active frontier of candidates.
   • Rank candidates by expected value: impact, likelihood, reversibility, cost, information gain, and alignment with constraints.
   • Include at least one conservative path and, when useful, one contrarian path.

4. Simulate before acting

   • For each leading candidate, run a quick mental simulation: actions, dependencies, likely failure modes, and validation signal.
   • Prefer cheap probes before expensive implementation.
   • Identify what observation would kill the candidate.

5. Act and observe

   • Execute the next smallest useful probe, edit, experiment, search, or analysis.
   • Record evidence, not vibes: command output, test result, source citation, user feedback, measured metric, or inspected artifact.

6. Update beliefs

   • Promote candidates with supporting evidence.
   • Prune candidates whose central bet failed.
   • Split promising-but-vague candidates into sharper sub-candidates.
   • Read references/loop-state.md for the compact state format.

7. Converge or continue

   • Converge when one path satisfies the success criteria and survives a verification pass.
   • Continue when the best path is promising but unverified.
   • Declare blocked only when the same blocking condition remains after genuine alternate attempts.

Required State

For substantial tasks, keep a compact state visible to yourself and summarize it to the user when useful:

• Objective
• Constraints
• Success criteria
• Known facts
• Unknowns
• Frontier
• Current best path
• Evidence collected
• Pruned paths
• Next probe
• Stop condition

Do not show long internal scratchwork. Show the state only when it helps the user steer or trust the process.

Search Modes

• Breadth-first: Use when the space is unclear and premature commitment is risky.
• Depth-first: Use when a path is obviously cheap, reversible, and likely.
• Beam search: Use when there are many plausible candidates; keep the top 2-4 alive.
• Adversarial review: Use when correctness, safety, or strategy quality matters.
• Experiment loop: Use when empirical evidence is available through tests, benchmarks, prototypes, or data.
• Hybrid: Start broad, then go deep after evidence separates candidates.

Candidate Card

Use this concise format when comparing options:

Candidate: <name>
Bet: <what must be true>
First probe: <cheapest useful test>
Evidence for: <observations supporting it>
Evidence against: <observations weakening it>
Risk: <main failure mode>
Decision: pursue | hold | prune

Verification

Before finalizing, run a verification pass:

• Check the solution against every success criterion.
• Look for untested assumptions and edge cases.
• Confirm that pruned alternatives were rejected for evidence-based reasons.
• State residual risk and the evidence supporting the final answer.

Guardrails

• Do not generate endless plans. Each loop should produce evidence or reduce uncertainty.
• Do not keep all candidates alive. Pruning is part of intelligence.
• Do not overfit to the first plausible solution when cheap probes can compare alternatives.
• Do not hide blockers. If the search cannot progress, name the exact missing input, tool, permission, or evidence.
• Do not call a solution verified because it is elegant. Verification requires an observable check.