Claude Fable and long-running business work: the handover problem

The difficult part of delegating a day of work is what happens halfway through it. A source file changes. Someone withdraws permission. A supplier answers an earlier question. The person who requested the work leaves for the evening, and another person needs to understand what is still in progress.

Those are the conditions a long-running AI assignment must survive. A model may be able to continue working across many steps, but an enterprise needs a reliable record of what was requested, what has happened and what remains authorized.

Claude Fable is worth examining where the assignment genuinely benefits from sustained analysis or coding. Use it inside a workflow that can pause, recover and produce evidence a colleague can review. Treat the conversation as one part of that workflow, not as its only memory.

Which Fable is being discussed?

This article concerns Anthropic's Claude Fable 5.1, not an unrelated product sharing the name. Anthropic's Fable page, checked on 26 September 2026, lists Fable 5.1 for demanding coding and knowledge work and identifies the API model as claude-fable-5-1. Availability depends on the product or platform through which it is accessed.

The same page describes support for long-running assignments. That positioning is a reason to evaluate the model for sustained work; it does not establish that an unattended task can safely exercise every business permission. The controls below are application responsibilities.

Review the model-specific terms before using sensitive records. Anthropic currently describes 30-day safety-monitoring retention by default, with different arrangements for eligible enterprise customers. It also describes safeguard-related routing for some requests. Confirm the applicable retention arrangement and any required API fallback configuration for your account; do not assume another Claude model's settings carry over.

Delegate an outcome someone can recognize

An instruction such as “improve our customer operations” has no natural endpoint. It invites the system to choose its own scope, priorities and evidence standards. A person would also struggle to deliver that assignment without a conversation.

A better assignment is to identify inconsistencies in the approved support procedures for one product, produce a proposed revision and list unresolved policy questions. The system can inspect a defined collection, compare versions and prepare a useful artifact. It cannot quietly extend the exercise to unrelated personnel records.

For coding, specify the expected behaviour, supported interfaces and files that may change. For research, specify the decision, acceptable sources and how uncertainty should be reported. For operational analysis, identify the period and which system owns each measurement.

The output can be ambitious while the authority remains narrow. A substantial draft, tested patch or reconciled comparison is a valuable deliverable even when a person must approve the final business action.

Write acceptance criteria before a long run

Acceptance criteria should describe visible results. A proposed procedure must name the source version and unresolved conflicts. A software change must include the relevant test result and any known limitation. A comparison must distinguish verified supplier statements from recommendations.

Avoid “keep working until perfect.” It provides neither a budget nor a credible definition of completion. Ask for a bounded result and a clear account of what could not be established.

Put the assignment in a durable work record

Create a job record outside the model conversation. It should include the requester, owner, permitted sources, deliverable, budget, deadline and current state. Add identifiers for the input versions and the working artifacts.

The state can be simple: queued, collecting evidence, drafting, waiting for a decision, ready for review, accepted or stopped. What matters is that a colleague can tell whether the system is working, blocked or finished without reading an entire transcript.

Keep proposed actions separate from completed actions. “Prepare a revised escalation matrix” is a request. “Saved draft revision three in the review folder” is an observable event. “Updated the production escalation policy” is a different event requiring different authority.

Checkpoints should preserve evidence, not just summaries

A useful checkpoint records the input versions used, artifacts already produced and actions completed. It also records unresolved questions and the next permitted step. A prose summary that says “most of the work is done” is not enough to recover a job.

If the model context is shortened or a session is restarted, the application should be able to reconstruct the task from these records. The ability to continue a conversation does not replace durable storage of business state.

Handle new information without losing the assignment

Suppose a team asks for an analysis of service renewals. During the run, a new supplier quote arrives with a different term. The system should not overwrite the earlier analysis and erase the reason its recommendation changed.

Record the new document, mark the affected section for review and preserve the prior artifact. If the request changes from comparison to negotiation, require an explicit scope change. Permission to analyze a quote is not permission to send a counteroffer.

A practical rule is to separate corrections from expansions. Correcting the reporting period can stay within the existing job. Adding a new customer dataset or an external communication can require a fresh authorization check.

Review risk at the point of action

Long-running agents can accumulate context that makes an action seem routine. That does not make its consequences smaller. Sending an external message, changing a customer entitlement or applying a database migration remains consequential near the end of a successful run.

Place approvals next to concrete actions. Show the recipient, affected records, proposed change and relevant evidence. If the payload changes after approval, the approval should no longer authorize the new version.

This design also makes the human review more efficient. A reviewer sees the decision that matters instead of receiving a vague request to approve the entire agent.

A long-running job needs several budgets

