One Problem, Many Models

Parts II and III separated Modeling from Alignment so that each could be examined clearly. In engineering work, the two are often entangled as new knowledge shapes the engineer's understanding of a problem. This interlude illustrates that process through one problem in DocAble.

The engineering techniques in this interlude may be familiar to you. An experienced engineer might recognize several of them immediately: reduce a working set, separate structure from payload, represent dependencies explicitly, analyze a critical path, bound concurrency, and measure the result. MAGE does not claim these techniques as new, nor does it replace the experience that helps an engineer recognize when to use them.

What MAGE does offer is a way of approaching problems with GenAI that affords fast iteration and sound, drift-resistant results. The engineer does not need to know the final model or architecture in advance. A problem may begin as an observation: a file fails, a service slows down, or a new requirement exceeds the system's current range. Modeling makes one consequential relation explicit; analysis suggests what to change or measure; implementation supplies new evidence; and that evidence may expose the next thing worth representing.

This interlude follows that loop from a memory failure through several changes in representation and architecture. The interest is not whether an experienced engineer could have arrived at the same design. It is whether the engineering process can discover, test, and preserve such knowledge systematically while implementation moves at agentic speed.

I. One Document, One Worker

DocAble originally treated an entire document as one unit of execution. A long-running Kubernetes worker opened the document, held the state needed for remediation in memory, modified it, and produced the result. Figure 3.5.1-1 traces how that execution unit later changed.

The document therefore served as both the user's artifact and the worker's in-memory unit of computation. Media needed by GenAI operations was read from that resident representation and sent to the model as needed.

For the small presentations used to develop the system, this worked well. The architecture was simple, and the document was a natural boundary: a user submitted a document and expected a document back. Nothing in the observed workload justified another unit of execution.

Experience eventually expanded the workload. Real teaching presentations carried more slides, images, and other media, and handling the whole document in one process began to put enough pressure on worker memory that the execution unit needed to shrink.

II. Pages as the Unit of Scale

As documents grew larger, whole-document execution put increasing pressure on worker memory. DocAble therefore introduced ChunkWorker, which divided a document into page ranges (Figure 3.5.1-1, panel b).

The new representation treated contiguous pages as independent work partitions. For a presentation, a chunk contained a range of slides together with the document state needed to remediate them; the system later recombined the resulting patches into the complete artifact.

Each worker now handled only part of the document, and multiple chunks could run concurrently. More importantly, chunking reduced the memory required by an individual worker. Memory affects both infrastructure cost and cold-start behavior, so a smaller worker was useful even for documents that did not strictly require chunking to fit.

Chunking worked across a much broader workload: ordinary teaching presentations and hundreds of documents from multiple universities. Page ranges gave each ChunkWorker a practical bound on its working state, and experience provided no reason to replace that design merely because another architecture was possible.

This architecture accommodated the inputs encountered so far. The page boundary gradually became part of how DocAble was understood: a document was divided into chunks because chunks were how large documents were processed. A roughly 250 MB media-heavy presentation eventually exceeded that operating regime.

Page boundaries were not the smallest possible partition. A sufficiently large slide could itself be divided into regions, shapes, media objects, or individual remediation operations. That would reduce the working set further. But finer partitions also impose costs: more coordination, more reconstruction, and less surrounding context available to each operation. Eventually the partition begins to cut across the semantic relationships needed to reason about the artifact.

This is the reasoning-horizon problem from Part I in architectural form. An agent can reason only over the information made available to it. Shrinking an execution unit may reduce its resource requirements while simultaneously shrinking the semantic context within which a judgment is made. Page chunking therefore had no hard scaling wall. It had an increasingly unattractive tradeoff: continue subdividing the artifact and pay both systems overhead and semantic loss, or reconsider why so much of the artifact had to reside in the worker at all.

The 250 MB presentation made the second question worth asking.

III. A New Class of Input

A 250 MB PowerPoint file does not imply that remediation needs 250 MB of document content resident in memory.

