PaperlayerView exact revision on arXiv

Source-linked AI summary

The Agentic Company OS: Substrate Inversion for Sustained Enterprise Agent Deployment

Oliver Aleksander Larsen, Mahyar T. Moghaddam

arXiv:2609.13334v1cs.SEcs.AIcs.MA

TL;DR

Enterprise agents often fail to reach production or improve through repeated operation, and the paper locates these problems in a mismatch between agent reasoning and inherited working context. It proposes substrate inversion and an operational framework; its claims are an architectural position for evaluation, not evidence that Markdown outperforms alternatives.

  • Problem

    Enterprise GenAI pilots often do not reach production, and deployed systems may fail to retain feedback or improve over time.

    Source: §1 · pp. 1–2

  • Method

    The paper proposes rebuilding the shared cognitive substrate around representations matched to agent reasoning, with schema translation at the action boundary, and specifies a four-layer framework.

    Source: §1 · pp. 2–3, §4 · p. 7

  • Results

    The position argues that rebuilding the substrate directly addresses four failure modes, while reshaping rather than removing the safety gap; superiority over alternative stacks remains untested.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The proposed architecture uses a Sync Agent, per-skill trust gradient, and shared loops; policy legibility and a single audit surface follow by construction, with enforcement and a guarded compile path also required.

    Source: §1 · p. 3, §8 · p. 16

    The position is best suited to interpretation-heavy operations and loses where typed-state guarantees and tight latency budgets dominate, such as high-frequency transactions.

    Source: §6.2 · p. 14

Abstract

from arXiv · show

Enterprise AI agents often succeed in a demonstration and then stall once they must operate day after day. An industry report estimates that most pilots never reach production and that deployed systems rarely retain feedback or improve over time, while agent benchmarks show single-run successes masking unreliable repetition. We argue that these failure modes share a common architectural root: agents reason over data structured for human operators and traditional applications, not for the language models that power them. This position paper proposes that companies deploying agents in sustained operation should rebuild their cognitive substrate, the shared environment agents read as working context, around representations matched to that reasoning surface, isolating schema translation to the action boundary. Markdown is the instantiation available today, not a proven agent-native primitive. Two mechanisms ground the argument: context-bandwidth asymmetry, the gap between one-pass reading of connected prose and field-by-field typed access that strips relations; and cross-loop coupling, the claim that action, skill, and policy loops compound only if they share one substrate. A four-layer framework (Data, Knowledge, Intelligence, Governance) operationalizes the position, with a Sync Agent enforcing the action boundary and a per-skill trust gradient, making governance and auditability structural properties of the substrate. The position revives the shared-substrate tradition of classical multi-agent systems under LLM-era economics. We analyze the main objections and risks, including indirect prompt injection on the compile path, and outline a research agenda for evaluating substrates directly.

1 Introduction

The introduction traces recurring deployment failures to a mismatch between agents’ working context and the language models reasoning over it. It proposes rebuilding that substrate for sustained operation, while treating Markdown as a current instantiation rather than a proven agent-native primitive.

1 Introduction

  • The motivating evidence includes pilots that rarely reach production, repeated-run inconsistency, and deployed systems that often fail to retain feedback or improve.The introduction also notes that model version changes can degrade behavior.Source: §1 · pp. 1–2
  • The paper locates recurring governance, transparency, coordination, safety, and improvement failures in a substrate built for human operators and conventional applications.It proposes rebuilding the substrate to address four failure modes directly, while reshaping rather than removing the safety gap.Source: §1 · p. 2
  • Substrate inversion puts agent reasoning in a shared context matched to the model’s reasoning surface and confines schema translation to the action boundary.The authors state that Markdown is available today, not a proven agent-native primitive, and do not claim superiority over alternative stacks.Source: §1 · p. 2
  • The authors connect the position to classical shared-substrate systems and argue that larger context windows, cheaper closed-loop measurement, and autonomous deployments make substrate choices timely.They describe the position as an architectural thesis open to empirical test, focused on interpretation-heavy enterprise operations.Source: §1 · pp. 2–3
  • The position rests on context-bandwidth asymmetry and cross-loop coupling: connected prose preserves relations, while action, skill, and policy loops compound only on a shared substrate.The paper also presents a four-layer framework, a Sync Agent, and a per-skill trust gradient to operationalize the position.Source: §1 · pp. 2–3

2 Background and Related Work

The background surveys inherited enterprise agent stacks and the shared-substrate tradition, then argues that LLMs change the economics of machine-readable shared context. It situates the paper’s assembly of substrate, governance, audit, and coupled improvement loops against adjacent work and imported safety risks.

