Як Warp будує self-improving agents з Claude і Skills

Judgment-heavy workflows швидко старіють: PR-review правила, issue triage, support/community tone і engineering conventions змінюються разом із продуктом. Static prompt поступово накопичує винятки, а ручне переписування інструкції стає окремою непомітною операційною роботою.

Warp показує інший pattern: inner loop виконує task за Skill, а outer loop збирає corrections і готує diff до самого Skill. Сильна частина архітектури не в слові self-improving, а в тому, що knowledge про якість стає versioned artifact із review history, а не містичною пам'яттю моделі.

Inner-loop trigger може бути новий GitHub Issue, pull request, support/community mention або інша подія. Input — поточний Skill, task payload, repository/context, tool permissions і acceptance rules. Agent виконує classification/review/response і пише trace або external record.

Outer-loop trigger — schedule або накопичений feedback set. Він читає попередні runs, human corrections, comments і grader results, визначає повторюваний failure pattern і генерує **diff до Skill**, а не неперевірену in-place зміну production instruction. Output — candidate Skill revision із evidence і expected improvement hypothesis.

• Inner trigger → issue/PR/mention/task.
• Inner output → bounded action + trace + reviewer correction signal.
• Outer trigger → scheduled feedback aggregation.
• Outer output → versioned Skill diff + eval candidate, не auto-promotion за замовчуванням.

Найнебезпечніша банальність — дозволити agent самому переписувати instructions, якими потім оцінюється його поведінка, і одразу deploy-ити зміни. Так feedback loop перетворюється на privilege-escalation loop. У production Skill repository, eval suite, CI policy і merge rules мають бути control plane, який agent не може тихо послабити.

A4 допускає autonomous bounded execution і пропозицію Skill update. Promotion потребує deterministic checks, diff review або trusted grader policy, version fingerprint і rollback target. Якщо agent змінює tool scope, auth assumptions, protected tests або approval requirements — це high-risk change незалежно від того, наскільки переконливо він пояснює improvement.

Failure modes: один noisy reviewer формує неправильне правило, attacker залишає adversarial comment, feedback не репрезентує production distribution, Skill diff overfits останні кейси, outer loop видаляє safety constraint, concurrent improvements конфліктують або model update змінює interpretation тієї самої інструкції.

Контролі: feedback provenance, minimum support threshold для нової rule, negative/adversarial slices, protected instruction sections, semantic diff review, conflict detection, model+Skill fingerprint і canary. Не кожне виправлення людини треба навчити agent повторювати; іноді це просто людина теж помилилася — дивовижно, але production systems мають враховувати й таку екзотику.

Перед promotion candidate revision проганяється на frozen regression corpus: normal tasks, past corrections, hard negatives, adversarial comments, no-answer/needs-info cases, policy exceptions і tasks поза scope. Для judgment-heavy review додається calibrated human/model grader, але security/authority assertions перевіряються deterministic rules.

Потрібні paired metrics baseline vs candidate: task success, correction rate, false-positive/false-negative by slice, unsafe-action rate, latency, tool calls і cost per verified task. Candidate не проходить release, якщо aggregate score покращився, але погіршив critical slice або розширив tool/authority surface.

Inner loops можуть працювати event-driven на кожен issue/PR, outer loop — daily/weekly залежно від обсягу feedback. Занадто часта перебудова Skill створює конфігураційний churn: команда вже не розуміє, яка behavior revision працювала в конкретний момент і чому змінився результат.

Full cost = agent inference + repository/tool compute + trace storage + outer-loop analysis + eval reruns + human review + failed candidates + canary/rollback + support. Хороший denominator — cost per accepted task після correction або cost per stable Skill promotion, а не кількість згенерованих diff-ів.

1) Виберіть bounded judgment task — triage або first-pass review. 2) Винесіть rules у versioned Skill. 3) Логуйте decision + correction reason. 4) Побудуйте frozen eval corpus. 5) Запустіть outer loop лише як PR generator. 6) Додайте candidate-vs-baseline replay і canary. 7) Автоматизуйте promotion тільки для низькоризикових changes із hard guards і миттєвим rollback.

Підходить командам із достатнім feedback volume і чіткою quality rubric. Якщо команда не може пояснити, що означає хороший review/triage, self-improvement loop просто автоматизує розмноження смаків, конфліктів і корпоративної міфології.