Modern Office documents use Office Open XML (OOXML). A .pptx, .docx, or .xlsx file is a package containing many parts. Much of its semantic structure is XML: text, slides, relationships, identifiers, and references among objects. Large binary assets such as images and other media live alongside those XML parts inside the package.

The file therefore holds two broad kinds of information. One kind describes document structure: slides, shapes, text, relationships, identifiers, and references. The other is media payload: images, animated GIFs, movies, and other embedded binaries.

The structural portion is comparatively small. It is largely text, and even an unusually large Office document may require only low megabytes to represent its semantic skeleton. The media payload can be hundreds of megabytes. Most remediation operations need only the structural portion; they may reach into the media, but not every media byte need be resident at once.

Until this point, DocAble had largely accepted the storage representation supplied by the document format as its working representation. For Office documents, that meant opening the OOXML package through the document library and letting its structure and media participate in the in-memory object graph; other formats followed analogous format-native representations. That was reasonable while the input sizes fit the worker. Handling a roughly 250 MB media-heavy file without allocating correspondingly large workers required us to reconsider the arrangement itself.

The existing representation coupled the two, and Figure 3.5.1-2 contrasts that arrangement with the one that replaced it.

So the architecture carried an implicit scaling relation: total media size drove resident worker state, and resident state drove the risk of running out of memory. Finer chunking could continue reducing how much of the document met this relation at one time, but it could not remove the relation itself—and increasingly fine partitions would introduce coordination costs and erode the semantic context available to remediation. On the observed workload that made no difference; the new file made it decisive.

A residency model made the alternative visible (panel b): the structural pipeline could operate on a lightweight representation while media lived in object storage, and operations that needed media could reach it by reference.

The 250 MB requirement had therefore exposed a relationship worth changing: the storage representation was also determining the worker's memory representation.

IV. Remove Media from the Working Set

The memory problem came from coupling document structure to media residency: total media size increased the worker's persistent working set even though most remediation operations needed only the document's structural skeleton. Skeletonization removes that coupling. For OOXML documents, the pipeline streams through the package, moves media into external storage, and leaves stable references in a much smaller structural skeleton.

Remediation then operates on the skeleton. If a GenAI operation needs an image, the worker follows the reference and streams that media through the network to the GenAI service without first materializing the document's complete media payload in worker memory. Recombination follows the same discipline in reverse. The worker no longer needs memory proportional to total media size.

The corresponding memory invariant states the property directly:

peak worker RSS <= C

where, within the declared operating envelope,

C =
    rolling stream buffer
  + structural skeleton
  + handles
  + remediation working set

and C does not grow with total media size.

The claim is stronger than the empirical claim available from chunking. Chunking had accumulated evidence that increasingly large documents worked, but those observations could not establish behavior for every larger media payload. Skeletonization supports a structural argument instead: within the declared operating envelope, peak worker memory is bounded independently of total media size.

No stage in the modeled path retains the complete media payload. OOXML media moves through bounded streaming buffers, the structural skeleton stays small relative to the media it references, and a media consumer holds bounded active state rather than accumulating the document's media. The guarantee depends on those assumptions; in particular, the write path must stream too. A supposedly streaming architecture that buffers the complete payload before writing it has only moved the memory spike.

The implementation enforces the assumptions behind the bound as invariants; measurement checks that the realized system behaves as the model predicts. The PDF path already shows approximately flat peak-RSS scaling across a count-scaled media sweep when each object is flushed; the corresponding OOXML media-size sweep remains a designed validation step.

None of this proves that arbitrary documents can never exhaust memory. A document could expose another scaling dimension: pathological structure, an individual object beyond the supported bound, excessive concurrency, or something not yet modeled. It closes a narrower class: within the modeled envelope, total media size no longer determines worker memory.

V. Once Memory Is Solved, Why Are We Chunking?

