PaperlayerView exact revision on arXiv

Source-linked AI summary

Agent-Integrated Software: Interaction Contracts and Continuous Assurance

Shengcheng Yu, Chunrong Fang, Zhenyu Chen

arXiv:2609.11381v1cs.SEcs.AI

TL;DR

The paper addresses the coordination problem created when users revise goals and shared objects while an integrated agent continues delegated execution. It proposes AIS and IIA, linked by interaction contracts and continuous assurance, and argues that dependable integration requires maintaining this correspondence throughout execution. The framework also shows that local component validity is insufficient and identifies assumptions and limits requiring further engineering and human studies.

  • Problem

    Embedding an agent in an existing application creates a persistent coordination problem because direct operations and delegated execution can affect shared business state concurrently.

  • Method

    The paper models AIS as an open transition system and IIA as task-level semantics, then uses interaction contracts and continuous assurance to constrain and track their correspondence.

  • Results

    The framework establishes that valid component calls and authenticated permissions are insufficient for interaction conformance when task-relevant state changes before effect admission.

  • Takeaways & Limitations

    Dependable agent integration requires keeping task revisions, authority, operational control, and outcome evidence connected throughout execution.

  • Takeaways & Limitations

    The framework is conceptual, its organization is not an empirical taxonomy or exhaustive derivation, and its practical benefits remain open to comparative engineering and human studies.

Abstract

from arXiv · show

Embedding an intelligent agent in an existing application creates a persistent coordination problem: users can revise goals and manipulate shared objects while delegated execution continues. We argue that dependable integration requires an explicit correspondence between task-level interaction and application behavior. We introduce Agent-Integrated Software (AIS) as a software pattern combining a conventional core, direct interaction, and a built-in agent, and Intent-Level Interaction Abstraction (IIA) as the task semantics through which users inspect and control delegated work. An open transition-system model relates AIS execution to IIA states and events. Interaction contracts constrain this relation through task bindings, role-specific authority, control transitions, and outcome evidence; continuous assurance maintains scoped claims as their dependencies change. A compact disclosure contract and conditional propositions illustrate why local component validity is insufficient and how selected admission invariants can be separated from planning. Contrasting software domains expose the framework's assumptions and limits. This perspective develops a research agenda spanning application abstraction, development support, controlled execution, quality assessment, and human supervision, with the aim of making agent integration a maintainable software engineering discipline.

1 Introduction

Embedding an agent alongside direct application interaction creates a coordination problem because users can revise shared objects while delegated execution continues. The paper proposes AIS and IIA, with interaction contracts and continuous assurance to maintain correspondence between task intent and application effects.

  • 1 Introduction: Agent integration must keep revisable task intent aligned with application behavior, because generated responses, authorized API calls, and database updates can still produce effects that no longer match the user’s instruction.The problem persists as delegated work changes before, during, and after execution, while different people retain authority over relevant resources and consequences.
  • 1 Introduction: AIS combines a conventional application core, direct user interaction, and a built-in intelligent agent while preserving the core’s ownership of domain objects, business behavior, and durable state.Existing applications can adopt the pattern incrementally, and the model or runtime may execute remotely.
  • 1 Introduction: IIA provides the user-facing semantics for delegated work through goals, contextual references, proposals, endorsements, interventions, and outcomes.The agent plans and executes, while IIA defines how that activity is presented and controlled across interfaces and runtime services.
  • 1 Introduction: Interaction–effect obligations explicitly bind application effects to task revisions, referenced objects, role-specific authority, operational control, and outcome evidence.This joint treatment spans the boundary between AIS and IIA independently of a particular protocol, access-control scheme, or transaction mechanism.
  • 1 Introduction: The framework connects semantic modeling, engineering support, controlled execution, quality assessment, and human supervision through interaction contracts and continuous assurance.Contrasting examples examine the argument’s scope, while practical benefits remain questions for comparative engineering and human studies.

2 AIS and IIA: A Semantic Framework

