Anthropic Opus 5 Prompting Strategies: A Developer's Guide for Long-Running Coding Agents ## Answer first Anthropic announced Claude Opus 5 on July 24, 2026. Its announcement describes Opus 5 as a step change improvement for the Opus tier powering long-running agents, with improvements in coding and professional work. Anthropic Newsroom That positioning makes a structured prompt architecture worthwhile, but it does not establish undocumented model behavior, API details, benchmark numbers, or guaranteed improvements in a particular application. The safest approach is to treat the release claim as a reason to evaluate Opus 5, not as proof that an existing agent will improve. A durable long-running coding agent should define its mission, invariants, tool contract, execution state, verification steps, recovery rules, and stopping conditions before adding more context. Prompts should request concise evidence, assumptions, decisions, and next actions rather than demanding a complete hidden chain of thought. This guide separates the verified announcement from framework-agnostic implementation guidance. ## Scope and evidence boundary The available first-party source is Anthropic's newsroom announcement. It states that Opus 5 is intended for long-running agents and claims improvements in coding and professional work. The supplied evidence does not include benchmark figures, latency, pricing, context capacity, tool-calling specifications, or controlled comparisons with other models. Developers should therefore avoid writing prompts around unsupported assumptions such as guaranteed memory retention, automatic recovery, or a particular function-calling format. Confirm the current model documentation and interface in use before production deployment. The strategies below are reusable prompt engineering patterns. They are not claims about undocumented Opus 5 internals or measured results. ## Build a three-layer prompt contract Long-running agents benefit from separating stable policy from changing task state. ### 1. System prompt: define the permanent contract The system prompt should describe: - The agent's mission and permitted scope - Coding conventions and architectural constraints - Required safety and security boundaries - Which actions require confirmation - The available tools in conceptual terms - Expected tool input and output conventions - Completion criteria - Failure and escalation rules - The format required for every response Keep this layer stable. Changing it during a run can create conflicting instructions. ### 2. User prompt: provide the current state Each user message should contain the information needed for the next decision: - The immediate objective - The current agent state - Relevant repository or issue information - Immutable constraints inherited from the system prompt - Recent verified tool results - Unresolved questions - The next action or checkpoint requested Avoid pasting an unfiltered transcript. Select state that can affect the next decision and attach references to longer evidence where possible. ### 3. Assistant prefix: define the response envelope Start the expected assistant response with a small, parseable envelope. For example, require fields for status, decision, evidence, action, verification, and next state. This reduces ambiguity across many tool calls. It also makes drift easier to detect because missing or contradictory fields can be checked by the orchestrator. If the API offers a structured response format, use it instead of relying only on prose. Do not ask the model to reveal a complete chain of thought. Ask for a concise rationale, the assumptions used, the evidence considered, and the proposed verification step. Store conclusions and decisions as state; do not treat raw reasoning as reliable memory. ## Use an explicit agent loop A long-running coding agent should move through a small set of visible states rather than freely repeating generate, call tool, and continue steps. A useful baseline is: 1. analyzing: inspect the request and identify constraints 2. planning: select a bounded plan and its verification method 3. executing: perform one tool action or a clearly defined batch 4. verifying: check outputs against explicit acceptance criteria 5. recovering: classify an error and choose a bounded recovery 6. checkpointing: summarize verified state and request the next decision 7. complete or blocked: stop with a precise outcome The system prompt should define transitions between these states. The user prompt should identify the current state. The assistant response should state the proposed next state. This design prevents a model from treating every response as a request to continue. It also makes retries observable. A failed tool call should not silently restart the plan unless the recovery policy explicitly allows that. ## Create a stable tool-use contract Tool-use prompts should describe the purpose of each tool, its authority, required inputs, output shape, and failure semantics. The exact request format depends on the API and framework being used, so do not copy a schema from another provider without validation. Use these principles: - Give tools short, stable names - Describe the observable effect in the tool description - Mark required fields explicitly - Use enums for controlled choices - Represent unavailable values with an agreed null or missing-field rule - Return machine-readable results whenever possible - Include enough information to distinguish success, partial success, and failure - Keep mutable session state outside the tool schema Tool names should remain stable across runs. Changing a name or parameter after deployments can break cached prompts, evaluators, and retry policies. ### Classify errors before retrying Not every error deserves a retry. Separate at least these categories: - Malformed input: repair the request if the correction is deterministic - Permission or authorization failure: stop or request authorization; do not retry blindly - Transient infrastructure failure: use a bounded retry policy with an idempotency key when supported - Semantic failure: inspect the result and revise the plan or tool selection - Policy violation: stop the action and report the violated rule - Repeated failure: checkpoint the state and escalate according to the application policy Exponential backoff can reduce pressure on an unstable dependency, but it does not repair a bad argument or a permission problem. Jitter should be used only when the surrounding system supports it. A retry budget should be part of the prompt contract and enforced by the orchestrator. The model should receive the remaining budget, the last error class, and the last verified state. It should not be allowed to invent a successful tool result. ### Keep tool results auditable Every tool result should include the action attempted, input reference, status, relevant output, and timestamp or run identifier supplied by the system. Sensitive values should be redacted. Long outputs should be stored externally and referenced by a stable identifier. ## Manage context as state, not as an unlimited transcript Long-running agents need several forms of memory with different lifetimes. ### Working context Working context contains information needed for the immediate decision. Preserve the mission, constraints, current state, unresolved decisions, recent verified results, and the next action. Remove duplicated transcript text, obsolete suggestions, and stale intermediate plans. ### Checkpoint summaries At meaningful boundaries, write a compact checkpoint containing: - Objective and acceptance criteria - Immutable constraints - Completed actions and verified results - Unresolved risks - Decisions that future steps must respect - The next recommended action - References to detailed evidence Checkpoints should be append-only where possible. If a checkpoint is corrected, retain the correction and its reason rather than silently rewriting history. ### External memory External memory is appropriate for repository state, issue links, generated artifacts, test results, and decisions that outlive a prompt window. Store stable identifiers and snapshots, not secrets or unrestricted credentials. Before retrieving external memory, tell the agent what question it must answer. After retrieval, require it to distinguish current evidence from historical context. ### Windowing A windowing policy should define what survives eviction. At minimum, retain mission, hard constraints, active task state, unresolved dependencies, and references to important evidence. Context length alone is not a sufficient quality measure. A long transcript containing repeated failed attempts can be less useful than a short checkpoint with verified state. ## Write evaluation prompts that detect drift Evaluation prompts should compare the current state with the original objective and acceptance criteria. They should not ask only whether the agent feels successful. A useful evaluation request includes: - The original objective - Required invariants - Current state and recent actions - Available evidence - Expected next milestone - Known risks - The evaluation question Ask for a compact result with: - Progress against the objective - Invariant violations - Tool errors grouped by class - Unresolved dependencies - Evidence of drift - Recommended next action - Confidence based only on available evidence Drift is present when the agent changes scope, ignores a hard constraint, repeats an ineffective action, relies on stale state, or treats an unverified result as complete. The evaluator should cite the evidence supporting each finding. Use automated checks for facts that can be tested, such as compilation, tests, schema validation, permission checks, and artifact presence. Keep the model evaluator as one signal rather than the sole authority. Human review remains necessary for security-sensitive changes, architectural decisions, and ambiguous acceptance criteria. ## Case study: code-refactoring agent Consider an agent assigned to refactor a repository while preserving behavior. ### System prompt policy Define the mission as producing a reviewable refactor, not merely changing code. Specify supported tools, required backups or diff visibility, forbidden destructive operations, required verification, and the rule that unverified changes must not be presented as complete. Include explicit invariants such as public interfaces, required tests, compatibility constraints, and prohibited data access. The agent should request clarification when an invariant conflicts with the requested change. ### User prompt for a run step Supply the current branch or workspace reference, the selected files, the refactor goal, acceptance criteria, existing checkpoint, available tools, and the immediate question. Do not paste the entire repository history unless it is relevant to the decision. ### Assistant response contract Require the assistant to report: - The interpretation of the task - The proposed change boundary - Relevant evidence - Tools to call next - Verification criteria - Risks or missing information - The next agent state The assistant should not claim that tests passed unless a tool result verifies that outcome. ### Recovery policy If a refactor tool fails, the orchestrator records the error class and remaining retry budget. The next prompt includes the last verified state and the failed action. The agent may repair malformed input, select another approved tool, or stop for authorization. It should not repeat the same failing action indefinitely. ### Evaluation prompt Ask the evaluator to compare the resulting diff with the original acceptance criteria. It should identify changed interfaces, unverified behavior, missing tests, and scope expansion. A successful result is a reviewable diff with verified acceptance criteria, not a large amount of generated code. ## Migration from Opus 4 and Sonnet 5 The supplied evidence does not provide technical differences between Opus 5 and either Opus 4 or Sonnet 5. Do not assume that a prompt that worked with another model will transfer unchanged. A low-risk migration process is: 1. Freeze the existing prompt, tool schemas, and evaluation tasks. 2. Run the same tasks through the new model in a controlled environment. 3. Change one prompt or tool variable at a time. 4. Record task success, invariant violations, tool errors, retry counts, context requirements, and unresolved cases. 5. Compare results against the frozen baseline. 6. Keep a rollback path to the previous model and prompt set. 7. Promote changes only after the application-specific evaluation criteria pass. These are migration practices, not measured Opus 5 results. The absence of supplied benchmark numbers means that any performance claim must come from a documented test conducted in the developer's own environment. ## Practical rollout checklist Before enabling Opus 5 for sustained coding work, verify the following: - The system prompt states mission, scope, and stopping conditions. - User prompts contain current state and relevant evidence rather than whole transcripts. - Tool schemas are stable and inputs are validated. - Error classes and retry budgets are explicit. - Checkpoints preserve decisions and verified outcomes. - External memory uses stable references and redacted secrets. - Evaluation prompts test acceptance criteria and detect drift. - Failed runs can resume without repeating destructive actions. - A previous model configuration remains available for rollback. ## Limitations The verified source supports the announcement date and Anthropic's description of Opus 5 as an improvement for long-running agents, coding, and professional work. It does not support detailed specifications, benchmark values, or comparisons with Opus 4 and Sonnet 5. Prompt patterns in this article are implementation guidance and should be tested against the actual API, tools, and application requirements before production use.