Embedding language-model agents into live applications breaks assumptions about interaction and execution; the authors propose 'Agent-Integrated Software' and 'Intent-Level Interaction Abstraction' with interaction contracts and continuous assurance to preserve task meaning and control, but the framework remains conceptual and untested in real deployments.

Main Finding

Embedding language-model agents into existing applications requires making the semantic relationship between user-level intent and concrete application effects explicit and maintainted over time. The authors propose Agent-Integrated Software (AIS) + an Intent-Level Interaction Abstraction (IIA) and formalize interaction contracts and continuous assurance as the engineering constructs needed to ensure dependable integration. Local component validity (API calls, permissions) is insufficient — a maintained, auditable interaction–effect obligation is required to guarantee that delegated work continues to correspond to the user’s intent as the application state, authority, or context evolves.

Key Points

• Agent-Integrated Software (AIS): a software-pattern that integrates (a) a conventional application core that owns domain objects and durable state, (b) direct GUI/direct-manipulation interaction, and (c) a built-in intelligent agent capable of planning and invoking application capabilities. AIS acknowledges continued coexistence of direct and delegated interactions over shared objects.
• Intent-Level Interaction Abstraction (IIA): an abstract, task-level interface / transition system exposing goals, contextual bindings, proposals, endorsements, interventions, controller epochs, unresolved decisions, and outcomes. IIA is the user-facing semantics through which users inspect and redirect delegated tasks.
• Formal models:
  • AIS is modeled as an open labeled transition system M = ⟨X, X0, Σ, →⟩ with label classes for GUI (G), intent-level (I), agent/runtime (A), and environment (E). State decomposed into core state s, task store t, control state c, journal j (admissions/outcomes), and agent internals w.
  • IIA is modeled as an abstract transition system I = ⟨Y, Y0, Λ, ⇒, V⟩ with an abstraction map π: X → Y and event abstraction α: Σ → Λ ∪ {ε}. Concrete transitions must have valid task-level interpretations (π-preservation).
• Interaction contracts: K = ⟨Pre, Step, Inv, Post, Dep⟩ — semantic specifications (preconditions/authority, allowed task/control transitions, consistency invariants, outcome definitions, and dependencies/assumptions) that constrain how concrete execution projects to IIA traces.
• Interaction–effect obligation: an explicit temporal relation Ψe = ⟨κ, r, βe, γe, ℓe, εe⟩ linking task identity and revision to reviewed payload/object bindings, role-specific authority, controller identity/epoch, and available outcome evidence.
• Conformance requirement: traces projected by π and α under environmental assumptions H should be included in the abstract traces allowed by the IIA + contract: Π Tr(M | H) ⊆ Tr(I | K). This addresses safety/consistency but requires additional progress/fairness assumptions for liveness.
• Key negative result: Proposition — local validity (valid API calls, authenticated permissions) does not guarantee conformance when task-relevant state can change between endorsement and admission. Example: a recipient removed via GUI after an endorsed proposal can still be the target of an authenticated send call, violating the contract.
• Engineering implications (high level):
  • C1 Task abstraction & degrees of autonomy: autonomy is a property of permitted transitions and role-scoped decisions, not a single fixed level.
  • C2 Bidirectional interfaces: application → agent must expose object identity/version, side-effects, retry/error semantics; agent → application (IIA) must expose task identity/revision, pending decisions, confirmed effects, cancellation semantics.
  • C3 Context, knowledge & memory: stable bindings must distinguish identity vs. position and observed version vs. current value; preserving referents across UI/platform changes is critical.
  • Additional implications developed in the paper include controlled execution, outcome evidence and auditing, admission invariants separated from planning, continuous assurance, human-supervision requirements, and impacts on lifecycle/evolution.
• Methods / contributions: formal semantic framework, definitions and proofs (e.g., non-sufficiency of local validity), worked examples (meeting organizer scenario), contrast across domains (collaboration apps, spreadsheets, IDEs, consoles), and a research agenda (application abstraction, development tooling, controlled execution, quality assessment, human supervision).

Data & Methods

