Legacy System Modernizationwith AI Agents in 2026

Start with the uncomfortable part, because everything else in this article depends on it. As of August 2026 there is no credible, independently measured productivity number for AI-assisted COBOL or mainframe modernization. Not a lower one than vendors claim. None. No randomized trial, no controlled field study, no auditable multi-customer dataset. The category has been sold aggressively for two years and measured by nobody outside the companies selling it.

That is a strange thing to write in an article whose commercial purpose is to sell modernization work. It is also the reason this article is worth reading. If you are a CTO with a system that runs the business and that nobody wants to open, the most valuable thing anyone can tell you is which claims have evidence behind them and which do not — because you are going to be shown a lot of the second kind.

The most telling admission comes from inside the ecosystem that benefits most. IBM's mainframe modernization tooling is the most serious product in this space, and IBM's own partner ecosystem concedes the point directly: tools alone do not deliver enterprise modernization outcomes. That is a systems integrator saying, in public, that the software you are being sold is not the thing that determines whether the program works.

There is one widely cited 2026 figure pointing the other direction, and it deserves precise labelling too. In June 2026 Gartner published a prediction that more than 70% of mainframe exit projects will fail due to overestimation of generative AI's capabilities. That is a Gartner Predicts statement — an analyst forecast, not a survey result and not a measurement of completed projects. It should not be repeated as data. It is, however, directionally consistent with the complete absence of evidence on the optimistic side, which is why it is worth knowing about.

The better-grounded numbers describe enterprise AI generally rather than modernization specifically, and they are sobering enough. Gartner's April 2026 survey of 782 infrastructure and operations leaders, fielded November to December 2025, found that only 28% of AI use cases fully succeed and meet ROI expectations, while 20% fail outright— leaving roughly half in partial-success territory. Note that this is materially less pessimistic than the “80% of AI projects fail” folklore, and it is real measurement rather than prediction. Skills gaps and data quality were each cited by 38% of respondents as the blocker.

Stanford HAI's 2026 AI Index adds the scaling picture: 88% of organizations use AI in at least one function, fewer than 10% have fully scaled it in any single function, and only 29% report significant ROI. Deloitte's 2026 State of AI in the Enterprise (n=3,235 senior leaders across 24 countries, fielded August to September 2025) supplies the cleanest expectation-versus-reality figure available: 74% hope to grow revenue through AI; 20% already are.

We will tell you what the evidence supports before we tell you what we would build. On legacy modernization the honest answer is that the tooling is real, the comprehension gains are real, and the migration-speed claims are not yet measurable. Plan the program so that it works either way.

— Frenchy Digital engagement principle

This is the most important piece of evidence in the article, and it is misquoted constantly in both directions, so here it is exactly.

In July 2025, METR published a randomized controlled trial measuring the effect of AI tools on experienced open-source developers. The design matters as much as the result. 16 experienced developers worked on 246 real issues in their own repositories — mature projects averaging more than 22,000 GitHub stars and over a million lines of code, with the contribution standards that implies. Issues were randomized to allow or forbid AI assistance. The tooling was Cursor Pro with the Claude Sonnet models of that period.

Now the caveat, which is not optional. METR itself now labels this study historical, notes explicitly that it does not necessarily reflect current tools or workflows, and changed its experiment design in February 2026. Anyone citing 19% as a fact about AI coding tools in 2026 is misusing it — including anyone citing it in support of the argument this article is making. It is a 2025 finding about 2025 tools. Cite it that way or do not cite it.

So what survives the caveat? Not “AI makes developers slower.” The tools have changed, the harnesses have changed, and the study was never designed to hold across model generations. What survives is narrower and considerably more useful to you:

• Perceived speedup is not evidence of speedup: The developers in the trial were not fooled by a marketing claim. They were fooled by their own experience of doing the work. Self-report was wrong by nearly 40 points in the direction people wanted it to be wrong.
• The effect was largest exactly where legacy work lives: High-context, unfamiliar-to-the-model codebases with strict quality bars and a maintainer who knows where the bodies are buried. That is the profile of every legacy modernization engagement.
• Model capability was not the binding constraint: The developers spent time reviewing, correcting, and re-prompting. On a large old codebase the cost of verifying an AI-proposed change is the dominant cost, and it scales with how little anyone understands the system.
• The remedy is measurement, not abstinence: The correct response to an unreliable perception signal is an instrument, not a policy. Baseline your change lead time and defect rate before the program starts, because afterwards nobody will be able to tell you honestly whether it helped.