AIS is modeled as an open application system whose execution and task-level interaction are connected through explicit abstractions and contracts. The framework requires concrete effects, authority, control, and evidence to remain interpretable at the task level, because local component validity alone does not ensure interaction conformance.

  • 2.1 AIS as an Open Application System: AIS uses an open transition system to represent direct GUI operations, intent-level events, agent steps, and environmental events over shared application state.Labels identify relevant principals, tasks, and operations, while execution remains open to interleaved external events.
  • 2.1 AIS as an Open Application System: The execution state separates core objects and policies, task revisions and bindings, control authority, effect records, and agent internals.Admission records host acceptance of an effect but do not alone establish that the effect occurred.
  • 2.4 Foundations and Derivation of the Engineering Agenda: The framework distinguishes architectural membership from dependability and treats its engineering agenda as a conceptual, conditional perspective rather than an empirically validated taxonomy.The framework is intended to support incremental adoption and distributed deployments without making quality claims true by definition.
  • 2.2 IIA as a Task-Level Abstraction: IIA abstracts task-level states and events so users can inspect, revise, endorse, intervene in, admit, and receive outcomes for delegated work.A state abstraction maps execution states to task states, while an event abstraction can hide only steps that change no task-relevant fact.
  • 2.3 Interaction Contracts and Behavioral Conformance: Interaction contracts constrain operations through preconditions, task and control transitions, consistency invariants, fulfillment conditions, and dependency assumptions.The contract is an application-level semantic specification that can be implemented through APIs, runtime guards, application code, or interaction design.
  • 2.3 Interaction Contracts and Behavioral Conformance: An interaction–effect obligation binds each effect to its task revision, reviewed bindings, role-specific authority, controller epoch, and outcome evidence.Because authority is checked at admission and evidence later determines reportable outcomes, revisions can invalidate future admissions without erasing earlier committed effects.
  • 2.3 Interaction Contracts and Behavioral Conformance: Valid component calls and authenticated permissions can still violate conformance when task-relevant state changes before effect admission.A recipient removed through the GUI can remain reachable through a valid API call, producing a trace excluded by the interaction contract.

3 Engineering Implications of the Framework

The framework shifts engineering attention from agent invocation to whether evolving execution remains a valid realization of the task. It requires complementary interfaces and semantics that connect task control, application capabilities, and authoritative effects.

  • 3 Engineering Implications of the Framework: A task becomes actionable through its goal, delegated scope, and unresolved decisions, which the IIA must preserve rather than replace with an inferred plan.Retrieval and proposal construction may be authorized while disclosure remains undecided.
  • 3 Engineering Implications of the Framework: Autonomy is defined by permitted task- and role-specific transitions, exposing decisions that change acceptance conditions or authority while allowing bounded retrieval and reversible preparation.Reviews matter only when later admissions remain bound to them; requiring approval for every internal step can add effort without narrowing relevant effects.
  • 3.2 C2: Bidirectional Interfaces: Complementary interfaces meet at task identity, contextual bindings, and effect evidence: the application exposes domain capabilities, while the runtime supplies task-control services.Callable APIs and well-formed event streams are insufficient if they cannot relate effects to reviewed tasks or establish commitment.
  • 3.2 C2: Bidirectional Interfaces: Protocol conformance does not establish application-level conformance because tool changes can preserve schemas while breaking semantic compatibility for preconditions, effects, cancellation, or outcomes.AG-UI can transport approvals, interrupts, and resume events, but the host must provide admission checks and authoritative outcomes.

3.3 C3: Context, Knowledge, and Memory

Context binds delegated tasks to application state across time, requiring distinctions among object identity, versions, explicit instructions, and inferred preferences. Personalization and retrieval extend these dependencies while creating provenance, privacy, and selective-refresh requirements.

  • 3.3 C3: Context, Knowledge, and Memory: Task bindings must distinguish object identity from position, current values from observed versions, and explicit instructions from inferred preferences.A screenshot may locate a document without preserving the identity needed to detect replacement.
  • 3.3 C3: Context, Knowledge, and Memory: Personalization and retrieval can introduce stale or conflicting dependencies, so provenance must support selective refresh and correction without becoming unrestricted retention.Read authority also differs from disclosure authority, and transferred summaries must respect purpose and recipient scope.

3.4 C4: Interaction Continuity and Shared State

