Agentic Systems Load (ASL)

Measure the work around code generation.

AI can generate code quickly. The expensive part is often discovering the right business rules, coordinating interpretations, and proving that a change is correct.

This paper proposes Agentic Systems Load (ASL) as a measurement framework, not an established law. It separates what can be counted from what must be experimentally calibrated. The core unit is task-specific: one Agent Load Unit (ALU) is one adjudicated context element required for a particular task. Product-wide complexity is a registry of potential elements, not a load that can be assigned to an agent without a task.

The economic model is additive and dimensionally consistent. Generation, reconstruction, coordination, verification, and expected failure cost are measured in the same unit — usually money or time. Context ratios are predictors of cost; they are not themselves costs and cannot make development free when they equal zero.

What this revision does

• Retires the ambiguous term Hidden Context Tax (HCT) and replaces it with a bounded Hidden Context Ratio (HCR) plus a separately measured Hidden Context Cost (HCC).
• Defines Agent Context Capacity (ACC) empirically at a target reliability, rather than deriving ALU capacity from token-window size.
• Uses set union for multi-agent coverage, so overlapping agent knowledge is not counted twice.
• Replaces universal formulas with observable accounting identities and testable statistical hypotheses.
• Positions GITMIR as one implementation pattern to test, not as a conclusion implied by the framework.

One name, one meaning, one unit.

Every metric is either directly observed, adjudicated after the task, or estimated under an explicit calibration protocol.

What ASL measures — and what it does not.

ASL is a task-level framework for observing how software context affects agent cost and reliability.

A software change depends on more than files and tokens. It may require state-transition rules, permissions, external contracts, invariants, prior decisions, exception paths, and business outcomes. These facts can be short in text yet decisive in effect. ASL treats them as task-relevant context elements.

ASL does not claim that every element has equal cognitive weight, that a universal ALU table exists, or that one formula predicts cost across models and repositories. It provides a common counting protocol so teams can collect comparable traces and learn local coefficients.

Three layers must remain separate

Unit of analysis

The unit is one task attempt under a defined environment: model version, tools, repository revision, prompt, available context sources, acceptance test, and stopping rule. Without these controls, a task cost cannot be compared across runs.

Boundary conditions

• ASL applies to changes for which correctness can be adjudicated after execution.
• It does not infer hidden business intent that no stakeholder, artifact, or system behavior can establish.
• It reports uncertainty when reviewers disagree on whether an element was required.
• It does not use product-wide line count as a proxy for task load.

Task-conditioned ALU and explicit sets.

The same repository can impose a small load for one task and a large load for another.

2.1 Agent Load Unit (ALU)

One ALU is one atomic, adjudicated context element that must be interpreted correctly for a specific task. Atomic means that the element can be marked required, delivered, applied, or missed without depending on a second label inside the same item.

An API, service, table, or module has no fixed ALU value. It contributes only the task-relevant elements identified by the rubric. This removes the conflict between task load and artifact size.

2.2 Required, delivered, applied, and reused sets

R(τ) is the required set. V(τ) is the subset explicitly delivered and retrievable before the relevant decision. A(τ) is the subset demonstrably applied correctly. U(τ) is the subset reused from validated persistent project state. If R(τ) is empty, the task is excluded from ratio analysis rather than divided by zero.

Count what happened before predicting why.

ASL v2 starts with trace data and keeps model assumptions visible.

3.1 Hidden Context Ratio (HCR)

The bands are reporting conventions, not validated universal thresholds. Teams should replace them after collecting enough local data.

3.2 Agent Context Capacity (ACC)

ACC is measured in ALU at a target success probability p under protocol q. The protocol fixes model, tools, retrieval, context order, task family, and acceptance criteria. Token-window size may influence ACC, but it is not converted to ALU by multiplying uncalibrated quality factors.

3.3 Directly observed costs

Measure hidden context without requiring it as input.

