Wait on a version before it moves — who published it, what changed beneath the number, which licence it now carries — then hold the bump for the named engineer who merges it.
A version publishes, and the account behind it is one the registry never verified.
02
A bump is opened minutes after a publish, and the advisory that would stop it runs on human time.
Reason
03
A release tarball is fetched, and the xz backdoor sat there and never in the git repository.
04
A build goes green, and the xz payload wanted a deb or rpm path a test matrix never enters.
05
A minor bump lands, and Redis 7.4 carries RSALv2 where 7.2 carried BSD-3-Clause.
Decide
06
A version carries provenance, and npm says that does not guarantee it has no malicious code.
07
A component is integrated, and CRA Art. 13(5) puts the due-diligence duty on the manufacturer.
Out
08
A defect arrives through an upgrade, and PLD Art. 11(2) leaves not upgrading no safer.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Preparing, recording and holding the bump belong to the agent. The merge belongs to a named engineer, who takes the version into the product and answers for it once it has shipped.
Example workflow
One version, registry to merge
AgentHuman
1Version publishedRegistry release, advisory, end-of-life notice or scheduled dependency scan
2Publisher context assembledThe publishing account, the release history, the age of the version and the licence it carries
3Bump preparedThe version range, the changed tree, the licence delta, the provenance state and confidence
Stages 1 to 4 run unaided, and nothing reaches the product at any of them — the agent is preparing, and the engineer lane opens at the merge gate.
5DecisionSplits at the merge gate
Soak period served
Goes to the named engineer to merge.
Anything fresh
Adds a platform owner read first.
Engineer merge
The bump is held with its publisher record, its licence delta and what the controls returned.
Merge · Pin · Send to platform review
Merged — by the named engineer▼
6Lockfile and inventory records updatedOnly where write access and merge policy allow it
7Outcome evaluatedSoak compliance, reverted merges, engineer corrections and what production found after the version shipped
Corrections
Each engineer rejection is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Taking a new version into a shipped product.
Accepting a licence change on behalf of the company.
Deciding that a publisher can be trusted.
Judging whether an upgrade is needed for safety.
Automation boundaryAgent acts unaided
✓Record who published the version and what changed.
✓Hold a freshly published version for the configured soak period.
✓Compare the licence a version carries against the one before it.
✓Hold the bump for the named engineer who merges it.
Nothing reaches the product except by a named engineer, inside the agreed boundaries.
Vouching for code the company did not write.
Granting the credential that publishes a package.
Waiving the soak period on a fresh version.
Changes to upgrade rules or merge thresholds.
Example output
One version bump, annotated
The vulnerability-autofix sibling answers a named finding; this one moves a version because it is old, which is how the supply-chain attacks that matter arrive. Below is one bump as the agent leaves it.
Upgrade proposal · single dependencyIllustrative example
Dependency
Recorded as
Licence
Evidence of record
Confidence
Held for
HTTP client, direct dependency
Raised one patch release above the pin
Licence unchanged
Registry record, 3 August 2026
Held unmerged
The named engineer, by name
As receivedTaken from the registry and the lockfile — the agent records custody of this version, not its contents.
What the record holdsPublisher accountRelease ageLicence identifier
Why no merge hereTaking a version into the product is an act a named engineer owns.
ActionMergePinSend to platform review
What the score decidesBelow the configured threshold a bump gets a platform read before the engineer 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 versionFrom the registry that served it
03Custody
Which rules reach an upgrade
The maintainer who published this owes nothing — MIT disclaims it and CRA Art. 64(10) exempts stewards from fines; the duty sits with the manufacturer who integrated the component.
01Approved path
A stranger wrote this
When a self-replicating worm ran through the registry in September 2025, the federal mitigation was to pin to versions published before it — the advice was to stop upgrading.
02Human review
What was checked, and not found
No law found requires a lockfile, a dependency policy, a maximum version age, a reading of the upgrade diff, licence-change detection or provenance verification, and running an end-of-life version is nowhere unlawful in itself. The nearest version-age control is a configuration key.
04Build an evidence trail
The version, the publisher who signed it and the engineer who merged it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Package registriesnpm · PyPI · Maven Central crates.io · NuGet · RubyGems · Go
An ecosystem-level provenance figure can read clean while freshly published versions carry most of the bumps held back. Nestack reports the correction rate by ecosystem class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Freshly published versions
9.9%
3.7×
Review
Single-maintainer packages
7.0%
2.6×
Review
Transitive tree changes
4.4%
1.6×
Watch
Long-established core libraries
1.9%
0.7×
Normal
Bar: correction-rate lift vs. established-library baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What the merge window cost
A loop ends when the bump merged before anybody looked is a standing case. That suite is what the next upgrade taken is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Held-bump rate rises on freshly published versions.
02Diagnose
Forty-two minutes from publish to pull request, and under thirteen from pull request to merge, is read back through the upgrade rules until a single cause remains.
03Improve
Numbered the change leaves, and the versions that drove it are filed with it.
04Verify
A single red version case is enough to stop the merge.
05Learn
The case is kept, and the merge rules are amended in that commit.
Learn → DetectThe return edge. The next upgrade is taken 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, upgrade workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Upgrade discovery and automation-boundary definition.
02Registry, forge and lockfile sources.
03Provenance-verification and licence-policy mapping.
04Registry-record ingestion.
05Publisher binding and licence-delta logic.
06Confidence scoring and review routing.
07Engineer merge workflow.
08Forge and lockfile integration.
09Version and provenance cases.
10Guardrails and merge-window controls.
11Version-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 ecosystem, one repositoryProductionProduction upgrade cycleAdvancedMultiple ecosystems / estates
Introduced at Pilot
Bump preparation to your upgrade rules✓✓✓
Named engineer merge✓✓✓
Dependency-tree baseline✓✓✓
Introduced at Production
Reporting by ecosystem class—✓✓
Platform review workflow in your systems—✓✓
Approved lockfile write-back—✓✓
Registry-and-forge integration—✓✓
Introduced at Advanced
Multi-registry coverage——✓
Cross-repository upgrade packs——✓
High bump volume——✓
Multi-ecosystem upgrade controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, bump volume, merge 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 live repositories and the ecosystems each one depends on→Dependency capture and upgrade-rule versioningWeek 1
02Representative lockfiles, registries and merge history→Source binding, publisher logic and the dependency baselineWeek 2
03Your upgrade cadence and the engineers it names→Licence-policy mapping, soak periods and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Registry, forge and lockfile assessment, then integration setupWeek 2
05Merges you would not want audited→Provenance cases and the failure-mode roundWeek 4
06What no bump may bring in→Confidence scoring, review routing, guardrails and merge controlsWeek 3
07A named engineer who merges the bump→Engineer merge 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
Each band takes the width its phase actually costs, which is why week five carries a pair of them.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Upgrade-workflow discovery, licence policy and the automation boundaryW2Registry and forge integration and the dependency-tree baselineW3Publisher binding, soak logic and merge controlsW4Evaluation suite, provenance cases and failure-mode testingW5Lockfile integration, pilot bumps and targeted correctionsW6One dependency quarter run under the platform owner, then Agent Care handover
Reading the bandEach bar runs only across the weeks it is named for, and the doubled fifth week is real.
At the end of W6When the version record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a dependency-upgrade agent around the publisher your last bump never named.
Show us one service and the last dependency bump merged into it. The person you trusted there was a stranger the registry never verified, and the pipeline that carried their code inside was yours. A version that cannot say who published it comes back as a finding.