Page chunking had served two roles at once: it partitioned execution and bounded each worker's memory. Skeletonization largely removed the memory requirement. That left a separate question: what should determine the unit of execution?

A page tells us where content occurs, not which computations depend on which others. DocAble already represented remediation as a dependency graph. Consider alt-text generation as a concrete example. Each page can first be analyzed independently. Those analyses feed an operation that builds shared document context. Once that context exists, the GenAI queries that generate alt text for individual images become ready to execute independently. The actions and their information dependencies form a remediation graph; the currently executable actions form its frontier.

The same graph admits different execution policies. Figure 3.5.1-3 shows the distinction.

The graph explains the ordering. Independent work can run together; a consumer waits only for information it actually needs from upstream. Pages do not create those dependencies. Information does. Expressed as a directed acyclic graph, the work currently ready to execute forms a frontier: the nodes with no unmet dependencies. A worker executes that frontier, materializes its outputs, and thereby exposes the next frontier.^** This is ordinary topological traversal of a directed acyclic graph, familiar from compilers, build systems, and dependency schedulers.

This reframes ChunkWorker. Page-oriented and frontier-oriented execution are not different remediation graphs. They are different ways of partitioning the same graph. Page execution groups work by where it occurs; frontier execution groups work by when it is ready.

Skeletonization removed the memory pressure that had made page ranges the natural execution boundary, so page identity no longer needs to determine execution. It can survive as metadata on graph nodes—useful for locality, debugging, rate limiting, or failure isolation—without remaining the fundamental unit of executable remediation.

For the present problem, the architecture therefore needs only a clean seam between the remediation graph and its executor: the graph supplies ready work and its dependencies; the executor consumes them. The executor can schedule by frontier now and exploit page locality later if measurements justify it. There is no need to build a strategy hierarchy merely because two policies are conceivable. The graph/executor seam preserves the degree of freedom without spending it. In the realized architecture, that execution-driving representation remains distinct from richer analytical projections built over the same computation identities. The distinction matters later: a model may govern realization while another view of the same structure serves analysis.

VI. Analyze Before You Build

Representing remediation as a dependency graph does more than provide an execution plan. The graph can be analyzed before an executor — or a proposed architectural change — is implemented. Figure 3.5.1-4 shows three such analyses.

Given the weighted graph in panel (a), the model reports which operations may run concurrently, which must wait, and that adding workers cannot shorten a dependency edge; the heaviest chain from start to finish is the critical path. If one node dominates that path, the model has found an optimization target, and the next question is structural: must it be one node? If its semantics permit decomposition, splitting it can expose parallelism and shorten the path (panel b), discoverable from the model with no implementation of the split. The graph cannot promise the optimization will pay off, since smaller operations may add coordination cost, lose batching efficiency, or contend for another resource; but it names the candidate and the quantities that decide whether it helps.

Dependencies can be redesigned

The same analysis exposed a problem in contextual image description (panel c). If each image description consumed the description generated for the preceding image, the operations formed a serial SCAN: for N images the dependency depth approaches N, so if each GenAI call takes roughly t, the serial floor grows as about N·t, and more workers cannot remove it. But the requirement is not to generate alt text serially; it is to give each image enough surrounding context to produce an adequate description. Rendering the surrounding pages up front and treating those thumbnails as a shared visual IR supplies that context: each image then consumes bounded neighboring visual context instead of a sibling's generated alt text, the payload grows but the dependency disappears, and the operation stays a parallel MAP. The analysis also clarified the requirement. Good alt text needs sufficient visual context; it does not require serial generation. That context can itself be represented and reused, just as textual document context already is. The model changed the proposed implementation before that implementation existed.

Predicting latency

The same graph supports a first-order latency model. For the representative workload used during this analysis, the relevant GenAI chain had three dependent levels whose per-call times add to an irreducible floor (Figure 3.5.1-5).

