Software Engineering in the Agent Era From Trustworthy Change to Human Agent Software Organizations

Software Engineering in the Agent Era: From Trustworthy Change to Human–Agent Software Organizations

arXiv:2609.04630v1 [cs.SE] 4 Sep 2026

A Preprint

Zhongjie Wang Faculty of Computing Harbin Institute of Technology China rainy@hit.edu.cn

Mingyi Liu Faculty of Computing Harbin Institute of Technology China liumy@hit.edu.cn September 4, 2026

ABSTRACT Software agents are making one part of software engineering unusually elastic: digital execution. Repository analysis, code generation, testing, migration, tool use, and portions of operations can increasingly be replicated and parallelized without proportional growth in human headcount. Other constraints do not scale in the same way. Problem framing, semantic commitment, verification, integration, attention, and acceptance of residual risk remain bounded by human cognition, organizational authority, and economic capacity. The resulting asymmetry raises a software-engineering question that is broader than code generation: how should scalable execution be governed so that it produces software changes that an organization can accept and sustain through their lifecycles? We develop a testable framework around two primary theoretical constructs and one execution abstraction. Trustworthy Change (TC) is the engineering object that moves from intent through delegated execution, verification, integration, acceptance, and operation. Responsibility Topology classifies a software organization by the distribution of independent authority to accept residual risk. A single-center topology has one final responsibility anchor for the baseline; a multi-anchor topology requires joint acceptance across independently governed domains. The Human–Agent Cell (HAC) is an execution abstraction: it produces candidates, proposals, and evidence, but execution alone does not confer acceptance authority. This separation becomes consequential as execution and acceptance authority scale along different dimensions: distributed HAC execution creates context-coherence and invalidation pressures, while multi-anchor governance adds joint acceptance and explicit responsibility-closure requirements. Responsibility, accountability, change management, specification, verification, and human oversight all predate this paper. Our claim is narrower: agent-scaled execution changes how these concerns fit together. We make independent residual-risk acceptance authority an explicit organizational classification axis and derive consequences for change state, shared engineering facts, verification, and flow control. Progressive Specification and bounded-capacity analysis remain hypotheses to be tested rather than laws asserted by the framework. The contribution is theory construction and operationalization; empirical validity remains open to controlled, longitudinal, and field studies. Keywords Agent Software Engineering · Trustworthy Change · Human–Agent Cell · Responsibility Topology · Single-Center Software Engineering · Multi-Anchor Team Software Engineering · Progressive Specification · Human–Agent Software Organization

1 Introduction: The Scale of Software Execution Is Changing 1.1 Scalable Digital Execution and Shifting Scarcity Many mainstream software-development planning and organizational mechanisms have historically treated human execution capacity as a major constraint. Compilers, IDEs, automated testing, continuous integration, and cloud infrastructure steadily raised developer productivity, but requirements analysis, program construction, fault diagnosis, verification, and maintenance continued to consume substantial human time. Consequently, whether a project followed waterfall development, agile methods, DevOps, or large-scale engineering practices, planning, task decomposition, organization design, and cost estimation were ultimately constrained by a scarce resource: Human Effort. Software agents weaken this assumption. A single developer can now delegate multiple digital execution processes to analyze a repository, generate code, construct tests, locate defects, migrate APIs, process data, configure environments,

Software Engineering in the Agent Era

A Preprint

update documentation, and perform parts of deployment and runtime diagnosis. Relative to conventional human labor, this execution capacity has three distinctive properties. The distinctive change is not simply that an agent writes code faster. Digital execution can be replicated, run concurrently in isolated workspaces, and expanded through token, compute, and tool budgets on a timescale far shorter than recruiting and training a human team. Its supply is now more elastic than the organizational mechanisms that decide what should be built and whether the result should be accepted. The formerly stable relationship Execution Capacity ∝ Number of Human Developers is weakening. SE 3.0 frames this transition as an intent-oriented, conversational form of human–AI software engineering [1]; SASE further places agents within the Actor, Process, Tool, and Artifact structure of software engineering [2]. By 2026, mainstream agent-development environments already support long-running tasks, concurrent agents, isolated workspaces, and programmable tool use. The first-order effect is a restructuring of the supply mechanism for software execution. Shifting scarcity. The other constraints of software development remain. In the sense of Brooks’s classic distinction between essential and accidental difficulties, agents may compress substantial implementation work without eliminating the semantic and organizational difficulty of deciding what a system should do and what evidence is sufficient to accept it [3]. An agent may implement a change rapidly, yet code completion leaves open whether the development goal is sufficiently decided, whether material ambiguity remains, whether a local implementation satisfies system-level constraints, whether verification evidence justifies the required claims, whether multiple local changes compose safely, and who can accept the residual risk after release. We use one running example throughout the paper. An order system initially defines status = {active, cancelled}, where cancelled conflates two meanings: user-initiated cancellation and automatic closure after payment timeout. The system later needs status = {active, cancelled, expired}, with cancelled = user-initiated cancellation, expired = automatic closure caused by payment timeout. At the code level, the change may look like one new enumeration value and a few conditional branches. Agents can propagate it quickly through domain models, payment services, SDKs, tests, analytics, and documentation. The engineering problem is larger. What happens if a successful payment callback arrives after timeout? Does the new status interact with refunds already in progress? Can historical data distinguish the two closure reasons without unsupported inference? How should an old SDK behave when it encounters the new enum? When does analytics adopt the new semantics? Which responsible roles can accept the altered order and payment behavior? The agent era increasingly exhibits Execution Capacity ≫ Judgment, Verification, Integration, and Responsibility. As implementation capacity grows, bottlenecks move toward semantic decisions, verification, integration, resource management, and formal acceptance of risk. 1.2 From Human Process Control to Trusted Change Governance A substantial part of software-engineering process design has historically organized and constrained scarce human execution capacity. Requirements, design, task decomposition, review, testing, configuration management, and project management constrain human activity and turn many local actions into maintainable software systems. These mechanisms remain necessary in agentic development, but the object of control must expand. One software change may be carried out by multiple agents, tasks, and commits. Merely observing people, agent tasks, or code submissions no longer tells us whether that change has satisfied the conditions required to enter an authoritative baseline. We summarize the shift as Human Process Control → Trusted Change Governance.

2

Software Engineering in the Agent Era

A Preprint

We use Trusted Change Governance for the governance paradigm and Trustworthy Change for the software change whose engineering acceptability is governed. Trusted Change Governance follows a change from intent formation and delegated execution through verification, integration, acceptance, and runtime operation. Figure 1 summarizes these two questions and previews the responsibility structures formalized in Section 3: a single-center form with one final anchor 𝑅 ∗ , and a multi-anchor form illustrated by the Order and Payment anchors.

Common Engineering Core

Responsibility Topology Single-Center (Single-Anchor)

Trustworthy Change (TC)

HAC 1

HAC 2

TC

R*

Responsibility traceability HAC 3

Intent

Delegation

Verification

Integration

Operation

Multi-Anchor (Shared TC) R Order

HAC 1

Specification

Resource

Evidence

HAC 2

TC R Payment

HAC 3

methods structurally deform under topology

Delegation / Execution

Responsibility / Acceptance

Authoritative State

What must a change satisfy? Who accepts the residual risk? Figure 1: The two basic questions of Agent Software Engineering: what engineering conditions a software change must satisfy, and who can accept its residual risk.

The resulting theoretical grammar is deliberately compact: Agent SE = Common Engineering Core + Responsibility Topology . The common engineering core describes what a software change must satisfy; Responsibility Topology describes the authority structure through which those conditions are finally accepted. 1.3 Research Positioning, Questions, and Contributions Current agentic software engineering spans several overlapping directions. SE 3.0 and SASE examine changes to actors, processes, tools, and artifacts when agents enter the lifecycle [1], [2]. MAGE argues that as implementation becomes more abundant, engineering scarcity shifts toward representation, evidence, and authority [4]. Hoda explicitly argues that Agentic SE must be framed beyond code and across the whole software process [5]; Alenezi similarly emphasizes verification bottlenecks, accountable oversight, and a shift from code authorship toward outcome ownership [6], [7]. Against this background, our contribution is narrower. Whole-process scope, accountability, and human oversight are established concerns; we focus on how independent residual-risk acceptance authority structures software organizations and change governance. Spec-Driven Development and harness engineering, meanwhile, move agentic development away from one-shot prompts toward persistent specifications, rules, skills, hooks, MCP-based tools, sandboxes, and agent runtimes. Microsoft advocates structured specifications as a shared engineering basis for humans and AI, while GitHub Spec Kit makes Spec, Plan, Task, and Implementation explicit elements of the development process [8], [9]. 3

Software Engineering in the Agent Era

A Preprint

Trust-oriented work is also shifting evaluation from whether an agent completes a task to whether success is sufficiently justified. Programming with Trust, Trustworthy AI Software Engineers, and process-oriented agent evaluation investigate evidence, inspection, accountability, and process quality [10], [11], [12]. A second lineage predates current coding agents and comes from software-engineering questions about organization, competing interests, and controlled evolution. Earlier work by the authors examined role distribution and transformation in software project teams [13], multi-stakeholder value/quality conflicts in composite services [14], and runtime adaptation and evolution in microservice systems [15]. Those settings differ substantially from agentic software development, but they repeatedly expose the same structural tension: locally acting units must retain enough autonomy to do useful work while the system as a whole still needs a defensible basis for coordination and acceptance. Agentic execution changes the speed and scale of that tension. Responsibility Topology addresses the authority dimension, while Authoritative Engineering State and Context Invalidation address coordination of distributed execution around binding engineering facts. Responsibility Topology is orthogonal to the SE4H/SE4A distinction. SE4H/SE4A asks whether software engineering activity is primarily oriented toward humans or agents; Responsibility Topology asks how residual-risk acceptance authority is organized. A single-center organization can have both SE4H and SE4A capabilities, as can a multi-anchor team. Actor or engineering-mode classifications cannot substitute for the authority topology. Relation to established governance mechanisms. Traditional mechanisms such as RACI-style role matrices, configuration/change approval boards, CODEOWNERS, branch or release approval workflows, and separation-of-duty rules are adjacent antecedents rather than substitutes for Responsibility Topology. A role matrix may record who is responsible, consulted, or accountable without specifying whether one actor can unilaterally override another’s final residual-risk acceptance right. Multiple CODEOWNERS or approval steps can still sit under one final responsibility center; conversely, a safety or compliance authority whose required acceptance cannot normally be waived constitutes an independent anchor for affected changes. Responsibility Topology therefore classifies effective acceptance authority rather than workflow participation, repository permission, or approval count. Our central question is consequently how execution, software change, shared engineering facts, and formal acceptance authority should be represented in one software-engineering model once agents become first-class execution actors. Research questions. The paper addresses four research questions. RQ1. Which production constraints of traditional software engineering are changed by agents, and why does this require engineering control to shift from human activity toward the software change itself? RQ2. How does Responsibility Topology distinguish single-center SE from multi-anchor Team SE, and why can the distinction not be reduced to human or agent headcount? RQ3. Which methods form a common engineering core for Agent SE, and which coordination and closure mechanisms arise from distributed execution versus Responsibility Topology? RQ4. Under bounded token, compute, tool, wall-clock, human-attention, and verification capacity, how should the production of Trustworthy Change be measured, estimated, and managed? Contributions. Table 1 summarizes the main contributions and their theoretical status. Table 1: Main contributions of the paper. Type

Contribution

Core question

Classification construct Execution abstraction

Responsibility Topology Human–Agent Cell (HAC)

Integrative construct

Trustworthy Change (TC)

Derived mechanisms Method hypothesis

Authoritative State / Context Invalidation / Responsibility Closure Progressive Specification Engineering

Research program

Bounded-Capacity Agent SE

How is authority to accept residual software risk distributed? What is the execution-participation unit in agentic software work? What constitutes a change that may formally enter the software baseline? How do distributed execution and distributed authority create different coordination and closure requirements? How far should software intent be refined before delegated execution? How do bounded digital resources and verification capacity constrain trustworthy throughput?

The contributions do not all have the same theoretical status. Responsibility Topology introduces a new organizational classification axis. Authoritative State, Context Invalidation, and Responsibility Closure are derived coordination and closure mechanisms: distributed execution creates context-divergence and coordination pressures, while independent 4

Software Engineering in the Agent Era

A Preprint

anchors determine formal closure conditions. HAC and TC are integrative constructs for agentic execution: they reorganize established concerns in human–AI collaboration, change management, evidence, resources, and responsibility into constructs with explicit boundaries and testable consequences. Progressive Specification and Bounded-Capacity Agent SE play the roles of a method hypothesis and a measurement/economics research program, respectively. Tools, metrics, agent hierarchies, and claims–evidence graphs are supporting mechanisms rather than parallel theoretical layers. The novelty claim is intentionally narrower than the vocabulary may suggest. Responsibility, accountability, human oversight, software change, specification, and verification all have long histories in software engineering and governance. Those concerns are prior work. The organizational contribution is the use of the distribution of independent residual-risk acceptance authority as a primary classification axis for Agent SE; the object-level contribution is the explicit Candidate–Eligible–Accepted change lifecycle with resource, evidence, runtime, and responsibility closure attached to the same change. This narrower claim is important because several contemporary approaches already address human–agent responsibility boundaries, approval protocols, graduated oversight, and engineering risk without using the same classification axis [16], [17], [18]. 1.4 Theory Status, Scope, and Empirical Commitments We distinguish three stages of theory development: Conceptualization → Operationalization → Empirical Testing. The present framework concentrates on the first two: it defines constructs and their relations, and it specifies how they can be mapped to observable engineering phenomena. Section 11 states empirical commitments and falsification conditions. Internal coherence is a quality criterion for theory formulation, not a substitute for empirical validity [19], [20]. Paper organization. Figure 2 summarizes the logical structure of the paper. Section 2 analyzes the shift in the control object of software engineering. Section 3 defines HACs, Responsibility Anchors, and Responsibility Topology. Section 4 formalizes Trustworthy Change and acceptance. Section 5 presents the common engineering methods. Sections 6 and 7 study the single-center and multi-anchor forms. Section 8 gives a reference tooling architecture, Section 9 addresses measurement and economics, Section 10 maps the research and industrial landscape as of September 2, 2026, Section 11 defines empirical commitments and a falsifiable research agenda, and Section 12 discusses longer-term implications.

5

Software Engineering in the Agent Era

A Preprint

1

2

Foundations

Introduction

From Human-Process Control to Trusted Change Governance

3

4

Trustworthy Change

Methods

5

Topology-specific Governance

6

HAC and Responsibility Topology

Common Engineering Methods

Single-center Governance

7

Multi-anchor Governance

8

9

Metrics and Economics

Operationalization and Validation

Main logical dependency

Tooling Projection

10

Evidence Landscape and Comparative Positioning

11

Falsifiable Research Agenda

12

Discussion and Conclusion

Same object, different closure conditions

Validation contract

Dependency or logical progression

Figure 2: Roadmap of the paper and logical dependencies among its major parts.

2 From Human Process Control to Trusted Change Governance 2.1 Production Constraints and Capability Mismatch Software engineering has always extended beyond programming. Historically, it has served three broad functions. First, it constrains development activity. Requirements, design rules, coding standards, reviews, testing, configuration management, and change control reduce the freedom of local action so that complex systems can remain coherent across many developers and long periods of evolution. Second, it augments development capability. Compilers, IDEs, build tools, automated tests, CI/CD, and cloud platforms continuously reduce the mechanical cost of software construction and operation. Third, it organizes collaboration. Roles, plans, module boundaries, ownership, configuration baselines, meetings, and project metrics turn many local contributions into system-level results. The Personal Software Process and Team Software Process are systematic examples of process discipline at individual and team scales [21], [22]. From this perspective, the persistent problem of traditional software engineering can be summarized as Limited Human Capacity → Reliable Software. Agentic execution. Agents reduce the marginal cost of search, generation, modification, testing, and local diagnosis. Execution capacity that previously required additional staffing can increasingly be expanded through model calls, agent instances, and compute resources. The change primarily affects the execution side of software work. The causal constraints of software systems do not disappear. State, authorization, data consistency, interface compatibility, performance, and security still depend on system behavior, not on whether the implementation was produced by a human or an agent. MAGE characterizes this transition as a relative scarcity of engineering judgment once implementation capacity expands, and highlights representation, evidence, and acceptance obligations [4]. A 12-week case study from the same research line develops a candidate middle-range theory of governance conversion: recurring failures exposed by high-velocity agentic implementation are converted into durable engineering controls [23]. Independent work on Agentic SE likewise identifies verification as a critical quality bottleneck once code generation becomes abundant [7]. 6

Software Engineering in the Agent Era

A Preprint

The distribution of value in software engineering therefore shifts: implementation remains necessary, but intent, specification, verification, integration, and responsibility occupy a larger share of the complete change cost. Capability mismatch. Table 2 summarizes recurrent capability mismatches and the engineering controls they motivate. Table 2: Typical capability mismatches in agentic software engineering. Capability expansion

Typical failure

Required engineering control

Generation outruns intent clarification

Fast implementation of undecided semantics Locally correct changes conflict systemwide Candidate changes accumulate Agents act on stale engineering facts

Intent and specification