Two adjacent data points give the same signal from a different angle, and both are large-sample. Google's DORA research on AI-assisted development (roughly 5,000 professionals, fielded mid-2025) found 90% using AI at work while 30% reported little-to-no trust in AI-generated code. Stack Overflow's 2025 developer survey (n≈49,000) found 46% distrust AI accuracy against 33% who trust it, only 3.1% highly trust it, 66% cite output that is “almost right, but not quite” as the top frustration, and 45% say debugging AI-generated code takes longer than writing it themselves. Note there is no 2026 edition of that survey; those figures are 2025.

“Almost right, but not quite” is the exact failure mode that makes legacy work dangerous. In a greenfield system, an almost-right change fails a test you wrote last week. In a forty-year-old system with no tests, an almost-right change ships.

Common legacy-modernization claims mapped against the available evidence — Frenchy Digital, August 2026.

Reframe the problem and the value becomes obvious. The reason nobody wants to touch your legacy system is not that the language is old. It is that the system's behavior exists only in the code, and nobody has read all of the code. The original authors are gone. The documentation describes a version from three acquisitions ago. The business rules are distributed across copybooks, batch jobs, stored procedures, and one screen that only Denise knows how to reach.

That is a comprehension problem, and comprehension is what these models are genuinely good at. Reading a large corpus and producing structured summaries with citations back to the source is close to the core competence. Producing correct novel code against undocumented constraints is not.

Every use below shares three properties that make it safe: the task is read-heavy, the output is a reviewable artifact rather than a production change, and being wrong is visible rather than silent. That is the filter to apply to any proposed agent use on a legacy system.

Legacy modernization tasks where AI agents produce reliable value, and the human role in each — Frenchy Digital, 2026.

Business-rule extraction deserves its own note because it is where the durable value usually sits. A rule like “accounts flagged before the 1998 migration are exempt from the late fee unless the branch code is in this list” is a business asset currently trapped inside a dying language. Getting it into a specification a domain expert can read, argue with, and correct is valuable whether or not you ever migrate — and it is the input that makes the migration possible at all. Several of our engagements have produced more organizational value from the extracted specification than from the code that was eventually written.

One technical constraint governs all of this work: context. Anthropic's engineering guidance on context describes context rot — accuracy degrading as context grows, well before the window fills — and frames context as an attention budget rather than a storage budget. On a million-line codebase this is not a theoretical concern. The approaches that work are just-in-time retrieval instead of preloading, compaction that preserves architectural decisions and unresolved questions, structured note-taking to external files that survive context resets, and sub-agent isolation where a searching sub-agent holds detailed context privately and returns a condensed summary of roughly a thousand to two thousand tokens.

Wholesale automated language translation — point the tool at COBOL, receive Java — is the most seductive pitch in this category and the one with the thinnest evidence. It is seductive because it appears to solve the entire problem in one purchase, and because a demo on a well-structured module genuinely looks impressive.

The failure mode is not syntax. Mechanical translation of syntax is a solved problem and has been for years. The failure modes are subtler and all of them are expensive:

• Translated structure preserves the wrong things: You get Java that faithfully reproduces the shape of decisions made under 1985 constraints — fixed-width records, batch windows, storage economics that no longer exist. It compiles. It is not modern software; it is COBOL with braces, and now nobody wants to touch it either.
• Implicit behavior does not survive: Numeric precision, rounding, collation order, date handling, null semantics, and overflow behavior differ between runtimes. A translation that is 99.9% behaviorally identical is a translation that is wrong on the 0.1% of transactions that will end up in a regulator's letter.
• Dead code gets translated too: Without a live-versus-dead analysis grounded in production telemetry, you pay to translate, test, and maintain code that has not executed since 2011 — and you inherit its bugs into the new system.
• The test gap is inherited, not fixed: If the source had no tests, the translation has no tests. You now have two untested systems and a cutover decision, which is strictly worse than the one untested system you started with.
• Verification cost dominates: Somebody has to confirm the translation is correct, and that somebody needs to understand the original. The scarce resource was never the typing.

