Abstract

Instructions that govern AI agents tend to grow, and change control does not stop them growing, because each addition is approved on its own merits. This report describes one case in a seven-agent estate. The convention governing how agent skills and processes may be changed, adopted specifically to resist accumulation, grew from about 13,000 to 21,964 bytes in five weeks through seven recorded amendments, each of them approved. An agent-condensed version of roughly 9,000 bytes remained hard for the human principal to follow. The document was then rebuilt from scratch in a single working session: one purpose sentence, a minimal rule set, only the process steps a reader needs, an explicit check of what the replacement would break, and repair of those findings before adoption. The result is 2,754 bytes and 44 lines, 87.5 per cent smaller than the original, which the principal can read and follow. The report sets out the method, the findings of the replacement check, the deliberate policy changes made along the way, and the reusable procedure that now applies the same method to other skills and processes. That procedure was itself revised the following day to prescribe the form of the result as well as the process, reducing it from 2,485 to 1,350 bytes.

1. The problem: governance that grows

An agent's skills and governing documents are instructions it is expected to read and follow. Each addition to them is usually a reasonable response to something that happened: a mistake, a new requirement, a clarification someone asked for. Over time the additions accumulate, and the text becomes longer, more qualified and harder to follow, both for the agent that has to act on it and for the person who has to approve it.

Corrections Consolidate (onet.com.au/papers/corrections-consolidate) addressed one cause of this, the habit of answering every agent failure with another rule, and introduced an amendment protocol to resist it. That paper conceded that the protocol "bought change control, not brevity". Human in Command (onet.com.au/papers/human-in-command) restored the human principal's ability to understand the shape of the skills library, and closed by noting that skill-by-skill review was now feasible and was the next piece of work.

This report concerns that next piece of work, beginning with the document that governs all the others. Its central observation is that approval does not prevent growth. A change process can examine every amendment, require independent review and obtain explicit human sign-off, and the governed text will still grow, because each amendment is judged locally, as an improvement to what is already there. Nothing in the process asks whether the whole document is still the simplest expression of what it is for.

2. Why size and legibility matter

There are two separate reasons to keep agent instructions small. The first concerns the agent; the second concerns the human.

The agent. Published evaluations consistently find that model performance falls as input grows, well inside advertised context windows. Liu and colleagues showed that models use information at the start and end of a long context much better than information in the middle (TACL 2024). The NoLiMa benchmark found that at 32,000 tokens, eleven of the models tested fell below half their short-context performance once the task required more than literal matching (ICML 2025, arXiv:2502.05167). Chroma's evaluation of 18 models found performance degrading with input length even on deliberately simple tasks, often non-uniformly (Hong, Troynikov and Huber, 2025). Specific to instructions, the IFScale benchmark found the best frontier models reaching 68 per cent accuracy when asked to satisfy 500 simultaneous instructions, with a bias towards those that appeared earlier (arXiv:2507.11538). Most of these studies vary the length of documents or of accumulated history rather than the standing instructions an agent is given.

The study closest to the agent setting refines that picture. ContextRotBench (Lu, Gunukula, Agashe, Liu and Wang, 2026) ran coding agents through long multi-step tasks with style constraints set at the start and checked after every later step. Adding about 98,000 tokens of random filler left adherence near baseline. Adding real work from unrelated tasks reduced it sharply: in one model, from 78 per cent of constraints satisfied to 62 per cent with interleaved work and 45 per cent when the agent was interrupted mid-task. The constraints remained in context throughout, but in the one model whose attention the authors could inspect, attention to them fell by about a third as the trajectory grew, and the agents kept making progress on the task while quietly dropping the rules. The authors call this constraint drift, and conclude that what degrades an agent is the kind of content that accumulates, not its length alone. Their study covers open-weight models, coding tasks and one harness, and the competing content was task history rather than loaded instructions.