Verification backpressure Context coherence

Agent action radius becomes excessive Deployment precedes risk closure

Task contract and sandboxing Responsibility gate

Rework and long-term responsibility obligations are underestimated

Accepted-TC accounting

Local implementation outruns integration Delegation outruns verification Local context updates outrun sharedstate synchronization Tool capability exceeds task authority Release outruns responsibility acceptance Generation cost falls faster than lifecycle cost

Semantic integration

These failures share one structure: execution has completed while the engineering conditions of the software change remain open. The order-state example is illustrative. A backend agent may implement expired while a client agent updates the SDK in parallel. If they rely on different versions of the state semantics, both candidates can be locally correct and still compose into a system-level error. 2.2 Software Change as the Control Object Traditional processes manage different stages through requirements, tasks, commits, pull requests, and releases. These objects remain valuable, but none individually spans a complete agentic change. One software change may cross multiple agents, tasks, and commits while also changing specifications, data contracts, configuration, prompts or instructions, and runtime policy. Engineering governance needs to trace why the change exists, who authorized it, what it altered, how it was verified, how it entered the baseline, what happened in operation, and who accepted the residual risk. We therefore elevate software change to the lifecycle-level control object and formalize it in Section 4 as Trustworthy Change. Five-loop governance. The process around TC is Intent → Delegation → Verification → Integration → Operation. • Intent decides the change goal, success conditions, and prohibited outcomes. • Delegation defines execution subjects, permissions, scope, and resources. • Verification relates engineering claims to evidence. • Integration determines whether the change may enter the authoritative baseline. • Operation continues to test the assumptions on which acceptance depended. Specification is the refinement through which Intent becomes delegable. Construction is execution after Delegation. Evidence is the primary output of Verification. Responsibility cuts across all five loops. 2.3 Repositioning Established Software Engineering Knowledge Agent SE does not require reinvention of requirements engineering, architecture, testing, configuration management, formal methods, DevOps, or project management. Their roles become sharper under scalable digital execution. Requirements engineering constrains semantic freedom; architecture controls change radius and context cost; testing and formal methods construct evidence; configuration management preserves the Candidate–Baseline boundary; DevOps feeds runtime facts back into TC; and project management must additionally govern HACs, agent resources, verification queues, and responsibility acceptance. TC provides a single object around which these established methods can reconnect. 7

Software Engineering in the Agent Era

A Preprint

3 Execution Units and Responsibility Topology 3.1 Human–Agent Cell: Definition and Interface In an agentic environment, the word developer no longer fully describes the execution unit that actually performs software work. We define 𝐻 𝐴𝐶𝑖 = ⟨𝐻𝑖 , 𝐴𝑖 , 𝑀𝑖 , 𝑇𝑖 , 𝑃𝑖 , 𝐵𝑖 ⟩, where • 𝐻𝑖 is the human execution subject; • 𝐴𝑖 is the set of personal agents; • 𝑀𝑖 is local working memory or context; • 𝑇𝑖 is the available tool set; • 𝑃𝑖 is delegated permission; and • 𝐵𝑖 is the resource budget. A Human–Agent Cell centers on one human execution subject and combines agents, local context, tools, permissions, and budget into the practical execution unit of software work. A HAC may use one agent or run multiple specialized agents concurrently. Changing a model version, adding agents, or changing a token budget does not usually create a new HAC. A material change in the human execution subject or in the formal engineering boundary is instead a HAC-level handoff, termination, or redefinition. HAC is the human-centered execution boundary studied in this paper; it is not claimed to be the only possible execution unit in an agentic software organization. Team-level, organization-level, or fully autonomous agents may exist outside a HAC while remaining subject to the same distinction between execution authority and residual-risk acceptance authority. HAC separation denotes an execution-boundary distinction, not epistemic independence; different HACs may still share models, tools, retrieval sources, or other common-mode dependencies. Figure 3 summarizes this human-centered execution boundary and its formal inputs and outputs.

Authoritative state snapshot

Human-Agent Cell (HAC)

Hi

Ai

Candidate Change

Mi

Task & Resource Contract

Authoritative-State Proposal

Ti Invalidation / refresh signal

Pi

Bi

local memory is not organizational fact

Local Evidence

execution unit, not acceptance authority

Human-Agent Cell (HAC)

Input / Output

Figure 3: A HAC as an execution boundary. It consumes an authoritative-state snapshot, a task/resource contract, and state-change signals, and produces candidates, local evidence, and proposals. Local memory does not automatically become organizational fact.

8

Software Engineering in the Agent Era

A Preprint

Formal interface. A HAC can retain substantial local information: agent scratch memory, provisional analyses, debugging hypotheses, unaccepted designs, and candidate alternatives. Such information is execution state rather than organizational truth. We define the minimal formal input as Input(𝐻 𝐴𝐶) = {Authoritative State Snapshot, Task–Resource Contract, State-Change Signal}, and its formal output as Output(𝐻 𝐴𝐶) = {Candidate Change, Authoritative-State Proposal, Local Evidence}. This boundary permits substantial internal autonomy while constraining state-changing outputs to candidate changes, proposals, and evidence. Organizational fact formation follows Proposal → Authorized Acceptance → Versioned Commit. Local memory and Authoritative Engineering State are therefore distinct by construction. 3.2 Responsibility Anchor and Effective Governance Rules A Responsibility Anchor is A responsibility node traceable to a natural person or an institutionalized organizational role that has formal authority to accept or reject residual risk for a software baseline or a key responsibility domain. Examples include a Product Owner, Security Owner, Architecture Owner, or Release Authority, provided that the role actually carries the relevant acceptance right. An agent may receive operational authority inside a delegated boundary and may be recorded as an auditable executor. In the governance model of this paper, acceptance of residual risk remains assigned to an identifiable human or institutional legal subject. This assumption is consistent with current governance frameworks that allocate provider, deployer, and human-oversight duties to natural persons, legal persons, public authorities, or other formal organizational actors [24]. We do not prejudge whether future legal systems may assign legal personality to AI systems. HACs and Responsibility Anchors belong to different analytical levels: 𝑁HAC ≠ 𝑁anchor . The same person can be both a HAC execution subject and an anchor for a responsibility domain; a person can also execute under the authority of a different anchor. Table 3 distinguishes the execution and acceptance roles of agents, HACs, and Responsibility Anchors. Table 3: Agents, HACs, and Responsibility Anchors. Object

Primary role

Agent HAC

Digital execution Local software execution

Responsibility Anchor

Residual-risk acceptance or rejection Cross-HAC or organizational execution

Team/Organization Agent

Produces Candidate? Yes Yes May participate Yes

Final acceptance authority No Only if its human subject holds the required formal authority Yes No

3.3 Responsibility Topology Responsibility Topology describes how residual-risk acceptance authority is distributed under the currently effective software-governance rules; it is distinct from a generic organizational chart, role matrix, or risk register because the classification depends specifically on independent final acceptance rights for a software baseline or affected responsibility domain.1 1 The phrase responsibility topology also appears in a February 2026 MARIA OS design note, where it denotes a weighted directed graph of decision nodes and responsibility flows with continuous human/agent responsibility allocation; see https://os.maria-code.ai/en/blog/agentic-company -structural-design. Our use is deliberately narrower: it refers specifically to the topology induced by independent residual-risk acceptance authority for software baselines or affected responsibility domains. We make the lexical overlap explicit because the two constructs are adjacent but not equivalent.

9

Software Engineering in the Agent Era

A Preprint

Single-center topology. If one final responsibility anchor 𝑅 ∗ can (1) finally accept or reject residual risk for the current software baseline and (2) revoke or override the software-engineering authority of other participants without changing the governance rules themselves, the organization has a single-responsibility-center topology. We use single-center SE for this theoretical form. A one-person company (OPC) is a common practical instantiation, but the topology is not defined by headcount. Single-center SE can contain many HACs, agents, contractors, or external specialists. For a change 𝑥, Acceptsingle (𝑥) = Accept 𝑅∗ (𝑥). Multi-anchor topology. If a software baseline contains at least two independent Responsibility Anchors, each holding acceptance rights in a key domain that another anchor cannot unilaterally revoke under normal governance, the organization has a multi-anchor topology. Responsibility Topology is an organization- or baseline-level property under the currently effective governance rules. For a particular change 𝑥 evaluated against authoritative state 𝑆 𝑣 , define the effective acceptance set 𝐾 (𝑥, 𝑆 𝑣 ) as the Responsibility Anchors whose acceptance is mandatory for that change under the current governance rules and authoritative state. When 𝑆 𝑣 is fixed, we write 𝐾 for brevity. Then Acceptmulti (𝑥) = Accept𝐾 (𝑥) = ∧ Accept 𝑘 (𝑥). 𝑘 ∈𝐾

System-level acceptance requires the relevant authority domains to close jointly. A multi-anchor organization may therefore have a particular UI-only TC with 𝐾 (𝑥, 𝑆 𝑣 ) = {𝑅Product }; the organization remains multi-anchor because topology describes the wider distribution of independent acceptance rights, not the cardinality of the effective acceptance set for every change. Quorum, alternative-approver, conditional-acceptance, and emergency-override structures are extensions beyond the present two-topology model. Operationalizing current governance rules. Responsibility Topology cannot be inferred solely from job titles, repository write access, or who happens to merge most changes. Empirical identification should observe at least three sources of evidence. First, de jure governance: job definitions, approval matrices, contracts, policies, formal ownership, and explicit risk-acceptance rules. Second, technical enforcement: CODEOWNERS, branch protection, IAM, deployment permissions, rollback authority, and release gates. Third, de facto practice: who actually accepts, rejects, revokes, or overrides a change during normal engineering governance. Technical permissions are not identical to formal risk-acceptance authority. A mismatch among de jure authority, technical enforcement, and de facto practice should be recorded rather than collapsed. While such a conflict remains unresolved, a valid acceptance path has not been established and the candidate cannot be treated as cleanly Eligible. A topology change occurs when management changes the governance rules so that the distribution of anchor authority changes. Operational distinction between anchor validity and acceptance. The R6/Pending distinction becomes operational only if an engineering record can separate two questions. Throughout this paper, ValidAnchor(𝑘, 𝑥), Accept 𝑘 (𝑥), Eligible(𝑥, 𝑆 𝑣 ), and AcceptedTC(𝑥) are Boolean-valued predicates over the recorded engineering and governance state rather than quantitative functions. In particular, Accept 𝑘 (𝑥) = true means that anchor 𝑘 has formally recorded acceptance of the residual risk of change 𝑥 under the currently effective governance rules. For a required domain 𝑘 and change 𝑥, let ValidAnchor(𝑘, 𝑥) denote whether current governance establishes a legitimate anchor for that domain; let Accept 𝑘 (𝑥) denote the change-specific acceptance decision recorded by that anchor. The first is inferred from de jure rules, technical enforcement, and de facto governance evidence; the second is a state of the particular TC. Thus an absent or invalid required anchor can trigger R6, whereas ValidAnchor(𝑘, 𝑥) = true,

Accept 𝑘 (𝑥) = false

is an acceptance-pending condition rather than an R6 failure. These symbols are operational notation, not additional top-level constructs. In practice, CODEOWNERS or deployment permissions can contribute evidence about the first question, but they are not by themselves proof of formal residual-risk authority. Worked closure example. The order-status change makes the topology distinction concrete. In a single-center organization, the required set is 𝐾 = {𝑅 ∗ }, Accept𝐾 (𝑥) = Accept 𝑅∗ (𝑥). 10

Software Engineering in the Agent Era

A Preprint

If the candidate has passed R1–R6 and the final anchor accepts it, Accept𝑅∗ (𝑥) = true,

Eligible(𝑥) = true, so

AcceptedTC(𝑥) = true. The same artifact change can require a different closure under multi-anchor governance. Suppose Order semantics and Payment timeout behavior belong to independently governed domains: 𝐾 = {𝑅Order , 𝑅Payment }, Accept𝐾 (𝑥) = AcceptOrder (𝑥) ∧ AcceptPayment (𝑥). If Order has accepted while Payment has not, Eligible(𝑥) = true,

AcceptOrder (𝑥) = true,

AcceptPayment (𝑥) = false,

the change is Eligible / Acceptance Pending, not Accepted. If instead ValidAnchor(Payment, 𝑥) = false, R6 fails because the required responsibility path is invalid. Extra reviewers, contractors, or agents change execution or evidence capacity; they do not create a new responsibility center unless governance creates a new independent acceptance domain. This criterion has two useful invariance properties. First, the topology can remain unchanged while execution capacity changes dramatically. A founder who moves from one coding agent to twenty concurrent agents has changed the execution graph, but not the location of final residual-risk acceptance if the same final anchor retains revocable authority. Likewise, adding contractors, reviewers, or specialist HACs does not by itself create a new responsibility center. Second, the topology can change while headcount remains nearly constant. Two engineers may constitute a multi-anchor organization if each has an independent, non-revocable acceptance right over an affected domain. These counterexamples make Responsibility Topology orthogonal to human count, agent count, and HAC count rather than a proxy for any of them. The distinction matters only if it changes engineering behavior. Under a single-center topology, conflicting evidence and local interpretations can ultimately be resolved by one final anchor without changing the governance rules. Under a multi-anchor topology, no single HAC or anchor can unilaterally close all affected responsibility domains. The organization must therefore represent which facts are authoritative, which changes invalidate other work, which anchors are required for a particular TC, and whether execution has completed without responsibility closure. In this sense, Responsibility Topology is not merely a descriptive taxonomy: it predicts different coordination and acceptance mechanisms. The boundary is intentionally based on residual-risk acceptance rather than ordinary technical permissions. A repository administrator may be able to merge code without possessing formal authority to accept the business or safety risk of the resulting baseline; conversely, a product or compliance role may possess formal acceptance authority without holding direct deployment credentials. Current effective governance rules, evidenced jointly by de jure authority, technical enforcement, and de facto practice, determine the topology. As specified above, unresolved disagreement among these sources leaves the acceptance path invalid for the current TC. Figure 4 summarizes the resulting independence of Responsibility Topology from human, HAC, and agent counts.

11

Software Engineering in the Agent Era

A Preprint

H = 10 HAC = 10 A = few R=1

1 Single final acceptance authority

2

H=4 HAC = 4 A = few R=2

3

4

H=1 HAC = 1 A = 20 R=1

H=4 HAC = 4 A = many R=2

Multiple independent anchors

SE4H Human

SE4A Human-Agent Cell (HAC)

Personal Agent

Responsibility Anchor

Figure 4: Responsibility Topology is orthogonal to SE4H/SE4A-oriented engineering modes. Humans, HACs, personal agents, and independent Responsibility Anchors are distinct quantities.

3.4 Execution Distribution versus Responsibility Distribution Agentic software organizations vary along at least two independent structural dimensions. Execution distribution concerns how work is spread across HACs and agents; responsibility distribution concerns how independent residual-risk acceptance authority is organized. Context divergence and invalidation arise primarily from distributed execution, whereas joint acceptance and responsibility closure follow from distributed authority. Multi-anchor governance makes explicit authority, versioning, and invalidation semantics necessary when cross-anchor closure depends on shared engineering facts. Table 4 separates the primary structural sources of the resulting coordination and closure mechanisms. Table 4: Primary structural source of coordination and closure mechanisms. “Strengthens” means that multi-anchor governance turns a coordination concern into an explicit cross-anchor closure requirement rather than creating the concern by itself. Mechanism or pressure

Distributed HAC execution

Independent acceptance authority

Candidate parallelism Context divergence / staleness Authoritative, versioned state Context Invalidation Cross-cell verification Joint acceptance Acceptance Pending Responsibility Closure / Orphan Delegation–Responsibility misalignment

Primary source Primary source Useful for coordination Primary trigger Enables heterogeneous evidence sources Not required Not required Not required Creates opportunities for mismatch

Not required Not required Strengthens: required for cross-anchor closure Strengthens when stale assumptions affect closure May impose domain-specific evidence obligations Primary source Primary source Primary source Makes unresolved mismatch non-collapsible by one center

Local memory versus organizational truth. Different HACs naturally possess different contexts: Context𝑖 (𝑡) ≠ Context 𝑗 (𝑡). If agents act on different versions of a specification, architecture decision, or contract, their candidates can each be locally coherent while being mutually incompatible with the current system semantics. 12

Software Engineering in the Agent Era

A Preprint

Delegation and responsibility are different structures. The structure that delegates execution is not the structure that accepts risk: Delegation Graph ≠ Responsibility Graph. Agents and HACs can complete their tasks while the anchor responsible for the affected risk domain still rejects the resulting change. Heterogeneous evidence. The value of a team does not come only from additional execution capacity. Different expertise, contexts, interests, and acceptance rights can create heterogeneous judgment: Heterogeneous Judgment + Independent Evidence + Distributed Acceptance. Section 7 develops this mechanism further. Toward human–agent team software processes. PSP emphasizes planning, measurement, and quality discipline in the individual software process; TSP extends this concern to team goals, roles, quality, and collective commitment [21], [22]. A related separation appears in Agent SE: single-center SE studies how one final responsibility center governs scalable digital execution, while multi-anchor Team SE studies how multiple HACs and independent anchors maintain shared engineering state, cross-cell verification, and system-level responsibility closure. These observations motivate a future research direction on human–agent team software processes; this paper does not define a new fixed process standard.

