The Agent Ledger #10: Legacy systems, shorter software lifespans, and agent auth

For the past two years, much of the discourse around AI in the enterprise has assumed a clean slate: greenfield agents, vector databases, modern APIs. The reality on the ground at large banks, insurers, and logistics firms is the opposite. The systems that actually hold the money and the inventory still run on COBOL, AS/400, and mainframe job schedulers, and any AI initiative that cannot reach those systems is essentially a demo.

That is why a wave of vendors is now retrofitting AI connectors into legacy operations tooling rather than asking customers to migrate. The pitch has shifted from replacement to mediation: let an agent read a CICS transaction log or trigger a batch job through the same control plane that already governs change management. For engineers, this changes what 'AI integration' means in a job description. Familiarity with older protocols and brittle data formats is suddenly a premium skill, not a liability.

The practical takeaway is that the most valuable agent in 2026 may be the one that can safely interact with a system written in 1996. Engineers building internal tooling should assume that their agents will need to speak to something they did not design, and budget for the observability and rollback machinery that implies.

National Australia Bank recently revised its capitalised software policy, citing AI as a reason that internally developed software now depreciates faster. This is the kind of accounting footnote that sounds dry but carries a sharp signal: a major institution is formally acknowledging that code written today is worth less, sooner, because AI changes both how quickly it can be replaced and how quickly it becomes obsolete.

For engineering leaders, the implications cut two ways. On one hand, the cost-benefit math for greenfield rewrites improves when the resulting asset has a shorter book life. On the other, the bar for what justifies capitalisation at all is rising. If an AI assistant can regenerate a service in a sprint, is that service really a multi-year asset? CFOs are starting to answer no.

Individual contributors should expect this to filter into how projects are scoped and staffed. Long-lived platform investments will need stronger durability arguments, and short-lived feature work may be funded more readily as opex. The craft of engineering does not change, but the financial frame around it is being rewritten in real time.

Two small Python packages worth tracking this month point to where agent infrastructure is heading. Authsome is a portable local authentication library aimed specifically at AI agents and developer tools, addressing a problem that most teams currently solve with environment variables and prayer. As agents start making real API calls on behalf of users, the question of how they hold and rotate credentials without phoning home to a central service becomes urgent.

Airgap-devkit takes a different angle: installing and managing developer tools in network-restricted environments. This matters because regulated industries and government work increasingly want AI coding assistants and agent frameworks running entirely inside their perimeter. The tooling for offline package mirroring, model weight distribution, and dependency auditing has lagged the demand, and projects in this space are filling a real gap.

Neither library is a finished product, and both carry pre-release version numbers. They are worth bookmarking less for immediate adoption than as evidence that the agent ecosystem is finally producing the unglamorous plumbing it needs. Engineers building internal platforms should be watching this layer closely, because the alternative is reinventing it badly.

The airgap-devkit project deserves a closer look on its own terms. For years, 'air-gapped' and 'modern developer experience' were nearly opposites: teams in classified or regulated environments made do with stale package mirrors and manual approvals. The arrival of capable open-weight models has changed the calculus, because the most sensitive workloads are now the ones most interested in running AI locally.

A toolkit that handles dependency resolution, signature verification, and tool installation inside a disconnected network is not glamorous, but it is the difference between an agent project shipping and stalling in a defense or healthcare context. Expect more of this category to emerge, and expect procurement teams to start asking pointed questions about how vendors handle offline operation.

A growing body of incident data suggests that the dominant cause of breaches is no longer sophisticated intrusion but ordinary software defects and misconfigurations. That framing matters for anyone shipping AI-generated code, because the failure mode of an LLM is precisely to produce plausible-looking output with subtle errors. The threat model is not that an attacker breaks in; it is that the code lets them walk in.

This reframes the case for AI code review tools, static analysis, and policy-as-code in CI pipelines. If the marginal line of code is now written or suggested by a model, the marginal defect is too, and the controls need to scale accordingly. Teams that treated security scanning as a compliance checkbox are finding it has become the main event.

The practical move for engineering teams is to invest in the feedback loop between code generation and code verification. An agent that writes code without an agent that audits it is a liability, and the audit step is where much of the next year of tooling investment will land.

Framework M Studio, a visual DocType builder and developer tools package, is a small reminder that the low-code pendulum is swinging back, and AI is the reason. When an agent can generate the underlying code from a structured definition, the value of having a clean visual representation of that definition goes up, not down. The form designer becomes the source of truth, and the code becomes a build artifact.

This pattern is showing up across the stack: schema designers, workflow builders, and prompt orchestration UIs are all converging on the idea that humans should edit structure while models handle implementation. Engineers who dismissed visual tooling a decade ago should take another look, because the integration point with agents is genuinely new.

A recent case in Hangzhou clarified that introducing AI automation into a workplace does not by itself justify pay cuts or layoffs under existing Chinese labor law. The headline-grabbing claim that China had banned AI layoffs was overstated, but the underlying ruling is still significant: courts are applying ordinary employment protections to AI-driven restructuring, and employers cannot use automation as a blanket justification.

For engineers, this is a useful counterweight to the more breathless productivity claims being made about coding agents. Whatever the technical capability of these tools, the legal and contractual frame around how they affect headcount is being shaped case by case, in multiple jurisdictions, and the early signal is that existing labor law mostly still applies.

The broader point is that the deployment of AI in software organizations is not just a tooling decision. It is an organizational and legal one, and the engineers closest to the tools are often the ones best placed to flag when a proposed rollout is making assumptions that will not survive contact with HR or the courts.