The human principal's own experience in this estate points the same way, although the threshold he describes has not been measured: on a model with a one-million-token context window, he observes agent behaviour starting to drift at around 200,000 tokens, which in practice can arrive after only a few turns of a working session. The drift takes three forms. An agent forgets a rule, and when asked can quote the rule it then failed to follow. Where an instruction leaves room for interpretation, an agent makes the intended call most of the time but, by his estimate, an unwanted one about one time in four. And an agent loses focus on the task, most often by building elaborate verification around a request for a straightforward change. In his observation, most of the context at that point is not the conversation between principal and agent. It is the skills and governing documents the agent loads to do the work, and the more of them there are, the more room there is for drift. The first form is the constraint drift ContextRotBench measured. The third resembles a mechanism seen earlier in this estate, where a broadly triggered skill imposed test-first and independent-review steps on a routine website change (A partially relevant skill is still a skill loaded with equal weight). The second may owe as much to ambiguous or conflicting instructions, which models do not reliably resolve (Geng et al., arXiv:2502.15851), as to the size of the context. ContextRotBench did not test loaded skills, but skills are procedural, task-shaped text of the kind it found competes for attention, not inert filler, so the principal's observation fits the mechanism it describes, at least for forgotten rules. These connections are inferences, not findings. The session records of the work described in this report are consistent with the principal's account of where the context comes from. In the main working session, the principal's own messages made up about 2 per cent of the stored text, while skill loads and reads of governing and procedural documents made up about 42 per cent. In the follow-up session that revised the reusable skill, the figures were about 1 and 28 per cent. These are shares of stored message text, not of the context the model received on any one call, and they exclude the standing system prompt. They also come from sessions whose subject was governance, where reading governing documents was the work itself rather than overhead. The consequence for the principal is that long-running sessions are unreliable, and work has to be broken into short tasks that will finish before the context grows too large. How much the volume of loaded instructions contributes to drift has not been measured, and is left for separate work.

The human. The second reason does not depend on the first. A document the principal cannot follow cannot meaningfully be approved by him. Human in Command made this argument at the level of the whole skills library; it applies equally to a single document. The principal stated the acceptance criterion for this work directly:

"You and other agents may be able to follow it, however the position I am taking is that text difficult for me to follow is more complicated than necessary. If an instruction can't be conveyed simply, with a logical flow, then it should not be there in the first place."

That criterion is deliberately human-centred. An agent able to follow a document is not evidence that the document is as simple as it could be, and in this case the evidence suggests the opposite.

3. Operating environment

The estate is private, runs on the Hermes Agent harness and has a single human principal. At the time of this work it had seven agents, each in its own profile with a distinct remit: system administration and estate operations; songwriting and music prompt construction; music promotion and release; visual art direction and video production; editorial research and article preparation; an independent second opinion on consequential conclusions, run on a different, higher model where possible; and a specialist agent added in October for a separate business. Skills are organised in a shared library and local per-agent libraries, as described in Human in Command.

Skill and process changes arrive from several directions. The harness runs a background reviewer that can propose skill changes at the end of a turn; agents run their own self-improvement reviews; agents propose changes deliberately while working; and the principal requests changes directly. Proposed changes are held as pending records and assessed weekly by each agent, which reports its recommendations to the principal by email.

The Sysadmin Agent (SAA) carried out the work described in this report with the principal in a single working session over 3 and 4 November 2026, and revised the reusable procedure described in section 7 with him on 5 November. The Second Opinion Agent (SOA) reviewed both versions of that procedure.

4. The case

The document in question is the estate's cross-agent convention for assessing and approving changes to skills, governing instructions and other reusable agent methods. It was adopted on 20 September 2026, after independent review and the principal's approval, as the implementation of the Corrections Consolidate protocol. Every agent's governing file points to it.

Its growth after adoption is recorded in its own amendment notes and in retained copies:

Point	Size (bytes)	Change
Proposed, 20 September	about 13,000	Reviewed proposal for adoption
2 October	17,878	Three amendments: review-email transition, author reconciliation of review advice, direct approval of straightforward proposals
21 October	18,846	Further alignment amendments, and the seventh agent added to scope
22 October	21,964	Pending-skill review and email procedure added

Each of the seven recorded amendments was a reasonable response to a real requirement, and each was approved. By 22 October the document ran to 390 lines in seven sections, with a 26-line front matter block, a 22-line preamble recording its own amendment history, separate route descriptions for background-review candidates and deliberate proposals that largely repeated each other, and a notification-ownership section that restated the final-sign-off email format twice.

The trigger for this work was a set of three pending skill changes the agents had recommended approving. Asked what they would actually improve, the SAA found that their value was fewer mistakes and less repeated investigation rather than any measurable efficiency, and that they would add substantial text. The principal objected that revisions of this kind lead to growth: a single line gets replaced with many lines in the name of clarity, and as the revisions accumulate the instructions become large enough to defeat the agent's attention. Looking for the procedure that should have caught this, he reached the convention itself and described it as "22k of spaghetti code disguised as governance".