4 Trustworthy Change: A Unified Object for Software Change 4.1 TC Components and States Prompts, tasks, commits, and pull requests each serve different software-engineering functions. A prompt expresses interaction intent, a task organizes execution, a commit records a versioned code change, and a pull request supports review and integration. An agentic software change often crosses several of these objects and may additionally modify specifications, data contracts, configuration, model instructions, and runtime policy. If governance is attached only to one local artifact, it becomes difficult to reconstruct the complete relationships among production, verification, configuration, and responsibility. We define the engineering object that spans the full lifecycle of a software change as Trustworthy Change (TC). The need for a lifecycle-spanning object follows from a mismatch among existing artifacts. A commit captures code history but not necessarily the intent that justifies the change. A pull request can aggregate discussion and tests but may not encode the resource envelope, runtime assumptions, or authority structure under which the change is accepted. A change request captures organizational intent but may be detached from the concrete provenance and evidence of the implementation. A release identifies a delivered baseline but is too late to serve as the unit that structures delegation and verification. Agentic execution makes these gaps more visible because one semantic change can be spread across many agent trajectories, commits, tool calls, generated tests, and state proposals. TC acts as a cross-artifact identity for one consequential software change. Its six components are not intended as six new documents. They form the compact working set of traceable closure dimensions used in this framework to answer six engineering questions: what was intended, under what authority and resources execution occurred, what changed and where it came from, what evidence supports the claims, how the change enters and survives operation, and who can accept the remaining risk. We do not claim that this decomposition is ontologically exhaustive or uniquely minimal. Omitting one of these dimensions exposes a corresponding class of governance or assurance failure that the framework is designed to make visible: ambiguous intent, unbounded action, untraceable provenance, unsupported claims, unsafe integration, or unclosed responsibility. Components. Table 5 summarizes the six working closure dimensions used by TC. Table 5: Six components of Trustworthy Change. Component

Main content

Intent & Specification Delegation & Resource Envelope Change & Provenance Evidence Integration & Runtime State Responsibility

Purpose, success conditions, failure conditions, and prohibited outcomes Execution subjects, permissions, scope, and resources The actual change, its origin, dependencies, and execution history Engineering claims and the evidence supporting them Baseline, release, operation, observation, and recovery state Proposal, authorization, verification, acceptance, and residual-risk ownership 13

Software Engineering in the Agent Era

A Preprint

TC can simultaneously serve as a production unit, verification unit, configuration/change-management unit, measurement unit, economic-accounting unit, and responsibility unit. This unification does not require all engineering information to be stored in one physical record. It requires that the information remain traceable to the same underlying software change. State progression. A HAC first produces a Candidate Change. Candidate means digital execution has produced an artifact ready for engineering evaluation. Whether or not the candidate is eventually accepted, token, compute, tool, and human-attention resources have already been consumed and therefore belong in the engineering cost. A Candidate becomes Eligible after passing engineering-qualification checks: Eligible(𝑥) ⇐⇒ ¬ (𝑅1 ∨ 𝑅2 ∨ 𝑅3 ∨ 𝑅4 ∨ 𝑅5 ∨ 𝑅6 ) . Eligible means the change is qualified to enter formal responsibility acceptance. For a change 𝑥 evaluated against authoritative state 𝑆 𝑣 , let 𝐾 = 𝐾 (𝑥, 𝑆 𝑣 ) denote the effective acceptance set defined in Section 3. System-level acceptance is Accept𝐾 (𝑥) = ∧ Accept 𝑘 (𝑥), 𝑘 ∈𝐾

and therefore AcceptedTC(𝑥) ⇐⇒ Eligible(𝑥) ∧ Accept𝐾 (𝑥). Eligibility and acceptance answer different questions: the former is a qualification judgment; the latter is formal closure of residual risk. This separation is especially important when generation is faster than organizational decision making. A candidate can be technically well formed and richly evidenced while still waiting for a required anchor; conversely, organizational willingness to proceed cannot make an inadequately evidenced candidate Eligible. The three-state progression prevents implementation completion, engineering qualification, and responsibility acceptance from collapsing into a single overloaded notion of “done.” It also creates a stable accounting boundary: all candidate work consumes resources, only Eligible changes may enter formal acceptance, and only Accepted TC enters the authoritative baseline. Eligibility is relative to the current governance rules, the current Authoritative-State version, and the currently available evidence. Tools and people can jointly determine it. R2, R3, and parts of R5 can often be highly automated; R1 and R4 frequently require semantic or professional judgment; R6 requires analysis of formal authority. In particular, Eligible(𝑥, 𝑆 𝑣 ) ⇏ Eligible(𝑥, 𝑆 𝑣+1 ). If an authoritative fact that affects 𝑥 changes, eligibility must be revalidated through the Context Invalidation actions defined in Section 7. If the required anchors validly exist but have not yet accepted the change, then Accept𝐾 (𝑥) = false.

Eligible(𝑥) = true,

The change is Eligible / Acceptance Pending; this is not an R6 failure. An agent that produced the candidate may assist with eligibility analysis, but it cannot by itself close the responsibility structure required for its own candidate. Figure 5 summarizes the resulting qualification and acceptance states.

14

Software Engineering in the Agent Era

A Preprint

Accept K complete

anchors exist, unsigned

Eligibility check

Candidate

Eligible

Pending

Accepted

R1–R6 triggered

runtime assumptions change

Rejected

Abandoned

New TC

State transition Feedback transition

Baseline

Neutral state

Pending state

Accepted state

Rejected state

Baseline state

Figure 5: Trustworthy Change state machine. Eligibility denotes engineering qualification; acceptance denotes closure of residual risk. A valid but unsigned anchor produces an acceptance-pending condition rather than an R6 failure.

4.2 Eligibility, Rejection, and Acceptance Table 6 lists the conditions that prevent a Candidate from becoming Eligible. Table 6: Conditions that prevent a Candidate from becoming Eligible. ID

Failure type

Typical issue

R1 R2 R3 R4 R5 R6

Intent / Specification Failure Delegation / Resource Failure Change / Provenance Failure Evidence Failure Integration / Operation Failure Responsibility Failure

Goal, non-goals, boundary, or key semantics remain undecided Authority is exceeded, scope is wrong, or resource budgets are uncontrolled Origin, dependencies, or execution process cannot be traced A material claim lacks sufficient evidence Baseline, release, observability, or recovery readiness is insufficient A required responsible subject or acceptance path does not exist, is invalid, or lacks legitimate authority

R1 and R6 are related but logically independent. R1 asks whether intent and specification are sufficiently decided. R6 asks whether the responsibility structure under which those decisions and subsequent risk acceptance occur exists and is valid. A legitimate Product Anchor may already exist while the requirement remains ambiguous; R1 fails while R6 does not. Conversely, the specification may be fully clear while no valid anchor exists for the affected responsibility domain; R6 fails while R1 does not. Semantic commitments relevant to R1 must be made by subjects authorized under the Responsibility Topology, but R1 cannot be replaced by R6. For a pre-production candidate, R5 evaluates operational readiness—for example release strategy, observability, and recovery planning—rather than requiring proof that future operation can never fail. Trustworthiness is not a permanent label. An Accepted TC is accepted relative to a particular version, evidence set, and time condition. New runtime facts can invalidate the acceptance assumptions and trigger a new TC. 15

Software Engineering in the Agent Era

A Preprint

4.3 Lifecycle and Responsibility The basic TC process remains Intent → Delegation → Verification → Integration → Operation. Intent creates goals and constraints; Delegation creates tasks, permissions, and resource envelopes; Verification relates claims to evidence; Integration prepares and validates the composition of an Eligible Change with the target baseline; Operation produces new runtime evidence. Final baseline commitment occurs only after the required acceptance set 𝐾 closes: Integration Readiness → Accept𝐾 → Baseline Commit → Operation. Specification is progressively refined between Intent and Delegation. Construction is execution after Delegation. Responsibility spans all five loops. Responsibility checkpoints. Each loop corresponds to a responsibility question: • Intent: who has authority to define or change the software goal? • Delegation: who has authority to authorize HAC and agent action? • Verification: who judges that the evidence is sufficient for the current claims? • Integration: who may admit the change to the authoritative baseline? • Operation: who accepts runtime residual risk and recovery obligations? Responsibility is therefore a longitudinal property of TC, not a sixth stage added to the software process. Three analytical scales of responsibility. We use responsibility at three distinct scales. First, the responsibility component inside a TC records who proposed, authorized, verified, and accepted a specific change: an instance-level responsibility record. Second, responsibility checkpoints across the five loops describe the governance questions that must close during the lifecycle: a process-level governance concern. Third, Responsibility Topology describes the formal organization of residual-risk acceptance rights among anchors: an organization-level authority structure. The three levels share a common responsibility semantics, but answer different-granularity questions. Four assurance questions. A TC can be continuously assessed through four questions: Q1. Are intent and specification sufficiently decided? Q2. Are the claims about the change sufficiently evidenced? Q3. Does operation continue to support the acceptance assumptions? Q4. Does responsibility remain identifiable and actionable? Security, performance, compatibility, structural correctness, and similar properties enter Q2 as claims supported by corresponding evidence. 4.4 Relation to Change Management and the Running Example TC maps directly onto established change and configuration-management concepts. Table 7 shows the corresponding mapping. Table 7: Mapping from traditional change management to Trustworthy Change. Traditional object

Location in TC

Change Request Impact Analysis Work Assignment Implementation Review / Testing Configuration Item Baseline Change Approval Release / Monitoring

Intent & Specification Specification refinement and risk analysis Task & Resource Contract Candidate Change Evidence Integration Accepted state Responsibility acceptance Integration & Runtime State

Agentic execution adds delegated permission, resource envelopes, agent provenance, evidence independence, runtime drift, and Responsibility Topology. TC can therefore be understood as an extensible engineering abstraction that reorganizes traditional change management for agentic execution conditions. 16

Software Engineering in the Agent Era

A Preprint

Running illustrative example. The order-state change is the paper’s running illustrative example. It is used to maintain conceptual consistency and to show how intent, delegation, evidence, Responsibility Topology, and Context Invalidation apply to the same software change. It is not a case study and does not empirically validate the framework. After the state space evolves from {active, cancelled} to {active, cancelled, expired}, Intent and Specification must at minimum define the semantic boundary between cancelled and expired, late payment callbacks, refund states, old-SDK behavior, and historical-data policy. Delegation constrains the scope, permissions, and budgets of backend, payment, client, and analytics tasks. Verification must cover the state machine, payment contract, late callbacks, legacy-client compatibility, and analytics consistency. Integration must specify contract versions, compatibility windows, release order, rollback, and monitoring. Responsibility is determined by the current Responsibility Topology. The point of the example is that a small artifact change need not imply a small semantic scope, verification scope, or responsibility scope for the TC.

5 Common Engineering Methods for Agent Software Engineering This section defines the common method layer once. Sections 6 and 7 do not introduce second versions of these mechanisms; they discuss how the same specification, task, verification, integration, and recovery methods respond to distributed execution and how their closure conditions differ when acceptance authority is concentrated or distributed. 5.1 Intent and Progressive Specification Natural language can express software intent at low cost, but an agent’s ability to adapt to language can also conceal unresolved issues. Intent Engineering therefore begins by distinguishing information with different epistemic and governance status: • Fact: a state that can already be observed or verified; • Evidence: data or facts supporting a judgment; • Assumption: a judgment on which the current analysis depends but that is not yet sufficiently verified; • Preference: a stakeholder inclination; and • Decision: a formal choice made by a subject with appropriate authority. In the order example, “the current cancelled state conflates two closure causes” is a fact. Customer-support and operational data may provide evidence. “The new enum will not break old clients” is an assumption until verified. “Users should be able to distinguish the two closure modes” is a preference. Formally introducing expired is a decision. Agents can support feedback clustering, historical retrieval, counterexample construction, and generation of clarification questions. Decisions that change software semantics should enter Authoritative Engineering State. Progressive specification. Natural-language specification creates costs in two directions. Under-specification gives agents a large interpretation space and can increase candidate divergence, clarification effort, and rework. Overspecification increases elicitation, modeling, maintenance, and context costs. We therefore model specification as a progressive path: Natural Intent → Clarification → Structured Specification → Executable Constraint → Formal Specification. Minimum Sufficient Specification. The goal is a Minimum Sufficient Specification: The lower practical boundary of a task- and risk-dependent effective specification region, if such a region exists. The hypothesis is not that one universal minimum exists across tasks; rather, additional rigor may eventually yield diminishing reductions in semantic divergence, rework, or verification uncertainty relative to its added lifecycle cost. Required rigor depends primarily on ambiguity, impact, irreversibility, and verifiability. Agents are well suited to ambiguity detection, generation of clarification questions, structured-specification drafting, generation of candidate contracts/tests/properties, and consistency checking. Semantic commitment remains with the authorized human responsibility subject.

17

Software Engineering in the Agent Era

A Preprint

Lifecycle cost

Minimum-sufficient zone

Illustrative - not fitted to data

Specification rigor Specification effort

Rework / downstream correction

Total lifecycle cost

Figure 6: Hypothesized lifecycle cost trade-off in Progressive Specification. The curve shapes and the existence of a minimum-sufficient region are empirical hypotheses tested by the research agenda in Section 11.

The curves in Figure 6 are conceptual illustrations: neither their shape nor the existence or location of a minimumsufficient region is an empirical result of this paper. The research question is whether, for practically relevant classes of changes, there is a level of specification rigor beyond which additional specification cost no longer buys commensurate reductions in downstream ambiguity, rework, or verification uncertainty. 5.2 Architecture, Change Locality, and Task Contracts An architecture intended for agentic software work should satisfy three properties. Agent-operable means that the system exposes stable commands, clear schemas, repeatable environments, and callable tools so that agents can act reliably. Human-understandable means that responsible people can still understand key states, dependencies, interfaces, and invariants. Human-takeoverable means that agent tasks can be stopped, reproduced, rolled back, handed off, and recovered. We use change locality to describe the engineering span of a typical change. It is not defined as an additive scalar. At minimum, it should be observed along three dimensions: 1. Artifact span: how many modules, files, interfaces, and data structures are touched; 2. Context span: how much engineering context and how many invariants must be loaded for execution and verification; and 3. Responsibility span: how many HACs, responsibility domains, and acceptance anchors are involved. Review Scope and Revalidation Scope can be observed separately when useful. Poor change locality is expected to correlate with higher context, integration, and verification cost, but this is an empirical claim rather than a definition. Information hiding and modularity [25] therefore acquire an additional agent-economics interpretation: good modularity may reduce not only human cognitive cost but also agent context and verification cost. For security, authorization, accounting, and other critical logic, an architecture may use a Deterministic Core + Probabilistic Shell: unacceptable consequences should be bounded by deterministic mechanisms even when probabilistic agents perform surrounding work. 18

Software Engineering in the Agent Era

A Preprint

Task and Resource Contract. Delegation to an agent must constrain goals, authority, and resources simultaneously. We represent a task as 𝑇 𝑎𝑠𝑘 = {Goal, Context, Scope, Permission, Budget, Acceptance, Stop, Handoff}, and the resource envelope as 𝑅 = ⟨Token, Compute, Tool, Wall-Clock Time, Human Attention⟩ . The Stop Condition is first class. An agent should stop current autonomous execution and escalate when, for example, it needs unauthorized data, expanded write permission, an irreversible migration, budget overrun, or a high-risk consequence that cannot be judged within the current boundary. The design grants agents substantial autonomy inside explicit authorization while keeping the boundary auditable. Agent execution threat model. The central security risk in agentic execution arises from coupling untrusted input to high-privilege tools. OWASP and NIST identify prompt injection, indirect prompt injection, and agent hijacking as major risks in current agent systems [26], [27]. Peer-reviewed work has begun to connect these threats to action boundaries: Task Shield evaluates whether instructions and tool calls remain aligned with the user’s task [28], while MCPTox studies tool poisoning through malicious MCP metadata and tool descriptions [29]. In software-engineering settings, attacks may originate in user prompts or in webpages, email, files, RAG content, tool descriptions, and tool outputs read by an agent. Representative threats include: • Direct Prompt Injection: user input attempts to override system or task instructions; • Indirect Prompt Injection: external documents, pages, email, or retrieved content carry malicious instructions; • Tool / Context Poisoning: malicious tool metadata or outputs contaminate agent context; • Data Exfiltration: sensitive information is leaked through network access, email, file writes, or tool calls; • Privilege Escalation / Unauthorized Action: the agent is induced to perform database writes, IAM changes, external messaging, deployment, or other actions beyond task authority; and • Persistent Context Poisoning: malicious content enters persistent memory or shared state and influences later agents. The security objective is not to assume that an agent can recognize every attack. Instead, Compromise of Interpretation ⇏ Unbounded Compromise of Action. Even when semantic interpretation is manipulated, permission boundaries, sandboxes, tool hooks, egress policies, and high-impact confirmation should bound the maximum harm radius. This containment-oriented view is also consistent with secure-development guidance such as the NIST Secure Software Development Framework, which treats security practices as lifecycle-integrated engineering controls rather than a final inspection step [30]. Table 8 summarizes the principal attack surfaces and controls. Table 8: Agent execution threats and engineering controls. Threat