The reference set is built after the run from evidence that was not necessarily available to the agent at decision time.

Pre-task use

Before execution, teams may calculate a Context Coverage Estimate from known acceptance criteria and product models. It must be labeled an estimate. HCR is reserved for the post-task value based on an adjudicated reference set.

Costs add; context ratios predict.

The accounting identity remains valid even before any predictive relationship is calibrated.

5.1 Observed task cost

Every term must be expressed in the same unit. For financial reporting, convert tokens, tool use, agent time, and human time to money. For operational reporting, keep separate time and money views if conversion rates are disputed.

5.2 Risk-adjusted expected cost

DirectCost includes generation, reconstruction, coordination, and verification. ExpectedLoss may include rollback, incident response, revenue loss, or downstream correction. The failure probability and loss distribution must be estimated from historical or experimental data.

5.3 Predictive model — hypothesis, not law

Here u = |R| / ACC. Coefficients are learned separately for a task family and workflow. The interaction term allows cost to accelerate when both hidden context and capacity utilization are high, but no universal exponential curve is assumed. At HCR = 0, cost remains positive because generation and verification still exist.

Token Burn Rate

TBR is reported directly as tokens or billed cost per accepted task. Claims of nonlinear token growth are empirical hypotheses tested against utilization; they are not embedded in the definition.

Coverage is a union, not a sum of capacities.

Two agents that know the same thing do not cover twice as much of the task.

For agent i, let A_i(τ) be the required elements it demonstrably applies correctly. Team coverage is the union of those sets.

Overlap is not automatically waste. It may be intentional redundancy for safety or independent review. ASL reports it so teams can distinguish deliberate verification from accidental duplication.

Coordination cost remains separate

Csync is measured in time or money, not ALU. It includes context transfer, plan handoff, conflicting decisions, duplicate exploration, merge resolution, and reconciliation of stale state. It can be compared with the incremental coverage or reliability created by an additional agent.

Measure divergence over the time it can cause harm.

A stale product model is useful only if drift is detected, bounded, and repaired.

7.1 Agent Context Drift (ACD)

At time t, compare accepted implementation state S_real(t) with the structured state exposed to agents S_model(t). Use a weighted set difference so high-impact rules can carry larger business weights than labels or descriptions.

The integral ends when the model is repaired, so detection and recovery are represented. Unlike D × T × connectivity, the formulation does not count time twice or assume drift grows forever.

7.2 Agent Verification Load (AVL)

AVL is observed verification effort, reported in minutes or money. Reviewers record time spent checking intent, related objects, constraints, plan validity, implementation, side effects, and business acceptance criteria.

Changed ALU, change connectivity, and intent uncertainty may predict VC, but their coefficients require calibration. They are not multiplied as if they were already measured in compatible units.

Minimum drift controls

• Version every model element and link it to repository revision or deployment state.
• Detect code changes that touch modeled objects and require confirmation or regeneration.
• Preserve decisions, acceptance evidence, and the reason for exceptions.
• Report model freshness and unresolved mismatches before an agent begins work.

A partial-refund task, measured step by step.

The numbers below are synthetic and demonstrate the method only. They are not GITMIR benchmark results.

Task: add partial refunds to paid orders while preserving payment, ledger, inventory, notification, and permission invariants.

Before execution, 15 required elements were delivered in retrievable artifacts. Eleven of those came from previously validated project state. Trace and result review found that the agent correctly applied 21 required elements.

Six falsifiable hypotheses.

Each hypothesis can be tested without purchasing GITMIR and without trusting the framework's author.

Minimum experimental report

• Task sampling and exclusion rules; repository and model versions; acceptance test.
• Agent, context window, tools, retrieval configuration, prompt, and stopping condition.
• ALU counting rubric, reviewers, agreement score, and adjudication process.
• Raw trace metrics plus accepted-first-pass rate, correction loops, and escaped defects.
• Effect sizes, uncertainty, failures, and negative results — not only averages.