None of this means the tooling is useless. It means the tooling is a component in a program whose critical path is comprehension and verification, not code production. Used after characterization tests exist, module by module, with a domain expert reviewing extracted rules, automated translation is a real accelerator on the part of the work that was never the bottleneck. Used as the program itself, it produces a second system nobody understands.

A migration you cannot verify is not a migration, it is a bet. Build the characterization suite first and the translation tooling becomes genuinely useful. Skip it and no amount of model capability tells you whether the output is correct.

— Frenchy Digital architecture principle

Here is the honest state of the tools, with the evidentiary status of each attached. Everything marked vendor-stated is a capability claim from the company selling it, not an independent evaluation — that distinction is the whole point of the table.

Legacy modernization tooling and the evidentiary standing of each capability claim — as of August 2026.

On IBM specifically. watsonx Code Assistant for Z performs COBOL-to-Java and PL/I-to-Java transformation alongside application analysis, and release 2.8 added an agentic workflow in 2026. IBM also previewed Project Bob at TechXchange 2025 for general availability in 2026. These are the vendor's own descriptions of what the products do. IBM has published no independent productivity measurement, and neither has anyone else. That does not make the tooling bad — it is the most serious offering in the category and it is worth evaluating seriously. It makes the tooling unproven, which is a different thing and calls for a different procurement posture: a paid pilot on a module you select, benchmarked against a human baseline you timed.

On integration plumbing. The Model Context Protocol is now the standard way to expose tools to an agent, and it stopped being any one vendor's asset in December 2025 when Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, with Block and OpenAI as co-founders and Google, Microsoft, AWS and Cloudflare supporting. The latest spec revision is dated July 28, 2026. For a modernization program this matters for one practical reason: the wrappers you build around your legacy system — a read-only query tool, a job-status tool, a schema-inspection tool — should be MCP servers rather than bespoke integrations, because they will outlive whichever agent framework you pick this quarter.

On durability.Migration runs are long. A characterization-test generation pass across a large module set, or a staged data migration, can run for hours or days, and a process that cannot resume from a crash is a process you will run twice. Durable execution engines address this directly — Temporal's official integration with the OpenAI Agents SDK reached general availability on March 23, 2026, providing crash-resume and replay. That is infrastructure, not orchestration semantics, and it is consistently underrated in agent architecture discussions.

Here is the thing that determines whether your project is feasible, and it usually gets discussed in week six instead of week one. Legacy systems rarely have APIs. An agent can read your codebase all day — reading is easy. The hard problem is the write path: how does the agent, or the system you are building around it, actually cause something to happen inside a system that was designed before REST existed?

There are six realistic answers and they differ enormously in reliability. Pick before you scope, because the choice cascades into every other decision.

Write-path options for agents interacting with a legacy system, ranked by reliability — Frenchy Digital, 2026.

On computer-use agents, honestly. The pitch is that if the system has a UI, an agent can drive it, and no integration work is needed. That is true in a limited and well-characterized set of conditions: structured, single-site, short-horizon flows against a stable interface, where a wrong action is recoverable. Outside those conditions it degrades badly — long-horizon multi-step tasks, drifting selectors and layouts, session interruptions, authentication walls, and anything where a wrong click cannot be undone.

The commercial record is the most legible evidence available on this, and it is not encouraging. Both flagship consumer browser agents have been shut down. OpenAI deprecated Operator and shut it down on August 31, 2025, folding the capability into ChatGPT agent. Google shut down Project Mariner on May 4, 2026, absorbing it into Gemini Agent and AI Mode, and the stated reasons were specific and technical: heavy compute for real-time visual processing, slow performance, and form-selection errors. Two of the best-resourced teams in the industry took their consumer browser agents off the market. That is a data point about the current reliability of the capability, not about ambition.

The capability itself is real and available — Anthropic offers computer use as an API capability where you run your own sandboxed virtual machine, alongside a macOS research preview launched March 24, 2026. Benchmark context helps calibrate: on OSWorld, 369 real operating-system tasks, the human baseline is 72.36%. Self-reported leaderboard entries for frontier models now sit in the mid-eighties, but the same models' verified scores on Anthropic's own model cards land around 72–73% on OSWorld-Verified — a six-to-eleven-point gap on identical models, where the scaffold and attempt budget explain more than the model does. And these benchmarks measure happy paths. Per-action latency compounds: a hundred-step session accumulates a lot of round trips, and each one is an opportunity to click the wrong thing.