Primary attack surface

Primary engineering control

Direct Prompt Injection

User input

Indirect Prompt Injection

Web / email / file / RAG

Tool / MCP Poisoning Data Exfiltration Privilege Escalation Persistent Context Poisoning

Tool description / output Network / email / file write DB / IAM / administrative tools Memory / shared state

Task scope, instruction/data separation, forbidden actions Untrusted-context marking, tool restriction, output validation Allowlist, trusted tool registry, runtime validation DLP, destination policy, network-egress control Least privilege, scoped credentials, approval gates Proposal/acceptance separation, versioned authoritative state

5.3 Construction and Evidence-Based Verification The engineering objective of agent-native construction is To produce Candidate Changes that are comparable, verifiable, and revocable inside controlled environments. Candidate changes should preferably be executed in branches, worktrees, containers, VMs, sandboxes, or equivalent isolated environments. Minimum useful provenance should trace the model or agent, context version, tool calls, dependency changes, manual edits, and build/test environment. 19

Software Engineering in the Agent Era

A Preprint

Agents lower the cost of producing alternatives, making multi-candidate exploration more practical. Yet every additional candidate increases comparison and verification cost. Candidate exploration must therefore also be constrained by resource and verification capacity. Evidence-based verification. Verification begins by stating what properties the change claims to satisfy. For the order-state TC, example claims include 𝐶1 :

Payment Timeout ⇒ expired,

𝐶2 :

User Cancellation ⇒ cancelled,

as well as claims about late payment, legacy clients, and analytics. Verification can then be represented as a claims–evidence relation: Claim𝑖 → {Evidence𝑖1 , Evidence𝑖2 , . . .}. Evidence quality depends on both coverage and independence. We distinguish Model/Method Independence, Context Independence, Criterion Independence, and Responsibility Independence. Common-mode epistemic failure. Hallucination or confabulation is one visible source of evidence failure; NIST identifies confident production of erroneous or fabricated content as a generative-AI risk [26]. The broader problem in Agent SE is correlated or common-mode epistemic failure. Agents executed independently may still share a base model, training data, omitted specification assumptions, retrieval sources, benchmark habits, or organizational priors, producing correlated mistakes. Using different model families can reduce some common failure sources, but model diversity alone does not establish evidence independence. Different models can share data, specifications, retrieval sources, or systematic biases. Risk-adaptive evidence expectations. The meaning of “sufficiently evidenced” in Q2 depends on claim type and risk. Table 9 gives illustrative risk-adaptive evidence expectations. Table 9: Risk-adaptive evidence expectations. Change / claim type

Illustrative minimum evidence expectation

Low risk, local, easily reversible Cross-module or public contract Data or state migration High-risk concurrency, payment, or authorization logic High-impact security or compliance property Very high risk and formalizable property

Deterministic test + provenance + reproducible command Regression + contract test + executable reproduction Invariant + representative migration test + rollback rehearsal Property/fuzz/concurrency test + independent verification Independent review + policy check + explicit acceptance Executable/formal constraint + independent evidence

These are not new correctness levels. They are risk-adaptive Evidence Profiles under Q2, shaped by risk, specification rigor, and responsibility domain. Different anchors may declare different minimum evidence gates for their domains. The approach borrows engineering-quality ideas such as being documented, consistent, complete, exercisable, and reproducible, but we do not call Candidate Change verification “Artifact Evaluation” because that term has an established meaning in research-artifact assessment. 5.4 Integration, Operation, and Recovery After local verification, a Candidate must still be integrated at system level. Conventional CI/CD is often represented as Code → Build → Test → Deploy. At the TC level, the lifecycle is richer: Intent → Specification → Candidate → Evidence → Eligible → AcceptedTC → Release → Runtime Evidence. Only an Accepted TC may modify the authoritative baseline. Integration must also resolve semantic conflict. Two candidates can merge cleanly in Git while contradicting one another at the level of API contracts, state models, data semantics, or architecture rules. Agent SE must distinguish textual merge from semantic integration. 20

Software Engineering in the Agent Era

A Preprint

AgentOps, recovery, and responsibility continuity. After release, the system continues to produce technical telemetry, user outcomes, agent behavior, cost, and incident evidence. Agentic operation adds sources of drift including model drift, context drift, cost drift, and architecture drift. When anomalies occur, autonomy can contract progressively: Auto-execute → Human approval → Read-only → Stop. Systems should also support rollback, restore, reproduce, and handoff. Table 10 summarizes how these common methods interact with distributed execution and Responsibility Topology. Table 10: How common engineering methods interact with distributed execution and Responsibility Topology. Method

Single-center SE

Multi-anchor Team SE

Intent decision

Converges to one final anchor

Specification

Concurrent HACs may still require context invalidation after authoritative-state changes Controls cognitive burden on one final anchor

May require joint acceptance across responsibility domains The same invalidation problem exists; explicit authority/version semantics support cross-anchor closure Also defines context, ownership, and responsibility boundaries The three roles may belong to different HACs and anchors Cross-cell evidence adds organizational heterogeneity

Architecture Delegation Verification Integration Takeover

Authorizer, verifier, and acceptor may be the same anchor at different times Relies more on tools, heterogeneous models, and external experts One center closes baseline acceptance Focuses on replacing the final anchor

Multiple anchors jointly close responsibility Requires reconnecting the Responsibility Graph

6 Single-Center Software Engineering Section 5 defined the common engineering methods. This section focuses on the capacity, verification, continuity, and economic consequences that arise when one final Responsibility Anchor closes residual risk. A one-person company is treated only as a common practical alias for this topology. 6.1 Capacity, Verification, and Evidence Independence A single-center organization can contain 𝑅 ∗ −→ {𝐻 𝐴𝐶1 , 𝐻 𝐴𝐶2 , . . . , 𝐻 𝐴𝐶𝑛 }. The periphery may additionally include security specialists, legal advisers, contract developers, cloud services, and independent testing organizations. These actors can provide execution, consultation, or evidence; formal acceptance of residual risk for the software baseline still closes at 𝑅 ∗ . The structural property of single-center SE is distributed execution capacity with concentrated final responsibility. Capacity and the verification queue. The order-state change can be delegated simultaneously to backend, payment, SDK, compatibility, and analytics agents. All resulting candidates eventually return to one responsibility center for understanding, verification, and integration. A conceptual upper bound on effective concurrency is
𝐶single ≤ min 𝐶𝐷 , 𝐵integration , 𝐵verification , 𝐵economic , where 𝐶𝐷 is the decomposability-induced throughput ceiling, 𝐵integration is integration bandwidth, 𝐵verification is verification bandwidth, and 𝐵economic is economic capacity. In practical terms, 𝐶𝐷 is the throughput ceiling induced by how far a change can be partitioned into independently verifiable subtasks; changes differ in how much safe parallelism they admit. Under a fixed workload, all terms denote effective throughput ceilings expressed in a common unit such as admissible TCs per unit time. The bound is schematic rather than a calibrated empirical law. Its practical implication is that adding execution units can increase the arrival rate of candidates without increasing the service rate of the verification and acceptance queues. When candidate supply exceeds those downstream capacities, the organization does not merely become “busy”: it accumulates partially understood changes, compresses review time, and creates pressure to substitute summaries or agent-generated confidence signals for independent inspection. The resulting bottleneck is structural because the final responsibility center still has to maintain enough understanding to accept residual risk coherently across the baseline. 21

Software Engineering in the Agent Era

A Preprint

This also explains why more reviewers do not automatically imply a different topology. Additional HACs can raise verification capacity while the same 𝑅 ∗ remains the final acceptance authority. A topology change is justified only when a stable responsibility domain acquires an independent acceptance right that the existing center cannot revoke under current governance rules. The framework distinguishes capacity scaling within a topology from changing the topology itself. A useful diagnostic is to ask what kind of constraint is binding. If delays arise from test execution, review bandwidth, or architecture comprehension, additional tools or HACs may be sufficient. If delays arise because one anchor is being asked to accept risks that require durable independent judgment—for example regulatory separation of duties, product-domain ownership, safety assurance, or contractual governance—then capacity expansion alone does not remove the organizational constraint. The problem has moved from execution scaling to responsibility design. When Generation Rate > Verification Rate, a Verification Queue forms. As the queue grows, the responsible subject has stronger incentives to rely on summaries, automated reviewers, and rapid approvals, which may weaken genuine engineering judgment. The Verification Queue is an observable backpressure signal in agentic software production. Evidence independence. A single responsibility center lacks some of the professional heterogeneity that arises naturally in larger teams. If coding, testing, and reviewing agents share a base model, specification, and context, multiple agents may miss the same defect. Single-center SE can increase Evidence Independence through deterministic static analysis, property-based testing, mutation testing, hidden tests, heterogeneous model families, real-user validation, and external professional review. External expert networks matter not only as extra execution resources but as sources of independent judgment. 6.2 Human Attention, Architecture, and Product Judgment As agents expand execution, the responsible person’s attention becomes an explicit system bottleneck. Major attention costs include Intent + Specification + Review + Integration + Incident + Context Recovery. Change Locality directly influences scalability. If a small feature forces the final anchor to reconstruct many modules, protocols, data models, and agent traces, high automation does not translate into stable leverage. A scalable single-center architecture depends on keeping the semantic scope, review scope, failure radius, and long-term responsibility obligations of a typical TC bounded. Product judgment and complete cost. As construction cost falls, the decision to create a change becomes more important. The responsible subject must ask whether the problem being solved is sufficiently evidenced, whether user value justifies migration and compatibility costs, whether the change creates new support or security obligations, and whether its long-term responsibility obligations are affordable. A more complete cost model for a TC is Creation + Verification + Integration + Operation + Long-Term Responsibility. Reducing Creation does not proportionally reduce lifecycle cost. Resource optimization should therefore focus on 𝐶Accepted TC rather than on the price of an individual model call. 6.3 Operations and Continuity Known, low-risk, reversible operational actions can be pre-authorized to agents: collecting logs, estimating impact, diagnosing known failures, or preparing rollback options. High-impact, uncertain, or irreversible actions escalate to 𝑅 ∗ . If old SDKs begin failing on the new expired state after release, an agent may automatically quantify affected versions, generate compatibility patches, and prepare rollback plans. The choice among rollback, forward fix, or temporary semantic mapping remains a risk-acceptance decision. The objective is an explicit boundary between pre-authorized automation and high-impact human acceptance. Takeoverability and anchor-absence resilience. Because the final responsibility center is a natural single point, two distinct continuity properties matter. Takeoverability measures whether, during formal responsibility transfer, a new authorized subject can identify the current baseline, acquire necessary permissions, stop high-risk agents, restore service, and assume required responsibilities. 22

Software Engineering in the Agent Era

A Preprint

Anchor-Absence Resilience measures whether the system can continue safely, degrade automatically, or wait in a controlled state while the primary anchor is temporarily unavailable, without immediately requiring formal responsibility transfer. The first concerns responsibility transfer; the second concerns temporary absence. High automation creates neither property by itself. Both depend on externalizing critical knowledge, state, authority, and emergency procedures. 6.4 When Single-Center Is No Longer the Right Topology A single responsibility center can become mismatched with the risk structure as the software develops independent high-risk domains, institutional separation-of-duty requirements, continuous on-call needs, or regulatory obligations. If new governance rules create multiple mutually independent Responsibility Anchors, then Single-center SE → Multi-anchor Team SE. This is a Responsibility Topology change. Hard governance triggers—such as regulation, separation of duties, or independent safety/security acceptance— determine the topology directly. Without such a trigger, the issue is economic and organizational: a new anchor becomes attractive only when the costs and continuity risks of one center justify an independently responsible domain. Section 9 develops this distinction and the transition condition. Diagnostic criteria. Table 11 summarizes the major single-center failure mechanisms. Table 11: Major failure mechanisms in single-center SE. Failure mechanism

Manifestation

Root cause

Verification Queue Same-origin assurance Cognitive overload

Candidates continuously accumulate Multiple agents share the same blind spot The anchor cannot understand material changes Current changes are cheap but long-term obligations accumulate System capability collapses when the anchor leaves

Generation exceeds verification capacity Insufficient Evidence Independence Change scope exceeds cognitive budget

Lifecycle obligations Anchor dependency

Lifecycle cost is underestimated Insufficient Takeoverability / Absence Resilience

The effective scale of single-center SE is ultimately determined by how many Accepted TCs one responsibility center can continuously understand, verify, integrate, finance, and sustain through their lifecycles.

7 Multi-Anchor Team Software Engineering Section 5 defined the common engineering methods. This section studies the practically important case in which distributed HAC execution coexists with multiple independent Responsibility Anchors. The coordination and authority pressures should not be conflated: context divergence is primarily induced by distributed execution, whereas joint acceptance and Responsibility Closure follow from distributed authority. Multi-anchor governance makes explicit authority, versioning, and invalidation semantics necessary when cross-anchor closure depends on shared engineering facts. The running order-state example connects Authoritative State, Context Invalidation, delegation, evidence, and responsibility closure. 7.1 Authoritative State and Context Coherence TSP already demonstrates that the quality of individual software processes does not add up automatically to team-process quality [22]. In Agent SE, a team is composed of 𝐻 𝐴𝐶1 + 𝐻 𝐴𝐶2 + · · · + 𝐻 𝐴𝐶𝑛 , where each HAC has independent agents, memory, tools, permissions, and budgets. Distributed HAC execution creates local-memory and evidence-coordination pressures; when the organization also contains multiple independent anchors, these coexist with a responsibility-closure problem. In the combined case analyzed here, the team faces three questions: 1. how Local Memory relates to Global Engineering Truth; 2. how the Delegation Graph aligns with the Responsibility Graph; and 3. how local evidence becomes a trustworthy system-level basis for acceptance. These are central research concerns for future human–agent team software-process research. 23

Software Engineering in the Agent Era

A Preprint

Shared Authoritative Engineering State. An authoritative engineering state is useful under either topology. Multiple independent anchors make explicit authority, versioning, and invalidation semantics structurally necessary for crossanchor closure: the team need not share all local memory, but it does need a jointly recognized set of formal engineering facts. We call this the Shared Authoritative Engineering State. Typical content includes Product Intent, Current Specification, Architecture Decisions, API/Data Contracts, Global Invariants, Ownership, Accepted TCs, Risk State, and Release State. An Authoritative-State item can be represented as 𝐴𝑆𝐸 = ⟨Content, Proposer, Acceptance Anchors, Version, Effective Time, Invalidation Policy⟩ . The proposer may be a HAC or an agent. A proposal gains organizational authority only after relevant anchors accept it and it is committed in versioned form: Proposal → Authorized Acceptance → Versioned Commit. The mechanism distinguishes information that is shareable from engineering facts that are actually binding. The stronger requirement follows from the multi-anchor topology. When several independent anchors govern different claims about the same system, no participant’s local memory can serve as the organization’s implicit source of truth. A local note may be accurate, widely retrieved, and repeatedly copied while still lacking the authority to constrain another HAC. Conversely, once a semantic decision is accepted into the authoritative state, dependent work must be able to determine which version was effective and whether its own assumptions remain valid. Authority and retrievability are distinct dimensions. This creates a second-order problem that is much less visible in single-center work: accepted information changes the validity of work already in flight. Suppose the order-state contract advances from v3 to v4. A backend HAC already working against v4 may continue; a client HAC using v3 semantics must refresh and replan; a payment HAC whose late-callback evidence depended on the old contract must reverify; and an analytics task that would require unsupported historical inference should stop. The engineering consequence of authoritative-state change is thus not merely synchronization of documents but selective invalidation of distributed reasoning and evidence. Context coherence. Context Coherence asks whether a formal engineering action can identify the Authoritative Facts on which it depends, their versions, and whether those facts remain valid. Different HACs may continue to have different contexts: Context 𝐴 ≠ Context 𝐵 . Coherence does not require all agents to hold identical context. Team state can instead be classified by consistency requirements. Strong consistency. Strong consistency is appropriate for Global Invariants, public API contracts, formal ownership, production schemas, and release state. Eventual consistency. Eventual consistency is appropriate for exploratory plans, preliminary analyses, and non-critical state that can tolerate asynchronous synchronization. Local state. Local state includes personal-agent scratch memory, provisional hypotheses, and unaccepted alternatives. Accordingly, Shared Memory ≠ Shared Authoritative State. Context Coherence is achieved when a formal action can identify the authoritative facts on which it depends, the versions of those facts, and the risk-appropriate response when they change. This definition deliberately avoids requiring globally strong consistency for every piece of information. Exploratory plans and temporary analyses can remain local or eventually consistent; public interfaces, accepted invariants, ownership, and release state may require stronger coordination. The framework therefore treats consistency as a property chosen by the risk and authority semantics of the information, not as a universal storage policy. 7.2 Context Invalidation and End-to-End Closure When authoritative engineering state changes from 𝑆𝑣 to 𝑆 𝑣+1 , 24

Software Engineering in the Agent Era

A Preprint