ASL connects established findings; it does not replace them.

The proposed contribution is a task-level bridge between software context, agent traces, and economic cost.

Novelty claim

ASL does not claim that persistent specifications, code graphs, context retrieval, modularity, or coordination cost are new. Its proposed novelty is the operational linkage of: (1) an adjudicated task-required context set, (2) the context delivered and applied by agents, and (3) observed reconstruction, coordination, verification, and failure cost.

A valid contribution must therefore be demonstrated by measurement quality and predictive usefulness, not by terminology alone.

Several product categories can reduce ASL.

The framework does not imply one exclusive architecture or vendor.

GITMIR as an implementation example

GITMIR focuses on a living business-logic model connected to agent execution: entities, fields, states, pages, services, events, requests, data flows, tasks, decisions, completed changes, and remaining work. Its intended mechanism is to increase delivered and reused context, reduce repeated reconstruction, expose change consequences, and leave project state for the next participant.

This description is a mechanism claim, not evidence of effect. GITMIR should be compared with repository-only, code-graph, and spec-driven baselines on the same tasks using the metrics in this paper.

Prove the business result task by task.

A credible product claim needs matched evidence, not a formula that already assumes the product works.

Recommended baseline conditions

Primary outcomes

Secondary diagnostics

• HCR, CRR, and CD with adjudication agreement.
• Repeated file reads, search calls, restarts, correction loops, and duplicate agent work.
• Time to accepted result, not time to first generated diff.
• Drift exposure and the time needed to restore synchronization after code changes.

A useful framework must be easier to falsify than to market.

ASL v2 is designed to produce measurements that can disagree with its central hypothesis.

Limitations

• ALU adjudication is labor-intensive and may vary across reviewers; agreement and provenance are mandatory.
• Atomic elements differ in importance. Weighted analysis can supplement counts, but weights must be defined before outcome review where possible.
• ACC is local to a task family and protocol. It must not be transferred across models, repositories, or tool configurations without validation.
• Matched runs may have learning and order effects. Randomization, counterbalancing, and sufficiently large task samples are needed.
• Production failure cost is heavy-tailed and often censored; averages alone can be misleading.
• A living model can itself create drift, maintenance cost, and false confidence. Those costs belong in the comparison.

Conclusion

Agentic software development should not be evaluated only by code-generation speed. Teams also pay to discover context, reconcile interpretations, verify behavior, and repair failures. ASL v2 provides a dimensionally consistent way to observe those costs and connect them to task-relevant context coverage.

The framework makes three disciplined claims: task load is task-specific; context ratios are not costs; and product value must be demonstrated through matched outcomes. If future experiments show that HCR and utilization do not predict reconstruction, verification, or failure, the framework should be revised or rejected.

The practical goal is not a literal zero-hidden-context environment. It is a measurable reduction in missing required context, repeated work, verification burden, and escaped business-logic defects.

Independent foundations and comparison points.

URLs and DOIs are included so every cited claim can be checked outside this paper.

1. N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang. "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the Association for Computational Linguistics, 12:157–173, 2024. DOI: 10.1162/tacl_a_00638.
2. T. J. McCabe. "A Complexity Measure." IEEE Transactions on Software Engineering, SE-2(4):308–320, 1976. DOI: 10.1109/TSE.1976.233837.
3. M. H. Halstead. Elements of Software Science. Elsevier North-Holland, 1977. ISBN: 978-0444002051.
4. F. P. Brooks Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975; anniversary edition, 1995. ISBN: 978-0201835953.
5. A. Bacchelli and C. Bird. "Expectations, Outcomes, and Challenges of Modern Code Review." Proceedings of ICSE 2013, pp. 712–721. DOI: 10.1109/ICSE.2013.6606617.
6. D. L. Parnas. "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 15(12):1053–1058, 1972. DOI: 10.1145/361598.361623.

Revision record