Engineering AI agent · Dependency upgrades
Dependency-Upgrade AI Agent
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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named engineer
- Version aged
- After launch
- Agent Care
What this agent does
Prepares the bump, never merges it
In
- 01
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
- 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
- 4Controls appliedPublisher checks, licence-delta checks, soak-period checks, tree-depth checks and confidence
No human action required
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.
Goes to the named engineer to merge.
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 required
8 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 boundary
Agent 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 dependency
Illustrative example- Dependency
- HTTP client, direct dependency
- Recorded as
- Raised one patch release above the pin
- Licence
- Licence unchanged
- Evidence of record
- Registry record, 3 August 2026
- Confidence
- Held unmerged
- Held for
- The named engineer, by name
As received
Taken from the registry and the lockfile — the agent records custody of this version, not its contents.
What the record holds
- Publisher account
- Release age
- Licence identifier
Why no merge here
Taking a version into the product is an act a named engineer owns.
What the score decides
Below the configured threshold a bump gets a platform read before the engineer sees it.
Action
MergePinSend to platform reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Each version
From the registry that served it
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.
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.
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.
Build 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 registries
- npm
- PyPI
- Maven Central
- crates.io
- NuGet
- RubyGems
- Go
Upgrade and bump tooling
- Renovate
- Dependabot
- Snyk
- Mend
- in-house bump bots
Build and lock state
- package-lock
- yarn.lock
- pnpm
- Gradle
- Maven
- go.sum
- uv.lock
Agent
Dependency upgrade
- Reads the registry
- Records the publisher
- Holds the merge
Inventory and evidence
- SBOM stores
- dependency graphs
- Sigstore
- provenance attestations
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six catches between the registry and the merge
Six catches along one chain, the last the strongest. What passes on is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a bump may stand
- L3
- Leaves the merge to a named engineer
- L4 – L5
- Keep the merge and the version behind it
- L6
- Leaves the version pinned when signals degrade
How Nestack evaluates it
Evaluate the whole upgrade path — not only the version that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the version the product ships
- E1Final-output evaluationDid the bump record the publisher and the licence it was actually taken from?
- E2Step-level evaluationDid the agent read the right registry, the right version and the live upgrade rules?
- E3Tool evaluationDid it read and write the correct lockfile and the correct dependency?
- E4Confidence calibrationDo low-confidence bumps actually attract more engineer corrections?
- E5Slice evaluationHow does performance change across specific ecosystem classes?
- E6Business outcomeHow many bumps needed a correction before the engineer merged?
Floor — the product a version ends up in
Failure modes
Where each failure originates in the agent
Seven failure modes, each set where the upgrade first shows it.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- QZ-03
Stale registry read
The version read is not the one now published.
Stage gathers
The publisher, the version, the licence and the tree
02 · Reasoning
2 modes
- QZ-04
Bump asserted, not verified
A version moves with no publisher record behind it.
- QZ-06
Retired upgrade rule read as live
A superseded merge rule is worked as current.
Stage proposes
The publisher, the licence and the changed tree
03 · Tool / write
2 modes
- QZ-02
Fresh version passed forward
A bump moves on without the soak period served.
- QZ-05
Bump bound to wrong dependency
The version is written against another package.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- QZ-01
Merged, publisher unrecorded
The record shows a merge but not who published it.
Stage returns
The version the product ships and a customer runs
05 · Change / Version
1 mode
- QZ-07
Silent upgrade drift
A soak period shortens while the stored rule keeps the old one.
Stage tracks
Model, prompt, upgrade rules and licence policy
- Sev-1 · a version merged on no record
- Sev-2 · a wrong version reaches the product
- Sev-3 · provenance degrades, bump held back
Affected slices
Fresh versions absorb the corrections
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 aggregate
Illustrative 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 threshold
2 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 stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Held-bump rate rises on freshly published versions.
- 02
Diagnose
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.
- 03
Improve
Numbered the change leaves, and the versions that drove it are filed with it.
- 04
Verify
A single red version case is enough to stop the merge.
- 05
Learn
The case is kept, and the merge rules are amended in that commit.
Learn → Detect
The 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.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Upgrade discovery and automation-boundary definition.Week 1
- 02Registry, forge and lockfile sources.Week 1, Week 2
- 03Provenance-verification and licence-policy mapping.Week 1, Week 2
- 04Registry-record ingestion.Week 2
- 05Publisher binding and licence-delta logic.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Engineer merge workflow.Week 3, Week 4
- 08Forge and lockfile integration.Week 5
- 09Version and provenance cases.Week 4, Week 5
- 10Guardrails and merge-window controls.Week 4
- 11Version-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final 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 tier | PilotOne ecosystem, one repository | ProductionProduction upgrade cycle | AdvancedMultiple 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 price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, bump volume, merge controls and deployment requirements.
- Separate from build
- Build 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 bring
We build with it
01Your live repositories and the ecosystems each one depends on
→Dependency capture and upgrade-rule versioning
Week 102Representative lockfiles, registries and merge history
→Source binding, publisher logic and the dependency baseline
Week 203Your upgrade cadence and the engineers it names
→Licence-policy mapping, soak periods and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Registry, forge and lockfile assessment, then integration setup
Week 205Merges you would not want audited
→Provenance cases and the failure-mode round
Week 406What no bump may bring in
→Confidence scoring, review routing, guardrails and merge controls
Week 307A named engineer who merges the bump
→Engineer merge workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, 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.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Upgrade-workflow discovery, licence policy and the automation boundary
W2Registry and forge integration and the dependency-tree baseline
W3Publisher binding, soak logic and merge controls
W4Evaluation suite, provenance cases and failure-mode testing
W5Lockfile integration, pilot bumps and targeted corrections
W6One dependency quarter run under the platform owner, then Agent Care handover
- Reading the band
- Each bar runs only across the weeks it is named for, and the doubled fifth week is real.
- At the end of W6
- When the version record validates, Agent Care takes the agent on.
- Duration
- Six-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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your repositories
- Named engineer
- Version aged
- After launch
- Agent Care available
Nestack Agents · Dependency upgrades
AGT-ENG-07 · Agent Care available after launch