Real-World Feedback Powers Continuous Evolution of AI Agent Skills

1. Skill Three-Layer Structure

In an Agent system, a Skill is a versioned capability package stored in a directory whose entry point is SKILL.md. The design splits a Skill into three layers:

Routing layer : name, description, and path, used by the Agent to decide whether the Skill matches the current task.

Instruction layer : the body of SKILL.md, describing the workflow, decision criteria, tool strategy, and output constraints.

Resource layer : sub‑folders such as references/, assets/, scripts/ that hold detailed documents, examples, templates, or executable code.

This hierarchy enables progressive loading: the Agent first reads the routing information, then loads the full SKILL.md when a task matches, and finally accesses additional resources only if needed.

2. Self‑Evolution: Updating the Three Layers with Real Feedback

Self‑evolution means continuously refining each layer based on actual task feedback. The routing layer can be tightened to improve trigger precision, the instruction layer can be revised to stabilize workflows, and the resource layer can be enriched with new examples or scripts. Every iteration should answer: which layer changed, what problem it solved, and what evidence proves the improvement.

Example: Travel‑Planner Assistant

Initial version travel-planner-skill v1.0:

---
name: travel-planner
description: Plan a multi-day travel itinerary based on destination, dates, and user preferences.
---
## Workflow
1. Collect destination, dates, budget, and travel preferences.
2. Search for attractions, restaurants, and transportation options.
3. Arrange attractions by day.
4. Generate a day-by-day itinerary.
## Output
Use one section per day.
Include attractions, food recommendations, and transportation notes

Generated itinerary for a three‑day Kyoto trip:

Day 1 清水寺、二年坂三年坂、八坂神社、祇园
Day 2 伏见稻荷大社、锦市场、鸭川
Day 3 金阁寺、岚山、竹林小径

The plan is complete but sub‑optimal: Day 3 packs two distant sites, and the “relaxed” preference is not reflected. The user replies, “Day 3 is too rushed, I don’t want many transfers, and restaurants should be on the way.”

These follow‑up prompts become part of the task trace (original request, initial solution, user correction, final adopted version, and evaluation). An optimizer abstracts the feedback into stable rules, e.g.:

When the user prefers a relaxed pace, limit each day to 2‑3 major stops and keep buffer time.

When the user dislikes frequent transfers, prioritize attractions within the same area.

Place restaurants and rest points near the day’s route.

3. Writing Each Feedback to the Correct Layer

The system decides where a rule belongs:

Trigger‑boundary issues → update the routing layer’s description.

Itinerary‑arrangement issues → modify the Workflow in the instruction layer.

Quality‑assessment issues → add or adjust Quality checks.

Scenario‑specific constraints (e.g., family travel) → place in the resource layer for on‑demand loading.

Update Instruction Layer: From Listing Attractions to Organizing by Area and Pace

First iteration modifies the Workflow:

2. Search for attractions, restaurants, and transportation options.
3. Arrange attractions by day.

Revised version:

2. Search for attractions, restaurants, and transportation options.
3. Group candidate places by geographic area before assigning them to days.
4. Estimate transit time between major stops.
5. Match each day's density to the user's pace preference:
   - relaxed: 2‑3 major stops per day, with buffer time
   - standard: 3‑4 major stops per day
   - packed: 4‑6 major stops per day

This change, placed in the instruction layer, adds area clustering, transit estimation, and pace‑based density control, turning a simple list into a structured, user‑centric plan.

Add Quality Checks

## Quality checks
Before finalizing the itinerary, check:
- Whether each day stays mostly within one geographic area.
- Whether transit time between major stops is reasonable.
- Whether the number of major stops matches the user's pace preference.
- Whether meals and rest breaks are placed near the route.

These checks ensure route coherence, reasonable travel time, pace alignment, and convenient dining/rest locations—criteria more important than merely adding more attractions.

Sink Resource Layer: Scenario‑Specific Files Loaded on Demand

If users frequently mention “children, seniors, limited walking”, a new resource file is added:

references/family-travel-constraints.md

It contains constraints such as reducing transfers, limiting walking distance, scheduling lunch breaks, and preferring easily reachable sites. The main SKILL.md gets a single trigger line:

If the user mentions children, seniors, stroller, or limited walking ability, read references/family-travel-constraints.md before finalizing the itinerary.

4. Periodic Skill Compaction: Compression and Refactoring

As iterations accumulate, the Skill becomes detailed. Regular compaction examines duplicated rules, rarely‑triggered rules, and opportunities to move details to the resource layer or merge them into higher‑level principles.

- Do not place far‑apart attractions on the same day
- Limit the number of attractions per day
- Leave rest time for relaxed travel
- Keep restaurants near the day's route
- Reduce transfers for family trips

After compression, these merge into a single stable quality standard:

Prioritize route coherence and pace fit: keep each day geographically coherent, limit major stops according to pace, place meals and breaks near the route, and reduce transfers for family trips.

5. Validation Determines Whether a New Version Is Released

When a candidate Skill is generated, it is validated against a historical task set. Metrics such as cross‑region moves per day, average transit time, explicit satisfaction of user preferences, and itinerary density are compared between v1.0 and v1.1. If the new version improves these metrics, it is released; otherwise, it is rejected and logged as negative feedback for the next cycle.

Conclusion: From Prompt Tuning to Ongoing Skill Operations

The example demonstrates that Skill self‑evolution focuses on small, verifiable updates. User feedback becomes evidence, which is abstracted into rules and written to the appropriate Skill layer. Validation decides whether the updated Skill becomes a new version. Over time, compression, merging, sinking, and deletion keep the Skill lightweight, clear, and maintainable.

In the long run, an Agent’s capability grows from one‑off prompt adjustments to continuous Skill operation. The model provides general reasoning, tools connect to external systems, and Skills encapsulate reusable procedural knowledge. Real‑world feedback continuously enriches routing, instruction, and resource layers, forming a version‑controlled, evaluable, roll‑backable, and reusable capability system.