He had already asked the SOA to condense it. The result was about 9,000 bytes, less than half the original, and in his assessment still abstruse. Condensation by an agent produced a shorter document that an agent could follow. It did not produce one the principal could. That is why the method that follows starts from nothing rather than from the existing text.

5. Method

The rebuild proceeded by the principal posing one question at a time and the SAA drafting the answer, with each element agreed before the next was considered. It is reported here in the order it occurred, because the order is part of the method.

5.1 Purpose first

The principal asked for three lines: the purpose of the document, when it should be used, and the result required. The agent's first purpose line, "Ensure lasting changes to agent instructions and working methods improve the work without adding unnecessary complexity", was rejected as describing a value rather than a function. The principal asked instead what would cause an agent to use the document.

Two further attempts followed. One framed the purpose around guiding an agent from proposal to verified implementation; the next tied it to the main sources of proposals, the self-improvement reviews and the harness's background reviewer. The principal rejected both: the second because most, but not all, proposals come from those sources, and "the purpose must state the exact purpose and nothing else." The agreed sentence, after one further tightening proposed by the agent, was:

The purpose of this skill is to assess new or changed skills and processes, and recommend whether to approve, revise or reject them.

The principal then asked whether the "when to use" and "required result" lines were still needed. Both were dropped. The purpose sentence already identifies the task that triggers the document, and "recommend whether to approve, revise or reject them" already states its result. A separate line for each would have repeated it.

5.2 A minimal rule set

The principal proposed five rules governing any change: reject it if it does not improve the work; no overlap or conflict with other skills or processes; make it as concise as possible; make it as simple as possible; and only increase the size of an existing rule if there is no other way to achieve the outcome. He noted that the document was being rebuilt under the same rules it would impose on every other proposal.

The agent kept all five and proposed three adjustments. Improvement must be demonstrated, not merely claimed. Overlap should mean duplicated instructions, not two documents legitimately pointing to the same common procedure. Size should be measured across the affected instructions as a whole, since otherwise an author could avoid enlarging one rule by adding another or moving the expansion into a reference file. It kept conciseness and simplicity as separate rules on the ground that a short instruction can still prescribe an unnecessarily complicated method. The agreed rules are in Appendix A.

5.3 Only what a reader needs to act

Asked whether anything else was needed to convey how assessment is done, the agent added one sentence: compare the exact proposal with existing skills and processes, apply the rules, and give a recommendation with brief reasons. The rules said what makes a proposal acceptable; this sentence said what to do with them.

The approval and implementation section was drafted next and was initially too compressed. Its reference to independent review hid the estate's three-way process, in which the author proposes, an independent agent reviews, the author reconciles, and the principal decides. The principal asked where that process appeared, and the section was redrafted as five numbered steps naming each party.

He then asked whether the author is always the agent that implements the change. It is not: an agent may propose a change to a skill another agent maintains, in which case the owner applies it. The draft kept that distinction.

A short governance section set the scope, the limits of approval and where the record is kept. Asked whether the document needed header fields for version, owner, author and maintainer, the agent proposed title, status, version and owner only. Authorship belongs in the change record, and maintenance belongs to the owner unless delegated, so neither earns a field of its own.

5.4 Check what the replacement would break

With a complete draft in hand, the principal asked: "If we were to use that as a drop in replacement for durable-agent-changes.md, what would break?"

The agent inspected the current document, the pointers to it in every agent's governing file, the seven weekly review jobs and the scripts that support them. It reported six findings:

1. Stale references. The weekly review jobs, a runbook and an internal messaging script referred to sections of the old document by name and number. The file would still be found, but the directions in it would point to sections that no longer existed.
2. A policy change by omission. The old document let the principal approve a straightforward proposal directly, reserving independent review for complex, uncertain or contested ones. The draft required independent review for everything. Nobody had intended that change. It arose because the simplified text described only the reviewed route.
3. Assessment and approval not distinguished. Read literally, the draft could send every weekly candidate, including ones the agent recommended rejecting, through independent review before the principal saw it.
4. Reporting detail removed without a pointer. The pending-item email format and final-sign-off notification were absent. They still existed in the weekly review procedure, its prompts and its code, so they would not have stopped working, but the relationship between the new document and that procedure would have been unstated.
5. Ambiguity about runtime changes. Agents were directed to the document before changing consequential runtime configuration. The draft did not distinguish routine configuration work from changes to governing instructions.
6. Status. The header still said draft.

It also reported what would not break: the pointers in agents' governing files would still find the file, no harness, schedule or permission would change, and historical approval commentary did not need to remain in the active text because it was preserved in the change records.

