It is a little scary to think about agents improving their own instructions. I think we are already seeing the first steps, although we still decide which changes to accept.
Every time you correct an agent, you create knowledge that has value. You explain that a global variable follows a different convention, that the event it selected is not suitable for the posting process, or that a particular customer calculates discounts per line. Often, though, you close the session and that knowledge goes no further. Next time, the agent may make exactly the same mistake.
Warp faced a similar problem with its own code review agent. The team initially adjusted prompts and added context to AGENTS.md when a problem appeared. That helped, but someone still had to identify each issue and decide how to change the agent’s behaviour. In Anthropic’s account of Warp’s approach, published on 26 August 2026, human feedback becomes part of a repeatable skill improvement cycle.
The feedback already exists. The question is how much of it we can use beyond the current task.
What happens when you correct an agent
Imagine a code review. The agent suggests a change, and a developer explains in the PR that the project’s global variables follow a particular naming convention. That comment contains knowledge about the project. Unless we have a way to recover it, it may stay in that PR, and someone will have to explain the same convention again.
This is familiar in AL projects. Some decisions never reach formal documentation. There are conventions shaped by years of product development, customer exceptions and patterns that a senior developer recognises because they know the project. We can give an agent that context during a session. What happens to it afterwards deserves attention too.
Warp’s approach
Warp describes two skills with different responsibilities. The base skill contains the instructions and domain knowledge for the task, such as code review, specification or triage. People then comment on the result where they already work, mainly in issues and pull requests. A detailed explanation gives the system more to work with than a simple positive reaction.
An improver skill runs periodically. It examines the accumulated feedback alongside the agent’s original responses and proposes a small change to the base skill. That proposal can go through a normal PR: a person reviews it, decides whether to accept it and merges the change. The next run then uses the updated skill.
The cycle connects the task, its result, human feedback, a proposed edit and a reviewed version of the skill. Warp’s published example keeps human approval before the change takes effect.
In this case, “learning” means updating the instructions available to future runs. The described process does not retrain the model. Correcting the current result can therefore also contribute to the next execution, provided that the proposed change is useful and accepted.
What they have learned about writing skills
Several lessons from the article seem useful for other agent systems. One is to avoid turning skills into huge collections of rules. Coming from software development, it is easy to write something that resembles a linter: if A happens, do B; if C appears, reject D. The list of cases can keep growing without making the underlying intention any clearer.
Warp recommends expressing principles and explaining why an instruction exists. This gives the model a basis for applying the intention to other cases. The team also values detailed feedback from people who know the domain. A positive reaction shows that a result was useful; an explanation can tell us why a recommendation worked or why it was wrong. Anthropic’s skill authoring guidance also recommends concise skills, tested with real use, and supporting resources loaded when needed.
People make mistakes too. A comment should not automatically become a permanent instruction. We need to know where the feedback came from, check it where possible and review changes before they become part of the system’s stable behaviour.
The distinction between skill and memory helps here. In the design described by Warp, a skill holds relatively stable knowledge about how to perform a task, while memory can collect information during runs and change more frequently. If every correction or customer exception becomes a permanent rule, we may eventually lose track of why those rules exist.
How this could fit AL and Business Central
This is where I see room to explore the idea. In a framework such as ALDC, many places where feedback appears already exist. Someone questions an architectural decision. A specification moves into technical detail too early. A Human Gate, a point where a person must decide, stops a phase. A reviewer suggests a change, and a developer explains why it does not apply to that customer.
We can use those observations to correct the current run. Some could also help improve future skill behaviour. I do not think this requires redesigning ALDC. A periodic process could review the available signals and identify those that justify a focused change. This is a possible extension I am considering here, not a capability demonstrated by this article.
For ALDC, the proposal would start with a skill execution and its human review. Relevant feedback would be checked, turned into a proposed skill edit and submitted in a PR. The accepted version would then become available to later runs.
AL gives us useful ways to check some of that feedback. The compiler can check whether the code meets language requirements. Tests can provide evidence that an expected behaviour still holds in the cases they cover. Analysers and validators can check specific properties, while BCQuality can contribute specialised rules and knowledge to the review.
Those checks have limits. A customer convention or an architectural choice cannot be validated just by compiling the code. Still, the agent proposing a skill update could compare the correction with the available evidence before opening the PR. That would give the person reviewing it a better basis for deciding whether the change belongs in the skill.
A partner’s knowledge could accumulate too
A partner may start with a shared set of agents and skills, then add its own development conventions, architectural practices and experience from particular types of projects. Each customer adds another layer of knowledge.
That knowledge does not all belong in a public skill. The community can maintain common AL and Business Central knowledge, the partner can maintain its practices, the project can retain its decisions, and customer business rules can remain in that customer’s context.
The same feedback process could propose improvements within these layers while keeping their scope clear. A rule for one customer should not become a rule for every project just because it appeared in a useful review comment.
That is what makes this approach interesting to me: skills could capture reusable engineering knowledge with a history we can inspect. We would be able to review a change and trace it back to the correction that prompted it, much as we do with code.
What interests me about this
I want our corrections to stop being disposable. Every day, we explain why a decision is right, which exception a customer needs or why a reasonable-looking recommendation does not work in a particular codebase. Some of that context should end with the session. Some deserves to remain.
Warp’s approach offers a way to make that distinction and propose deliberate updates, with human review before they take effect. It also leaves us with a practical question about our own work with Copilot, Claude, Codex or other agents in AL: how many corrections have we had to repeat more than once?
There is probably knowledge there that we are still not capturing.
Read the Spanish version on Substack.
References
How Warp builds self-improving agents on Claude. Claude Blog, 26 August 2026.
Warp Agents Demo: GitHub Issue Triage. Public demonstration repository, archived on 2 June 2026; useful as a reference, not presented here as a maintained installation package.
Skill authoring best practices. Claude Platform documentation.