Interaction continuity requires preserving task meaning as interfaces, controllers, principals, and execution locations change. Shared continuity records and guarded authority transitions separate responsibility transfer, recovery, permissions, and outcome knowledge.

  • 3.4 C4: Interaction Continuity and Shared State: GUI edits change the admissible continuation of delegated work by revising the reviewed binding, regardless of whether correction arrives through chat or direct manipulation.Changed conditions require refresh and, where necessary, renewed endorsement; an acknowledged stop fences new admissions while earlier ones still require reconciliation.
  • 3.4 C4: Interaction Continuity and Shared State: Handover distinguishes same-user takeover, transfer to another person, remote continuation, and recovery, which share a continuity record but require different authority and recovery semantics.A controller lease records task-control authority and its expiry conditions.
  • 3.4 C4: Interaction Continuity and Shared State: Responsibility transfer requires both a rights-filtered successor account and enforcement that prevents the former controller from admitting effects under its old authority.Lost acknowledgements leave ownership unresolved, while late provider responses leave effect knowledge incomplete.
  • 3.5 C5: Permission, Safety, Security, and Privacy: Delegation spans initiators, resource owners, approvers, affected parties, and executors, whose authorities do not merge automatically even when one person holds multiple roles.An organizer’s request does not supersede team release policy or a disclosure officer’s approval.
  • 3.5 C5: Permission, Safety, Security, and Privacy: Authority conditions must be revalidated when ownership, recipients, accounts, or controllers change, and endorsements must originate outside agent inference.Guarded business APIs do not support a complete claim if an unrestricted alternative shell or database connection can bypass them.
  • 3.5 C5: Permission, Safety, Security, and Privacy: Safety, security, and privacy impose distinct obligations for mistaken actions, adversarial redirection, excessive disclosure, role-specific views, logs, and derived memory.Preserving attribution during handover does not transfer prior credentials or private context.

3.6 C6: Execution Semantics and Failure Recovery

Failure recovery must distinguish application state from knowledge of effects, because timeouts can leave execution status ambiguous. Cancellation fences future admissions but cannot undo already admitted effects, making replay and compensation domain-dependent.

  • 3.6 C6: Execution Semantics and Failure Recovery: Timeouts can leave the runtime unable to distinguish non-execution from a committed effect, so stable identifiers and authoritative status queries are needed to manage replay safely.Treating both cases as failure risks duplicate execution, while treating both as success produces misleading feedback.
  • 3.6 C6: Execution Semantics and Failure Recovery: Cancellation changes future admissibility at a boundary but cannot reverse an effect already admitted to an external provider.Compensation is a new domain operation with its own authority and failure conditions; undo can also overwrite a collaborator’s later edit.

3.7 C7: Observability, Debugging, and Responsibility

AIS observability must connect task revisions and endorsements to host admissions and outcome records, not merely explain agent reasoning. This separation assigns different evidence needs to users and developers.

  • Observability and diagnosis: AIS traces must connect task revisions and endorsements to host admissions and outcome records for dependable diagnosis.Without that connection, an explanation can describe why the agent acted without establishing authorization or effects.
  • Evidence responsibilities: Users need records of occurred effects and pending decisions, while developers need the dependency or transition responsible for a mismatch.Approvals, admission witnesses, and receipts support these distinct perspectives.

3.8 C8: Architecture, Joint Evolution, and Operating Costs

The correspondence between task meaning and application behavior can change despite stable API types, because models, hosts, and adapters evolve jointly. Stronger effect guarantees require costly host services and broader operational assessment.

  • Joint evolution: Model replacement, host updates, and adapter revisions can invalidate previously supported traces or assurance claims without changing visible API types.Each change can alter plans, object meanings, admission behavior, or reporting semantics.
  • Architecture and guarantees: Integrating an agent without stable references, guarded writes, control hooks, and outcome records may provide useful preparation or retrieval but weaker effect guarantees.These services carry development and maintenance costs.
  • Operating costs: Integration should be judged against total development, computation, supervision, and recovery effort, including the conventional workflow it complements.Deployment also changes latency, information exposure, and continuity assumptions.

4 Interaction Contracts and Continuous Assurance

Interaction contracts separate task validity, authority, control, and outcome evidence across the IIA–AIS boundary. Continuous assurance maintains these scoped obligations as implementations and dependencies change.

  • Contracted dependability: Dependability requires both a valid interaction history and an adequate task result, because either authorization or usefulness can fail independently.A successful final state may follow an unauthorized intermediate effect, while authorized execution may still produce an inadequate result.
  • Contracted dependability: The contract separates task acceptance by authorized stage from outcome adequacy, so preparation may end in an inspectable proposal while execution may require clarification.Completed writes alone cannot evaluate these distinct judgments.
  • Interaction contracts: K1–K4 bind admissions to reviewed task bindings, current authority, controlled admission, and faithful outcome reporting.The contract applies these obligations to a concrete reviewed-disclosure scenario and specifies symbolic bindings, roles, and records.
  • Interaction contracts: Planner-independent admission safety holds when a trusted gate atomically enforces the contract and exclusively appends immutable admission records.Under those premises, every admitted effect satisfies K1–K3 at admission regardless of planner selection.
  • Continuous assurance: A timeout can support authority evidence while leaving delivery unknown, so reporting uncertainty preserves outcome fidelity whereas asserting delivery without evidence violates it.The assurance claims remain separable rather than collapsing into a generic task-success indicator.
  • Continuous assurance: Continuous assurance reassesses only the claims affected by change: planner replacement can affect release evidence, unmediated writes can invalidate gate coverage, and adapter changes can undermine outcome reporting.This makes assurance a maintained argument over dependencies rather than a one-time validation.