The second finding is the most important result of the check. Simplification is a rewrite, and a rewrite can change policy without anyone deciding to. The rebuilt draft was clearer than the original, and in one place it had a different meaning from it.

5.5 Repair, and decide policy deliberately

The principal asked the agent to apply all the proposed remedies, and made two policy decisions of his own. He wanted to keep the right to waive independent review and approve a change himself: "As long as I am the last reviewer, I am not concerned with what goes on behind the scenes to get there, however sometimes I want a change right away." And he ruled that an agent whose own assessment recommends rejection should stop there and not seek a second opinion.

The revised draft therefore states the waiver explicitly, stops work on a rejection recommendation, separates weekly assessment from the review of a proposal being advanced, directs routine configuration work to existing authority, points to the weekly review procedure for reporting formats rather than repeating them, and requires that affected references be updated as part of implementing any replacement.

Policy changed in two places, and both changes were deliberate decisions by the principal rather than side effects of shortening the text. That is the distinction the replacement check exists to protect.

5.6 Apply and verify

On the principal's instruction, the agent preserved the original as a recovery copy, replaced the document, marked it active and recorded the decision. Its first adoption record stated plainly that the stale references found in section 5.4 had not yet been updated. They were aligned later the same day: the weekly review procedure and its prompt template, all seven agents' saved review-job prompts, the shared-skills runbook and the internal messaging script. The SAA confirmed that each job definition changed only as intended, and the messaging script's regression suite passed all 13 of its tests.

6. Result

	Before	After
Size	21,964 bytes	2,754 bytes
Lines	390	44
Front matter and amendment history	48 lines	5 lines
Sections	7, with nested subsections	Purpose, rules, three short procedural sections
Routes described	Separate background-candidate and deliberate-proposal routes, a direct route and a reviewed route	One five-step route with an explicit waiver
Reporting formats	Specified in full	Pointer to the weekly review procedure

The replacement is 87.5 per cent smaller than the original and about 30 per cent of the size of the agent-condensed version. Its full text is reproduced in Appendix A so that readers can judge its legibility for themselves.

The claimed result is legibility. The principal can read the document from top to bottom, follow its logic and state what it requires. No claim is made that agents follow it more accurately than they followed the original, or that sessions consume fewer tokens because of it. Neither has been measured.

7. Making the method repeatable

Before going further, the principal asked for a skill that would apply the same process to any other skill or process, with the intention of using it over time on every large instruction file in the estate. The SAA drafted it, the SOA reviewed it and recommended approval as written, and the principal approved and installed it the same day. That first version was 2,485 bytes and described the process as six stages: establish the result, draft from the purpose, consolidate, check replacement impact, resolve the findings, and apply and verify, followed by a completion section specifying what to report.

On rereading it the next day, the principal identified a gap. The skill described the process that had been followed, but it did not prescribe the form that process had produced. The convention had been rebuilt as a one-line statement of what it needed to achieve, a minimal rule set of one line per rule, and a short governance section saying what it granted and what it did not. Although the first version of the skill broadly followed that shape itself, nowhere did it require the skills it simplified to take the same form. Modelling a structure is not the same as instructing it.

The SAA agreed and redrafted the skill to state the form as rules. The SOA reviewed the redraft and again recommended approval unchanged. It noted that mandatory before-and-after size reporting, the enumerated consumer checklist and the prescribed completion report were being removed rather than preserved, and judged that an acceptable reduction, since size is not the acceptance criterion and recovery, review, approval, reference updates and verification already belong to the change convention the skill points to. The principal approved the replacement, and it was installed with a recovery copy of the first version retained. The installed skill is 1,350 bytes, 46 per cent smaller than its first version. Its body reads in full:

Simplify Instructions

Reduce a skill or documented process to the simplest instructions sufficient to achieve its intended result.

Rules

• Rebuild from the intended result rather than trim the existing structure.
• Begin with one plain sentence stating what the skill or process must achieve.
• Give the minimum sufficient rules in logical order, one line per rule.
• End with one or two lines of governance stating what the skill grants and what it does not.
• Add detail only where its absence would leave a necessary instruction unclear or incomplete.
• Remove repetition, obsolete instructions and incident history; reference existing procedures rather than duplicate them or relocate unnecessary text.
• Check the draft against the original requirements, preserving necessary behaviour and safeguards and identifying any proposed policy change.
• Check affected references and workflows, and include necessary consequential changes in the proposal.

Governance