The current in-process design had local concurrency of six, so a 37-image alt-text frontier required seven waves, for a predicted total of about 32.788 s. A distributed frontier executor with modeled cloud concurrency of 64 could execute the 37-wide level in a single wave, but would pay cold-start and round-trip taxes for each graph round — about 11.4589 s under the current estimated parameters.

The local concurrency limit of six was not merely a scheduler setting. In the ChunkWorker architecture, each concurrent worker opened and manipulated its own format-native document state, including associated media objects. Increasing concurrency therefore multiplied pressure on CPU and, especially, the machine's working memory. The concurrency cap kept that aggregate resource demand within the practical operating envelope of the host.

Skeletonization changes that constraint as well. Once workers retain the structural skeleton while media streams on demand, concurrency no longer multiplies the same large resident media state. The frontier executor can therefore exploit graph width without requiring every concurrent operation to carry a page chunk's format-native working set.

The model therefore predicted roughly a 2.9× advantage for frontier execution on that workload: the existing design pays about 24.6 seconds in width serialization, while the distributed design trades that for about 3.3 seconds of modeled round overhead. Several cells remain estimated and need staging measurements before any production cutover, but the number is useful before it is perfectly calibrated. It says why the candidate should win, and it says what to measure next.

Predicting the cost of a design change

Models can also answer questions about designs that do not exist yet. Suppose an engineer proposes another intermediate representation. Adding that IR creates a new fact and perhaps another dependency edge; the critical-path model can insert the proposed node into the DAG and recompute:

• Δ critical-path floor
• Δ above-floor latency
• Δ execution rounds
• Δ peak width
• whether the proposed node lands on the critical path

An IR off the critical path may add no serial latency; one that deepens the critical chain adds its call time to the floor and may add another distributed round. The model therefore supports an explicit marginal-cost query for a proposed representation — again, before any implementation. This is ordinary engineering analysis, applied before code exists.

Use prediction error as evidence

Implementation eventually supplies measurements, and the useful comparison is not simply whether the result was fast. A residual — the gap between prediction and observation — turns into an engineering question, and it drives a loop that runs both before and after implementation (Figure 3.5.1-6).

The residual creates an engineering question. The queue overhead may have been underestimated. Two apparently independent nodes may share a serialized resource. Media loading may add a cost the latency model omitted, or the graph itself may be missing a real dependency. A prediction that matches observation provides evidence that the model captures the dominant mechanisms; a miss identifies where the model or system deserves investigation. Modeling thus contributes both before and after implementation: before, it compares designs and exposes optimization targets; after, disagreement between prediction and observation helps find what the model missed.

VII. The Resulting Model Family

The large-file requirement did not produce one model. It produced a connected family, each member answering a different question. Table 3.5.1-1 collects them.

These models take different forms because they answer different questions. Some are typed graphs, some quantitative functions, some declarations of entities and invariants. They stay separate and compose through shared identities and explicit relationships: the remediation graph and fact catalogue supply the static dependency structure; the batch model supplies per-call cost; the critical-path model combines them into latency; the distribution model supplies the execution topology the coordination taxes are charged against; and the media-residency model supplies the independent memory bound that makes the execution design affordable.

Together they answer questions that would otherwise invite implementation experiments: what happens if we add an IR, where the critical path lies, whether splitting a node exposes useful parallelism, at what frontier width distributed execution beats local execution, how peak memory changes as media grows, and which assumption a measurement would have to violate for a prediction to be wrong. Some answers are structural and some require calibrated measurement; a good model says which is which.

From examples to a bound

The memory story shows the progression clearly:

1. "My simple decks work."
2. "My real decks work."
3. "Hundreds of documents from several universities work."
4. "The 250 MB media-heavy deck does not."
5. Model the relationship that failed.
6. Remove total media size from the worker-memory equation.
7. Enforce the assumptions that the bound requires.