This is the layered architecture we deploy. It is designed around one assumption: the agent will be wrong, repeatedly, in ways that are not obvious. Every layer exists to make that survivable.

Reference architecture for an AI agent operating against a legacy system — Frenchy Digital, 2026.

Two layers carry most of the weight. Layer 2, the deterministic scaffold, is the one teams skip and the one that most improves results. Call graphs, dependency inventories, schema dumps, and coverage reports are cheap to produce with conventional tooling, they are reproducible, and they are correct. Feeding them to the agent as facts is strictly better than asking the model to infer them, and it collapses a large amount of token spend and hallucination surface at the same time. Run the deterministic tools first, always.

Layer 5, the test-first change gate, is the one that gets deferred and should not be. The rule we enforce is simple: no change is proposed against a module that lacks characterization coverage. Not “we will add tests after” — no proposal at all. This is unpopular in week two and it is the reason these programs survive month six.

A note on layer 6. The distinction between a proposal and a commit is the whole safety model, and it degrades quietly. Teams start with careful review of every diff, then reviewers get faster, then approvals become clicks. Instrument it: track review duration as a distribution rather than an average, track the share of proposals modified before merge, and treat a flat modification rate as a broken control rather than a perfect model. A review step nobody performs is a review step you have removed while keeping the paperwork.

An agent operating against a system of record is a high-blast-radius agent and needs the controls that go with that. The specific hazard in legacy work is that the systems involved usually lack the fine-grained authorization that would contain a mistake. There is often no per-record permission model to fall back on. The credential either can update the ledger or it cannot.

Governance controls for AI agents operating against legacy systems of record. Cross-reference the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework.

Prompt injection deserves a paragraph of its own, because the legacy context makes it worse. A codebase is a large body of text that your organization did not fully author and has not fully read. Comments written by contractors who left in 2003. String literals containing customer-supplied data. Test fixtures built from production exports. Vendored dependencies nobody audited. README files, migration scripts, and the ticket bodies your agent reads to understand a change request. Any of it can contain text that a model interprets as instruction rather than data.

The approval-gate detail is worth stating precisely because it is where well-intentioned designs fail. An approval prompt that reads “update the customer record” is not an approval — it is a template. The human must see the resolved values: which environment, which connection, which table, which key, and the actual diff. If an injection has redirected the target, the resolved display is the layer where a human has any chance of noticing.

On cost controls. Modernization workloads are long-running and read-heavy, which is exactly the shape that produces surprise invoices. Anthropic's figures give the scale: agents use roughly 4× the tokens of a chat interaction, multi-agent systems roughly 15×. As of August 2026 the mechanics that matter most on Anthropic's published pricing are prompt caching — a five-minute cache write costs 1.25× base input, a one-hour write 2×, and a cache read 0.1×, so the break-even is one read for the five-minute TTL and two for the one-hour — and the Batch API at 50% off both input and output, which stacks with caching. Both are highly applicable here, because a codebase-comprehension prompt has an enormous stable prefix and most archaeology work is not latency-sensitive.

Two traps worth knowing before you build a budget. The minimum cacheable prefix is model-dependent and non-monotonic — 512 tokens on the newest tier, 1,024 or 2,048 on others, and 4,096 on several — and below the floor the request silently does not cache at all. And the tokenizer changed: Claude 4.7 and later, including Sonnet 5, produce roughly 30% more tokens for the same text. The per-token price did not change; the cost per request did. Re-baseline with a token-counting call rather than applying a multiplier to last quarter's numbers.

You cannot manage this work without measurement, and the measurement you are being offered is not the measurement you need. Public coding benchmarks have a contamination problem severe enough that leaderboard position carries almost no information about performance on a codebase the model has never seen — which is precisely your situation.

The clearest single comparison: on SWE-rebench's fresh, decontaminated task set — 111 problems drawn from 65 repositories, collected between May 15 and July 1, 2026 — frontier models land at roughly 64%. The figures circulating from vendor self-reports on SWE-bench Verified are around 95%. Same class of task, roughly 30 points apart, and the main variable is whether the model could plausibly have encountered the problem during training.

Coding-benchmark standings and their validity problems, with primary sources — as of August 2026.