Follow [path to]/durable-agent-changes.md for assessment, review, approval, implementation and verification. This skill guides simplification; it does not itself authorise changes or extend existing authority.

The first rule carries the lesson discussed in section 8, that rebuilding is not the same as trimming. The next three rules state the form. The fifth is the exception that allowed the convention its numbered review and implementation steps, which were added back because the one-line version hid the distinct roles of author, reviewer and approver. The final two rules carry forward the replacement check from section 5.4, the step that caught the unintended policy change. The governance line refers to the rebuilt convention, which is reproduced in Appendix A.

With the revised skill installed, the principal started the next stage later that day: an inventory of the estate's 161 non-harness skills, ranked by size from the largest down, to be worked through one at a time.

8. Discussion

Why condensation was not enough. The agent-condensed version removed more than half the text and was still hard to follow. A plausible explanation is that condensing an existing document preserves its structure, its qualifications and its assumptions about what a reader already knows, and makes them denser. Rebuilding from purpose discards the structure and reinstates only what is needed. This report has one instance of each approach and cannot establish the general case, but the difference in outcome was large: about 9,000 bytes and still abstruse, against 2,754 bytes that the principal can read.

The human as acceptance test. The rebuild was driven by the principal's questions, and most of its decisive moments were his: rejecting a purpose that described a value, asking whether a line was still needed, asking where the three-way process had gone, asking what would break. None of those questions required technical knowledge of the harness. They required a reader willing to say that he could not follow something and to treat that as a defect in the text.

Simplification needs its own impact check. The draft was a better document than the original and, until the check, a different policy. Shortening governing text is precisely the kind of change in which a safeguard or route can vanish without anyone noticing, which is the failure Corrections Consolidate recorded when a direct replacement silently removed a clause an independent review had insisted on. Asking what would break, and inspecting the consumers rather than only the text, is what caught it here.

Prescribe the form, not only the process. The first version of the reusable skill described the steps that produced a legible document but left the shape of the result to whoever applied it. An agent following it could have completed every step and still returned a document in its original structure, only shorter. Stating the target form as rules (one purpose sentence, one-line rules, a short governance section, and detail only where its absence would leave an instruction unclear) gives both the agent and the reviewing human a concrete standard to check the result against.

Subtraction as a change-control outcome. The rebuilt rules allow total instruction size to grow only when the outcome cannot be achieved by replacing, consolidating or removing existing text. The convention now applies that test to every proposal, including any future amendment to itself.

9. Limits

This is one document in one estate, rebuilt with one principal over two days, followed by one revision of the reusable skill the next day. Legibility was judged by the principal himself, which is the criterion the work set out to meet but is not an independent measure. No controlled comparison of agent behaviour or token consumption before and after has been made. Some detail was moved rather than removed: reporting formats now live in the weekly review procedure the convention points to, which is itself among the documents to be assessed under the new method. The reusable skill in section 7 has been reviewed, revised into its own prescribed form and installed. At the time of writing it has not yet been applied to another skill.

10. Related work

OpenAI's developer guidance for its GPT-6 Astra model reaches a compatible conclusion from the agent side: accumulated skills and instruction files should be revisited with each model generation, descriptions shortened, multi-workflow skills turned into minimal routers, and every standing instruction questioned for whether it is still needed (Rethinking skills and prompts for GPT-6 Astra). It ends by suggesting that the review need not be manual, and that the model can be asked to audit the instructions itself. The case here suggests a qualification. An agent audit can make instructions shorter, but whether they are clear enough to govern is a judgement for the human accountable for them.

Corrections Consolidate governs when a failure may change governing text. Human in Command governs whether the principal can understand the library as a whole. This report addresses whether an individual document within it can be understood, and provides a procedure for bringing documents to that standard one at a time.

11. Conclusion

A change process that approves each amendment on its merits will not, by itself, keep governing text small. The convention examined here was written to resist accumulation and still grew by two-thirds in five weeks, through amendments that were each sound. Rebuilding it from a single purpose sentence, adding only what a reader needs to act, checking what the replacement would break and repairing the findings before adoption reduced it from 21,964 bytes to 2,754, and produced a document its human principal can read.

Practical takeaway

For anyone maintaining instructions for an agent harness:

