Fable 5.2 can advance a large migration. How should the team retain its architecture decisions?

Anthropic released Fable 5.2 on November 9 with an emphasis on difficult reasoning and long-running Agent tasks. Its release material cites a Python-to-Rust service migration in which service startup became 26 times faster. That describes startup in that particular test, rather than model generation speed or a promised result for other migrations.

That capability makes larger assignments plausible: tracing dependencies across modules, rewriting implementations, and iterating against tests. Engineers then inherit more than a code diff. They also inherit judgments formed during the work.

Which compatibility behaviors must remain? Why can an older interface not be removed yet? Does a performance improvement depend on a particular deployment environment? Those answers can constrain another repository or team. Context that helps today’s Agent continue does not necessarily tell its successor which judgments the team accepted.

A large migration therefore has two connected deliverables: a verifiable implementation and decisions that later work may rely on. They need different acceptance checks.

A PR checks the change; a decision explains what later work may assume

Keep code, tests, benchmark scripts, and repository architecture decision records—ADRs—in Git. A PR already connects implementation and discussion. If every consumer works in that repository, a maintained ADR may be enough; changing the model is not a reason to add a knowledge system.

A shared record becomes useful when the conclusion guides work outside that repository: a compatibility requirement affects another service team, an environment constraint affects operations, or an Agent must find the current decision across projects. The team needs to query scope, ownership, and current applicability as well as find the original PR.

Busabase can hold that shared layer: a concise decision, its scope, source links, and change history. It does not replace tests or turn a polished summary into architecture approval. Reviewing implementation in Git and accepting reusable knowledge in Busabase serve different purposes.

Read constraints before the first change

Ask the Agent to read existing design documents, applicable ADRs, and interface requirements. Link authoritative material where it already lives. Copying every repository document creates another version to maintain.

A small starting setup is a migration Folder, a Doc describing scope and acceptance, and a Base for decisions that other work will reuse. This is a suggested structure, rather than a built-in template.

| Resource | Contents | Job |

| --- | --- | --- |

| Folder: migration project | Links to the project Doc and Base | Delimit the work |

| Doc: scope and acceptance | Goals, compatibility constraints, Git references, responsibilities | Give Agent and reviewer the same contract |

| Base: architecture decisions | Conclusion, evidence, scope, owner, lifecycle | Query and propose shared judgments |

| Skill or custom prompt | How to read constraints, propose changes, and attach evidence | Reuse the procedure in later work |

An opening instruction can say:

Read this project’s scope and acceptance Doc, then the architecture decisions accepted for this service. List the compatibility requirements and their sources. Separate missing evidence, expired conclusions, and conflicts. Do not treat unresolved items as implementation assumptions or modify shared records yet.

The output should be a source-linked constraint list with unresolved questions for the owner. Verify model access separately: installing the Busabase plugin does not grant Fable access or establish that a particular Claude Code environment can select it.

Turn a discovery into a proposal before making it a rule

During migration, an Agent may discover undocumented behavior or propose removing compatibility logic. Separate an observation from a decision. Test output is evidence; choosing future behavior is a consequential judgment.

A proposal needs a specific conclusion, actual code or test evidence, affected services and environments, unresolved limits, and an accountable owner. “Migration succeeded; roll it out” is too broad. One module passing tests does not establish that other modules share its constraints.

Consider “may this compatibility path be removed?” as a structural example, not an approved action. The Agent should link the real PR and test result; the owner decides the conclusion and its scope. Where evidence is absent, leave it unresolved instead of filling fields with example links.

Separate the decision’s lifecycle from the ChangeRequest status

A small decision Base can use these fields. They are a team-designed schema, not automatic architecture validation by Busabase.

| Field | Suggested type | Review question |

| --- | --- | --- |

| decision | Text | What may the next Agent rely on? |

| evidence | Text or URL | Which real PR, test, benchmark, or ADR supports it? |

| scope | Text | Which service, repository, version, and environment? |

| owner | Member or text | Who accepts and maintains it? |

| state | Select | Pending, accepted, conditional, or superseded? |

| supersedes | Same-Base relation | Which earlier decision does it replace, if any? |

| review_condition | Text | What change requires another check? |

The state field is distinct from the ChangeRequest review status. One describes whether the conclusion is usable; the other describes whether a field change reached the canonical record. A merged CR may simply have stored a proposal whose business state remains pending. A later Agent must not execute it as an accepted decision.

For human review before shared knowledge becomes canonical, use proposal-only access. Write-level access normally merges immediately; retain review explicitly where that connection can write. A prompt saying “wait for approval” does not itself configure the API path. Check API Keys and the actual connection.

Cross-check implementation and conclusion

The engineering reviewer checks the Git diff, tests actually run, and coverage limits. The decision owner checks whether evidence supports the claim, scope exceeds the test boundary, or another team still depends on the behavior being replaced.

A merged PR can coexist with a pending or conditional cross-team decision. Conversely, accepting an architecture direction does not establish implementation, testing, or deployment. Those states still require Git and deployment evidence.

Use a ChangeRequest to narrow scope or add evidence, merge after the authorized decision, then read the current record back. If a later decision replaces an earlier one, maintain the replacement relation and old lifecycle state explicitly. Preserve why the earlier choice existed instead of silently overwriting it.

A useful writeback instruction is:

Prepare architecture-decision proposals from conclusions that affect later migration work. Attach real PR and test references, scope, unresolved questions, and owner. Reuse an existing record for the same decision. Submit for review without approving it yourself; return CR links and field differences. After approval and merge, read back and report which decisions are accepted and which remain unusable as implementation assumptions.

Start the next round from currently applicable records

The next Agent should confirm project and access, read current merged records, and select accepted decisions whose scope matches and whose review conditions remain satisfied. Exclude superseded decisions. Pending CRs can identify questions, but do not belong in the accepted list.

Do not resolve conflicts merely by choosing the most recently edited row. Inspect replacement relations, scope, and ownership, then return unexplained conflicts to the owner. A record is not automatically fresh: a changed PR, upgraded dependency, or deployment environment may trigger its review condition.

Busabase Playbooks can save this reading and proposal method in a Skill or custom prompt. Define who runs the next task, when it reads, and how failures are reported. Saving a procedure does not itself start an Agent or create a schedule.

Begin with one conclusion another task needs

Choose a current conclusion with real PR and test evidence that matters to another round of work. Complete reading, proposal, human review, merge/readback, and subsequent reuse before attempting to organize every chat. Most intermediate reasoning need not become team knowledge.

The Claude Code knowledge-base guide explains how shared records complement CLAUDE.md, auto memory, and repository material. The Claude Code plugin page provides the maintained installation instruction: have the Agent read the setup guide and perform a read-only connection check after authorization.

The model capability comes from the tasks described in Anthropic’s release. Sustaining the value requires connecting implementation evidence, decision ownership, and later retrieval. The successor should find the conclusion and understand where, why, and by whom it was accepted.