in-flight tasks depending on the earlier version should select one of the following actions according to impact: Action(𝑇 𝑎𝑠𝑘 𝑖 ) ∈ {Continue, MarkStale, Refresh, Replan, Reverify, Stop}. Continue means the authoritative change is immaterial to the task. MarkStale permits further exploration but forbids promotion to Eligible. Refresh updates context only. Replan changes the execution plan. Reverify reconstructs evidence. Stop terminates a task whose effective objective is no longer valid. For any affected TC, this policy operationalizes Eligible(𝑥, 𝑆 𝑣 ) ⇏ Eligible(𝑥, 𝑆 𝑣+1 ) : eligibility must be revalidated after the relevant authoritative facts change. Figure 7 summarizes the corresponding promotion and state-change-response paths.

Authoritative state

Intent

Spec

Contract

Ownership

Accepted TC

Authorized acceptance

Shared but non-authoritative

Local

chat

retrieved notes

scratch notes

unaccepted proposal

tentative plans

private memory

Sv

Proposal

Continue

Mark Stale

Backend task → Continue

Refresh

Replan

Client SDK → Refresh / Replan

Promotion / commit

retrievable ≠ authoritative

Reverify

Payment checks → Reverify

State-change response

S v+1

Example mapping

Stop

Historical backfill → Stop

Authoritative state

Figure 7: From local information to Authoritative Engineering State and then to Context Invalidation. Shareable or retrievable information becomes binding only through authorized acceptance and versioned commitment. Context invalidation can arise under either topology; multi-anchor governance makes the authority/version path explicit for cross-anchor closure.

After the order-status contract changes from v3 to v4, a backend task already based on v4 can Continue. A client task still interpreting every closed order as cancelled must Refresh and Replan. Payment race analysis must Reverify. A historical automated backfill task invalidated by the new semantic decision can Stop. Complete team closure. The Delegation Graph describes how work is decomposed, assigned, and executed. The Responsibility Graph describes which subjects possess formal acceptance authority for which responsibility domains. The two can differ substantially: Delegation Graph ≠ Responsibility Graph. A characteristic system-level failure is Execution Closure ≠ Responsibility Closure.

25

Software Engineering in the Agent Era

A Preprint

Intent

Spec / Contract v4

Delegation

Candidate & Evidence

Acceptance

Baseline

Change intent

Spec / Contract v4

Delegate execution

Candidate & Evidence

R*

Baseline updated

Context update

Spec / Contract v4

Authoritative state updated

Client task stale

Multi-anchor

Single-center

End-to-end closure of the order-state change. Figure 8 contrasts the closure paths for the same artifact change under single-center and multi-anchor governance; the following sequence then walks the multi-anchor case through Authoritative State, invalidation, delegation, evidence, and acceptance.

Refresh / Replan

R Order accepted

Delegate execution

Acceptance

Candidate & Evidence

AND

Baseline not yet updated

R Payment pending

Same artifact change; different closure conditions.

Delegation / execution

Responsibility / acceptance

Accepted

Pending

Not yet committed

Figure 8: The same order-state change has different closure conditions under single-center and multi-anchor topologies. The multi-anchor path combines a context-invalidation example caused by distributed execution with waiting for independent acceptance; only the latter is topology-specific.

Step 1 – Proposal. A Product HAC proposes splitting cancelled into cancelled and expired, producing a new Order Status Contract proposal. Step 2 – Authoritative State. The Order and Payment Responsibility Anchors separately accept the domain semantics and payment-timeout semantics. After authorized acceptance, the proposal becomes 𝑂𝑟 𝑑𝑒𝑟𝑆𝑡𝑎𝑡𝑢𝑠𝐶𝑜𝑛𝑡𝑟𝑎𝑐𝑡 = 𝑣4 and enters Shared Authoritative Engineering State. Step 3 – Context Invalidation. The Client HAC still uses v3 semantics and performs 𝑅𝑒 𝑓 𝑟𝑒𝑠ℎ + 𝑅𝑒 𝑝𝑙𝑎𝑛. A prior late-callback analysis in the Payment HAC performs Reverify. A historical automated backfill task contradicted by the new decision performs Stop. Step 4 – Delegation. Backend, Client, and Payment HACs receive the common Task & Resource Contracts defined in Section 5. The topology-specific point is not a new contract schema: delegation may be orchestrated centrally while authority to accept the resulting change remains distributed across independent anchors. Step 5 – Candidate. Each HAC outputs a Candidate Change and Local Evidence. Step 6 – R4 failure example. Suppose the Payment Candidate implements expired, but no evidence covers a successful payment callback arriving after automatic timeout closure. The candidate triggers R4. It cannot become Eligible even if the code compiles and ordinary unit and SDK tests all pass. Step 7 – R6 failure versus Acceptance Pending. If no valid Responsibility Anchor exists for the Payment domain under current governance rules, R6 fails. If 𝑅Payment validly exists but has not yet formally accepted the change, R6 does not fail. The change may be in Eligible = true, Accept𝐾 = false, that is, Eligible / Acceptance Pending. Step 8 – Multi-anchor acceptance. Once the evidence is complete and eligibility passes, 𝐾 = {𝑅Order , 𝑅Payment }, Accept𝐾 (𝑥) = AcceptOrder (𝑥) ∧ AcceptPayment (𝑥), 26

Software Engineering in the Agent Era

A Preprint

AcceptedTC(𝑥) ⇐⇒ Eligible(𝑥) ∧ Accept𝐾 (𝑥). Step 9 – Baseline and operation. The Accepted TC enters the authoritative baseline. Legacy-SDK behavior, late callbacks, refund processing, and analytics continue to generate Runtime Evidence. If runtime facts invalidate the assumptions on which acceptance depended, a new Intent and TC are created. Figure 9 makes the separation between execution and responsibility closure explicit for the running example.

HAC-Order

R Order

done

accepted

HAC-Client

R Payment

TC

done

pending

R Release

HAC-Payment done

K={

present, not in K

ROrder , RPayment }

ExecutionClosure = true ResponsibilityClosure = false

Delegation / Execution

Responsibility / Acceptance

Figure 9: Execution Closure does not imply Responsibility Closure. All three HACs have completed execution, but the Payment Anchor has not accepted, so the TC cannot enter the baseline.

7.3 Delegation, Responsibility, and Layered Evidence Teams can exploit different HAC contexts, expertise, and responsibility positions to increase evidence independence. A risk-adaptive structure can be organized as Local → Cross-cell → Team → Organization/External. Local verification is cheapest but most correlated. Cross-cell verification asks a different HAC to inspect the change. Team-level verification addresses architecture, contracts, and global invariants. Organization/external verification addresses high-risk areas such as security, compliance, and finance. R4 remains Evidence Adequacy; Responsibility Topology does not alter its definition. What changes is the provenance, independence, and relevance required of the evidence used to satisfy R4. For higher-risk cross-domain changes, cross-cell or external evidence can reduce the correlation of same-origin errors and shared blind spots, provided that the evidence remains relevant to the changed claims and acceptance scope. Agent scope can similarly be described as Personal, Team, and Organization scope. These levels describe execution scope; they do not determine formal responsibility structure. 7.4 Team Throughput, Organizational Memory, and the Augmented Conway Hypothesis With multiple humans and multiple agents, effective concurrency is constrained by
𝐶multi ≤ min 𝐶𝐷 , 𝐵local , 𝐵cross , 𝐵integration , 𝐵architecture , 𝐵economic . 27

Software Engineering in the Agent Era

A Preprint

Here 𝐶𝐷 is the decomposability-induced throughput ceiling; under a fixed workload, all terms are expressed in a common throughput unit such as admissible TCs per unit time. Higher local productivity in individual HACs can still coexist with lower system-level Trustworthy Change throughput. Team project state should also distinguish Planned → Delegated → Executing → Candidate → Eligible → Acceptance Pending → Accepted. Organizational memory should preferentially preserve current decisions, rationales, specifications, invariants, ownership, Accepted TCs, and known risks. Chat transcripts and agent traces can be retained for audit but do not automatically acquire authoritative status. Operationalizing the augmented Conway hypothesis. Conway’s classic observation connects organizational communication structures to system structures [31]. We propose a testable extension: beyond human communication, Agent Delegation and Context Dependency may also influence software co-change and integration structure. Define 𝐺 𝐻 = Human Communication Graph, 𝐺 𝐷 = Agent Delegation Graph, 𝐺 𝐶 = Context Dependency Graph,

𝐺 𝑆 = Software Dependency / Co-change Graph.

Because these graphs may have different node types, empirical work should project them onto a shared Task, Module, or TC space rather than adding the graphs directly. The empirical question is whether, when two engineering units must coordinate because of software dependency, Human Communication, Agent Delegation, and Context Sharing provide corresponding coordination paths. Candidate outcomes include Rework Rate, Integration Conflict Rate, Cross-HAC Replan Rate, Context Refresh/Revalidation Rate, Stale-Context Escape Rate, TC Lead Time, and Defect/Rollback Rate. We call the possibility that Agent Delegation and Context Dependency add explanatory power after controlling for Human Communication the Augmented Conway Effect hypothesis. 7.5 Failure Modes and a Human–Agent Team Process Research Direction Table 12 summarizes the principal failure modes in the combined distributed-HAC, multi-anchor setting. Table 12: Major failure modes when distributed HAC execution coexists with multi-anchor governance. Failure mechanism

Typical manifestation

Context Staleness Unauthorized Truth Delegation–Responsibility Misalignment Cross-cell Semantic Conflict False Independence Verification Congestion Invalidation Storm Responsibility Orphan

Agents act on outdated specifications An unaccepted proposal is treated as authoritative fact Execution is complete but responsibility is not closed Artifacts merge while semantics conflict Multiple reviewers share the same model and blind spots Local candidates exceed cross-HAC verification capacity Frequent authoritative changes force repeated task rework An anchor exits and a responsibility domain loses a valid acceptor

In summary, multi-anchor Team SE combines common Agent SE methods with distributed-execution coordination and topology-specific responsibility closure. The mechanisms above motivate a future research direction on human–agent team software processes. Within the scope of this paper, Authoritative State, Context Coherence, the dual-graph relation, and cross-cell evidence are recurring concerns; we do not prescribe a fixed team process script or introduce another process standard.

8 A Reference Tool Architecture for Agent Software Engineering Three layers and their theoretical roles. Section 5 defined common methods such as Task Contracts, evidence, and sandboxing, while Section 7 defined Authoritative State, Context Coherence, and Responsibility Graphs. This section does not propose a component-by-component product design. It shows how those theoretical objects can be projected onto existing software-engineering infrastructure. Tool capabilities can be organized by scope: HAC/Personal → Team → Organization. 28

Software Engineering in the Agent Era

A Preprint

Figure 10 projects these scopes onto a three-layer reference architecture.

HAC layer

Team coordination layer

Organization governance layer

Authoritative snapshot

Task & Resource Contract

Candidate / Proposal / Evidence

Local workspace

Authoritative state

Delegation graph

Responsibility graph

Context invalidation

Acceptance gate

Policy

Identity & authorization

Resource budget

Audit trail

Compliance rules

Support / constraint

Layer

Theoretical object

Figure 10: Three-layer reference architecture for Agent SE. The figure shows where theoretical objects can be represented, not a mandatory product decomposition.

The HAC layer primarily supports local execution, permission boundaries, and candidate evidence. The Team layer supports facts shared across HACs, Context Invalidation, responsibility acceptance, and integration. The Organization layer supports identity, policy, compliance, model/tool governance, and cost control. Concrete platforms may merge or split these capabilities; the framework does not require one service per theoretical object. Mapping industrial primitives to engineering objects. Current agent-development platforms already provide repository-instruction files such as AGENTS.md and CLAUDE.md, skills, hooks, MCP tools, sandboxes, subagents, and specification workflows. A September 2026 source-code study of eleven production coding-agent harnesses finds recurring runtime subsystems for execution loops, tool use, context management, safety controls, orchestration, and extension surfaces [32]. This makes the status of the tooling layer important to state explicitly: these primitives are not atomically novel contributions of this paper. They are the existing substrate on which TC, Responsibility Topology, Authoritative State, and Context Invalidation can be operationalized over a complete software change. Table 13 maps representative industrial primitives to framework roles.

29

Software Engineering in the Agent Era

A Preprint

Table 13: Mapping industrial agent primitives to the framework. Industrial primitive

Primary role in the framework

AGENTS.md / CLAUDE.md / Repository Rules Spec / Plan Skills / Custom Agents MCP / Tools Hooks / Policy Hooks Sandbox / Worktree / Cloud VM Subagents / Agent Team Tests / CI / merge-readiness package CODEOWNERS / approval policy / IAM Usage / token / model routing

Part of an Authoritative State Snapshot or task-local context; authority depends on acceptance and versioning Intent & Specification Delegated execution capability Tool capability in a Task Contract Delegation guard, Stop Condition, deterministic verification Permission boundary and Candidate isolation Execution nodes in a Delegation Graph Evidence and eligibility inputs One form of technical evidence for a Responsibility Graph Resource Envelope and bounded-capacity control

Implementation plausibility. The reference architecture primarily adds state semantics and governance relations to infrastructure that already exists. It does not depend on unavailable foundational computing capabilities. Table 14 summarizes how the core mechanisms can reuse existing infrastructure. Table 14: Implementation plausibility of the core mechanisms. Mechanism

Reusable infrastructure

Additional Agent-SE semantics

Authoritative State Context Coherence Responsibility Graph

Acceptance, version, effective time, invalidation Task–state dependency and staleness Residual-risk acceptance authority

Task Contract Evidence Graph

Git, artifact stores, CMDB Dependency graphs, event buses IAM, CODEOWNERS, approval matrices Sandboxes, policy engines, workflows CI, test reports, static analysis

TC Pipeline

CI/CD, change management

Permission, budget, stop, handoff Claim–evidence relations and Evidence Independence Candidate → Eligible → Accepted TC state machine

This mapping establishes implementation plausibility: prototypes can be built by extending existing engineering infrastructure. It is not empirical validation of utility, cost, organizational impact, or developer experience.

9 Measurement, Engineering Economics, and Project Control 9.1 Measurement Model and Accepted-TC Accounting This section translates the structural constraints in Sections 6 and 7 into observable engineering variables. Verification queues, human attention, and anchor dependency in single-center SE must be measurable; context invalidation and cross-cell verification in distributed HAC execution, and Responsibility Closure in multi-anchor governance, must likewise become project-state and economic variables. The resource vectors, flow measures, and cost variables defined here have two purposes: to provide operational quantitative tools for single-center and multi-anchor SE, and to establish candidate measurement models for the empirical tests in Section 11. This follows the long-standing goal-driven measurement principle in software engineering. GQM derives Questions from explicit Goals and then derives Metrics from those Questions rather than beginning with whatever activity data happen to be easy to collect [33]. The section operationalizes the basic claim of Bounded-Capacity Agent SE: digital execution can be elastically expanded, but verification, integration, Human Attention, and responsibility acceptance remain capacity-constrained. The central measurement principle is to derive observables from the constructs rather than to select convenient activity counters first. For example, Responsibility Topology can be operationalized through the number and independence of required acceptance anchors for a TC, then related to outcomes such as acceptance latency, cross-domain waiting time, or unresolved long-term responsibility obligations. Context Invalidation can be operationalized through the number of affected in-flight tasks, the actions issued to those tasks, and the rate at which stale context escapes into later verification or integration. Evidence independence can be represented through diversity of method, context, criterion, and responsibility source rather than by simply counting reviewer agents. These mappings also define what should not be interpreted as evidence for the theory. A high commit count does not 30

Software Engineering in the Agent Era

A Preprint

imply high TC throughput; many agent trajectories do not imply many independent verification sources; and a large team does not imply a multi-anchor topology. Accepted TC is used as the accounting boundary precisely because it is closer to the theoretical object than raw activity measures. The measurement layer is therefore part of the operationalization of the theory, not a separate productivity framework. Accepted-TC accounting. Agents lower the cost of producing code, tests, and documentation, further weakening the relationship between LOC, commit count, pull requests, agent-task count, and actual software value. We use Accepted TC as the accounting boundary for trustworthy output. Accepted-TC accounting is intended for within-project lifecycle analysis; it is not a cross-project scalar of software value. Its primary purpose is to distinguish changes that have entered the formal software baseline from work that remains Candidate, Rejected, Abandoned, or Eligible-but-not-Accepted. The SPACE framework emphasizes that developer productivity is multidimensional and cannot be represented by a single activity or output metric [34]. Accepted-TC Accounting retains this caution: TC is an accounting boundary, not a universal productivity score. 9.2 Resources, Cost, and Agentic Effort Using the resource definition from Section 5, 𝑅 = ⟨Token, Compute, Tool, Wall-Clock Time, Human Attention⟩ . Tokens capture model inference and context resources; Compute includes builds, tests, simulations, and agent runtime; Tool includes APIs, databases, and external services; Wall-Clock Time is elapsed delivery time; Human Attention includes clarification, review, integration, exception handling, and responsibility acceptance. Token ≠ Human Hours. Tokens are better interpreted as a digital execution resource. Candidate project-level measures include TokenPerAcceptedTC =

Total tokens , #{Accepted TC}

HumanAttentionPerAcceptedTC =

Total human attention , #{Accepted TC}