1. Reread your governing documents as their approver, not their author. If you cannot follow one from top to bottom, treat that as a defect, whatever an agent can make of it.
2. Rebuild from the purpose rather than condensing the text. Write one sentence saying what the document is for, then add back only what a reader needs to act on it.
3. Ask what the replacement would break, and inspect its consumers. Prompts, scheduled jobs, scripts and cross-references depend on headings and section numbers, and simplified text can change policy by leaving out a route nobody meant to remove.
4. Make every policy change a decision. Where the rebuild changes what the document requires, say so and have the accountable human decide it.
5. Turn the method into a procedure that prescribes the result. Describing the steps is not enough. State the form you want the rebuilt document to take, so the next one is held to the same standard, and write the procedure in that form itself.

---

Appendix A: The rebuilt convention

The complete active text of durable-agent-changes.md, the convention referred to in section 5.4 and in the governance line of the skill in section 7, reproduced as adopted. The front matter is omitted, one internal path has been abbreviated, and names have been replaced by roles in square brackets: the human principal, the SAA and the SOA.

Assessing Skill and Process Changes

The purpose of this skill is to assess new or changed skills and processes, and recommend whether to approve, revise or reject them.

Compare the exact proposal with existing skills and processes, apply the following rules, and give a recommendation with brief reasons.

Rules

• Reject proposals that do not demonstrably improve the work.
• Reuse existing instructions rather than duplicate them; resolve conflicts before approval.
• Use only the words needed to convey the instruction clearly.
• Use the simplest method that achieves the intended outcome.
• Increase the total instruction size only when the outcome cannot be achieved by replacing, consolidating or removing existing text.

Assessment, review and approval

1. The author assesses the candidate against these rules. If the recommendation is reject, stop work on it; do not seek another opinion unless [the human principal] requests it.
2. For a candidate worth pursuing, the author prepares the exact proposal and identifies what it replaces.
3. An independent reviewer assesses the proposal: [the SAA] reviews other agents' proposals; [the SOA] reviews [the SAA]'s. If the designated reviewer helped author it, [the human principal] chooses another reviewer.
4. The author considers the review and presents [the human principal] with the final proposal, recommendation and brief reasons for accepting or rejecting the reviewer's advice.
5. [The human principal] makes the final decision. He may waive independent review and approve a change directly at his discretion. Only the exact approved proposal may be applied.

Implementation

The responsible owner, or an agent authorised to act for them:

1. Preserves a recovery copy and applies the approved change.
2. Updates affected references and instructions so they agree with the replacement.
3. Verifies the intended result and reports the outcome.

Governance

• This procedure covers skills, reusable working methods and governing instructions, wherever recorded. Factual updates and routine configuration or operational work follow existing authority.
• Approval applies only to the stated change; it does not override other authority or approval requirements.
• Keep the proposal, review where required, [the human principal]'s decision and implementation result together in the existing task or change record.
• Weekly assessments report candidates; they do not initiate independent review or implementation. A rejection recommendation stops further work, but does not remove a pending item from reporting before [the human principal]'s decision.
• For pending-item reports and final-sign-off notifications, follow [path to]/README.md.

References

• Geng, Y., Li, H., Mu, H., Han, X., Baldwin, T., Abend, O., Hovy, E. and Frermann, L. (2025). Control Illusion: The Failure of Instruction Hierarchies in Large Language Models. AAAI-26. arXiv:2502.15851. https://arxiv.org/abs/2502.15851
• Hong, K., Troynikov, A. and Huber, J. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma technical report. https://www.trychroma.com/research/context-rot
• Jaroslawicz, D., Whiting, B., Shah, P. and Maamari, K. (2025). How Many Instructions Can LLMs Follow at Once? arXiv:2507.11538. https://arxiv.org/abs/2507.11538
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. and Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12:157-173. https://aclanthology.org/2024.tacl-1.9/
• Lu, D., Gunukula, S., Agashe, S., Liu, T. and Wang, X. E. (2026). ContextRotBench: Measuring Long-Horizon Degradation in Coding Agents. OpenReview. https://openreview.net/forum?id=DiZ67nkfay
• Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S. and Schütze, H. (2025). NoLiMa: Long-Context Evaluation Beyond Literal Matching. Proceedings of ICML 2025. arXiv:2502.05167. https://arxiv.org/abs/2502.05167
• OpenAI Developers. Rethinking skills and prompts for GPT-6 Astra. https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra
• Waddington, S. (2026). Corrections Consolidate: Why Every Agent Mistake Should Not Create Another Rule. https://onet.com.au/papers/corrections-consolidate/ DOI 10.5281/zenodo.23719418
• Waddington, S. (2026). Human in Command: Governability Before Review in a Growing Agent Skills Library. https://onet.com.au/papers/human-in-command/ DOI 10.5281/zenodo.23719654