Evolution Agent

Evolution Agent

What this does

Turns the signals your system is already producing (quality-check findings, feedback reactions, and real outcomes) into a short list of concrete proposed changes to your own skills, scores, and workflows. Each one arrives as a reviewable proposal with the data behind it. You approve; the system updates. It never edits itself. This is the layer that makes a library of skills improve over time instead of drifting.

What you'll need

You do not need to connect anything to get value today. Paste your findings and the skill runs now. Connect the tools below and it reads the feedback and outcome streams automatically.

• Works today with: your quality-check findings and any feedback you have collected (thumbs, notes, outcomes). Paste them and the skill drafts the changes.
• More powerful connected to your feedback log: it reads reactions, click-through, and re-asks automatically instead of you summarizing them.
• Sharper with outcome data: cross-references what a skill predicted against what actually happened (did the AT_RISK deals slip, did the high-fit accounts convert).
• Sharper with a version-control connector: writes each proposed change as a reviewable diff you can approve in one click.

How this runs at your connection level

This skill is never reliant on a connector. It runs on the findings and feedback you paste today and gets sharper as you connect the streams it reads. It never claims an improvement it cannot show in the data, and it never merges a change on its own.

• Bring your data: paste your QA findings and feedback. The skill drafts the proposed changes today, each with its rationale. No connection required.
• Connect your tools: the same skill reads the feedback log and outcome data automatically and turns proposals into ready-to-review diffs. Same output, less effort, sharper.
• Just exploring: nothing collected yet? Get the framework, the four change types, and a worked example, so you can see the shape before you feed it signal.

Every run ends with the one thing to review first: the single highest-priority change, and why it matters now.

Customize this for yourself

This was built to evolve a suite of GTM skills. Set these to your stack:

The method

Read both feedback streams

Implicit signals (reactions, click-through, re-asks, outcome attribution) and explicit signals (thumbs plus structured reasons). Neither alone is enough. A single thumbs-down is noise; the same pattern across both streams is a signal worth acting on.

Attribute outcomes honestly

Cross-reference each skill's predictions to what actually happened, controlling for cohort confounds (window size, segment mix, sample size). Never claim a lift without accounting for what else moved. Small samples lie, and a self-improving system that believes its own inflated numbers gets worse, not better.

Propose, never merge

Every change ships as a reviewable proposal with a diff and a rationale tied to data. Four kinds:

• Tighten a rubric: when two tiers converge on the same outcome, collapse or re-cut them.
• Update a trigger or definition: when language in the field has shifted (a new tool named in calls, a new phrase reps use).
• Propose a new workflow: when the same sequence of skills fires together often enough to bundle.
• Retire a skill: when it is unused past RETIRE_DAYS or persistently below ACCURACY_FLOOR.

Name the one thing to review first

Every pass ends by surfacing the single highest-priority change, usually the skill whose accuracy dropped below the floor, with the specific cases to investigate.

Quality gates

• Every proposal has a rationale tied to data. Not "tighten this rubric" but "STRONG_FIT converted at 82% and FIT at 79%, too close to differentiate. Collapse to one tier plus an above-baseline override."
• Nothing auto-merges. Every change is a reviewable proposal you approve before anything updates.
• Outcome claims are honest. No "we improved win rate by 5%" without controlling for cohort confounds.
• A skill is retired only on evidence: low invocation past the window, or precision below the floor, never a hunch.

Output (example)

EVOLUTION PASS - week of May 25
4 proposed changes ready for review

1. Tighten the fit rubric
   STRONG_FIT converted 82%, FIT 79% (too close). Collapse to one tier
   plus an "above-baseline" override.
2. Add a term to the tech-stack list
   A tool showed up in 12 calls this month vs 4 last quarter.
3. Propose a new workflow: renewal prep
   The same 3 skills fired in the same order 17 times. Bundle them.
4. Retire an unused skill
   Invoked twice in 180 days, both tests. Deprecate.

Accuracy (trailing 90 days):
  Fit scoring     82%
  Deal health     78%
  Churn predict   67%   <- below the 75% floor

Review first: churn prediction at 67%. Tighten it or lower its confidence.

Where the numbers come from

RETIRE_DAYS (90), the 75% accuracy floor, and the trailing-90-day window are defaults from one team's cadence, not laws. A fast-moving library wants a shorter unused window; a high-stakes one wants a higher accuracy floor. Re-tune them to how much risk you carry. The loop (read both streams, attribute honestly, propose, approve) does not change. The thresholds are yours.

Example chat

You: Pull together what we've learned this month across the skill library, what should we change?

Claude: Ran the pass. Four proposals, one of them urgent.

1. Tighten the fit rubric: STRONG_FIT converted 82%, FIT 79%. Collapse to one tier.
2. Retire an unused skill: invoked twice in 180 days, both tests.
3. Add a term to the tech-stack list: a new tool named in 12 calls this month.
4. Propose a new workflow: same 3 skills fired together 17 times.

Accuracy on churn prediction dropped to 67%, below the 75% floor. That's the one to review first, not the rubric tweak, even though the rubric tweak is the easier fix to ship. One sharpener: connect the outcome source (your CRM) so the accuracy numbers update automatically instead of me asking you to paste last month's results.

Go further

The manual pass proves the loop works. Here is what it looks like running continuously.

• Run the pass on a schedule. Put this on a monthly scheduled Claude task so drift gets caught before a quarter goes by, not after.
• Feed it real reactions. Connect Slack reactions and Amplitude click-through so implicit and explicit feedback both flow in without anyone logging them by hand.
• Ship proposals as diffs. Wire a GitHub connection so each proposed change lands as a pull request against the SKILL.md, ready for one-click review instead of a paragraph to re-type.

You still approve every merge. The pass just stops depending on someone remembering to run it.

Make it yours

Fork it. Change the feedback sources, the floors, the windows, the change types. The point is not to run someone else's improvement loop. It is to make your own skills compound instead of rot, with a human on every merge. Built by an operator. Customize it, break it, make it better.