2 Background and Related Work

  • Retrieval, typed-tool, and vertical agents inherit working context from relational stores, schemas, or vertical-specific stores; current benchmark gaps remain confounded with planning and tool limits.The cited file-native evaluation found no significant single-task accuracy effect from serialization format alone, while substrate structure and compounding improvement remain unisolated.Source: §2 · p. 3
  • The paper rejects inheriting human-first working context, arguing instead that agents’ working context should be rebuilt rather than patched with retrieval or tools.Table 1 frames the comparison around reasoning location, translation, loop coupling, audit, and governance.Source: §2 · p. 4, Table 1 · p. 4
  • The position links translation layers to machine-learning technical debt, agent stacks to organizational communication structure, and shared representations to distributed cognition.It extends the shared-representation argument from coordination to closed-loop improvement.Source: §2 · p. 4
  • Classical blackboards and multi-agent systems used shared working media, but hand-engineered representations and blackboard control impeded adoption; LLMs make prose machine-readable at company scale.Scheduling still falls to an orchestrator whose control policy remains open.Source: §2 · p. 4
  • Living-wiki proposals, LLM multi-agent scaffolding, runtime memory [30], and demand for governance guardrails inform the framework.Substrate inversion locates persistence in the shared substrate rather than solely inside the runtime.Source: §2 · p. 5
  • The architecture treats version-control logs, versioned trust metadata, and shared policy as safety infrastructure, but compiling untrusted content into agent context imports prompt-injection risk.The authors distinguish this safety contribution from the risk of indirect injection, identified as the most serious case.Source: §2 · p. 5
  • The authors position their novelty as assembling an enterprise prose substrate, version-controlled governance and audit, and improvement loops coupled through one corpus.They contrast this whole assembly with prior work on governance, learning, safety [15], and blackboard coordination [14] [34].Source: §2 · p. 5

3 Substrate Inversion: The Argument and Its Mechanisms

The paper argues for a single reasoning surface matched to LLMs, with schema translation isolated at the action boundary. Context-bandwidth asymmetry and cross-loop coupling explain this design commitment.

3 Substrate Inversion: The Argument and Its Mechanisms

  • Substrate inversion commits to one agent-native reasoning surface and translation only at the action boundary, shared across the three improvement loops.The authors frame the substrate as the agent’s environment, rather than an implementation detail around the agent.Source: §3 · pp. 5, 7
  • Connected prose carries relations through one-pass reading, whereas typed systems strip them and require repeated narrative reconstruction, as Figure 1 illustrates.The sales example combines five contexts—prospect reply, pipeline stage, payment history, playbook, and pricing rules—across Markdown or CRM, ledger, and email APIs.Source: §3 · p. 5, Figure 1 · p. 6
  • H1 predicts that per-step reassembly cost bounds compositional reach, with a tighter bound as task depth increases.The paper states that even information already in context may be recovered unreliably depending on its position.Source: §3 · p. 6
  • Action, skill, and policy loops operate at seconds, days, and weeks-to-months scales; their corrections compound only when they share a substrate.A correction must propagate from action to skill to policy, and a policy update must be read by a later action.Source: §3 · p. 6
  • H2 predicts that split substrates drive improvement toward the noise floor, while a unified substrate lets it compound; model upgrades alone do not rescue split loops.The paper identifies H2 as its central falsifiable claim and says the same benchmark tests it.Source: §3 · p. 7

4 The Agentic Company OS Framework

The framework separates authoritative systems of record from a shared reasoning substrate and places coordination, policy, and external-system translation in defined layers. A Sync Agent, per-skill trust levels, and shared feedback loops make the design operational, while several deployment limits remain open.

4 The Agentic Company OS Framework

  • The framework assigns distinct jobs to Data, Knowledge, Intelligence, and Governance, with the Sync Agent translating only at the action boundary.Freshness, read authorization, write concurrency, rereading cost and latency, and recovery from substrate corruption remain deployment questions.Source: §4 · p. 7

4.1 The Four Layers

  • Data remains authoritative for transactions; Knowledge holds connected prose; Intelligence coordinates through shared files; Governance stores policy in those same files.The architecture maps Governance to setpoints, Intelligence to comparison and action, Knowledge to measurement, and Sync Agent ingestion to sensing.Source: §4.1 · pp. 7–9, Figure 2 · p. 8

4.2 The Sync Agent and the Action Boundary

  • The Sync Agent ingests continuously through webhooks and forwarding email or in batch at onboarding, maintains compiled summaries, and handles typed writes at the action boundary.Compiled state is a materialized view, not authoritative; deep investigations can use typed tools and then write a fresh summary back.Source: §4.2 · p. 9

4.3 Trust Gradient and In-Band Governance

  • Trust is assigned per skill: shadow drafts only, assist requires approval, autonomous-sampled uses spot checks, and full permits execution under retrospective audit.Only a human may raise a trust level; a deterministic controller may downgrade it after severe regression, while other update rules remain open.Source: §4.3 · pp. 9–10, Figure 3 · p. 10

4.4 Three Closed Loops, One Substrate

  • A corrected outcome can inform the next action, skill revision, and policy review through shared files, though tightly coupled loops may oscillate.Graduated rollout, sampled human review, and slower policy cadence are proposed dampers.Source: §4.4 · pp. 10–11, Table 2 · p. 10

4.5 Worked Example: A Customer File

  • The constructed customer file combines status and payment fields with renewal narrative and linked activity history, and both a human and agent read it.The example is explicitly illustrative, not deployment data; the Sync Agent updates its frontmatter when external state changes.Source: §4.5 · p. 11

5 Alternative Approaches