and 𝐶rejected changes = Cost(candidates not accepted). These are most useful for longitudinal comparison within a project, experiments on agent configurations, and analysis of architecture evolution. Architecture, context, and verification cost. Change Locality connects architecture to agent-engineering cost. Larger Artifact Span is expected to increase integration scope; larger Context Span may increase token and review cost; larger Responsibility Span may increase cross-cell and acceptance cost. Teams should additionally observe Context Staleness and Revalidation Load. For example, ContextStalenessRate =

#{active tasks affected by stale authoritative context} . #{active tasks}

Evidence Independence also creates a cost–risk trade-off. External experts, different-model review, cross-cell verification, and formal verification are usually more expensive than local self-check. Verification investment should therefore scale with risk and impact rather than being maximized uniformly. Agentic effort estimation. Agent-era project control still requires estimates of how many resources a change will consume. Candidate predictors include Ambiguity, Context Size, Change Locality, Tool Steps, Risk, Verification Requirement, and Responsibility Topology. We hypothesize that agentic effort is jointly influenced by specification ambiguity, required context, change locality, tool steps, risk, verification requirements, and responsibility topology. No particular functional form, monotonicity, or unit scale is assumed. Section 11 treats the relation as an empirical estimation problem. Ambiguity also lacks a single reliable measure. Candidate proxies include Clarification Count, Unresolved Specification Slots, Mutually Exclusive Interpretations, Candidate Semantic Divergence, and Replan Rate induced by semantic clarification. Such proxies should be calibrated by model and harness. 31

Software Engineering in the Agent Era

A Preprint

9.3 Concurrency, Flow Control, and Topology Economics Single-center capacity is constrained by
𝐶single ≤ min 𝐶𝐷 , 𝐵integration , 𝐵verification , 𝐵economic , while multi-anchor team capacity is constrained by
𝐶multi ≤ min 𝐶𝐷 , 𝐵local , 𝐵cross , 𝐵integration , 𝐵architecture , 𝐵economic . Here 𝐶𝐷 is the decomposability-induced throughput ceiling. Under a fixed workload, every term in each bound denotes an effective throughput ceiling expressed in a common unit such as admissible TCs per unit time. These expressions are schematic rather than calibrated performance laws. Agent Execution Concurrency remains bounded by downstream verification, integration, architecture, and economic capacity. Project dashboards should track the Trustworthy Change Flow; Figure 11 illustrates the verification and acceptance queues that may become binding.

Verification bottleneck

HAC Sources

Acceptance bottleneck

HAC HAC

Candidate Queue

Verification Queue

Eligible Queue

Acceptance Queue

Narrow gate (capacity bottleneck)

Accepted output

Accepted TC

HAC

Throughput limited by the narrowest gate

Source

Queue (execution)

Figure 11: Trustworthy Change flow and potential bottlenecks. As agent generation throughput increases, verification and responsibility acceptance can become new queues.

METR’s 2026 revision of developer-productivity experiments similarly notes that multi-agent concurrency, task selection, and agent usage patterns make simple wall-clock comparisons harder to interpret [35]. Economic pressure on responsibility topology. Responsibility Topology is defined first by governance and residualrisk acceptance structure, not by direct cost minimization. A move from single-center to multi-anchor Team SE must therefore distinguish two types of condition. Hard governance triggers. Law or regulation, professional qualifications, separation of duties, independent security or safety acceptance, and contractual governance requirements can directly mandate independent responsibility structures. In these cases Team Topology is a governance requirement; economic efficiency is secondary. Economic transition pressure. Absent a hard governance trigger, the costs of maintaining a single responsibility center can be compared with those of a multi-center structure: 𝐶single = 𝐶verification queue + 𝐶anchor attention + 𝐶external assurance + 𝐶continuity risk + 𝐶delay + · · · , 𝐶multi = 𝐶cross−cell + 𝐶state synchronization + 𝐶multi−anchor acceptance + 𝐶governance + · · · . The scalar comparison assumes that heterogeneous costs have been mapped by a project-specific valuation model into a common economic unit; otherwise they should remain a cost vector. 32

Software Engineering in the Agent Era

A Preprint

Define Δ𝐶topology = 𝐶single − 𝐶multi . If Δ𝐶topology > 0, a team structure may have an economic advantage. The inequality does not automatically justify creation of a new Responsibility Anchor. If the Verification Queue reflects only a shortage of mechanical review capacity, single-center SE can add agents, external reviewers, or delegated HACs while preserving one final responsibility center. A new anchor requires an additional condition: a responsibility domain with a legitimate, stable acceptance right that is not normally unilaterally overridable by the current anchor. 9.4 Human Attention and Primary Metrics Agents may reduce implementation hours while increasing review fragmentation, context switching, and approval frequency. Human Attention should therefore be observed structurally—for example Context Switch Count, Deep-Work Interval, and Time-to-Regain-Context—rather than only as total labor hours. Human-attention measurement should prefer low-intrusion workflow proxies, aggregated telemetry, or voluntary self-report where possible; empirical studies should treat privacy, surveillance effects, and measurement overhead as part of the measurement design. Every Accepted TC also creates long-term responsibility obligations: compatibility, maintenance, security updates, data obligations, customer support, incidents, and eventual exit. Classical software engineering economics already places lifecycle cost, maintenance, risk, and project decisions in one analytical frame [36]; Agent SE adds tokens, agent runtime, verification queues, and human-attention costs. 𝐶lifecycle (𝑇𝐶) = 𝐶creation + 𝐶verification + 𝐶integration + 𝐶operation + 𝐶long-term responsibility . We also use a conceptual measure of Trustworthy Change Productivity: TCP =

Value of Accepted TC . Complete engineering resources

Value may be represented by user outcomes, revenue, cost reduction, reliability, risk reduction, or public value. TCP is an organizational-economic construct, not a universal scalar suitable for comparing all software systems. Primary metrics for Agent SE. Table 15 summarizes the primary candidate measures used by the framework. Table 15: Primary candidate metrics for Agent SE. Category

Example measures

Output Digital resources Human resources Waste Flow Architecture Team context Verification Continuity

Accepted TC, TC Value Token/TC, Compute/TC, Tool Cost Human Attention/TC, Review Fragmentation Rejected Change Cost, Retry Token Ratio Verification Queue, Acceptance Latency Artifact Span, Context Span, Responsibility Span Context Staleness, Invalidation Precision/Recall, Stale-Context Escape Rate Evidence Independence, Escaped Defect Takeover Time, Anchor-Absence Recovery Time

If the order-status split is measured only by coding time, it may show dramatic agent acceleration. The complete TC still requires clarification of late callbacks, definition of historical semantics, verification of payment invariants, legacy-client testing, analytics changes, anchor acceptance, and observation of production behavior. Coding acceleration describes Construction; Agent SE must observe the complete Trustworthy Change Flow.

10 Research and Industrial Landscape as of September 2, 2026 10.1 Evidence Mapping Scope The observation date for this section is frozen at 2 September 2026. We distinguish evidence sources by the claims they can support. Table 16 summarizes the role assigned to each evidence type in the landscape mapping. 33

Software Engineering in the Agent Era

A Preprint

Table 16: Evidence types and their roles in the landscape mapping. Evidence type

Primary use

Peer-reviewed paper Preprint / vision paper Industrial paper Official documentation Vendor engineering practice Survey

Methods, empirical results, and research questions Conceptual frameworks and propositions awaiting validation Reported deployment and observed outcomes Whether a product capability exists at the freeze date Engineering-method and infrastructure trends Adoption, self-reported behavior, and organizational perception

The existence of a product capability establishes that the capability has entered practice. It does not establish a causal effect on software quality or productivity. Likewise, an arXiv framework may be close to this paper conceptually without having established empirical validity. We therefore use the landscape to locate constructs and open questions, not to turn proximity into evidence for our claims. 10.2 Agentic SE, Responsibility Protocols, Specification, and Harnesses SE 3.0 and SASE advance intent-centric and agent-native views of software engineering and expand the set of actors, processes, tools, and artifacts under consideration [1], [2]. MAGE makes representation, evidence, and authority explicit as engineering concerns when implementation becomes abundant [4]. A related case study grounds governance conversion in recurring failures observed during high-velocity agentic implementation and the durable controls created in response [23]. Feldt and colleagues’ Semi-Executable Stack similarly widens the scope of software engineering beyond executable code toward instructional and operating artifacts whose interpretation still matters [37]. Hoda’s “beyond code” framing argues for a whole-of-process view of Agentic SE rather than a coding-only one [5]. Alenezi characterizes the shift toward supervised agent workflows, verification bottlenecks, and outcome ownership [6], [7]. These works are important prior context for our thesis; the novelty of this paper does not lie in claiming that Agent SE should extend beyond code, verification, or human oversight. A newer line is closer to the responsibility boundary itself. Prifti’s AI-SDLC protocol language formalizes human–agent responsibility boundaries, approval gates, capability boundaries, and process invariants [16]. GAIE calibrates human oversight intensity to regulatory impact, reversibility, customer proximity, and data sensitivity [17]. Risk Architecture for AI-Native Engineering Teams focuses on roles, decision rights, escalation, and assurance at the engineering-management layer [18]. These are adjacent to Responsibility Topology but not equivalent. They specify how responsibility is constrained or oversight is calibrated; our classification asks how many independent residual-risk acceptance centers a particular software baseline or change actually requires under current governance. Specification and harness engineering. Spec-Driven Development became a visible practical trend in 2026. Microsoft argues for structured specifications as a shared engineering basis for humans and AI [8]; GitHub Spec Kit makes Spec, Plan, Task, Implementation, clarification, and analysis explicit workflow artifacts [9]. The Specification Paradox argues that code automation shifts complexity toward domain understanding, requirements, validation, and evolution [38]. Our Minimum Sufficient Specification hypothesis is deliberately narrower: it asks whether, for classes of changes, there is an empirically identifiable region beyond which added specification rigor ceases to repay its lifecycle cost. Harnesses are also becoming an object of study rather than merely a product feature. A source-code study of eleven production coding-agent harnesses identifies recurring subsystems for loops, tools, context management, safety controls, orchestration, and extension surfaces [32]. This evidence supports the stance in Section 8: the methods layer of this paper is intentionally synthetic. Sandboxes, hooks, tools, context mechanisms, and policy guards are not claimed as new primitives; the contribution is to connect them to TC state, responsibility, and authoritative engineering semantics. 10.3 Verification, Human–Agent Organization, and Economics Programming with Trust and Trustworthy AI Software Engineers make assurance, transparency, responsibility, and epistemic discipline central concerns [10], [11]. AgentLens shows that final test success alone can conceal process failures and “lucky passes” [12]. A September 2026 benchmark study further shows that nominal labels such as “bug fix” or “feature” are poor proxies for the actual demands placed on coding agents; its Spread–Novelty–Centrality profile separates benchmarks that share the same category label and links task demands to agent behavior [39]. This result is directly relevant to our research agenda: TC-oriented evaluation should characterize change scope, evidence, context, and acceptance demands rather than treating issue labels as sufficient task descriptors. OpenAI’s 2026 evaluation reports likewise discuss contamination, task quality, and signal/noise problems in coding benchmarks [40], [41]. NIST treats confabulation as a governance risk [26]. At the execution-security boundary, Task Shield constrains instructions and tool calls through task alignment [28], while MCPTox demonstrates systematic 34

Software Engineering in the Agent Era

A Preprint

tool-poisoning risk in real MCP servers [29]. These lines motivate a shift from Final Pass toward claims, evidence, process quality, execution security, and evaluation validity. Human–Agent organization and observable responsibility boundaries. AIDev observes coding agents in real GitHub development [42]; normative work on Human–AI Software Engineering Teams uses concepts such as commitment, obligation, prohibition, and permission [43]. OrgAgent, company-like heterogeneous-agent organizations, and selforganizing development systems organize the agent workforce in different ways [44], [45], [46]. A mixed-methods study of 448 professional developers at Microsoft found that accepted AI autonomy varies by task and individual, and that task accountability is associated with lower odds of allowing AI to act on a developer’s behalf [47]. That finding does not validate Responsibility Topology, but it demonstrates that accountability and autonomy boundaries are observable properties of real software work rather than purely normative abstractions. Cross-organizational deployment introduces another boundary. Reid and colleagues distinguish singular, federated, and open governance for multi-agent interactions across organizational perimeters [48]. Their framework is broader than software-change acceptance, but it provides a useful external coordinate for the federated extensions discussed in Section 12. Project management and bounded capacity. Agentic Software Project Management has entered the ICSE research agenda [49], while METR’s evolving productivity methodology emphasizes that concurrency, task selection, and agent use complicate simple wall-clock comparisons [35]. These developments fit the bounded-capacity view: execution can expand rapidly while verification, attention, integration, and budgets remain finite. 10.4 Industrial Practice and Comparative Positioning Industrial practice increasingly makes responsibility and verification explicit rather than treating agents only as coding tools. EPAM’s Agentic Development Lifecycle includes human–agent responsibility mapping, approval gates, authority levels, and continuous governance as first-class lifecycle activities [50]. McKinsey’s August 2026 synthesis of agentic product-development practice similarly highlights operating-model redesign, roles and responsibilities, verification mechanisms, AI operations, and organizational change as recurring characteristics of teams reporting greater impact [51]. These sources are practice evidence, not proof of our topology, but they reinforce the engineering relevance of responsibility boundaries. Across OpenAI Codex, Anthropic Claude Code, GitHub Copilot/Spec Kit, Replit, Huawei CodeArts Agent, and related platforms, persistent instructions, specification artifacts, skills, hooks, MCP tools, sandboxes, subagents, parallel workspaces, context layers, governance controls, and cost controls are increasingly routine [52], [53], [54], [55], [56]. A broad evolution can be summarized as Prompt → Harness → Agent Runtime → Team/Organization Control. The point is not that every product implements the theoretical constructs in this paper. Rather, the implementation substrate for testing those constructs already exists. Table 17 summarizes the closest adjacent 2026 governance directions. Table 17: Adjacent 2026 research on responsibility and governance. “Adjacent” means conceptually close, not equivalent to Responsibility Topology. Direction

Primary object

Relation to this paper

AI-SDLC protocols [16]

Human–agent boundaries, approval gates, process invariants

Graduated oversight [17]

Oversight intensity conditioned on risk and regulation Roles, decision rights, escalation, framework adequacy Lifecycle scope, workflow supervision, accountable judgment Runtime architecture of production coding agents

Formalizes responsibility protocols; does not classify organizations by independent residual-risk acceptance centers Calibrates how much oversight a task receives; orthogonal to how acceptance authority is distributed Closely related governance layer; broader than TCspecific acceptance topology Establishes prior whole-process and accountability framing that this paper builds upon Provides empirical substrate for our tooling projection; not itself a responsibility model

Risk architecture [18] Whole-process Agentic SE [5], [6], [7] Harness engineering [32]

Table 18 provides a broader qualitative construct-coverage comparison used only for theoretical positioning.

35

Dimension

SE 3.0 / SASE

MAGE

SDD / Harness

Trust / governance

Agent organization

This work

Agent as first-class actor Intent / Spec Harness / Permission

Explicitly modeled First-class concern Addressed

Explicitly modeled Purposeful representation Addressed

Explicitly modeled First-class artifact First-class mechanism

Principal organizational unit Partially addressed Addressed

Inherited and integrated Progressive Specification Linked to TC and responsibility

Evidence

Structured artifacts such as MRP Not a primary classification axis

Validators / gates

Quality gates

Explicitly discussed Supports assurance Approval/capability boundaries addressed First-class assurance concern

Reviewer roles

First-class TC component

Accountability, protocols, oversight, decision rights

Governance mainly organizes agent Independent residual-risk acceptance as work primary axis

Responsibility Topology

HAC Unified TC object Shared Authoritative State Context Invalidation Delegation / Responsibility graphs Accepted-TC Economics

Human authority represented; Not a first-class object topology not explicitly classified Not explicitly modeled Not explicitly modeled

Human–AI collaboration modeled more broadly Partial conceptual overlap Per-change obligations Not a team-level first-class Partial conceptual overlap object Not explicit as a team protocol Not a primary mechanism

Spec-to-code workflow Spec as source of truth

Not explicitly separated

Partial overlap

Specification evolution supported Workflow-centric

Not a primary accounting object

Cost as constraint

Efficiency/cost discussed

Human/AI roles discussed

Agent is principal organizational unit Assurance attached to processes/actions Not change-centered Governance state partially addressed Shared memory/state addressed Not primary

Responsibility boundaries and escalation addressed Not primary

First-class execution unit

Software Engineering in the Agent Era

Table 18: Qualitative construct-coverage comparison of major research directions. Entries are author judgments for theoretical positioning, not results of a coded systematic review or quantitative mapping.

First-class engineering object Explicit authority, versioning, and invalidation Memory/communication addressed Explicit protocol

Delegation structure central

Explicitly separated

Token/cost experiments

Explicit research agenda

36 A Preprint

Software Engineering in the Agent Era

A Preprint

As of the freeze date, the most important open questions for this framework remain empirical: whether Responsibility Topology adds explanatory power beyond team size, whether Minimum Sufficient Specification can be identified in practice, whether Context Invalidation reduces stale-context failures, and whether Accepted-TC-centered accounting improves measurement of agentic software work.