A token ceiling controls one expense. It does not control every cost the job can incur. Tool calls, external services, repeated searches, retained artifacts and human interventions can all grow independently.

Set limits for total execution time, external operations, retries and the amount of source material collected. Define what happens at each limit. A stopped job should retain its useful work and explain why it stopped rather than presenting an incomplete draft as finished.

Use a smaller bounded run to estimate consumption before approving a larger assignment. Scale estimates cautiously: a job with many dependencies may spend more effort resolving conflicts than a short sample reveals.

Distinguish waiting from working

A job can spend hours waiting for a human decision while doing little computation. Conversely, it can consume substantial resources in a short loop. Report elapsed duration, active processing and waiting time separately.

This distinction helps operations allocate review capacity. If most jobs wait for one manager, a faster model will not improve turnaround until the handover is redesigned.

Recovery must be safe for external systems

When a worker restarts, it may not know whether the last external action succeeded. Resubmitting the action can create a duplicate record or send the same message twice. The model cannot resolve that uncertainty by guessing from its previous narrative.

Use stable operation identifiers and record confirmed downstream results. Where the target API supports an idempotency mechanism, preserve the same identifier for a retry of the same intended operation. Where it does not, inspect the target state or route the uncertainty to a person.

A completed tool response should become part of the job record before the workflow proceeds. Recovery then starts from evidence of what happened rather than a model's expectation of what should have happened.

Test interruption as a normal operating condition

A demonstration usually follows a clean path. Enterprise work does not. Include interruptions in the evaluation: revoke a source permission, change a document version, disconnect a tool and stop the worker after it has prepared an action.

The expected outcome is not always automatic recovery. Sometimes the correct behaviour is to pause with a precise explanation. A system that admits it cannot determine whether an action completed is safer than one that repeats the action to preserve the appearance of progress.

Test reviewer handover as well. Ask a colleague who did not initiate the job to inspect the checkpoint and continue the review. If that person cannot understand the status, the handover record needs improvement.

Use a hypothetical migration review as the pilot

Imagine a software team preparing to replace an old reporting module. The Fable assignment is to inspect the approved repository snapshot, map the affected interfaces and draft a migration proposal. It may create a branch and a test plan in an isolated workspace.

The job cannot change production credentials, run a live migration or commit the organization to a release date. It can identify dependencies, produce a proposed patch and ask focused questions about undocumented behaviour.

At checkpoints, the system saves the interface inventory and the tests it has actually run. A failed test remains visible. An unavailable integration environment is listed as a limitation rather than converted into a passing assumption.

The engineering lead receives a proposal that can be accepted, revised or stopped. Success means that the work is easier to inspect and continue. It does not mean the agent completed the assignment without ever needing clarification.

Give the next engineer a usable package

The final package should include the deliverable, changed files or records, relevant verification results, open questions and a short operational handover. Include the configuration needed to reproduce the evaluation without exposing credentials.

The reviewer should be able to reject one part without losing the rest. Separating the dependency inventory from the proposed implementation allows useful analysis to survive even if the patch is unsuitable.

Decide when a simpler workflow is better

A fixed sequence with a small classification step may not need a long-running agent. A scheduled data export should not become an open-ended reasoning task. Repeated calculations should remain deterministic where the rules are known.

Use sustained model work for assignments whose intermediate steps genuinely depend on findings. Even then, keep routine transport, authorization and state transitions in ordinary application code.

A business should also consider the cost of maintaining the integration. If the source systems change frequently and nobody owns the workflow, the agent will inherit an unstable working environment. Budgeting for the model without budgeting for that environment produces a fragile service.

Commission a deliverable that survives the original builder

For a long-running agent project, request an example job record and recovery runbook before accepting the implementation design. Ask another engineer to identify the latest completed action, the next permitted action and the reason for any pause. The exercise should work without access to the original developer's personal notes.

Include a handover test in acceptance. Stop a job, change an input document and let a different authorized operator resume it. The operator should see that the source changed and understand whether earlier work remains valid. This is a more revealing test than simply letting a long demonstration run uninterrupted.

The delivery scope should also name the artifacts the business owns: tool definitions, configuration, evaluation cases, deployment instructions and operational records. Clarify which parts depend on a hosted feature and what happens if that feature is withdrawn.

For a useful first discussion with an integration team, bring one assignment that repeatedly crosses several systems. Describe where it currently waits for information or a decision. Those handovers usually reveal the engineering work that matters more than the length of the prompt.

Questions about enterprise use

Buy the operating model with the model

The commercial decision should include the workflow owner, support arrangements, budget controls and the expected review process. Ask how work is resumed after an interruption and how permission changes reach active jobs.

A capable model can make ambitious assignments practical. A durable handover makes those assignments manageable for the business that must live with the result.