Three findings make the case that this is a structural problem rather than a quirk of one benchmark. First, OpenAI formally retired SWE-bench Verified in February 2026 after auditing 138 problems its models failed, each reviewed by at least six engineers: 59.4% had material test or description flaws. Second, contamination research found models score three times better on SWE-bench Verified than on decontaminated equivalents and six times better at locating edited files without project context, a result the authors describe as logically impossible without prior exposure. Third, UC Berkeley researchers reached 100% on several major agent benchmarks without solving a single task, using pytest hooks, config leakage, and prompt-injected judges.

The practical conclusion for a modernization program is short: build a private eval from your own tickets. Anthropic's engineering guidance is the best primary source on the method, and its core advice transfers cleanly. Start with 20 to 50 tasks taken from real failures. Run each trial isolated from a clean environment, because shared state produces correlated failures and inflated scores. Grade the outcome rather than the path — rigid tool-sequence matching penalizes an agent for solving the problem a different way. Calibrate any LLM judge against human labels, and read sampled transcripts weekly rather than trusting the aggregate. Run the whole thing in CI on every agent change and every model upgrade.

• Weight the set toward legacy failure classes: Silent behavioral drift, boundary conditions, dead code that turns out to be live, undocumented data assumptions, and encoding or precision issues. These are the failures that reach production in an old system.
• Measure reliability, not just success: Sierra's τ-bench work established the distinction: pass^k requires all k trials to succeed. A model with pass^1 under 50% can fall to roughly 25% at pass^8 — a reliability collapse completely invisible to a single-attempt metric. On a system of record you care about the eighth attempt.
• Measure cost alongside accuracy: Princeton's HAL research found agents can be 100× more expensive while only 1% better, and that higher reasoning effort reduced accuracy in the majority of runs across 21,730 rollouts. Accuracy-only comparison will lead you to an expensive configuration that is not better.
• Sample production traces continuously: LangChain's guidance suggests starting at 10% trace sampling, with at least 20 labeled examples to calibrate a judge; human reviewers sustain roughly 50 to 100 traces per hour. Budget the human time explicitly — it is the part that gets cut.
• A 100%-pass eval has stopped telling you anything: It tracks regressions and gives no improvement signal. When your set saturates, add harder tickets from the same backlog.

One more caution on model selection. Benchmark scores also vary enormously with the harness rather than the model — bare-model, vendor-scaffolded, and full-system leaderboard variants of the same benchmark can differ by 30 to 50 points. If a vendor quotes you a number, the harness matters as much as the model name, and neither predicts your codebase.

Everything above resolves into an order of operations. The order is not negotiable, and most failed modernization programs failed because they ran it backwards — starting with a target architecture and a cutover date, then discovering in month nine what the system actually does.

Modernization sequencing with exit criteria per phase — Frenchy Digital, 2026.

On the strangler fig pattern. The name comes from Martin Fowler's description of the strangler fig, which grows around a host tree and gradually replaces it. Applied to software: you build the new system around the edges of the old one, route traffic capability by capability, and retire the original piece by piece. It predates the current wave of AI tooling by two decades, and that is a point in its favor — it is the migration approach with the longest track record of not producing catastrophes.

What AI changes is the cost of the phases, not the order. Comprehension gets meaningfully cheaper. Characterization test generation gets meaningfully cheaper. Seam selection, cutover decisions, and business-rule validation do not — those are judgment, and judgment on a system whose behavior is undocumented remains the expensive scarce input. A program that budgets for cheaper comprehension and the same amount of judgment is budgeted correctly.

On big-bang rewrites, one more consideration beyond the usual argument. A rewrite requires the organization to freeze the original while the replacement is built, which never happens, so the target keeps moving. It concentrates all risk on a single cutover event with no rollback. And it delivers zero value until the end, which means it is the first thing cut when budgets tighten in month eleven — leaving you with a half-built replacement and the original system still running. The exceptions are genuinely small systems and systems being replaced by a commercial product rather than rewritten.

These are the bands Frenchy Digital uses to scope AI agent engagements in 2026, applied to legacy modernization work. They assume the comprehension and test phases are in scope rather than assumed away, because assuming them away is what makes these programs overrun.

Frenchy Digital cost bands for AI agent engagements applied to legacy modernization, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, eval expansion, incident response, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