11 Empirical Commitments and a Falsifiable Research Agenda 11.1 Operationalization and Validation Contract The constructs introduced in this paper have sustained value as software-engineering theory only if they produce empirically distinguishable expectations. This section further operationalizes Responsibility Topology, Human–Agent Cell, Trustworthy Change, Context Coherence, Progressive Specification, and Bounded-Capacity Agent SE by connecting abstract constructs to observable variables, directional hypotheses, and falsification conditions. The paper covers the two precursor stages of theory development: conceptual development, which defines constructs and relations, and operationalization, which maps those constructs onto observable engineering phenomena. Controlled experiments, field studies, and longitudinal studies remain responsible for empirical testing. The operationalization follows a goal–question–metric logic: the theoretical claim is stated first, then research questions and observables are selected so that support and failure can be distinguished [33]. This section therefore states the framework’s empirical commitments. Each major claim should answer three questions: how can the construct be observed or measured; what relation or difference should appear if the claim holds; and what result should weaken, modify, or reject the claim? Recent empirical and benchmark work provides useful signals without validating the framework in advance. In a study of 448 professional developers, task accountability was associated with lower willingness to let AI act on the developer’s behalf [47]; this motivates, but does not prove, the proposition that responsibility structure affects autonomy boundaries. Likewise, recent benchmark analysis shows that nominal categories such as “bug fix” or “feature” can hide materially different task demands [39]. These findings argue for measuring the constructs proposed here directly rather than treating existing task labels or headcount as sufficient proxies. Core empirical commitments. Table 19 states the core propositions, observable expectations, and weakening signals. Table 19: Core theoretical claims and falsification signals. ID

Theoretical claim

Observable expectation

Main weakening or falsification signal

P1

Minimum Sufficient Specification occupies a task-dependent effective region

Raising rigor from an under-specified level reduces semantic divergence, rework, or escaped specification defects; later marginal benefit slows while specification cost continues to rise

P2

Agent concurrency is constrained by verification capacity Evidence Independence improves assurance

With fixed verification resources, Accepted-TC throughput eventually saturates or falls Greater independence is associated with lower escaped-defect rates Larger Artifact, Context, or Responsibility Span predicts higher cost or latency Appropriate invalidation reduces stale-context escapes After controlling headcount and system scale, topology still predicts differences in acceptance latency, assurance, or continuity More misalignment predicts unauthorized change, rollback, or responsibility ambiguity Higher Takeoverability predicts lower transfer time and recovery cost

After controlling task type and model/harness, additional rigor does not systematically reduce rework, semantic divergence, or escaped specification defects over any practically relevant range; or incremental specification cost is consistently offset by downstream savings, leaving no identifiable minimum-sufficient region Throughput remains near-linear while verification burden does not increase Changes in independence have no stable relation to escaped defects The spans add no explanatory power for cost or quality Invalidation only increases interruption without reducing semantic errors or rework Topology adds no explanatory power after covariate control

P3 P4 P5

Change Locality affects complete engineering cost Context Invalidation improves team coherence

P6

Responsibility Topology has independent explanatory power

P7

Delegation–Responsibility Misalignment creates governance risk Takeoverability reflects responsibility continuity

P8

Misalignment measures have no stable relation to these outcomes Takeoverability does not explain continuity outcomes

These propositions are deliberately exposed to evidence that may force the framework to narrow or change. 11.2 Specification, Ambiguity, Effort, and Capacity Minimum Sufficient Specification. Multiple specification levels can be constructed for the same change. For example, S0 may be a one-sentence natural-language request; S1 adds normal examples; S2 adds counterexamples and non-goals; S3 uses a state machine or decision table; S4 uses executable contracts or formal properties. Candidate Divergence, Clarification Count, Token use, Verification Effort, Rework, and Escaped Defect can then be

37

Software Engineering in the Agent Era

A Preprint

measured to study whether 𝐶spec = 𝐶specification + 𝐶generation + 𝐶verification + 𝐶rework + 𝐶invalidation exhibits a task-dependent effective region. Ambiguity proxy metrics. Ambiguity is difficult to observe directly. Candidate proxies include Clarification Question Count, Unresolved Specification Slots, Mutually Exclusive Interpretations, Candidate Semantic Divergence, and Replan Rate induced by semantic clarification. Clarification Count alone is insufficient because models and harnesses differ in how readily they ask questions. Empirical work should calibrate proxies within model/harness conditions and compare their explanatory power for rework, candidate divergence, and verification cost. Value of clarification. Strategies such as Always Ask, Never Ask, Confidence-Based Ask, and Risk-Based Ask can be compared. Define VoC = Expected loss without clarification − Cost of clarification. The main question is which combinations of ambiguity and risk justify interrupting agent execution to obtain a human semantic decision. Concurrency, effort, and topology economics. Concurrency turning point. Increase the number of parallel agents while controlling Task, Model, and Harness, and measure Candidate Rate, Accepted-TC Rate, Verification Queue, Human Attention, Rework, and Token/Accepted TC. If trustworthy throughput first rises and then saturates or declines, further work can estimate an effective concurrency region conditioned on Task Decomposability. Agentic effort estimation. Study whether Specification Ambiguity, Context, Change Locality, Tool Steps, Risk, Verification Requirement, and Responsibility Topology jointly explain or predict Token use, Human Attention, Lead Time, and Rework. Statistical and machine-learning estimators can then be compared for cross-project generalization. No particular functional form is assumed in advance. Topology economic pressure. Study whether the 𝐶single and 𝐶multi terms from Section 9 can be reliably estimated and how Verification Queue, Anchor Attention, and Context Synchronization Cost influence organizational choices. Economic pressure must be separated from Hard Governance Triggers so that a Responsibility Anchor is not reduced to a throughput resource. 11.3 Evidence, Architecture, and Context Compare Generator Self-Check, Same-Model Reviewer, Different-Model Reviewer, Deterministic Tool, Cross-HAC Verification, and Domain Expert verification. Outcomes include defect detection, specification omission, and escaped defects. Evidence independence can be decomposed into Model, Context, Criterion, and Responsibility Independence. The research question is which dimensions actually reduce common-mode failure. If different-model review does not reduce correlated errors after controlling other factors, model diversity alone should not be treated as a valid independence proxy. Architecture and context coherence. Change locality. Collect Artifact Span, Context Span, and Responsibility Span separately and analyze their relationships with Token use, Review, Revalidation, Lead Time, and Defect outcomes. Consistency policy. Compare Strong Consistency, Eventual Consistency, and Local State for different engineering facts. Evaluate how State Type, Risk, Dependency, and Change Frequency explain which policy is appropriate. The framework does not assume that these factors collapse into a known scalar function. Context invalidation. Use expert judgment as a reference to evaluate automatic selection among Continue, MarkStale, Refresh, Replan, Reverify, and Stop. Measures include Invalidation Precision, Invalidation Recall, Unnecessary Interruption, Missed Invalidation, Stale-Context Escape Rate, and Downstream Defect. These measures distinguish Context Coherence evaluation from benchmarks that observe only final pass/fail. 11.4 Responsibility Topology and Continuity Explanatory power of responsibility topology. Compare single-anchor and multi-anchor systems while controlling Domain, System Size, Team Size, and Risk. Outcomes can include Decision Latency, Accepted-TC Throughput, Escaped Defect, Incident Response, Responsibility Ambiguity, Takeover Time, and Anchor-Absence Recovery Time. 38

Software Engineering in the Agent Era

A Preprint

Delegation–responsibility misalignment. Define misalignment patterns such as an executor without a responsible anchor, a required anchor missing from acceptance, permissions extending beyond the responsibility domain, or a release gate omitting necessary acceptance. Study whether these patterns predict Unauthorized Change, Rollback, or Incident outcomes. Augmented Conway effect. Collect the Human Communication Graph, Agent Delegation Graph, Context Dependency Graph, Module Dependency Graph, and Co-change Graph. Project the graphs onto a shared Task, Module, or TC space, then test whether Agent Delegation and Context Dependency add explanatory power after controlling Human Communication. Near-term engineering outcomes should be preferred: Rework, Integration Conflict, Context Revalidation, TC Lead Time, and Defects. The hypothesis does not presuppose that graph misalignment directly causes any specific API failure. Human attention and continuity. Attention fragmentation. Record Human Hours together with Context Switches, Deep-Work Duration, Review Fragmentation, and Approval Count. Study the point at which more agent concurrency begins to increase human cognitive fragmentation. Blind takeover. Ask a qualified subject who did not participate in daily development to Identify the Baseline, Stop Agents, Deploy a Fix, Restore Service, Explain the Architecture, and Assume Responsibility. Measures include Takeover Success, Takeover Time, Undocumented Dependencies, and Privilege Recovery Time. Anchor-absence resilience. Simulate temporary unavailability of the primary anchor without formal responsibility transfer. Observe whether the system can degrade automatically, block high-risk changes, continue pre-authorized low-risk tasks, and wait safely for the anchor to return. 11.5 Benchmark and Reporting Protocol Future benchmarks can expand from Issue → Patch → Test Pass to Intent → Clarification → Candidate → Evidence → Acceptance → Runtime. Evaluation would then cover Correctness, Scope, Permission, Evidence, Context Handling, Human Attention, Cost, and Responsibility Closure. A Single-Center Track should emphasize single-anchor bandwidth, external assurance, Takeoverability, and AnchorAbsence Resilience. A Multi-Anchor Track should emphasize effective acceptance sets, joint acceptance, and Responsibility Closure; studies with multiple HACs under either topology should additionally report context coherence, cross-cell verification, and Context Invalidation. Agent SE studies should report Model, Version, Harness, Tools, Permissions, Context, Budget, and Experiment Date. Benchmark descriptions should also report the demand profile of the change itself rather than relying only on labels such as “bug fix” or “feature” [39]. Table 20 summarizes the resulting evaluation layers and primary records. Table 20: Evaluation layers for Agent SE research. Layer

Primary records

Task Execution Change Team

Type, Ambiguity Proxy, Risk, Context, Permission Model, Token, Tool, Retry, Human Intervention Candidate, R1–R6, Evidence, Eligible, Accepted Context Version, Anchor, Cross-cell Verification, Invalidation Precision/Recall, Stale-Context Escape Runtime, Defect, Maintenance, Long-Term Responsibility Obligations Takeover, Anchor Transition, Anchor-Absence Recovery

Lifecycle Continuity

The purpose of these designs is to expose the core constructs of the framework to empirical risk rather than leaving them as unfalsifiable conceptual labels.

39

Software Engineering in the Agent Era

A Preprint

12 Discussion and Conclusion: What Software Engineering Governs in the Agent Era 12.1 Organizational and Economic Implications Agents substantially increase the amount of software execution that one responsibility center can mobilize. This shift may allow very small human cores to develop and operate more products for longer periods. Multi-person responsibility structures remain necessary when software involves independent professional responsibility, separation of duties, legal or regulatory requirements, or continuous operational obligations. Earlier service-ecosystem research provides a related pre-agent precedent for coordinating multiple stakeholders and independently controlled providers under shared objectives [57], [58]. Agents change the feasible range of different Responsibility Topologies. Single-center and multi-anchor forms are two basic responsibility structures jointly shaped by software risk, agent capability, organizational conditions, and institutional environment, not two stages of organizational size. The changing value of teams. One traditional value of software teams is additional labor. Once one HAC can already invoke multiple agents in parallel, the marginal value of a new HAC increasingly lies in independent knowledge, independent context, independent evidence, and independent acceptance. The engineering value of a team depends more strongly on genuine heterogeneity. If multiple HACs use the same model, the same context, and the same implicit assumptions, headcount does not automatically increase assurance. An important design goal for future Team SE is to preserve professional difference, independent rejection rights, and responsibility continuity under high digital execution capacity. Risk-adaptive autonomy. Agents can perform longer tasks, call more tools, and act in production. These capabilities expand execution radius, but software-engineering maturity should not be measured by autonomy alone. More appropriate dimensions include task scope, context validity, permission, budget, evidence, stop mechanisms, recovery, and responsibility. Autonomy should be adapted to observable properties such as impact, reversibility, detectability, available evidence, and responsibility structure. No fixed function over these factors is assumed; autonomy should be jointly constrained by risk-relevant properties. At the opposite extreme, requiring humans to approve every important action can itself create verification bottlenecks and rubber-stamping. Human attention should be concentrated where semantic commitment and residual-risk acceptance are actually required. 12.2 Engineering and Educational Implications As natural language becomes a major development interface, prompting can appear to become the central engineering skill. Yet once interaction contains state machines, interfaces, invariants, exceptions, and acceptance criteria, it has entered the domain of specification. Future engineers may write fewer program statements directly, but they still need to understand program behavior, state, architecture, security, performance, failure, and data as causal structures. Agent SE education should preserve enough computing and software foundations to support independent judgment while adding agent-native abilities in intent, specification, delegation, evidence, integration, operation, and responsibility. Professional value will increasingly lie in deciding what should change, constraining digital execution, identifying the evidence on which change may be accepted, and knowing when to reject or stop. Architecture and organizational memory. The ability of agents to process larger contexts does not make modularity obsolete. Cross-module change still raises context, token, verification, and responsibility-closure costs. A central objective of agent-oriented architecture is: Enable most changes to close within bounded context and bounded responsibility scope. Organizational memory faces a similar transition. Future software organizations will accumulate large volumes of chat, traces, documents, decisions, commits, and incident records. As retrieval improves, the harder question shifts from “can we find the information?” to “is the information we found still authoritative?” Thus Knowledge Retrieval → Authority Management may become a foundational infrastructure shift in agentic software organizations. 12.3 Scope, Generalization, and Limitations Agents can progressively assume coding, testing, debugging, migration, deployment, monitoring, and diagnosis. High-impact action still raises three questions: who allowed the action; who judges the result reliable enough; and who bears the residual responsibility when consequences occur? 40

Software Engineering in the Agent Era

A Preprint

Many responsibilities can be encoded in advance through policy, pre-authorization, contracts, and deterministic controls. Yet creating those policies, setting risk thresholds, and changing the rules still require explicit Responsibility Anchors. Responsibility Topology provides an organizational axis independent of human headcount and agent count. Generalizing the topology. This paper uses single-center and multi-independent-center forms as two basic types. The empirical commitments in Section 11 cover only these types and their directly derived mechanisms; they do not attempt to validate more complex topologies. Real organizations may include hierarchical responsibility, federated responsibility, temporary joint acceptance, external certified authority, or platform-mediated responsibility. Work on multi-agent deployment across organizational boundaries already distinguishes singular, federated, and open governance regimes [48]. Our two-type classification does not subsume those regimes. It provides a local building block that asks, for a particular TC inside a given governance regime, which independent anchors must accept the residual risk. Enterprise and supply-chain extensions remain a separate research problem outside the present empirical claims. What is software engineering ultimately engineering? As more programs are generated by agents, the center of Software Engineering shifts from code production toward trustworthy software change. Intent determines why change is needed. Specification constrains its allowable semantics. Delegation determines who can act and under what resource boundary. Evidence justifies claims. Integration turns local changes into a shared system. Operation continues to test the assumptions on which acceptance depended. Responsibility ensures that software consequences remain traceable to subjects with legitimate authority to decide and remediate. From this perspective, Agent-era Software Engineering can be defined as: The organization of humans and scalable digital execution under bounded resources and explicit responsibility so that software changes can be continuously formed, verified, integrated, accepted, operated, and sustained through their lifecycles. 12.4 Conclusion Agentic execution changes the balance of software engineering more than it changes its purpose. Code, tests, migrations, and operational analyses can now be produced at a rate that was implausible when most software-process theory was formed. The difficult question is what happens after that execution has been produced: which intent it implements, which evidence justifies it, which other work it invalidates, and who is authorized to accept the residual risk. This paper has organized that problem around two primary constructs and one execution abstraction. A Human–Agent Cell is the execution boundary. Trustworthy Change is the change-centered engineering object. Responsibility Topology describes the distribution of independent residual-risk acceptance authority. None of these claims makes change management, accountability, specification, verification, or human oversight new. The intended contribution is a narrower reorganization of those concerns for a setting in which execution is cheap enough to stop being a reliable proxy for engineering completion. The distinction between single-center and multi-anchor organizations matters because it changes formal closure conditions. Distributed HAC execution may already require authoritative shared state and invalidation when binding facts change. Multi-anchor governance makes the authority/version semantics of that state, cross-domain evidence, and explicit Responsibility Closure across independent anchors structurally necessary when closure spans responsibility domains. This framework is not a finished empirical theory. Its value now depends on whether its distinctions survive measurement. Responsibility Topology may add no explanatory power after team size and risk are controlled. A minimum-sufficient specification region may not appear. Evidence diversity may fail to reduce common-mode error, and context invalidation may cost more than it saves. Any of those results would narrow or remove part of the framework; that is the point of stating the commitments explicitly. A compact summary is 𝐻 𝐴𝐶 → Candidate Change → Eligible Change → Accepted Trustworthy Change . The agent era increases the capacity to produce the left side of this chain. Software engineering remains responsible for whether the right side is reached for reasons that can be inspected and challenged, with the resulting obligations sustained by an identifiable organization.

41

Software Engineering in the Agent Era

A Preprint