5 A Research Agenda from Development to Assurance

The research agenda focuses on constructing, evolving, enforcing, testing, and maintaining the correspondence between application semantics and delegated task behavior. Its directions also address evidence costs, provider guarantees, human authority, and sustainable deployment.

  • Agenda scope: The agenda organizes research around application semantics, task models, contracts, and evidence that support continued development assistance and quality assessment.The six directions span application analysis through maintenance of assurance evidence.
  • R1: Application abstraction: R1 seeks tools that recover semantic obligations about object identity, authorization conditions, and effect evidence rather than merely enumerating callable operations.Abstraction adequacy also requires exposing omitted consequential distinctions and unsupported clauses.
  • R2: Joint evolution: R2 addresses joint evolution of goals, bindings, decisions, and unresolved dependencies so harmless edits can be distinguished from changes requiring endorsement or plan invalidation.The representation must combine explicit relations, inferred dependencies, and user correction without treating model confidence as proof.
  • R3: Controlled execution: R3 proposes conformance profiles for operations crossing APIs, GUI automation, and remote services, comparing guarantees under retries, revocation, and controller transfer.Profiles should expose support for atomic checks, duplicate prevention, status queries, and compensation.
  • R4–R5: Tools and assurance: R4–R5 connect contract artifacts to development tools and scoped assurance, while requiring independent review, dependency-aware reassessment, and measurement of maintenance costs.Generated specifications cannot serve as independent oracles, and frequent passing checks can still miss lost premises.
  • R6: Human authority and sustainability: R6 examines portable authority and consent across organizational boundaries while accounting for model substitution, data exposure, latency, operating cost, recovery, supervision, and maintenance.Context changes should trigger explicit revalidation rather than implicit inheritance.

6 Discussion

The framework’s scope is tested across domains with different bindings, authorities, continuation rules, and outcome evidence. Its limits include abstraction adequacy, trustworthy realization, and the absence of empirical validation or universal replacement claims.

  • 6.1 Scope across Software Domains: The four hypothetical domains preserve shared task-revision questions while requiring domain-specific bindings, authority, continuation rules, and outcome evidence.Spreadsheet edits, IDE commands, and refunds illustrate why a common record does not erase domain-specific semantics.
  • 6.1 Scope across Software Domains: Consequential intermediate effects must remain represented because temporary disclosure followed by deletion differs from never disclosing information.
  • 6.2 Human Supervision: Mandatory review should be accountable to application and domain owners, with resource policies and requester choices determining additional conditions.Candidate decision dimensions include reversibility, affected people, disclosure scope, commitment cost, unfamiliar authority, and unresolved intent.
  • 6.2 Human Supervision: Supervisory burden requires multidimensional measures because fewer confirmation dialogs can improve convenience while weakening control.Relevant measures include inspection time, intervention frequency, context switches, recovery effort, latency, computation, and decision quality.
  • 6.3 Architectural Scope and Theoretical Limits: AIS and IIA address different descriptive levels, but the framework’s practical value depends on the explanatory and engineering value of their application-level relation.The formalization cannot assess omitted effects or reconstruct unavailable commit receipts and authoritative permission changes.
  • 6.3 Architectural Scope and Theoretical Limits: The propositions are conditional consequences of definitions and assumptions, not verified deployed-system properties; conformance alone does not establish progress, fairness, semantic usefulness, or usability.Applications with inaccessible third-party state or unmediated write paths may support only restricted contracts, and deterministic workflows may remain lower-cost for stable procedures.

7 Conclusion

The paper proposes AIS and IIA to connect direct operations, delegated tasks, and shared business state through explicit interaction–effect obligations. Interaction contracts and continuous assurance maintain those connections as execution dependencies change, motivating evaluation of whether the abstraction supports useful delegation at acceptable cost.

  • 7 Conclusion: AIS contains the relationship between direct operations, delegated tasks, and shared business state, while IIA supplies its task-level interaction abstraction.
  • 7 Conclusion: Interaction–effect obligations keep task revisions, role-specific authority, operational control, and outcome evidence connected throughout execution.
  • 7 Conclusion: Interaction contracts specify these obligations and continuous assurance maintains claims about their realization as dependencies change.The research agenda spans application analysis, development assistance, control semantics, quality assessment, and human supervision.
Loading 2609.11381v1…