• No empirical dataset or user study is reported. The paper uses formal, conceptual, and analytic methods:
  • Formal modeling: AIS as an open labeled transition system; IIA as an abstract transition system; a precise abstraction relation (π, α) connecting concrete execution to task-level semantics.
  • Contract specification: an interaction-contract schema K = ⟨Pre, Step, Inv, Post, Dep⟩ for expressing application-level semantic obligations.
  • Trace-based conformance criterion using trace projection Π and environmental assumptions H to relate concrete traces to permitted abstract traces.
  • Logical/contract reasoning and a specific proposition showing that component-level correctness (API schema & permissions) is insufficient to guarantee interaction conformance.
  • Illustrative examples and cross-domain contrasts (collaboration apps, spreadsheets, IDEs, service consoles) to expose assumptions and limits.
  • Development of a design-oriented research agenda grounded in the formal apparatus.
• The approach is normative and prescriptive: it defines what must be specified, monitored, and guaranteed to make agent integration a maintainable engineering discipline.

Implications for AI Economics

• Transaction and monitoring costs: AIS + continuous assurance increases ongoing compliance and monitoring requirements. Firms must invest in logging, evidence collection, and verification to meet interaction contracts. These are recurring costs that affect the total cost of offering agent-augmented applications and may raise prices or reduce margins.
• Product differentiation and market advantage: Vendors that can credibly provide formal interaction contracts and continuous assurance can charge premium prices (or gain market share) because they reduce buyers’ uncertainty about correctness, privacy, and liability. Specialized assurance providers can emerge as complementary service markets.
• Liability, insurance, and risk pricing: Explicit interaction–effect obligations make it clearer which party is responsible for particular outcomes (e.g., whether an unauthorized disclosure happened because of agent planning or host admission). That clarity enables more precise liability assignment and insurance products — but also creates measurable exposure that must be priced into contracts and premiums.
• Contract design and SLAs: Interaction contracts map naturally to Service Level Agreements and legal terms. They allow specification of admissible effects, required evidence, progress guarantees, and what constitutes fulfillment. This reduces ex-ante information asymmetries but increases the complexity of contracting and auditability.
• Incentives for maintenance and continuous assurance markets: Because conformance depends on evolving dependencies (schemas, APIs, policies), vendors face ongoing maintenance obligations. Markets will arise for continuous assurance tooling, automated contract-checkers, monitoring-as-a-service, and third-party attestations — creating recurring revenue streams and new entrants.
• Labor and supervision economics: The framework reframes “human-in-the-loop” as a formal control/authorization role with quantifiable responsibilities. Depending on how admissions and endorsements are scoped, the marginal supervisory labor required may be higher (if many approvals are needed) or lower (if well-scoped admission invariants and evidence reduce oversight). This affects the labor market for supervisors and the division of tasks between humans and AI.
• Externalities and social costs: Failures of interaction conformance (e.g., accidental disclosures or incorrect operations) generate externalities (privacy breaches, downstream transaction costs). Formal contracts and assurance can internalize some of these costs but may not eliminate systemic risks (e.g., widespread misinterpretation across shared platforms).
• Incentive alignment and standardization: Standardized IIA/interaction-contract formats reduce search and negotiation costs and lower transaction frictions across platforms. Standardization also facilitates credible third-party assurance and reduces asymmetric information, potentially accelerating adoption and lowering insurance costs.
• Adoption barriers and firm strategy: Smaller firms may face higher relative fixed costs to implement continuous assurance, possibly leading to consolidation or reliance on managed platforms. Conversely, cloud providers or platform vendors can bundle assurance as a differentiator, shaping competitive dynamics.
• Regulatory/compliance economics: Regulators could require interaction contracts or evidence-collection for sensitive domains (health, finance, legal), increasing compliance costs but also raising entry barriers and affecting competition. Well-posed contracts make audits and compliance verification more tractable, changing enforcement cost structures.
• Pricing of APIs and capabilities: Because semantic compatibility (preconditions, effects, cancellation) matters for conformance, providers that expose richer metadata (versions, side-effect semantics, outcome evidence) can command higher prices; conversely, opaque APIs impose higher integration and assurance costs on consumers.

Overall, the framework reframes integration risk as specification and evidence risk. Making interaction–effect obligations explicit reduces information asymmetry but imposes ongoing monitoring and maintenance costs — creating new markets (assurance, auditing, contract verification), changing liability/insurance calculus, and altering incentives for product design and supervision.