References [1]

A. E. Hassan, G. A. Oliva, D. Lin, B. Chen, and Z. M. Jiang, “Towards AI-native software engineering (SE 3.0): A vision and a challenge roadmap,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 9, pp. 1–25, 2026, Article 268. doi: 10.1145/3807901

[2]

A. E. Hassan, H. Li, D. Lin, B. Adams, T.-H. Chen, Y. Kashiwa, and D. Qiu, Agentic software engineering: Foundational pillars and a research roadmap, arXiv preprint arXiv:2509.06216v3, Version 3, revised June 24, 2026, 2025. doi: 10.48550/arXiv.2509.06216 [Online]. Available: https://arxiv.org/abs/2509.06216

[3]

F. P. Brooks, “No silver bullet: Essence and accidents of software engineering,” Computer, vol. 20, no. 4, pp. 10–19, 1987. doi: 10.1109/MC.1987.1663532

[4]

J. C. Davis, K. Kalu, H. Peng, and P. V. Patil, Model-based agentic software engineering, arXiv preprint arXiv:2608.25174, 2026. doi: 10.48550/arXiv.2608.25174 [Online]. Available: https://arxiv.org/abs/2608.25174

[5]

R. Hoda, “Toward agentic software engineering beyond code: Framing vision, values, and vocabulary,” in Proceedings of the 2026 International Workshop on Agentic Engineering (AGENT ’26), Preprint: arXiv:2510.19692, 2026, pp. 181–185. doi: 10.1145/3786167.3788422

[6]

M. Alenezi, From determinism to delegation: AI-native software engineering and the evolution of the agentic engineer, arXiv preprint arXiv:2606.28791, 2026. doi: 10.48550/arXiv.2606.28791 [Online]. Available: https://arxiv.org/abs/2606.28791

[7]

M. Alenezi, Rethinking software engineering for agentic AI systems, arXiv preprint arXiv:2604.10599, 2026. doi: 10.48550/ arXiv.2604.10599 [Online]. Available: https://arxiv.org/abs/2604.10599

[8]

A. Gupta, Spec-driven development: A spec-first approach to AI-native engineering, Microsoft for Developers, published June 10, 2026; accessed September 2, 2026, Jun. 2026. [Online]. Available: https://developer.microsoft.com/blog/spec-drivendevelopment-ai-native-engineering/

[9]

GitHub, Spec Kit documentation, Updated August 21, 2026; accessed September 2, 2026, 2026. [Online]. Available: https://github.github.com/spec-kit/

[10]

A. Roychoudhury, C. Păsăreanu, M. Pradel, and B. Ray, “Agentic AI software engineers: Programming with trust,” Communications of the ACM, vol. 69, no. 5, pp. 56–58, 2026, Preprint: arXiv:2502.13767. doi: 10.1145/3769314

[11]

A. Aleti, B. Ray, R. Hoda, and S. Chen, Trustworthy AI software engineers, arXiv preprint arXiv:2602.06310, 2026. doi: 10.48550/arXiv.2602.06310 [Online]. Available: https://arxiv.org/abs/2602.06310

[12]

P. Sahoo, G. Mittal, X. Li, S. Ma, B. Steenhoek, P. Lin, and Y. Hu, AgentLens: Revealing the lucky pass problem in SWE-Agent evaluation, arXiv preprint arXiv:2605.12925, 2026. doi: 10.48550/arXiv.2605.12925 [Online]. Available: https://arxiv.org/abs/2605.12925

[13]

Z. Wang and D. E. Perry, “Role distribution and transformation in open source software project teams,” in Proceedings of the 22nd Asia-Pacific Software Engineering Conference (APSEC), 2015, pp. 119–126. doi: 10.1109/APSEC.2015.12

[14]

M. Li, Z. Tu, H. Xu, X. Xu, and Z. Wang, “Towards multi-stakeholder value/quality conflict detection, measurement and resolution in composite services,” Computing, vol. 107, no. 1, p. 46, 2025. doi: 10.1007/s00607-024-01408-5

[15]

X. He, Z. Tu, X. Xu, and Z. Wang, “Programming framework and infrastructure for self-adaptation and optimized evolution method for microservice systems in cloud–edge environments,” Future Generation Computer Systems, vol. 118, pp. 263–281, 2021. doi: 10.1016/j.future.2021.01.008

[16]

Y. Prifti, P. De Meo, and A. Provetti, Specifying AI-SDLC processes: A protocol language for human-agent boundaries, arXiv preprint arXiv:2606.20615v3, Version 3, revised August 16, 2026. doi: 10.48550/arXiv.2606.20615 [Online]. Available: https://arxiv.org/abs/2606.20615

[17]

R. Kang, Governed AI-assisted engineering: Graduated human oversight for agentic code generation in regulated domains, arXiv preprint arXiv:2606.22484, 2026. doi: 10.48550/arXiv.2606.22484 [Online]. Available: https://arxiv.org/abs/2606.22484

[18]

L. G. Iyer, Risk architecture for AI-native engineering teams: An organizational framework for agentic system governance, arXiv preprint arXiv:2607.01421, 2026. doi: 10.48550/arXiv.2607.01421 [Online]. Available: https://arxiv.org/abs/2607.01421

[19]

D. I. K. Sjøberg, T. Dybå, B. C. D. Anda, and J. E. Hannay, “Building theories in software engineering,” in Guide to Advanced Empirical Software Engineering, Springer, 2008, pp. 312–336. doi: 10.1007/978-1-84800-044-5_12

[20]

S. Gregor, “The nature of theory in information systems,” MIS Quarterly, vol. 30, no. 3, pp. 611–642, 2006. doi: 10.2307/25148742

[21]

W. S. Humphrey, “The personal software process (psp),” Software Engineering Institute, Carnegie Mellon University, Tech. Rep. CMU/SEI-2000-TR-022, Nov. 2000. doi: 10.1184/R1/6585197.v1 [Online]. Available: https://www.sei.cmu.edu/library/thepersonal-software-process-psp/

[22]

W. S. Humphrey, “The team software process (tsp),” Software Engineering Institute, Carnegie Mellon University, Tech. Rep. CMU/SEI-2000-TR-023, Nov. 2000. [Online]. Available: https://www.sei.cmu.edu/library/the-team-software-process-tsp/

42

Software Engineering in the Agent Era

A Preprint

[23]

J. C. Davis, P. C. Amusuo, T. Singla, B. Çakar, and K. A. Davis, Cheap code, costly judgment: A case study on governable agentic software engineering, arXiv preprint arXiv:2607.01087v2, Version 2, revised July 4, 2026, 2026. doi: 10.48550/arXiv.2607.01087 [Online]. Available: https://arxiv.org/abs/2607.01087

[24]

European Union, Regulation (eu) 2024/1689 laying down harmonised rules on artificial intelligence (artificial intelligence act), Official Journal of the European Union; accessed September 2, 2026, 2024. [Online]. Available: https : / / eur lex.europa.eu/eli/reg/2024/1689/oj/eng

[25]

D. L. Parnas, “On the criteria to be used in decomposing systems into modules,” Communications of the ACM, vol. 15, no. 12, pp. 1053–1058, 1972. doi: 10.1145/361598.361623

[26]

C. Autio, R. Schwartz, J. Dunietz, S. Jain, M. Stanley, E. Tabassi, P. Hall, and K. Roberts, “Artificial intelligence risk management framework: Generative artificial intelligence profile,” National Institute of Standards and Technology, Tech. Rep. NIST AI 600-1, 2024. doi: 10.6028/NIST.AI.600-1

[27]

OWASP GenAI Security Project, LLM01:2025 prompt injection, OWASP Top 10 for LLM Applications; accessed September 2, 2026, 2025. [Online]. Available: https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[28]

F. Jia, T. Wu, X. Qin, and A. Squicciarini, “The task shield: Enforcing task alignment to defend against indirect prompt injection in LLM agents,” in Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Vienna, Austria: Association for Computational Linguistics, Jul. 2025, pp. 29 680–29 697, isbn: 979-8-89176-251-0. doi: 10.18653/v1/2025.acl-long.1435 [Online]. Available: https://aclanthology.org/2025.acl-long.1435/

[29]

Z. Wang, Y. Gao, Y. Wang, S. Liu, H. Sun, H. Cheng, G. Shi, H. Du, and X. Li, “MCPTox: A benchmark for tool poisoning on real-world MCP servers,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 40, 2026, pp. 35 811–35 819. doi: 10.1609/aaai.v40i42.40895 [Online]. Available: https://ojs.aaai.org/index.php/AAAI/article/view/40895

[30]

M. Souppaya, K. Scarfone, and D. Dodson, “Secure software development framework (SSDF) version 1.1,” National Institute of Standards and Technology, Tech. Rep. NIST SP 800-218, 2022. doi: 10.6028/NIST.SP.800-218

[31]

M. E. Conway, “How do committees invent?” Datamation, vol. 14, no. 4, pp. 28–31, 1968, issn: 0011-6963.

[32]

P. Barbaste, T. Darrigol, G. Vu, and T. Wiltberger, Harness engineering: Anatomy, architecture, and evolution of coding agents – a source-code study of eleven systems, arXiv preprint arXiv:2609.00006, 2026. doi: 10.48550/arXiv.2609.00006 [Online]. Available: https://arxiv.org/abs/2609.00006

[33]

V. R. Basili, G. Caldiera, and H. D. Rombach, “The goal question metric approach,” in Encyclopedia of Software Engineering, J. J. Marciniak, Ed., John Wiley & Sons, 1994, pp. 528–532.

[34]

N. Forsgren, M.-A. Storey, C. Maddila, T. Zimmermann, B. Houck, and J. L. Butler, “The SPACE of developer productivity: There’s more to it than you think,” ACM Queue, vol. 19, no. 1, pp. 20–48, 2021. doi: 10.1145/3454122.3454124

[35]

J. Becker, N. Rush, T. Cunningham, D. Rein, and K. Mahamud, We are changing our developer productivity experiment design, METR, published February 24, 2026; accessed September 2, 2026, Feb. 2026. [Online]. Available: https://metr.org/blog/202602-24-uplift-update/

[36]

B. W. Boehm, Software Engineering Economics. Prentice-Hall, 1981, isbn: 9780138221225.

[37]

R. Feldt, P. Lenberg, J. Frattini, and D. Parthasarathy, The semi-executable stack: Agentic software engineering and the expanding scope of SE, arXiv preprint arXiv:2604.15468, 2026. doi: 10.48550/arXiv.2604.15468 [Online]. Available: https://arxiv.org/abs/2604.15468

[38]

T. Sirqueira and J. Faciroli, The specification paradox: Rethinking requirements engineering in the age of AI, arXiv preprint arXiv:2608.16618, 2026. doi: 10.48550/arXiv.2608.16618 [Online]. Available: https://arxiv.org/abs/2608.16618

[39]

R. Shayanfar, K. Gallaba, and A. E. Hassan, What does an agentic software engineering benchmark measure? profiling task demands and agent behaviour beyond what category labels reveal, arXiv preprint arXiv:2609.01271, 2026. doi: 10.48550/arXiv.2609.01271 [Online]. Available: https://arxiv.org/abs/2609.01271

[40]

OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities, Published February 23, 2026; accessed September 2, 2026, Feb. 2026. [Online]. Available: https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/

[41]

OpenAI, Separating signal from noise in coding evaluations, Published July 8, 2026; accessed September 2, 2026, Jul. 2026. [Online]. Available: https://openai.com/index/separating-signal-from-noise-coding-evaluations/

[42]

H. Li, H. Zhang, and A. E. Hassan, “AIDev: Studying AI coding agents on GitHub,” in Proceedings of the 23rd International Conference on Mining Software Repositories (MSR), 2026, pp. 1029–1033. doi: 10.1145/3793302.3797249

[43]

H. K. Dam, G. Mahala, R. Hoda, X. Zheng, and C. Conati, Towards autonomous normative multi-agent systems for human-AI software engineering teams, arXiv preprint arXiv:2512.02329, 2025. doi: 10.48550/arXiv.2512.02329 [Online]. Available: https://arxiv.org/abs/2512.02329

[44]

Y. Wang, X. Shen, Y. Han, M. Backes, P.-Y. Chen, and T.-Y. Ho, OrgAgent: Organize your multi-agent system like a company, arXiv preprint arXiv:2604.01020, 2026. doi: 10.48550/arXiv.2604.01020 [Online]. Available: https://arxiv.org/abs/2604.01020

[45]

Z. Yu, Y. Fu, Z. He, Y. Huang, K. Y. Lee, M. Fang, W. Luo, and J. Wang, From skills to talent: Organising heterogeneous agents as a real-world company, arXiv preprint arXiv:2604.22446, 2026. doi: 10.48550/arXiv.2604.22446 [Online]. Available: https://arxiv.org/abs/2604.22446 43

Software Engineering in the Agent Era

A Preprint

[46]

W. Lyu, Y. Xiao, Y. Zhang, and Y. Sun, Self-organizing multi-agent systems for continuous software development, arXiv preprint arXiv:2603.25928, 2026. doi: 10.48550/arXiv.2603.25928 [Online]. Available: https://arxiv.org/abs/2603.25928

[47]

R. Choudhuri, C. Bird, C. Badea, M. Gerosa, and A. Sarma, You shall not pass! where and why developers draw the line on AI autonomy, arXiv preprint arXiv:2607.00533, 2026. doi: 10 . 48550 / arXiv. 2607 . 00533 [Online]. Available: https://arxiv.org/abs/2607.00533

[48]

A. Reid, S. O’Callaghan, D. Venini, L. Carroll, and T. Caetano, Risks and controls for multi-agent systems: An analytical framework for deployment of AI agents across organisational boundaries, arXiv preprint arXiv:2608.26626, 2026. doi: 10.48550/arXiv.2608.26626 [Online]. Available: https://arxiv.org/abs/2608.26626

[49]

L. I. Assalaarachchi, Z. Masood, R. Hoda, and J. Grundy, “Toward agentic software project management: A vision and roadmap,” in Proceedings of the 2026 International Workshop on Agentic Engineering (AGENT ’26), Preprint: arXiv:2601.16392, 2026, pp. 157–164. doi: 10.1145/3786167.3788409

[50]

S. Shandrokha, A. Chaudhary, A. Di Marzo, P. Seviaryn, V. Vlasenko, and P. Golub, Introducing agentic development lifecycle (ADLC): Building and operating AI agents in production, EPAM Systems, published February 5, 2026; accessed September 3, 2026, Feb. 2026. [Online]. Available: https://www.epam.com/insights/ai/blogs/agentic-development-lifecycle-explained

[51]

McKinsey & Company, Beyond the copilot: Scaling the agentic product development life cycle, Published August 21, 2026; accessed September 3, 2026, Aug. 2026. [Online]. Available: https://www.mckinsey.com/industries/technology-media-andtelecommunications/our-insights/beyond-the-copilot-scaling-the-agentic-product-development-life-cycle

[52]

M. Segner, Steering Claude Code: When to use CLAUDE.md, skills, hooks, and subagents, Anthropic, published June 18, 2026; accessed September 2, 2026, Jun. 2026. [Online]. Available: https://claude.com/blog/steering-claude-code-skillshooks-rules-subagents-and-more

[53]

OpenAI, Introducing the Codex app, Published February 2, 2026; accessed September 2, 2026, Feb. 2026. [Online]. Available: https://openai.com/index/introducing-the-codex-app/

[54]

Replit Team, What’s changed from Replit Agent 3 to Agent 4, Published March 19, 2026; accessed September 2, 2026, Mar. 2026. [Online]. Available: https://replit.com/blog/whats-changed-agent3-to-agent4

[55]

Huawei Cloud, CodeArts Agent: Agent settings, Official user guide, updated September 1, 2026; accessed September 2, 2026, 2026. [Online]. Available: https://support.huaweicloud.com/intl/en-us/usermanual-enterprise/codeartsagent_enterprise_0015. html

[56]

Huawei Cloud, CodeArts Agent: Multi-task parallelism, Official user guide, updated August 25, 2026; accessed September 2, 2026, 2026. [Online]. Available: https://support.huaweicloud.com/intl/en-us/usermanual-space/codeartsagent_space_0003. html

[57]

X. Wang, H. Xu, J. Yang, X. Xu, and Z. Wang, “A collaborative service composition approach considering providers’ self-interest and minimal service sharing,” IEEE Transactions on Parallel and Distributed Systems, vol. 36, no. 3, pp. 598–615, 2025. doi: 10.1109/TPDS.2025.3534283

[58]

M. Liu, Z. Tu, X. Xu, Z. Wang, and Y. Wang, “A data-driven approach for constructing multilayer network-based service ecosystem models,” Software and Systems Modeling, vol. 22, no. 3, pp. 919–939, 2023. doi: 10.1007/s10270-022-01029-6

44

Related documents

• LLM-as-Code Agentic Programming for Agent Harness#282880
• Continuous Assurance of Agentic Security Auditors for Software Delivery Decision Gates#1129860
• Continuous Assurance of Agentic Security Auditors for Software Delivery Decision Gates#1108613
• OpenComputer: Verifiable Software Worlds for Computer-Use Agents#204842
• Agent-Integrated Software: Interaction Contracts and Continuous Assurance#673573