The paper considers retrieval, typed-tool agents, and vertical applications as alternatives to substrate inversion, responding to each while conceding where they remain competitive. Its central distinction is whether agents share a reasoning substrate across action, skill, and policy loops.

5.1 Better Retrieval Is Sufficient

  • Retrieval improves fragment selection but does not remove the need to reassemble retrieved pieces; at low compositional depth, it can be functionally equivalent and the choice is economic.The framework retains retrieval as a Sync Agent tool for raw records.Source: §5.1 · p. 12

5.2 Tool-Using Agents on Typed Schemas

  • Typed tool contracts clarify individual calls, but field-by-field access still requires reassembly and split skill and policy substrates can block correction from propagating.A hybrid that versions playbooks, policies, and outcome logs together captures cross-loop coupling; the residual disagreement is the reassembly issue isolated by the proposed benchmark.Source: §5.2 · p. 12

5.3 Vertical AI Applications

  • Vertical applications can serve single-vertical companies, but disconnected substrates may impede company-level improvement and cross-functional coordination.They can also plug into the Intelligence Layer as specialized agents reading and writing the shared substrate.Source: §5.3 · p. 13

6 Risks, Governance, and Scope

Substrate inversion makes governance and audit structural, but safety still requires active defense. Its fit is strongest for interpretation-heavy operations and weaker where typed-state guarantees and low latency dominate.

6.1 Risk Identification, Evaluation, and Accountability

  • The compile path imports prompt-injection risk into trusted context, where poisoned artifacts can persist across calls, spread between agents, and steer playbook revisions.The authors propose quarantined, uncredentialed compilation and a separate credentialed action worker, while noting that screening cannot be considered finished.Source: §6.1 · p. 13
  • Trust levels can be checked deterministically at the action boundary against a pinned, verified revision, but the check gates skills rather than payloads, leaving egress control open.Only designated principals may write Governance Layer files, except that a deterministic controller may lower a skill’s trust level.Source: §6.1 · p. 14
  • Rules, approval thresholds, and trust levels become auditable substrate artifacts, but read-side access control and deletion under data-protection law remain open problems.Signed commits and protected branches are required for attribution and immutability; crypto-shredding of per-record keys could blunt, but does not resolve, the erasure conflict.Source: §6.1 · p. 14

6.2 Scope: Where the Position Fails

  • The approach best fits interpretation-heavy work, not high-frequency transactional systems where typed-state guarantees and tight latency budgets dominate.Structured systems of record remain authoritative; the payment processor still holds the money, and the ledger remains authoritative.Source: §6.2 · p. 14

7 Research and Adoption Agenda

The paper proposes a gradual, reversible department pilot and a benchmark that varies representation and loop coupling while holding source information constant. It also identifies unresolved operational questions that must not be treated as solved.

Adoption path

  • Start with one owned, interpretation-heavy departmental workflow, increase trust from shadow to full autonomy with human approval at each step, and track time-to-full-autonomy, regression, and rollback.Rollback leaves CRM, ledger, and mail systems untouched; replicate only after a rollback drill and sampled audit succeed.Source: §7 · pp. 14–15

Research agenda

  • The proposed benchmark holds the source corpus fixed while varying representation and whether action, skill, and policy loops share one substrate.Conditions include Markdown, typed schemas, retrieval, relational stores, and a hybrid; the split-loop arm separates action, skill, and policy across distinct stores.Source: §7 · p. 15
  • Compositional depth is the number of inter-entity relations a task must jointly resolve; longitudinal tests measure pass-rate change per closure against a frozen-playbook noise floor.The hypotheses predict greater connected-prose gains as depth grows and compounding improvement on a unified substrate, but neither outcome is yet measured.Source: §7 · p. 15

Open operational questions

  • Operational boundaries remain unresolved, including corpus-scale effects, freshness, read authorization, concurrent edits, rereading cost, and recovery from corrupted files.The minimal write regime is a convention rather than merge semantics, and the cost of rereading the corpus on every action may conflict with seconds-scale action loops.Source: §7 · pp. 15–16

Standards

  • Standards bodies are asked to specify vendor-neutral substrate-level audit guarantees so Git-based provenance can sit alongside log-based provenance in compliance frameworks..Source: §7 · p. 16

8 Conclusion and Future Work

The conclusion advocates rebuilding the cognitive substrate around agent reasoning while treating Markdown as a current instantiation, not a proven primitive. The position remains unbenchmarked against alternatives, and the authors frame it as work to test in deployment.

8 Conclusion and Future Work

  • The proposed operational form combines four layers, a Sync Agent, a per-skill trust gradient, and three closed loops, with policy legibility and a shared audit surface following by construction.Safety and attribution additionally require action-boundary enforcement, signed commits, and a guarded compile path.Source: §8 · p. 16
  • The position has not yet been benchmarked against alternatives, and open work includes compile-path injection, cost, concurrency, skill discovery, and empirical validation.The paper specifies an experiment to test H1 and H2 but presents these items as work for testing the position.Source: §8 · p. 16
  • The authors offer substrate inversion as work in progress to be debated and tested in deployment..Source: §8 · p. 16
Loading 2609.13334v1…