Why Enterprise Agents Stall After the Pilot: A Review of 'Substrate Inversion'

Source Document

Oliver Aleksander Larsen, Mahyar T. Moghaddam, "The Agentic Company OS: Substrate Inversion for Sustained Enterprise Agent Deployment", arXiv:2609.13334 [cs.SE], submitted 2026-09-11, DOI 10.48550/arXiv.2609.13334. Affiliation: University of Southern Denmark, Software Engineering.

This is a preprint, not yet peer-reviewed, and the authors themselves label it a "position paper" — it presents an architectural argument and a proposed benchmark design to test that argument, not new experimental results. The text has no funding or conflict-of-interest section (we checked around the references and for Acknowledgments/Funding/Conflict keywords — none found in the manuscript itself, only arXiv's own site-wide sponsor footer). We cross-checked the full text against a GitHub Actions snapshot of the arXiv HTML full text taken 2026-09-15T23:32:58Z — this session's egress was blocked for the control domain example.com on all three 10-minute-spaced retries, and two manual re-triggers of the snapshot workflow both failed with arXiv API HTTP 406, so we used the most recent snapshot available (collected three days prior).

Study Overview

The research question is why enterprise AI agents succeed in demos but stall in sustained operation. The authors decompose this into five failure modes (governance, transparency, coordination, safety, and plateaued improvement gaps) and trace them to one architectural root: agents reason over a substrate — the working context they read — that was built for humans and legacy applications, not for the language models doing the reasoning. Their prescription, "substrate inversion," is to stop inheriting the schema of existing systems (CRM, ledger, email) and instead rebuild the agent's working context around a representation matched to how an LLM reads. Markdown is named as today's available instantiation, explicitly not claimed as a proven optimal representation.

Two mechanisms ground the argument. Context-bandwidth asymmetry (Hypothesis H1): connected prose is read in one pass, while typed APIs and schemas expose the same information field by field, stripping relations that the agent must reassemble at every step — a cost the authors predict grows with task depth. Cross-loop coupling (Hypothesis H2): three improvement loops at three time-scales — action (seconds), skill (days), policy (weeks to months) — only compound if they share one substrate; split across separate systems, the authors predict improvement decays toward noise. Both hypotheses are stated as falsifiable, but only through a benchmark the authors propose in Section 7 and have not yet run.

Central Claims and Design

This paper contains no empirical benchmark table. Because the literature type here is a position paper rather than an experimental study, this section reproduces the authors' own architecture tables and design decisions in place of the usual "Key Results."

Of the four layers (Data, Knowledge, Intelligence, Governance), the Data layer keeps existing systems (CRM, ledger) untouched, while the Knowledge layer is a single Git repository of markdown that both humans and agents read. Authority to call external systems is concentrated in one component, the Sync Agent, at the action boundary. Trust levels attach to individual skills rather than to agents — shadow (draft only) → assist (human approves every execution) → autonomous-sampled (spot-checked audit) → full (retrospective audit only) — and only a human may raise a level, though a deterministic controller may lower one. The three improvement loops below only compound, per the paper's central design logic, because they read and write the same shared substrate.

Credibility Assessment

The most important thing to state up front is a limitation the paper discloses itself: the fifth of five open questions in Section 8 is "empirical validation — the position has not yet been benchmarked against the alternatives of Section 5." H1 and H2 are hypotheses that can only be confirmed or falsified by the experiment the authors propose in Section 7, which has not been run. The work has not been peer-reviewed. No conflict-of-interest statement could be found in the manuscript — absence of a statement is not the same as confirmed absence of a conflict, and we note that distinction explicitly.

On the credibility side, Section 5 is devoted entirely to steel-manning the three strongest objections (better retrieval suffices, typed-tool agents suffice, vertical AI apps suffice), and in each case the authors concede ground ("we concede that at low compositional depth the two approaches are functionally equivalent"). Stating the specific observations that would falsify H1 and H2 is also unusual discipline for what is otherwise a vision paper. As conflicting evidence, the paper itself cites GAIA and AgentBench findings that performance drops with task depth — directionally consistent with H1, but the authors are explicit in Section 2 that no benchmark yet isolates substrate structure itself as the cause.

Related Research (Literature Cross-Check)

• McMillan, D. (2026). Structured Context Engineering for File-Native Agentic Systems — Contradiction / qualification. Reports that serialization format alone does not significantly affect single-task accuracy — a finding that could directly cut against this paper's core mechanism (H1: connected prose beats typed fields). The authors cite it themselves in Section 2, while noting that no benchmark yet isolates substrate structure in the way their proposed experiment would.
• Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems — Prior work / contrast. Solves agent memory persistence inside a single agent's runtime; this paper addresses the same underlying problem one level up, at the shared, organization-wide substrate rather than any one agent's runtime.
• Staufer, L. et al. (2026). The 2025 AI Agent Index — Extension / empirical backdrop. An empirical survey documenting how sparsely deployed agent systems disclose governance, transparency, and safety practices — the real-world backdrop for this paper's claim that governance should be made structural by construction.

Bibliographic details for these three works were taken from this paper's own reference list (Section 2, "Background and Related Work"). We could not independently re-verify their primary text because this session's egress was blocked — we do not cite any numeric claims from those three papers themselves, only this paper's own summary of them. Note that GAIA, AgentBench, tau-bench, and ReAct are cited in this paper's own bibliography by venue only, with no arXiv identifier given, so we did not include them here rather than guess at a link. The three works we do cite sit in distinct relationships to this paper: McMillan is conflicting evidence in tension with the core mechanism, MemGPT is a contrasting approach at a different architectural layer, and the AI Agent Index is the empirical backdrop for the governance gap this paper responds to.

Reviewer's Assessment

First, the most practically useful part of this paper is not the big "substrate inversion" claim but the risk analysis in Section 6.1. The observation that the compile pass is exactly where untrusted external content becomes trusted agent context, and that a single poisoned file is then permanently re-exposed to every agent reading the substrate, is a concrete, actionable warning — and the authors themselves admit the trust gradient "gates the skill, not its payload," leaving this open. Even without adopting this architecture, the underlying risk pattern — one component with both write access to shared context and every external credential — applies to any shared-context design, markdown or not.

Second, stating H1 and H2 in falsifiable form and specifying the experiment in Section 7 is honest practice, but it does not change the fact that this is an unproven claim. The individual design pieces — trust gradient, four-layer split — look reasonable in isolation, but nothing in this paper shows the combination actually outperforms typed-tool agents or RAG in practice. "Logically plausible" and "empirically confirmed" need to stay separated when reading this work.

Practical Takeaways

• Start with one department, not a company-wide rollout — Following the authors' own adoption path, migrate one interpretation-heavy workflow with a named owner (sales qualification, support triage) into a markdown-based context first.
• Design trust levels per skill, not per agent — Letting the same agent hold different automation levels (draft-only / human-approved / sampled-audit / fully autonomous) per skill keeps human oversight on the riskiest actions specifically.
• Concentrate write access to shared context in one component — Mirroring this paper's Sync Agent narrows the audit surface to one point, but that same point becomes the largest attack surface (Section 6.1) — design privilege separation around it from day one.
• Run your own comparison before adopting — Use the Section 7 benchmark skeleton (varying representation and loop-coupling as separate factors) as a template for a minimal internal A/B test before committing.
• Measure continuous recompilation cost separately — The authors note that daily compilation is cheap, but rereading the full corpus on every action may not be; without caching or selective-read policies, cost and latency can grow faster than expected at scale.

Conclusion

The contribution of the Agentic Company OS is not a demonstrated performance gain but a structural diagnosis of why enterprise agents keep stalling — inherited, human-first schemas — paired with a concrete experiment design to test that diagnosis. The individual design pieces (trust gradient, action boundary, coupled loops) look reasonable, but as the authors themselves acknowledge, the position has not yet been benchmarked against the alternatives. This review treats the framework as a hypothesis, not a result, while judging the risk analysis and adoption path worth acting on today. For a practical checklist on splitting execution authority by skill, see Agent Harness Permission and Sandbox Gating on this site's blog.

References

• The Agentic Company OS: Substrate Inversion for Sustained Enterprise Agent Deployment — arXiv abstract (source)
• Same paper, full HTML text — used for table/design cross-checking (via snapshot)
• Agent Harness Permission and Sandbox Gating — sunny34.com blog
• Structured Context Engineering for File-Native Agentic Systems (McMillan, 2026) — related work source
• MemGPT (Packer et al., 2023) — related work source
• The 2025 AI Agent Index (Staufer et al., 2026) — related work source