Baseline the behaviour of the running system before a line is ported, reconcile the far side on meaning rather than row counts, and hold the cutover for the owner who calls it.
A subsystem is picked up, and the behaviour it shows under real traffic is captured before it is ported.
02
A boundary is crossed, and the change is classified against the regime that governs it before work starts.
Reason
03
A record is moved, and it is reconciled on meaning as well as value, because a checksum catches only one.
04
A retention clock crosses as a field in its own right, so the age of a record is not reset to today.
05
A code path with no callers is left standing and raised as a separate change, not folded into the port.
Decide
06
A cutover date is set, and where a regime asks for expected dates it is declared before the work begins.
07
A rollback stops being possible, and that hour is recorded as a gate rather than a line in a status note.
Out
08
A test suite is ported, and the old suite is kept runnable against the new system so the signal survives.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Baselining, porting and reconciliation belong to the agent. The cutover belongs to a named owner, who declares the far side live and answers for it.
Example workflow
One subsystem, baseline to cutover
AgentHuman
1Subsystem and source receivedRepository, runtime traces, schema and the records that will cross
2Baseline capturedProduction traffic, observed outputs, record semantics and what the old suite still asserts
3Port draftedThe ported code, the mapping, the equivalence result and confidence
4Controls appliedEquivalence replay, semantic reconciliation, change-classification checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is cut over at any of them — the agent is porting, and the owner lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the migration owner to accept.
Low confidence
Adds an architecture read first.
Owner acceptance
The port is held with its baseline, its unexplained differences and the confidence.
Accept · Amend · Send to architecture review
Accepted — cut over by the owner▼
6Source and target systems updatedOnly where write access and change policy allow it
7Outcome evaluatedAmendment rate, equivalence outcomes, defects after cutover and what review found
Amendments
Each owner amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Declaring the cutover and taking the new system live.
Classifying the change against the regime that governs it.
Deciding that a code path is genuinely dead.
Signing the readiness assessment before a cutover.
Automation boundaryAgent acts unaided
✓Baseline the behaviour of the system as it runs now.
✓Replay real traffic through both sides and diff what comes back.
✓Reconcile the migrated records on their meaning as well as their value.
✓Hold the cutover, with its differences, for the owner.
Nothing is cut over except by a named owner, inside the boundaries agreed at implementation.
Removing or repurposing a legacy flag.
Choosing the region a regulated workload runs in.
Translating third-party or copyleft code to a new language.
Changes to cutover policy or approval thresholds.
Example output
One ported subsystem, annotated
This serves teams who may have to show, long after the old system is switched off, that the new one does what the old one did; below is one port as the agent leaves it.
Migration output · single subsystemIllustrative example
Subsystem
Difference found
Reconciled on
Baseline of record
Confidence
Held for
Settlement ledger
A status ordinal arrives unchanged and means something else
Meaning, not value
Production replay
86%
The named migration owner, by name
As receivedTaken from the legacy system as it runs and the records that crossed — nothing here is assumed equivalent.
What the record holdsProduction replayField-semantics mapRetention-clock field
Why this is heldThe rows all match; what the ordinal means on the far side does not.
ActionAcceptAmendSend to architecture review
What the score decidesBelow the configured threshold a port picks up an architecture read before the owner sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each ported subsystemFrom the system it came out of
03Porting
Baseline before you port
Restructuring inside one platform declares that nothing changes; crossing a language, platform or architecture boundary declares that things will, so it gets a baseline, a test plan and a rollback.
01Approved path
The old system was the spec
Get it wrong and the correction lands after the source is decommissioned, when the only account of the old behaviour is the new system itself.
02Human review
What was looked for, and not found
No law found in this work requires a migration to preserve behaviour, to hold a rollback plan, to run both systems in parallel, or to avoid a single cutover weekend. Translating code you own attaches nothing. The nearest duty found governs data, and asks that neither value nor meaning alters.
04Build an evidence trail
The behaviour, the baseline it was measured against and the owner who cut over stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A subsystem-level equivalence figure can read clean while undocumented legacy paths carry most of the amendments. Nestack reports the owner-amendment rate by subsystem, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Undocumented legacy paths
8.6%
3.7×
Review
Records with implied semantics
6.1%
2.6×
Review
Cross-region workload moves
3.8%
1.6×
Watch
Well-specified stateless services
1.7%
0.7×
Normal
Bar: owner-amendment-rate lift vs. stateless-service baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a reused flag costs later
A loop shuts when the behaviour nobody wrote down is a regression case. That suite is what the next cutover run is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises in one subsystem class.
02Diagnose
The flag reused because its old meaning was believed extinct is worked backwards until one cause is left standing.
03Improve
The change goes out numbered, and the baselines that forced it ride beneath.
04Verify
Nothing ships while one touched behaviour case is still red.
05Learn
The case is held, and the cutover rules are rewritten alongside it.
Learn → DetectThe return edge. The next cutover run is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, migration workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Cutover discovery and automation-boundary definition.
02Platform and runtime assessment.
03Change-classification and record-semantics mapping.
04Legacy-system ingestion.
05Porting logic and baseline binding.
06Confidence scoring and difference routing.
07Owner acceptance workflow.
08Source and target system integration.
09Behaviour and reconciliation cases.
10Guardrails and cutover controls.
11Baseline-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne subsystem, one waveProductionProduction migration wavesAdvancedMultiple systems / platforms
Introduced at Pilot
Porting to your baselines✓✓✓
Named owner acceptance✓✓✓
Legacy-behaviour baseline✓✓✓
Introduced at Production
Reporting by subsystem class—✓✓
Acceptance workflow in your systems—✓✓
Approved write-back—✓✓
Source-and-target integration—✓✓
Introduced at Advanced
Multi-language porting rules——✓
Multi-stage cutover approvals——✓
Large migration estates——✓
Multi-system cutover controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, migration scope, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your subsystems and what each one still does→Behaviour capture and baseline versioningWeek 1
02Representative production traffic and records→Porting baseline, semantics mapping and the equivalence suiteWeek 2
03Your change-classification and cutover policy→Change-classification and record-semantics mappingWeek 1
04Access to relevant APIs, feeds or exports→Platform and runtime assessment, then integration setupWeek 2
05Cutovers you would not want examined→Reconciliation and failure-mode casesWeek 4
06What no cutover may assume→Confidence scoring, difference routing, guardrails and acceptance controlsWeek 3
07A named migration owner to accept ports→Owner acceptance workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Widths are taken from the work itself, so the fifth week carries a pair of bands rather than a blank.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Cutover workflow discovery, behaviour baselining and the automation boundaryW2Source and target integration and the porting baselineW3Porting workflow, confidence logic and acceptance controlsW4Evaluation suite, reconciliation cases and failure-mode testingW5System integration, pilot subsystems and targeted correctionsW6One migration wave run under the programme owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6When the behaviour record validates, Agent Care picks the agent up.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a code-migration agent around the behaviour your last cutover never wrote down.
Show us one subsystem you mean to move and who calls the cutover. The baseline was never the specification — it was the behaviour the old system showed under real traffic, and nobody wrote it down. A regulated migration delivers the evidence that the new system is the old one.
