A picture shared by engineer Claude accurately describes the three most common problems of long-task agents: the inability to keep track of the state, the inability to estimate the workload, and the inability to evaluate its own output. Many people will go through a similar process when using Agent seriously for the first time. The first ten minutes are amazing. It can read code, change files, run commands, and explain itself what to do next. After half an hour I started to feel uneasy. It's still executing, but you're no longer sure it remembers its original goal. Two hours later, the problem became more obvious: it had done a lot of things, changed a lot of files, and ran a lot of verifications, but the final results submitted did not stand up to closer inspection. Engineer Claude’s picture breaks down this problem very accurately: the Agent will lose status, misjudge the workload, and overestimate the quality of its output. Putting these three problems together will form the most common out-of-control link in long tasks: the context is getting dirty, the plan is getting more and more empty, and the verification is getting shallower. In the end, the Agent did not suddenly become stupid, but just went further and further away in a system that lacked a control loop. So this article won’t talk about how to write a more “smart” prompt. Let’s talk about a more engineering question: If you want Agent to handle long tasks stably, what at least control layers must be added to the system? These three layers can be regarded as full-text indexes. Context refers to the scene, Planning refers to the boundary, and Verification refers to the evidence. If any one layer comes loose, the other two layers will be dragged down. State loss: The Agent's workbench will become more and more cluttered. Many Agent long-term tasks have problems, and the earliest signal that appears is usually not in the code, but in the state. It starts out knowing what the target is and what files it has just read. As conversations become longer, tool calls increase, error messages pile up, and temporary judgments are repeatedly overridden, the noise in the context begins to increase. In the second half, it is still working, but it is no longer like moving along the original task, but more like finding a seemingly reasonable exit in the current context. This is the real bounds of the context window. The context window is often understood as "how much the model can remember." This understanding is too optimistic. For the Agent, context is more like a workbench. Task instructions, file fragments, command output, error logs, user additions, and the model's own intermediate judgments are all piled on this table. It is certainly useful to make the table larger, but no matter how big the table is, it does not mean that it can automatically organize materials. Anthropic puts it very directly in Claude Code best practices: the context window will fill up quickly, and the fuller the window, the easier it is for the model to forget early instructions or make mistakes. It also recommends giving Claude clear means of verification, such as tests, screenshots, and expected output, as this is a high-leverage action that improves the quality of the results. This experience is very obvious in the long-term Agent. Many deviations occur in steps 40 and 80, after the Agent has accumulated enough context that "seems relevant but actually interferes". Even more troublesome is the state rupture between sessions. If a task is not completed, change the session and continue. The Agent seems to be able to connect, but what it connects is often only a compressed summary, leaving only the compressed scene. Which decisions have been confirmed, which plans have been rejected, which files have just been changed but have not been verified, and which failed paths should not be tried again. If this information is not written into the external state, it can easily be lost in the next round. Therefore, the production-level Agent cannot put all the state in the context. The minimum usable state layer must have at least a few types of things: If these things only stay in the conversation, the Agent will start to work based on impressions once the context becomes dirty. Write it into progress.md, task ledger, trace log, issue comment or database to have a chance of being stably read back in the next round. This is also the first level of value of many harness designs: so that the model does not need to rely on on-the-spot memory. A good Agent system will actively separate "working status" and "reasoning context". Only the materials needed for the current step are placed in the context, and the long-term status is placed externally. Each time it enters a new phase, the Agent first reads the status before continuing execution; each time it completes a phase, the Agent first writes the status and then cleans up the context. This sounds like a checkpoint in a traditional project. Put it in Agent, it is more like an anchor point to prevent task drift. Without this anchor, a long task can easily turn into a context gamble: the more you write in the front, the harder it will be to judge what it will remember later. Planning distortion: Agent often does not judge how big the problem is. The status problem is half solved, but long tasks will still overturn. Another, more insidious type of failure comes from a sense of task size. When a human engineer receives a request, he will subconsciously judge several things: Is this a small change? Will it affect the data structure? Has there been any migration? Are there any compatibility issues? What are the acceptance criteria? Is this thing suitable to be done all at once, or should it be broken into several stages? Agents often do not have this scale. If you ask it to "change the document generation process", it may scan the entire content system. If you ask it to "make a usable demo", it may only have an empty UI shell. If you ask it to "fix a bug", it may easily refactor half of the module. It seems that they are working hard and the direction is reasonable, but the boundaries of the tasks are beginning to loosen. This type of problem will be magnified in long tasks. In the beginning, Agent tends to one-shot complete projects. It will make a big plan, write down the architecture, code, testing, documentation, and deployment, and then start from the first step. The first few steps seem to go smoothly, but by the time most of the context is used up, the really difficult part has not yet been touched. In the second half, it began to shrink the scope, skipping details, and finally ended with the words "the core function has been completed." The other situation is just the opposite. When it sees partial progress, it regards partial completion as overall completion. If the page can be opened, it means that the product is available; if the interface returns 200, it means that the function has passed; if the unit test has passed, it means that there is no problem end-to-end. Many Agent failures get stuck at an earlier point: deciding "enough is enough" too quickly. This is the problem with the sense of task size. What the planning layer has to solve is very specific: let the Agent form several hard constraints. What are the deliverables of this mission? What content is explicitly not done? What are the completion criteria for each stage? How much context, how many tool calls, and how much time is allowed to be consumed in the current phase? If you find that the range has become larger halfway through, when should you stop and re-estimate? If the verification fails, is it allowed to continue to expand the implementation, or must the current problem be fixed first? Without these constraints, a plan is just a prologue. The agent will constantly reinterpret the plan during execution, eventually delivering something that is further and further away from the original goal. I now prefer to divide Agent planning into two levels. The first level is task segmentation. It answers "How should this thing be broken down?" Here, large tasks need to be broken down into small stages that can be independently verified. Each stage has clear input, output, and acceptance methods. The second level is the operating budget. It answers "What is the maximum extent of this section?" Including max turns, token budget, tool call budget, time limit, number of failed retries, and conditions that trigger manual confirmation. If one of these two layers is missing, the Agent will easily lose control. With only task segmentation and no running budget, the Agent may explore infinitely in a subtask. There is only a running budget and no task division. When the limit is approaching, the Agent will randomly find a version that can be delivered and end the work. Anthropic can already see this direction in the idea of long task harness: first, the initializer agent sets up the environment, lists the features, and writes them into the progress file; The subsequent coding agent only processes one feature per session, and writes the status back after completion. Anthropic describes this problem as the challenge of making continuous progress across multiple context windows. Each new session needs to pick up where the previous session left off. A truly useful plan in engineering is usually not as simple as "I'm going to do A, B, C." It's closer to a construction sheet: just what to do at this stage. What verification will be used after finishing it? How to rollback or retry if verification fails. In what situations do you have to stop and ask someone. Which state should be read in the next stage to continue. Agent needs boundaries more and does not need to encourage delegation of authority. The clearer the boundary, the more it resembles a schedulable execution unit. The blurr the boundaries, the more it resembles a diligent but unreliable free-play system. Verification failure: The most dangerous ability of the Agent is to make things that are not done right appear to be done. The status will be lost and the plan will drift, but these two things can usually be seen by others. Verification failure is more troublesome. Agent is very good at giving his work a decent ending. It will say "Implementation Completed" "Basic Verification Passed" "Core Process OK". If you continue to ask, it can also explain the verification steps, list the changed files, and add a risk statement. The problem is that these words sometimes just wrap up the conclusion for a very shallow verification. The most common case is curl-only verification. If the interface can return 200, the Agent will say that the function is available. It didn't click on the page, it didn't go through the real user path, it didn't look at the browser console, it didn't check whether the data was actually written, and it didn't confirm how the error status was displayed. This problem is especially obvious when doing web applications. The existence of a button does not mean that the button can be used. Just because the page can be opened does not mean that the main process has run through. Passing the test does not mean that the user will not be stuck in the loading state. If the Agent only verifies on the command line, it is easy to misjudge "the system is responding" as "the product is usable". The second case is stub escape. When Agent achieves complex functions, it will first write a simplified version. The action itself is fine. In projects, mocks, stubs, and placeholders are often used to build processes. The problem lies in forgetting to come back to it later, or packaging this temporary implementation into a stage achievement. For example: The payment process only prints logs and does not have a real state machine. TODO is written in the permission judgment, but the page has already released the entry. RAG only returns fixed examples, but says "the retrieval link has been opened". The chart data is hard-coded, but the dashboard is said to be completed. The E2E test only tests happy paths, not failed paths. The third situation is self-rating too high. When the Agent evaluates its own output, it often finds problems but downgrades them. It will say "The current implementation meets the core requirements and can be optimized in the future." This sentence is very common in manual review, but be careful when putting it in Agent. Many key flaws are eliminated by this sentence. The real problem is that the Agent does not have a sufficiently independent evaluation position. The Agent who writes the code naturally hopes that the task will converge. It has invested in context, tool calls, and multiple rounds of inference, and is approaching limits. In the second half of the process, it will tend to interpret uncertain issues as acceptable risks, interpret unfinished parts as subsequent optimization, and interpret shallow verification as basically passed. This is also very similar to human engineers. The code you write and review yourself is usually not strict enough. The difference is that human engineers know that there are CI, QA, code reviews, and online monitoring in the team. If the Agent does not have these external mechanisms, it will declare itself qualified. Therefore, the verification layer cannot rely solely on the oral reports of the Agent. An Agent system that can run long tasks requires at least three types of verification: The first type is machine verification. If you can use tools to judge, don't leave it to models. Testing, type checking, lint, build, schema validation, data reconciliation, screenshot diff, accessibility check, and log scanning all fall into this category. The second category is environmental verification. The agent needs to walk through a real or close to real environment. Web applications require a browser, not just curl. The data task needs to read back the results, not just the success of the write command. When publishing a document, you need to fetch it back to check, not just the API returns OK. The third category is independent evaluation. Generators and evaluators should be separated. The Planner splits the tasks, the Generator executes them, and the Evaluator checks them based on the rubric. Evaluator is not responsible for comforting Generator, nor is it responsible for explaining it. It only answers a few hard questions: Is the need really met? Is the critical path really run through? Is there a stub or TODO wrapped into the delivery? Are failed paths handled? Is the verification evidence enough? If it’s not enough, what should I practice in the next round? This is also the direction that Anthropic emphasizes in the long-running application development harness: Let the independent evaluator use Playwright to operate the application like a real user, test UI functions, API endpoints and database status, and avoid letting the agent that generates the code itself say "I think it is OK". This design is very important. It turns "done" from a sentence into a chain of evidence. Changing the code is only the first step, and passing the test is only the second step. Only when the real path is run, the evidence can be played back, and the evaluator agrees can it be delivered. What many Agent products currently lack is this chain of evidence. They can execute, interpret, generate daily reports, and write beautiful logs. But once you ask, "How do you know this is really the right thing to do?" the answer starts to become vague. What production-level agents should be most wary of is misjudgment of success by the system. Failure can be retried, rolled back, and upgraded. The really expensive thing is: it fails, but the system thinks it succeeds. The five-layer architecture of engineered Agent. If you look at the previous three issues together, you will find that Agent loss of control is often not a single point of failure. Without precipitation in the status layer, the planning layer can only guess the task progress based on the current context. The planning layer has no boundaries, and the execution layer will continue to expand its scope. If the verification layer is not strong enough, the Agent will package partial success into overall completion. In the absence of a supervisory layer, all risks will flow all the way to the end, and it will be up to the users themselves. Therefore, the production-level Agent cannot only look at the model call chain. A more stable structure would have at least five floors.
- State layer: Let the task have a recoverable scene. The state layer is responsible for saving things that the Agent cannot lose. Including task goals, current progress, stage products, decision records, file changes, verification results, blocking points, and manual confirmation records. It can be progress.md, a database, a trace store, an issue comment, or an artifact ledger. The form is not important, the key is that it can be read back, can be continued, and can be audited. Without a state layer, the Agent's long tasks become one-off conversations. The conversation was cut off, and so was the scene. After context compression, many details remain only a vague summary. The next round of Agent seems to be continuing, but part of the engineering site has actually been lost. 2 Planning layer: compress large tasks into schedulable small tasks. The planning layer is responsible for breaking down user goals into stages, dependencies, budgets and stopping conditions. The plan here cannot stop at a nice-looking checklist. It is more like the job spec in the scheduling system: what to do in the current stage, what is the input, what is the output, what verification is used, how long it is allowed to run at most, stops after a few failures, and which operations require manual confirmation. A good planning layer will limit the agent's degree of freedom. It allows the Agent to handle only one task at a time that is small enough and verifiable enough. Doing so sacrifices a bit of the illusion of "auto-bottom", but in exchange for higher recovery capabilities. If a certain stage fails, you can rerun this stage without having to mess up the entire long task. 3 Execution layer: Tool calls are only part of it. The execution layer is responsible for turning plans into actual operations. Reading files, changing code, running tests, opening browsers, checking logs, adjusting APIs, writing documents, and generating images are all on this layer. Many agent systems make the execution layer very lively, with many tools, great permissions, and fast actions. However, the status and verification before and after cannot keep up, and in the end it becomes more dangerous. The key to the execution layer is not the number of tools, but the ability to return to the task state every time a tool is called. After a command is run, the output must enter the state. After a file has been modified, the change needs to enter the status. When an API call is successful, the status must be entered when the result is read back. If a tool call only flashes in context, it will soon be drowned out by the subsequent noise. 4 Verification layer: Turn completion into an evidence chain The verification layer is responsible for answering a question: How do you know that this thing is really done right? At this level, external evidence should be used as much as possible. Test results, browser screenshots, database readbacks, logs, traces, diffs, rubric scores, and manual reviews are all more reliable than the Agent itself saying "completed." The validation layer is best separated from the execution layer. When the same Agent evaluates himself after completing the task, it is easy to interpret the risk as acceptable. A standalone evaluator would be much stricter. It does not need to understand the entire mental activity of the Generator, it only needs to check the product against acceptance criteria. The harder this layer is, the less users need to be the last QA themselves. 5 Supervision layer: Controls permissions, costs, and upgrade paths. The supervisory layer is responsible for when Agent can continue and when it must stop. This includes permission control, budget control, loop budget, max turns, dangerous operation confirmation, pre-release confirmation, failed upgrade, human takeover, and rollback strategy. Many Agent workflows pursue automation on the surface, but what they actually lack is this layer of brakes. A mature supervisory layer will not frequently interrupt normal tasks, nor will it allow Agents to perform freely. It only intervenes at a few key points: The scope of the mission is expanded. The budget is nearing its upper limit. Authentication fails continuously. Operations involve deletion, publishing, permissions, payment, and production data. Agent finds himself unable to judge. The results impact real users. The value of the supervisory layer is that it takes "whether to continue" out of the on-the-spot judgment of the model and turns it into system rules. When these five layers are combined, the Agent changes from a model that calls tools to a restorable, verifiable, and stoppable execution system. Models still matter. It determines single-step reasoning quality, code quality, tool selection capabilities, and exception handling capabilities. But once the task becomes longer, the stability is often determined by the layers outside the model: whether the state has settled, whether the plan has boundaries, whether the execution is recorded, whether there is evidence for verification, and whether there are hard stopping conditions for supervision. Stronger models will change the harness, but will not cancel it. When the model becomes stronger, many outer designs will indeed change. Tasks that previously had to be broken into 5 sprints may become coherent on their own under the new model. Where previously it was necessary to write very detailed intermediate plans, the new model can make sound judgments with fewer prompts. In the past, special sub-Agents had to be used to look up information. The new model may be able to complete it in a longer context. This is normal. Behind every harness component, there is a judgment: the current model is not stable enough in this matter, so the system needs to add a layer. As the model's capabilities improve, this judgment should be retested. Keeping an outdated harness in place will make the system slower, heavier, and create new failure points. Anthropic also mentioned in the discussion of long-running harness that the harness component encodes assumptions about the model's capability boundaries. These assumptions need to be re-stress tested after the model is updated. This point is important. It reminds us that harness cannot be a religion. The more layers you have, the more professional you are, and the more roles you have, the more advanced you are. A good Agent architecture should be thinned as the model capabilities change, removing the shell that is no longer needed and leaving the truly valuable control points. But there are a few categories of things that are difficult to completely eat up with model capabilities. The first category is external states. Models can read longer contexts, but state in real tasks does not exist only in context. File systems change, databases change, API states change, browser pages change, users change their needs elsewhere, and permissions and costs change. For Agent to continue working, it needs a state layer that can be aligned with the external world. The second category is external validation. Models can be better at reflecting and writing tests. But "Has the page been actually clicked?" "Has it been written into the database?" "Can the published document be opened?" "Is the user path stuck?" These questions require environmental feedback. Just relying on the model to think about it once will always leave you short of one layer of evidence. The third category is authority and responsibility. Deleting files, publishing content, modifying permissions, touching production data, and spending money to call external services cannot all be handed over just because the model is smarter. Clear rules, audit logs, and human confirmation are needed here. The model is responsible for judgment and the system is responsible for authorization. The fourth category is cost. Long-task agents can easily turn tokens, tool calls, browser sessions, and external API calls into hidden costs. The stronger the model, the more expensive a single call is and the more budget routing, max turns, timeout and circuit breaker are required. Otherwise the system will look automatic and the billing will be automatic. Therefore, the changes brought about by stronger models are to re-divide the architecture. Architecture will not disappear. The model is responsible for an increasing number of semantic judgments, code generation, exception handling, and local planning. The harness is responsible for putting these capabilities into processes that are observable, recoverable, verifiable, and stoppable. There are two extremes that should be avoided. One is the superstitious model. Once the model is upgraded, the status, verification, permissions, and budget are all handed over to it for on-the-spot judgment. Short demos are beautiful, but long tasks can easily lead to minefields. The other is the fetish harness. What the model can already do stably is forced to be broken down into complex processes. In the end, the system is slow, expensive, and difficult to maintain, and errors are still hidden in the orchestration layer. A better approach is to periodically ask the question: Is this harness still solving real problems? If the answer is yes, keep it and make it more observable. If the answer is no, delete it and let the model do it directly. The work of the agent architect should not wrap the model more and more thickly. More precisely, it is to continuously identify the current capability boundaries of the model, and then only add necessary engineering controls outside the boundaries. The minimum engineering closed loop of long-task Agent It is easy to talk about the architecture in vain. Truly useful Agent design ultimately comes down to some very specific actions: how the task comes in, where the status is written, who will verify it, when to stop, and how to recover after failure. I would give priority to putting the following modes into any long-task Agent system. Spec-first: Write the construction order first, and then let the Agent do it. Do not directly ask the Agent to "help me complete this function." First let it generate a short spec, which only writes a few things: Goal: What to deliver this time. Non-goals: What is explicitly not to be done. Constraints: technology stack, style, permissions, budget, time. Acceptance: How to judge completion. Risks: Where scope may expand. This spec does not need to be long. Half a page is enough. The key is to let the task solidify before execution. Later, if the Agent wants to expand the scope, bypass verification, or finish work early, it can compare it with the spec. Plan gate: The plan first passes the level, and then enters automatic execution. Let the Agent make the plan first, and do not execute it immediately. The plan must include: Phase breakdown. Deliverables for each stage. Verification method at each stage. Files or systems expected to be encountered. Stop condition. Operations that require manual confirmation. This step is most suitable for people to participate. You don't need to review every line of code, but you should review the way tasks are broken down. If you disassemble it wrongly, the faster you run behind you, the farther you will go. Many agents lost control, and the mistakes started from the first plan: the boundaries were lost at that time. Progress ledger: Write status at each stage. Don’t rely solely on dialogue to survive long tasks. Each time a stage is completed, the Agent writes a progress ledger. It can be Markdown, JSON, or issue comment. Just keep the format simple: The value of this document lies in continuation. In the next round, the Agent reads the ledger first and then the code. People can also glance at the ledger and quickly know where it is. Even if the context is full, the session is disconnected, or the model is changed, it can be retrieved. Independent evaluator: Let another role approve the generator. Don't be the final judge. You can use another Agent, or you can use scripts, tests, CI, Playwright, or manual review. The key is that the evaluation criteria should be independent of the execution process. The output of Evaluator should not be written as "Overall good, there are some suggestions." Such words are useless. A better format is: The Evaluator must have the authority to evaluate FAIL. An evaluator without failure rights is just a summarizer. Browser-level verification: Web products must go through the Web task, curl and unit testing are not enough. At least let the Agent use the browser to walk through the critical path: whether the page can be opened. Whether the control can be clicked. Whether the form can be submitted. Whether the data can be displayed. Is the error status normal? Does the console report any errors? Are there any obvious layout issues on the mobile side? If it’s a visual-related task, take screenshots as well. Screenshots are cheap evidence. It can help you find many "invisible command line" problems. Stop condition: Let the Agent know when to stop. The Agent needs a clear stop condition. Common stopping points include: Two consecutive verification failures. The scope of tasks has been significantly expanded. You need to delete, publish, change permissions, spend money, and touch production data. The current stage is over budget. Encountered multiple possible options but unable to decide which one to choose. Critical dependencies are unavailable. The goals given by users conflict with each other. Stopping is normal. If you lose the boundary and continue running, the risk is even greater. A good Agent workflow should allow it to say: "I need human judgment now." Rollback path: Each stage must be able to return to the Agent. The stronger the automation, the more rollback path is needed. Code tasks require at least git diff. Data tasks must have dry-run, backup, and row count. Publishing tasks require drafting, previewing, and readback verification. Configuration tasks should record old values. Don't let the Agent automatically perform high-impact operations without a rollback path. Trace everything: Leave the process behind. Agents with long tasks are most afraid of black boxes. Leave at least these things: Enter the task. Models and tools used. Key tool calls. File changes. Verify the results. Manual confirmation. Retry on failure. final product. The tracing documentation of OpenAI Agents SDK also adopts a similar idea: recording LLM generation, tool call, handoff, guardrail and custom events in agent run for debugging, visualization and monitoring in development and production environments. The purpose of trace is not to make the dashboard beautiful, but to answer questions when something goes wrong: Why does it do this? Where does it start? Which step of verification missed the problem? A large part of Agent's controllability comes from traceability. Finally: The upper limit of the Agent depends on the model, and the lower limit depends on the architecture. The upper limit of the Agent's capabilities certainly comes from the model. A stronger model will write better code, be better at troubleshooting problems, be better at using tools, and make fewer low-level mistakes. There is no doubt about this trend. When long tasks are put into production, one should not just look at the upper limit. It also depends on the lower limit: whether the messed up state can be restored, whether the plan can be rolled back if it drifts, whether verification failures can be discovered, whether permission risks can be blocked, and whether cost abnormalities can be stopped. The ReAct paper has made one direction clear for a long time: the agent needs to alternate between reasoning and acting, obtain observations from the external environment, and then update the plan. Reflexion further emphasizes the importance of feedback signal for agent improvement. It converts feedback into language memory so that subsequent attempts can learn from failures. These studies and today's engineering practice actually point to the same thing: the quality of Agent not only comes from generation, but also from feedback after action. Without status, feedback cannot be retained. Lack of planning, feedback and I don’t know which stage to return to. Without verification, the feedback itself is false. Context, Planning, and Verification are no longer just three tricks. They are already the most basic control surfaces of the Agent system. A stronger Agent in the future will not just be more like a "person who works automatically." It will be more like an auditable engineering system: you know what you are doing, you know where you are doing it, you know how to prove that you are doing it right, and you know when to stop and find someone. When I judge an Agent workflow, I will first skip the model name. I would start by asking these five questions: Where is the status? How do you plan to dismantle it? How to record execution? How to verify the results? When must it stop? The answers to these five questions are unclear. The stronger the model, the greater the noise caused when deviation occurs. After the answer is clear, the Agent actually starts to enter the project from the demo. References Anthropic, Best Practices for Claude Code. The article emphasizes that the context window will fill up quickly, and the fuller the window, the easier the performance will decrease. It is recommended to verify the path through testing, screenshots, and expected output to Claude. Anthropic, Effective harnesses for long-running agents. This article discusses long-running agents across multiple context windows, and uses initializer agents, coding agents, progress files, and session handoff to maintain continuous progress. Anthropic, Harness design for long-running application development. This article introduces the three-role structure of planner / generator / evaluator, and lets the evaluator use Playwright to operate the application like a user and verify the UI, API and database status. Anthropic, Building effective agents. The article distinguishes agentic systems into workflows and agents, and emphasizes that simple, composable patterns are often more effective than complex frameworks. OpenAI, Agents SDK Tracing. The documentation states that tracing logs LLM generation, tool call, handoff, guardrail, and custom events for debugging, visualization, and production monitoring. Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models. The paper proposes to let the model alternately generate reasoning traces and task-specific actions, use external observations to update plans and handle exceptions. Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning. The paper proposes to convert feedback signals into language reflections and save them in an episodic memory buffer for improvement in subsequent attempts.
