Factory Private
Enterprise AI
Private AI package work needs durable context
September 24, 2026 - 3 minute read
Keeping software packages up to date is mostly a memory problem. A maintainer has to remember build conventions, upstream quirks, reviewer decisions, and the fixes that did not work last time. When that context is lost, every new package update starts from scratch.
The pressure keeps growing. New CVEs land every week, upstream projects ship new releases, and security teams want patched packages fast. Teams that use AI agents for this work need those agents to remember, and they often need the work to stay inside their own environment.
Package maintenance is repeated decisions
A single package update can start with an upstream release or a new CVE, move through a broken build, and end with a reviewer asking for a change. That review decision often applies to the next ten packages too.
Say a reviewer approves a build flag for most packages, but flags one upstream release that needs an exception. On the next package, the agent should reuse the approved rule without carrying the exception into a release where it does not apply. That only works if the agent remembers both the rule and the reason for the exception.
Without that memory, engineers spend time re-explaining decisions or replaying long chat histories. Reviewers catch the same mistakes again. Throughput looks fine on paper while the real cost hides in rework.
What long-running sessions make possible
Chainguard builds and maintains secure open source packages and container images. Its published Factory case study describes one Droid session running for two weeks across six repositories and building 80 packages without losing context. Staff Engineer Josh Wolf put it this way.
"When you don't have to think about context windows, you can treat Droid like a colleague that just remembers what you've been talking about."
Wolf also describes teaching Droid a task once or twice, then letting it work independently on later iterations. That pattern fits package work well, because so much of it repeats with small variations.
Factory keeps long sessions useful through context compaction. Its compression research explains how structured summaries keep intent, file changes, decisions, and next steps as a session grows. Teams should still check the working tree and test results directly, because a summary is not a substitute for the actual build.
Running package work in a private environment
Many teams that maintain packages, especially for security, cannot send source code or build artifacts to a hosted service. For them, the agent has to run inside their own boundary.
Factory Private runs Factory in the customer's environment, and the airgapped deployment guide covers setups with no Factory cloud dependency. In those setups, model inference and telemetry also stay inside the environment. Because Factory is model-agnostic, teams can use the models they already trust.
A disconnected build still needs source archives, base images, package indexes, signing tools, and test fixtures. Make sure those are available inside the environment before handing work to an agent. A build that quietly reaches out to a public registry breaks the isolation you set up.
Keep the agent's permissions narrow
Preparing a patch and publishing a package are different jobs and should need different permissions. Factory's Agent Safety & Controls cover command restrictions and sandboxing. Use them with separate credentials for development, signing, and publishing.
A good setup lets a Droid prepare and test a package update, then hands it to a person who signs and releases it. Another engineer should be able to rebuild the package and see which earlier decisions the agent reused.
What to measure
Count completed packages, but also track how often reviewers correct the same issue, how often the agent repeats an investigation, and how long patched packages wait for review. Those numbers show whether the agent is actually carrying context forward.
For CVE-driven updates, measure the time from advisory to published package. That is the number security teams care about, and it is where durable context pays off the most.
If you are evaluating private AI for package maintenance or CVE patching, use the form below to talk with the Factory team.
Frequently asked questions
Why is package maintenance a memory problem?
A maintainer has to remember build conventions, upstream quirks, reviewer decisions, and fixes that did not work last time. When that context is lost, every update starts from scratch.
What did Chainguard report about long Droid sessions?
Chainguard's published case study describes one Droid session running for two weeks across six repositories and building 80 packages without losing context.
How can package work stay private?
Factory Private runs Factory in the customer environment, and the airgapped deployment guide covers setups with no Factory cloud dependency. Source archives, base images, package indexes, signing tools, and test fixtures must be available inside the environment.
Should the agent publish packages?
Preparing a patch and publishing a package should need different permissions. Let Droid prepare and test the update, then hand it to a person who signs and releases it.
Further reading
Talk with Factory
Discuss your team’s software development, privacy, or deployment requirements.
Contact us