What moves a project within a band, in rough order of impact: how much documentation survives; whether anyone who worked on the original system is still reachable; whether production telemetry exists that can distinguish live code from dead; whether the system has any programmatic write path at all; how many downstream consumers depend on undocumented behavior; and whether a domain expert is genuinely allocated rather than nominally assigned. The last one is the most common cause of overrun and the least often budgeted.

One budgeting note that consistently surprises people: the model spend is not the cost driver. Even on a large comprehension pass, inference is typically a small fraction of a phase budget — the engineering time to review, correct, and integrate the output is the dominant line, and it is roughly the same whether the model is cheap or expensive. That is an argument for choosing the model that produces the least rework rather than the lowest per-token price, and for spending the caching and batching effort described earlier, which reduces the small line without touching the large one.

Every one of these has appeared in a real proposal we have been asked to review. None are hypothetical.

The Frenchy Digital red-flag list for AI-assisted legacy modernization proposals, 2026.

Ask any vendor for one thing before you sign: a paid pilot on a module you select, measured against a baseline you timed, with the characterization tests written first. A vendor who will not do that is selling a demo. A vendor who will is showing you what the tooling actually does on your code, which is the only evidence that exists.

— Frenchy Digital buyer’s principle

This article argues for a specific approach, so here are the ways that approach fails and the parts of the argument that are weakest.

• The evidence gap cuts both ways: There is no measured productivity number supporting AI-assisted modernization, and there is also no measured number refuting it. The honest position is uncertainty, not pessimism. METR is the closest thing to a rigorous measurement in adjacent territory, and METR itself says it is historical.
• Comprehension output can be confidently wrong: A generated dependency map or business-rule extraction that is 95% correct is dangerous precisely because it is mostly right — reviewers calibrate to its accuracy and stop checking. Every comprehension artifact needs validation against something external: production telemetry, a domain expert, or a test that actually runs.
• Characterization tests pin bugs as well as features: That is the intent, and it is also a trap. A test suite that enshrines a forty-year-old defect makes fixing that defect look like a regression. Tag tests as contract versus incidental as you go, or you will spend the migration arguing about which failures are real.
• Prompt injection has no solution: Every control in the governance section reduces blast radius. None of them prevent injection. If your risk tolerance requires prevention rather than containment, do not give an agent a write path to the system of record at all.
• Private evals are expensive and go stale: Building 20 to 50 real tasks with clean environments is real engineering work, and human review time is the part that gets cut first. An eval nobody maintains is worse than none, because it produces a green signal that means nothing.
• Human-in-the-loop degrades silently: Review quality decays as volume rises and reviewers acclimate. Without instrumentation on review duration and modification rate, you will not notice until an incident tells you.
• The organizational constraint usually dominates the technical one: Gartner's April 2026 survey found skills gaps and data quality each cited by 38% of I&O leaders as the blocker — ahead of tooling. Our own experience matches: the programs that stall usually stall because the domain expert was never really available, not because the model was not good enough.
• Model behavior drifts under you: Vendors ship new versions continuously and behavior changes without a commit in your repository. Pin versions, canary upgrades, and keep the eval set running — otherwise the answer to what your system did last quarter is a guess.

None of this argues against doing the work. It argues for doing it in an order where being wrong is cheap, with instruments that tell you the truth rather than what you hoped. The organizations getting real value from AI agents on legacy systems are, without exception in our experience, the ones that measured the before-state and kept measuring.

And the framing that matters most for a CTO deciding whether to start: the case for modernization does not depend on AI being transformative. A system nobody understands is a business risk regardless of tooling. Comprehension, documentation, and a test suite are worth building whether or not a model helped write them — and if the tooling turns out to be less capable than claimed, you still end up with an understood system instead of an untouchable one. Sequence the program so that it delivers that outcome either way.

Legacy modernization sits at the intersection of several harder problems, and the rest of this cluster covers them in depth. If your comprehension layer needs to serve answers across a large corpus, start with RAG for enterprise knowledge bases. If you are deciding how many agents the archaeology phase should fan out to, multi-agent systems architecture covers both sides of that argument with the primary sources.

For the private eval set and the tracing that makes it usable, see AI agent evaluation and observability. For the injection surface a legacy codebase represents, see prompt injection and the OWASP LLM Top 10. And for the caching, batching, and token mechanics that determine what a long comprehension pass actually costs, see LLM cost optimization and token economics.