Steps 1–3 accumulate empirical evidence; step 4 exposes the boundary of that evidence. Steps 5–7 do something different: they seek a property over a declared class of inputs. The resulting guarantee is deliberately narrow — within the modeled envelope, total media size does not determine peak worker memory. Other unknowns remain possible; a future artifact may expose another structural dimension or another resource limit, and MAGE offers no reason to pretend otherwise. But if the next 250 MB deck arrives because it carries more media, the architecture should not have to learn this lesson again.

Three days

Laid out this way, the sequence looks like a substantial architecture project. It included the large-file requirement, skeletonization and streaming, typed-patch work, the reconsideration of ChunkWorker, remediation and fact graphs, quantitative analysis, and the chunkless execution design. It also included implementation and corrections when assumptions proved wrong. The elapsed engineering time was about three days, working inside the existing governed engineering environment.

The significance of that number is not that these are unusually difficult techniques, or that an experienced engineer could not have reached the same conclusions. It is that the models were cheap enough to participate in the engineering loop rather than follow behind it. Dependency graphs, performance models, data-flow models, invariants, and intermediate representations are established software-engineering tools. Their cost has long limited how aggressively engineers use them. A model that takes a week to build may describe code that changes the next day, so the rational response is often to model less, implement the candidate, and measure.

Agentic implementation changes that calculation—but only if engineering reasoning can move with it. In this example, models and implementation evolved together. The residency model stated the memory property the implementation had to preserve. The remediation graph showed that page chunking was one scheduling policy rather than the structure of remediation itself. The critical-path model rejected a serial SCAN before anyone built it and identified a wide node as an optimization target. When implementation disagreed with a prediction, the discrepancy became another engineering question rather than an invitation to keep patching until the tests passed.

None of those models needed to describe the whole system. Each needed to make one consequential question cheap enough to answer before implementation answered it by default. Three days matters because, at that timescale, modeling and analysis can remain inside the implementation loop.

Finding the models

Part IV asks engineers to find the models their work needs. This example shows what that instruction means in practice. Nobody began with a plan to construct seven models. The whole-document architecture worked until larger workloads made memory consequential. Page chunking solved that problem across the workload then observed, but a media-heavy document exposed a remaining scaling relationship. Modeling residency led to skeletonization; skeletonization removed the memory rationale for page partitioning; the remediation graph then exposed causal structure; and critical-path analysis exposed latency limits and optimization opportunities.

The sequence was discovered, not prescribed. Each model appeared because the previous design exposed a question that implementation alone could not answer well. Some questions concerned structure: what depends on what? Some concerned bounds: what determines peak memory? Others concerned prediction: where is the latency floor, and would another worker help? The form followed the question.

This is why the process is not the linear one—design, then implement, then document with models—but a loop in which implementation, measurement, and analysis expose the next thing worth representing (Figure 3.5.1-7). A model need not describe the whole system, nor need it survive forever. It needs to make some consequential property easier to reason about than the implementation itself does. Some models become durable engineering capital because later decisions keep depending on them; others settle one question and disappear. Keep a model while the questions it answers justify its cost.

This changes what "model-based" can mean in an agentic engineering process. It need not mean specifying the system completely before implementation begins. Implementation can move quickly, expose a question, and supply measurements while the engineer builds just enough representation to reason about what matters next. The danger is that cheap implementation makes the other half of that loop easy to skip: try something, see whether it works, and try something else. That approach produced the first three steps of the memory story—more examples of success—but it could not produce the bound.

None of the engineering techniques in this interlude requires MAGE. An experienced engineer might have recognized some of them earlier, chosen different representations, or found a better architecture. MAGE offers something different: a disciplined way for the engineer and the agent to discover what the particular system needs. Observations become questions; questions motivate models; models support predictions and constraints; implementation supplies evidence; and discrepancies expose what remains poorly understood. What is learned can then become part of the engineering environment rather than remaining only in the engineer's head.

The objective is not to replace engineering judgment with models, or to make familiar software-engineering techniques sound new. It is to make good engineering reasoning systematic, controlled, and fast enough to keep pace with agentic implementation.