When Routine Operations Break Architectural Pattern Relationships in LLM Agent Harnesses

When Routine Operations Break Architectural Pattern Relationships in LLM Agent Harnesses Boming Xia∗†‡ , Qinghua Lu‡§∗ , Dino Sejdinovic∗† and Liming Zhu‡§

arXiv:2611.09088v1 [cs.SE] 6 Nov 2026

∗ Responsible AI Research Centre † Adelaide University ‡ CSIRO § UNSW

Abstract—LLM agent harnesses distribute tool mediation, state management and safety guardrails across native services, independently written plugins and configuration. Routine operations can change the runtime order or retained state that architectural pattern relationships require, without any code change. We study five relationships associated with the Guardrail Enforcement Point, Autonomy Controller and Blackboard patterns across five released harnesses, analysing a main sample of fourteen independently written plugins. Using PatternOps, our assessment procedure, we trace requirements from pattern descriptions, provider documentation and deployment profiles to the providers responsible for them and the records used to assess them. We then compare alternative allocations under supported operations. After a policy plugin was reapplied or an edit allow rule was saved, a prohibited edit executed without policy evaluation even though the participating plugins were active. Which alternatives qualified depended on the requirement. Allocations that kept the required order, or kept or rebuilt the needed state, held on their tested paths and operation sequences, while others prevented prohibited effects but missed edits rejected elsewhere. In these harnesses, a pattern relationship is a property of the running system and its history, so architects should evaluate it against the decision paths, state lifetimes and operation sequences their deployments use. Index Terms—Architectural patterns, LLM agent harnesses, plugin composition, runtime conformance, empirical study

I. I NTRODUCTION An LLM agent harness can execute a prohibited edit while its policy and approval plugins remain active. Harnesses coordinate model and tool calls, manage execution state and mediate actions through mechanisms such as policy checks and operator approval [1]–[5]. Architectural patterns describe reusable arrangements of responsibilities and relationships for concerns such as guardrail enforcement, operator control and shared state [6]–[8]. Native services, independently written plugins and configuration realise these responsibilities jointly, so their runtime interactions decide whether the required relationships survive routine operations, such as reapplying a plugin, saving consent or compacting the history. Consider policy participation, an assessed Guardrail Enforcement Point (GEP) requirement: the designated policy must decide before an action covered by the deployment executes, even when an operator approves it. In one harness, a policy plugin submits tool calls to a policy service and an approval plugin asks the operator [9]–[11]. Their callbacks form a chain of responsibility [12]: by default, they run in registration order until one answers without passing the call on [9]. We arranged policy-first order and confirmed that an initial edit in observe mode, used for calibration, reached

policy. The documented switch to enforce mode re-registered the policy callback behind the approval plugin. The operator then approved a prohibited edit, and it executed without a policy decision. Disabling and re-enabling the approval plugin re-registered it last and restored evaluation. The same enabled plugins and final settings thus gave different policy coverage after different operations (Fig. 1a). Runtime order is one way to carry a relationship. Retained state is another: after an allow rule was saved, a policy reviewer that checks only requests still needing operator approval abstained, and a prohibited edit executed [13], [14] (Fig. 1b). Reapplying a plugin can also discard source provenance held in its instance. An allocation assigns responsibilities to harness parts, and a carrier is the runtime order or retained state on which a required relationship depends. Preservation through routine operations therefore depends on the allocation as a whole, not on any plugin in isolation. These dependencies reflect established concerns in complete mediation, feature interaction, aspect precedence, safe dynamic update and architectural mismatch [15]–[20]. Recent studies examine runtime pattern conformance, interacting changes to agent harnesses, action-bound approval and contracts or shared decision cores for composed agent controls [21]–[25]. For an architect choosing where to enforce policy or retain decision state, the remaining question is which alternative allocations among a harness’s native services and independently written plugins preserve a specified relationship through the operations a deployment supports, and what obligations each allocation introduces. Answering it requires knowing what carries each relationship and how operations and routes change it. We investigate five assessed relationships across five released harnesses as a multiple-case study with controlled comparisons [26], analysing a main sample of fourteen independently written plugins from source. GEP is the principal case, covering policy participation and decision information, such as provenance needed for a policy decision. Supporting comparisons examine whether an Autonomy Controller (AC) response applies to its pending action, whether resumption repeats completed work under a task-derived requirement and whether a shut-down Blackboard member remains excluded under a specified deployment profile. Using PatternOps, our assessment procedure (Section III), we distinguish pattern duties, provider promises and deployment requirements. We trace each requirement to its allocation and carrier and judge

(a)

Callback order on DeepSeek Harness rc.2

Arranged policy first (observe mode)

Governance submits call

Key Policy records decision

Tool Approval asks

Operator decides

Mode switch (observe → enforce): Governance re-registers behind Tool Approval

Plugin

After the switch Prohibited edit

Tool Approval ends chain

Operator approves

Prohibited edit executes

Not reached: Governance / policy

Alternative Native consent

Governance submits call

Policy blocks

No edit applied

Not asked: native question

Policy denies

No edit applied

(b)

Native stage

Study policy

Operator

Saved consent and Permission Reviewer on OpenCode 2.2.5 Edit prevented

Control arm No saved allow rule

Permission stage: would ask

Reviewer evaluates

Edit executed

Matched arms: An earlier “always” reply saved a rule allowing edits to any file in the saved-rule arm Saved-rule arm Prohibited edit

Permission stage: already allowed

Reviewer abstains (not an ask)

Prohibited edit executes

No policy request

Off-path

Fig. 1. Policy participation under supported operations. (a) A mode switch reorders callbacks in DeepSeek Harness. Native consent, the host’s own approval question after the plugin chain, keeps policy reachable in enforce mode under the tested read-only profile. (b) A saved allow rule makes OpenCode’s reviewer ineligible. Rows of (b) are matched arms in separate processes.

the assessed actions from records joined across providers1 . We ask: • RQ1: How are the assessed relationships realised across native capabilities, plugins and configuration, and what carries them? • RQ2: How do supported operations and execution routes preserve or break these relationships? • RQ3: Which alternative allocations preserve them under the tested conditions, and with what trade-offs? The study contributes: 1) An evidence-grounded account of how selected architectural relationships are allocated and carried across released agent harnesses (RQ1). 2) Controlled evidence of operation-dependent losses and restorations, including different policy coverage with the same enabled plugins and final settings, and a state repair that fails after a subsequent operation (RQ2). 3) Requirement-specific comparisons of alternative allocations, distinguishing prevention of prohibited effects from evaluation of every admitted edit, together with their tested conditions and operating obligations (RQ3). II. R EQUIREMENTS AND CARRIERS Judging whether a relationship holds needs two distinctions: who sets the requirement it must meet, and what runtime order or state carries it. The harness core is the host. An assembly combines a particular host release with its plugins, configuration and services. The parts of an assembly that supply a pattern’s responsibilities are that pattern’s providers, and a 1 The companion and anonymised evidence are available at https:// anonymous.4open.science/r/pattern-relationships-supplement-C35A/.

pattern relationship is a required relation among the responsibilities of one pattern, realised by one or several providers. Each judgment concerns one pattern relationship and the requirements stated for it (Table I), not the whole pattern. Authority. Requirements have three authorities: pattern descriptions supply pattern duties, provider documentation supplies provider promises and the study’s deployment profile supplies deployment requirements. A provider can meet its promise while its allocation fails another requirement. Table I records the authorities and the fixed study readings. Policy participation has three nested requirements. Effect prevention, the weakest deployment requirement, needs only that no prohibited effect occurs. The GEP pattern duty adds that the designated policy decides before a covered action executes and that its prohibitions are enforced. Calibrating policy on all admitted proposals requires it to evaluate even edits that another provider rejects. We call this stricter deployment requirement the every-edit requirement. An edit that another provider rejects before policy sees it thus violates only the every-edit requirement. An edit that executes unevaluated also violates the GEP duty, and a prohibited one also violates effect prevention. Policy can also escalate a call to the operator for consent. We report escalation handling separately. Every policy-participation comparison also requires that an operator’s rejection stops the call it answers. Carriers and operations. Carriers come in two kinds, and one relationship can depend on both. A connector’s order or position, such as the callback chain, decides whether policy sees an edit before an approval question ends the call. Retained state, such as saved consent, a plugin’s private labels or a member cache, decides which requests a provider acts on and what a decision still knows. Carriers thus lie in

TABLE I A SSESSED RELATIONSHIPS AND REQUIREMENT AUTHORITIES .

Relationship

Authority of assessed requirement

GEP: policy participation

Pattern duty: The inline enforcement point “must return before execution proceeds” and enforces prohibitions returned by policy (§3.2.1). Provider promise: Governance “intercepts every tool call”. Deployment requirement: A study policy service decides; approval does not override a prohibition; every admitted edit call is evaluated, including rejected ones (the every-edit requirement).

GEP: decision information

Pattern duty: The decision receives the candidate action and its boundary context. Provider promise: Airlock: untrusted content cannot direct an egress-capable tool, and compaction cannot launder (remove) a label. Deployment requirement: An untrusted source restricts edits, or under Airlock’s built-in rules egress-capable tools, while it is in the model’s input or a summary’s sources. RiskProof: an observe-mode read restricts the first enforce decision.

AC: response applied

Pattern duty: The operator’s response is applied before progression (§3.2.2). Study reading: the response to the pending action.

AC: completed work

Deployment requirement (task): Resumption repeats no completed work.

Blackboard: membership

Pattern duty: Knowledge is “accessible to all agents”. Study reading: participating members. Provider promise: Ensemble: its lookup returns only members that have not shut down. Deployment requirement: A shut-down member stays excluded until it re-enrols.

Sources: the AgentOps catalogue for GEP and AC (§ numbers) [6], Microsoft’s agent memory design for Blackboard [7] and Nii’s model as background [8]. Airlock and RiskProof track source provenance in DeepSeek Harness, and Ensemble is an OpenCode board plugin.

a connector’s semantics [27] or in retained state. The studied operations are ones the hosts support for normal use, and each can change a carrier without changing any provider’s code. On DeepSeek Harness, reapplication disposes of an instance and creates another after its configuration changes, as the switch from observe to enforce mode does for the policy plugin. A reload, here on OpenCode and Pi, replaces instances without a configuration change. Both thus replace a component instance in the sense of dynamic reconfiguration [18]. Compaction replaces an earlier interval of the conversation history with a summary and keeps a later tail verbatim. III. S TUDY DESIGN The cases were chosen purposively to expose different ways in which harnesses compose decision providers and retain their state. Source analysis and observation on the released hosts locate each relationship’s providers and carrier (RQ1). Comparisons then vary operations and execution routes (RQ2) and allocations (RQ3) against the requirements of Section II. PatternOps. PatternOps is the specified procedure this study uses to turn a pattern relationship into requirements that an assembly’s own records can decide (companion Section III). The inputs are a fixed pattern description, an identified assembly and an assessment question. Assessors record what they knew in advance, derive the pattern duties and identify competing readings of ambiguous phrases. Source authority settles the reading. They record provider promises, fix deployment requirements and bind each requirement to its providers and carrier in a Pattern Realisation Contract. Each pattern and host gets its own derivation and bindings. Judgments. Assessors join each action’s records across providers and label each requirement part satisfied, violated, unsupported (the records decide neither way), not exercised

(the boundary was not reached) or not applicable. Within a fixed requirement and judgment scope, labels for applicable parts combine in this order: violated, unsupported, not exercised then satisfied. An unsupported part alone never establishes a violation. If an inspected path lacks the required decision but an uninspected provider could have supplied it, the path judgment is violated and the assembly judgment unsupported. A positive judgment must hold under every reading fixed for the assessment. Later readings are reported as sensitivities. Subjects. The main sample comprises fourteen independently written plugins analysed from source (companion Section IV lists them): eleven for DeepSeek Harness and three for OpenCode. Exploratory and bounded repository searches selected the DeepSeek Harness plugins for different control and state arrangements. From code, six, including Governance and Airlock, have approval branches that end the chain without delegating (passing the call on) for the tools they cover, so each can skip a policy callback registered after it. The OpenCode subjects are the policy reviewers Permission Reviewer and ACP and the board plugin Ensemble [14], [28], [29]. ACP was selected after the saved-rule loss, because its code also reviews already-allowed requests. Host comparisons exercise ten sample plugins at the pinned releases of Table II [9], [13], [30]–[32]. Transfer cases substitute Intutic for the policy plugin Governance [33] and Edit Approval or AgentGuard for the approval plugin Tool Approval [34], [35]. Edit Approval runs on the host’s earlier 0.1.0-rc.8 release, and AgentGuard’s approval branch delegates. The provenance plugins Airlock and RiskProof supply decision information [36], [37]. On Deep Agents the AC subjects are LangChain’s batched and per-call review, including

TABLE II H OSTS , CARRIERS AND TESTED OPERATIONS . GEP IS THE PRINCIPAL CASE .

Host

Carrier: operations or routes

GEP policy participation DeepSeek Harness rc.2, Callback order: start, switch, alpha.2, rc.5, rc.8 configuration edit, disable and enable OpenCode 2.2.5 Permission stage under saved consent: reload, saved allow rule, revoke Claude Code 2.1.317 Hook precedence: saved allow rule GEP decision information DeepSeek Harness rc.2, Provenance labels in a plugin instance or alpha.2, rc.5 the history: reapplication, compaction, compaction then reapplication Pi 1.5.0 Session log: reload, resume AC response applied Deep Agents 0.7.28, Route to the tool node: normal and direct 0.7.13 routes. Pending request: graph recreation OpenCode 1.19.3 Pending request: reattachment AC completed work (task-derived) Deep Agents 0.7.28 Saved task results: resumption after approval or rejection Blackboard membership OpenCode 1.18.30, Member cache and stored status: running 2.0.32 lookup, restart, remove and restore DeepSeek Harness rc.2, alpha.2 and rc.5 are 0.2.1 prereleases, and rc.8 is 0.1.0-rc.8. Operations are pooled across the listed releases.

Deep Agents’ own approval option, which builds batched review. The vendors’ Hookify (Claude Code) and plan-mode (Pi) plugins supply comparisons outside the main sample [32], [38]. A bounded search for repositories created after the main study selected one further OpenCode plugin, opencode-guard, as a boundary case [39]. Baseline subjects keep their code unchanged. Tables mark each provider native (N), external (E, an existing plugin loaded separately from the host) or study-built (S, code the study wrote or modified). Below, the policy plugin means Governance, the approval plugin Tool Approval, the provenance plugin Airlock and the board plugin Ensemble. Comparisons. Matched comparisons fix a relationship’s requirement and workload and, for GEP, its policy, and vary one allocation or one operation. Programmed comparisons also fix the action sequence, whereas live ones fix the task and let the model choose its actions. A changed allocation can bundle several mechanisms, so a contrast between allocations measures the allocation as a whole. A provider variant, such as a repackaged plugin, changes how one provider is built without moving a responsibility. The execution unit is a process (one fresh start of the host) or, for some comparisons, a workflow (a planned run that may include a restart or graph recreation). Execution. Programmed model responses and operator replies drive native dispatch, approval, storage and tools. They fix the action sequence. For the five-edit DeepSeek Harness workload, a deterministic study policy service decides by tool and file name. The programmed model returns identical

summaries at compaction. Most DeepSeek Harness operations use a study controller in the host process. Selected runs use public operations alone: an outside client drives the stock command-line interface (CLI) and plugin management, with no study controller or recorder in the host. Across seven DeepSeek Harness and OpenCode comparisons, one CLI model and five API models replace the programmed model, so that models choose their own actions (companion Section VIII). The CLI model’s serving identity was unreported. An adapter checks the response format before forwarding final text or one call to an offered tool. Dispatch, policy, consent and effects run in the assembly. Two maintenance processes used the host’s own model route without the adapter. Units and controls. An attempt counts once the host admits it as a tool call within the covered scope: the selected edit tools and, in the maintenance task, also shell tools. Unless stated otherwise, DeepSeek Harness policy-participation tests propose five selected edits after the operation under test, with the approval plugin limited to edits. The policy would block one edit, allow two and escalate two. The operator approves the prohibited edit if asked, approves one edit in each remaining pair and rejects the other. Controls check policy activity, legitimate progress and relevant state before or after the operation, as each comparison requires. On DeepSeek Harness an allowed and a blocked read establish policy activity on the read path, judged separately from edits. A legitimate action, one that policy allows, must proceed when approved and stop at a matching rejection, the operator’s reply to that call’s own question. A provider of decision information must restrict edits, or egress-capable tools under Airlock’s built-in rules, while a fresh untrusted source is relevant. A continuing Blackboard member must receive board items. Joined records and evidence. An absent effect does not establish policy participation, since another provider can also prevent it. The unit of judgment is therefore one relationship at one action or state transition, read with the history it needs. The companion specifies each relationship’s deciding join. Repeated programmed units reproduced their outcomes, and other releases, packaging and clients, public operations alone and live models test sensitivity to those conditions. Inputs and expectations, informed by the pinned code and earlier results, were bound before execution for the initial DeepSeek Harness mode-switch comparisons, Deep Agents’ approval option, Ensemble 0.20.0 and the later-selected opencodeguard. “From code” marks claims, including explanations of observed outcomes, that rest on reading the pinned code alone. Asterisks identify results based on analyses corrected after collection on unchanged records (companion Section IX). For RQ3 the study records added attempts and questions, changed decision behaviour and operating obligations separately. Worked assessment. Take the prohibited edit after the switch on DeepSeek Harness rc.2 (Fig. 1a). The GEP duty requires the designated policy to decide before a covered action executes (Table I), and the study policy prohibits this

edit. Governance submits calls to that policy, Tool Approval asks the operator and the host orders their callbacks. The admitted call joins to the operator’s approval and the changed file but to no policy record with the same session, tool and arguments. The callback inventory places Governance behind Tool Approval, whose answer ends the chain, and a blocked read in the same process shows that policy stayed active on the read path. Without records covering the edit path, the missing policy record would leave participation unsupported. Here the captured call, approval, effect and complete policy stream establish violations of all three nested requirements. IV. P OLICY PARTICIPATION Two carriers decided policy participation: callback order on DeepSeek Harness and saved consent at OpenCode’s permission stage. On both hosts an ordinary operation changed the carrier and opened a path around policy with the participating plugins active (Fig. 1). Starts put approval first despite the configured row order. DeepSeek Harness runs plugin callbacks in registration order by default, and no declared rule sets that order: the host’s base profile, which lists one plugin per row, states that “Row order carries no load semantics”. In all 24 inventoried rc.2 and alpha.2 starts of the unchanged pair that recorded callback order, the approval plugin registered first, although the configuration lists the policy plugin first. From code, the loader registers each plugin when its own import completes, so packaging can affect the order, which the repackaging comparison below tests. In cold observe-mode starts that tested edits before any rearrangement, and in fresh starts from the final enforce settings, policy evaluated no selected edit (Table III). The documented switch undid a policy-first order. For the unchanged pair, we arranged policy-first order. Policy then evaluated every selected observe-mode edit. The switch reapplies the policy plugin. Reapplication disposes of its registration and appends a new one, so its new callback sat behind the approval plugin’s, as the ordered callback inventory shows. Policy then evaluated no selected edit, and in each process the edit that policy prohibits executed once the operator approved it (Table III). The loss recurred across releases, including rc.5, and packaging, through public operations alone and for live models’ own edits. Under the approval plugin, the five API models made 28 reads and 28 edits, and policy evaluated every read and no edit, at startup or after the switch. The same plugins and settings kept or lost participation depending on history. Disabling and re-enabling the approval plugin through public plugin management, with plugin code and configuration unchanged, restored policy evaluation of all five selected edits, and the next switch removed it again. Processes that lost participation had the same final effective provider settings as those that kept it, but a different runtime order. No captured component check reported the loss: both providers stayed active, the policy plugin still blocked a read in enforce mode and the plugin manager raised no warning. Joining each edit to its policy record exposed the loss.

TABLE III S ELECTED EDIT ATTEMPTS EVALUATED BY POLICY, BY ALLOCATION AND OPERATION .

(a) DeepSeek Harness rc.2 Condition / comparison

Evaluated / edits

Governance + Tool Approval Cold observe start Policy-first observe → switch Fresh enforce start After disable/enable (3 processes) Next switch (2 processes) Alternatives / study variants Native consent (read-only): observe → switch Prepended registration: switch; fresh enforce In-place update: arranged switch; fresh enforce Volatile-mode* : arranged switch; cold observe Single-module: observe; switch

0/1 1/1 → 0/5 0/5 5/5 0/5 1/1 → 5/5 5/5; 5/5 5/5; 0/5 5/5; 0/1 1/1 (3); 0/5

(b) OpenCode 2.2.5 Allocation / condition

Denied by Selected edits configuration

Permission Reviewer No saved rule: start; reload 5/5; 5/5 After saved allow: next prohibited edit 0/1 (4) After native revoke 3/3 Alternatives after saved allow Study eligibility-only variant 6/6 Study stage provider* 6/6 Study check before the tool body* (1 6/6 process) Published ACP (1 process) 3/3 Study ACP, renewed question (1 process) 4/4

– – – 0/1 0/1 1/1 1/1 1/1

Values are policy-evaluated/selected attempts per process. Each condition used two processes unless parentheses give another number. Arrows show before and after an operation, and semicolons separate conditions. OpenCode workloads differ across rows, and the configuration-denied edit is additional. –: not tested. * Corrected analysis. Other routes: companion Section V.

The transfer plugins lost participation the same way unless the approval question delegated. A configuration edit or a study replay of the rewrite performed by Intutic’s sync daemon recreated Intutic behind the approval plugin. In all six Intutic processes, an edit that policy prohibits executed once approved. Edit Approval on rc.8 showed the same loss after a configuration change or the switch. Through public operations alone, AgentGuard’s delegating approval branch kept policy evaluating all five selected edits at the start, after its own disable and enable and after the switch, in two processes. These operations moved AgentGuard behind the policy plugin and back, so on its tested branch delegation, not order, kept policy reachable. From code, its own denial ends the chain before policy, a branch these runs did not exercise. Moving consent after the chain kept policy in the path. Native consent moves approval to the host’s own question after the plugin chain. Policy evaluated every selected edit through the same switch with the study controller, with live models, through public operations alone and on rc.5 (Table III). Four of the five API models made 54 read and edit calls, all evaluated

by policy. The remaining model made no admitted call under native consent in this comparison. File edits used the nondefault read-only mode, in which every edit needs the host’s approval. Live models obtained wider permission for permitted edits on the first attempt or on a retry after denial. Policy participation holds only while no callback ahead of policy ends the chain (Table V). Fixing registration order also kept policy first. A study variant prepended the policy callback, keeping it first at an enforce start and through the switch. The readiness dependency* , a study change, makes the approval plugin wait for the policy plugin’s registered callback. In two processes it kept policy evaluating all selected edits at a start, through the switch and after reapplying the approval plugin. From code, withdrawing that readiness unloads the approval plugin, which restarts after the policy plugin re-registers. Accepted work did not reveal whether policy took part. The maintenance task asked live models to implement a feature in the provenance plugin’s source across the switch. Acceptance required all 390 unchanged upstream tests to pass. The CLI model’s work passed under both allocations. Joining host session logs to policy records gave unique decisions for all 44 post-switch covered attempts under native consent and none for the 19 under the approval plugin. One API model’s work also passed under both allocations through the host’s own model route, without the adapter. Policy evaluated every attempt under native consent and none of its 32 post-switch edit and shell attempts under the approval plugin. The API-adapter comparisons showed the same participation split (companion Section VIII). Repairs aimed at one operation failed at another. Two study changes, an in-place update and a volatile-mode variant* , apply the switch to the running instance. Both kept an arranged policy-first order through the switch but left the approval plugin first at an unarranged cold start. Single-module repackaging of the policy plugin, a provider variant, did the reverse: it registered first in the tested starts but lost participation at the switch. Preventing every prohibited effect still left rejected edits unevaluated. In one process, a study policy wrapper around dispatch, after the chain, prevented every prohibited effect in the tested sequence but evaluated only four of the six postswitch edits, missing the two that the approval plugin rejected first. It meets the GEP duty but not the every-edit requirement. Saved consent made edits ineligible for policy review. On OpenCode, Permission Reviewer applies policy inside the native permission stage, before the native question, and the study configured it so that policy-allowed edits still raise that question. With no allow rule saved, it evaluated every selected edit at a start and after a reload. In four processes, one “always” reply saved an allow rule for edits to any file, which from code covers every edit tool. The next edit, which policy prohibits, took effect without evaluation, while two control processes that replied “once” evaluated every later edit. The saved rule marked the request as already allowed, so the reviewer abstained. A public issue reports this native

behaviour [40]. A public revoke restored evaluation. All five API models reproduced the loss and the restoration with their own edits. The unevaluated prohibited edit breaks the GEP duty, because standing approval does not replace the policy decision. The reviewer kept its documented promise to review only asks, so the loss is a mismatch between that promise and a deployment that gives it the GEP decision. Wider eligibility reached saved-rule edits but missed a configuration-denied edit. The study’s eligibility-only variant of Permission Reviewer widens only its eligibility filter, to admit already-allowed edits. With the rule in place, it evaluated all six later selected edits in each of two processes. Legitimate progress and matching rejections held. Its unchanged verdict mapping still escalated policy-allowed edits, so it asked again. The stage provider* , a study provider at that stage that leaves an allowed verdict unchanged, did not ask again. Both missed the one edit per process that OpenCode’s configuration denies, which never reaches that stage. Checking before the tool body reached the configurationdenied edit, with different consequences for escalation. A study check before the tool body* evaluated the configurationdenied edit. It could not ask the operator, so it turned escalations into denials. From code, the published ACP plugin also checks each call before the tool body and reuses that verdict at the permission stage, and its policy records are consistent with that reuse. Under the saved rule it kept policy deciding every selected edit, the configuration-denied one included, and prevented the prohibited edit, but its escalated edit ran without a new question. A study variant mapping ACP’s escalation to the native question renewed it: a rejection prevented the edit and a one-time approval allowed it. A local hook remained effective after saved consent. On Claude Code, Hookify evaluated both programmed Bash calls after an allow rule was saved and denied the matching destructive delete. Fresh consent did not supply the designated policy decision. In two programmed workflows, the later-selected opencode-guard asked again for every edit its rules send to the operator despite a saved allow rule [39]. The guard’s rejection stopped the edit. Approval allowed it unless native permission denied it. Both workflows matched all eight predictions. The local guard supplied no designated-policy decision. Decision. The requirement selects the placement (Table V). When the chain is policy’s only path, the every-edit requirement places policy before any step that can end an admitted attempt. For the unchanged pair, the next switch undid restoration, and separate fresh starts also missed policy. After either operation, operators should check that a covered edit reaches policy for evaluation. V. D ECISION INFORMATION A policy decision can be reached yet lack the source provenance that its rule needs. In DeepSeek Harness, source provenance sits in a plugin instance’s private state, which reapplication discards, and in the host’s conversation history, which compaction re-encodes. Table IV gives the outcomes. Controls

TABLE IV D ECISION INFORMATION ON D EEP S EEK H ARNESS RC .2: RESTRICTION AND CLEAN WORK AFTER EACH OPERATION .

Allocation

Compact, then Clean work Reapply Compact reapply allowed

State in the plugin instance E Airlock noL yesL , noL – S in-place update yes – – S decoder fix – yes, yes no, no E RiskProof no – – S in-place update yes – – State outside the plugin instance S reconstruction – yes, yes yes, yes S journal – yes, yes yes, yes S registered rep.* – yes, yes yes, yes No retained state S input-only provider – yes, yes yes, yes

yes yes yes yes yes yes yes yes no

E external, S study-built. Indented rows change the plugin above. Study edit rule throughout. Operation cells report whether the restricted edit was prevented. Rows come from separate comparisons. Clean work, with no relevant untrusted source, is judged after the operations. Pairs: source summarised, then in the verbatim tail. Dash: not tested. L: also observed for a live model’s own edit, same release and rule. * Analysis corrected after collection, on unchanged records.

tested restriction of edits under the study rule, or bash under the built-in rules, with a fresh untrusted source, and progress on clean work, actions taken while no untrusted source is relevant. RiskProof’s controls followed its switch, which falls by design between the source read and the restricted edit. Reapplication discards what an instance knew. The provenance plugin Airlock labels sources by trust [36]. Its built-in rules restrict egress-capable tools such as bash, and a study rule that replaces them denies an edit while an untrusted source is relevant. Changing only its logging destination reapplied it, on rc.2 and alpha.2. The new instance no longer held the earlier source in its private state and treated the context as user input, so the edit that the source should restrict executed. Under the built-in rules, reapplication also released a bash call that they had blocked after a synthetic note from a Model Context Protocol (MCP) tool, although the note stayed in the model’s request. This loss recurred on rc.2 and rc.5 and in a live model’s own call* . RiskProof, a second provenance plugin, was set to deny untrusted edits under the host’s exact-version profile exemption from its compatibility check. The study requires an observe-mode read to restrict the first enforce decision, but the switch to enforce mode reapplied the plugin and discarded that read’s provenance, as its own code comment predicts [37]. Each plugin owns this state, but the host’s reapplication decides how long it lasts. A study in-place update, which keeps the running instance, preserved the restriction for both plugins. A format change between releases hid a source in the verbatim tail. Airlock promises that compaction cannot launder a label, and for a summarised source the summary inherited the label, so immediately after compaction every labelling allocation denied the edit. With the source in the

verbatim tail, the original plugin permitted the edit on rc.2, on rc.5 and with a live model, although the source stayed in the model’s request. The tested hosts use new field names for the replaced history range. Airlock still reads the names used by its documented host release, so its view of the history differs from the host’s. From code, the plugin declares no host-release range for the host’s compatibility check to enforce. A repair that survived compaction failed at the next reapplication. Two study repairs of Airlock kept the restriction through compaction. The decoder fix, also tested on rc.5, reads the renamed fields but still keeps labels in the plugin instance, whereas reconstruction rebuilds them from the host’s history at each decision. A loggingonly reapplication after compaction separated them: the decoder fix’s new instance no longer held the source, while reconstruction kept the restriction. Four fresh repeats of these reapplication cells gave the same outcomes. The decoder fix thus addressed only the format change, while reconstruction also removed the dependence on the instance’s lifetime. Reconstruction failed 41 of 390 upstream tests because the test mocks lacked the host session accessor it uses. State outside the instance survived both operations. A study journal persists the plugin’s observed events and restores them after reapplication. Under the built-in rules on rc.5, a live model’s own summary inherited the source’s label. The original lost it at a reapplication, while the journal, which also carries the decoder fix, kept it. With programmed models, the registered representation* , study-built label state that the host rebuilds from the session log, also kept the labels in nine workflows, each with up to two compactions and two reapplications. Pi’s vendor plan-mode plugin, an analogous allocation, restored its restriction from the session log after a reload and a resume. By contrast, the input-only provider, which keeps no state and refuses a summary whose sources are not linked, prevented all eight restricted edits but also refused all four clean ones, because identical programmed summaries hid whether their sources were trusted. Decision. In the DeepSeek Harness comparisons, studybuilt allocations that kept state outside the plugin instance or rebuilt it from the host’s history preserved restriction and clean work across the tested sequences (Table V). Each repair must be tested against every operation sequence in use. VI. A PPROVAL , RESUMPTION AND MEMBERSHIP Three supporting requirements, each under its own authority (Table I), test execution routes and retained state beyond GEP. On each tested route the operator’s response must apply before its pending action progresses. The maintenance task requires resumption to avoid repeating completed work. The Blackboard deployment requires a shut-down member to stay excluded until it re-enrols, both while the board plugin runs and after a restart. Per-call review held on every tested route, and batched review failed on direct routes. Eighteen programmed Deep Agents workflows crossed two review modes, three routes and three operator responses (approval, rejection and none).

TABLE V W HICH TESTED ALLOCATIONS MET EACH REQUIREMENT, BY OPERATION . (a) GEP policy participation, by allocation Allocation

Operations tested

Effect GEP duty prevented

Every edit

DeepSeek Harness rc.2 unless marked Approval in the same callback chain E Governance, E Tool Approval Enforce start; switch after a no no no policy-first start E Governance, E Edit Approval Enforce start / configuration yes / no yes / no yes / no (rc.8) change or switch Consent stage after policy E Governance, N consent after the chain

Conditions and obligations

Reachability loss: the approval question ends the chain before policy Reachability loss: a configuration change re-registers the changed plugin last

Observe start / switch

– / yes

– / yes

yes / yes

Read-only mode, tested file edits. No earlier callback ends the chain. Allowed edits need wider permission

Enforce start; switch Observe start / switch, approval-plugin reapplication

yes – / yes

yes – / yes

yes yes / yes

Competing prepends untested Private field. From code, withheld readiness disables both plugins

Delegating approval E AgentGuard, delegating branch

Observe start, disable and enable / switch

– / yes

– / yes

yes / yes

From code, AgentGuard’s own denial ends the chain before policy

Repairs for one operation S in-place update S volatile-mode variant* S single-module Governance

Switch / enforce start Switch / observe start Observe start / switch

yes / no yes / – – / no

yes / no yes / – – / no

yes / no yes / no yes / no

Held at one operation, lost at the other (reachability) As above As above

Policy after the chain S wrapper around dispatch

Switch

yes

yes

no

Reachability loss: two rejected edits never reached policy

Eligibility loss: abstains on already-allowed requests, as documented The configuration-denied edit never reaches the stage. The variant asks again

Policy-first order S prepended registration S readiness dependency*

OpenCode 2.2.5 Policy in the permission stage E Permission Reviewer

Start, reload / saved allow rule S eligibility-only variant; S stage Saved allow rule provider*

yes / no

yes / no

yes / no

yes

yes

no

yes yes yes

yes yes yes

yes yes yes

Policy before the tool body S check before the tool body* E published ACP S ACP with a renewed question

Saved allow rule Saved allow rule Saved allow rule

Relationship: requirement

Held

GEP local hook rule, Claude Code

Hookify: every tested Bash None observed call after a saved allow rule

Vendor hook plugin; rule saved by a study handler. A native deny rule alone gives effect prevention only

GEP decision information: reapplication and compaction

State outside the instance Labels in the instance: (Table IV). Pi plan mode, reapplication (lifetime). Airlock: an analogue: reload, resume tail (interpretation)

Compatible source records. Registered representation* : synchronous, pure updates (from code), which the study requires not to throw

AC response applied: before progression

Per-call review: all nine workflows, normal and direct routes

Batched review: direct route (reachability)

Documented limits on middleware order, resumption and answers covering several calls

AC completed work: none repeated

Per-call tasks: resumption

Study grouped node: resumption (lifetime)

A saved boundary that resumption reuses

Blackboard membership: exclusion until re-enrolment

Study repair of lookup and status: restart and running lookup, on two releases

Ensemble: running lookup (lifetime)

Two changes tested together. If resumption re-enrols, Ensemble’s delivery is correct

Restorations (GEP, Blackboard)

Disable and enable, revoke (OpenCode), remove and restore (Ensemble)

The next switch undid disable and enable (reachability)

Tested between calls. Re-check after relevant operations

Escalations become denials An escalated edit runs without a renewed question Escalations are asked again

(b) Other hosts and relationships Lost (carrier question)

Conditions and obligations

N native, E external, S study-built. In enforce mode the requirements nest (Section II). Yes: the assessed actions met the requirement under the listed operations and conditions. The GEP-duty column covers policy participation and enforcement of prohibitions, and conditions report escalation handling. Slashes follow the listed operation order. At observe starts only evaluation is assessed, so effect and GEP-duty cells are dashed. Carrier questions classify observed losses. Counts: Table III, Sections IV–VI. * Analysis corrected after collection on unchanged records (Section III).

LangChain’s batched review asks about a model turn’s calls together and records a rejection only as a message. The default router then withholds the rejected call on the normal route to the tool node, the graph step that runs tools. Per-call review applies the response where the call executes, before its effect. Both review modes held on the normal route. A direct route to the tool node, which LangChain middleware can request, skips the router, as a user-reported issue records [41], and a study middleware took it before or after review. Per-call review held in all nine of its workflows, six of them on the direct route. Batched review violated the requirement in four of the six direct-route workflows: three calls executed before any question when the middleware jumped before review, and one executed after its delivered rejection. Deep Agents’ approval option builds batched review and reproduced the execution after a delivered rejection in both its processes. This is a composition loss: a decision protects only the routes that consult it. Pending requests survived where their continuation state did. On Deep Agents, graph recreation with the same checkpoint store and thread kept the pending call, and its matching response then applied. An empty store lost the pending work, and an approval for the original request, sent on another thread, left both threads’ requests pending. On OpenCode the server kept a pending request across client reattachment. Resumption avoided repeating completed work where each result was saved. In a programmed Deep Agents maintenance task built from Airlock’s source and tests, each pending edit followed its matching approval or rejection. Ordinary per-call tasks, which run each tool call separately, save each completed result, so resumption did not repeat a completed configuration edit, and after approval the project passed all 390 upstream tests. A study-built node grouped the completed edit with the pending one, an arrangement LangGraph’s documentation warns against [42]. Resumption repeated the completed edit after either reply. After approval the duplicate change prevented compilation. The same stored status preceded opposite membership decisions. The board plugin documents that its lookup returns only members that have not shut down [29]. From code, its running lookup reads a member cache with no expiry, whereas after re-initialisation a check of stored status decides. Membership thus has two sources of truth, although no runtime trace shows which lookup ran. In each of two matched pairs, the prerequisite board calls and arguments matched by role, and both runs stored the member as shut down. Only one run per pair then re-initialised the plugin: by restart, or by removing and restoring it through native configuration in the same host process. Without re-initialisation, the shut-down member’s read delivered the new item into its next model request. After re-initialisation, the read was refused and the item appeared in neither the tool result nor that request. The continuing member received the item in both arms. Under the study requirement that re-enrolment must be explicit, the running lookup violates both the provider promise and the deployment requirement. If a resumed prompt instead re-enrols the member, delivery is correct and refusal after re-

initialisation blocks the expected resumption. A study repair kept the exclusion in the running process and across a restart on two plugin releases. It makes the running lookup also check stored status and keeps a shut-down member shut down when its status updates. We tested both changes together. VII. S YNTHESIS ACROSS CASES RQ1: allocations and carriers. Responsibility for a relationship and control of its carrier could lie in different providers. The host controlled registration, reapplication, permissions and history format in the principal-case losses, while the board plugin controlled its own member cache. Connector order or position carried policy participation and AC review. Retained state carried decision information, completed work and membership, and saved consent decided reviewer eligibility. The saved-rule loss occurred while Permission Reviewer followed its documented eligibility rule, so a provider can meet its promise while the allocation fails a stronger requirement. RQ2: operations and mechanisms. Preservation depended on operational history and sequence. With the same plugins and final settings, different histories gave different policy coverage, and a restoration lasted only until the next switch. The decoder fix kept provenance through compaction but lost it at the next reapplication, so success under one operation does not establish preservation through a sequence. Supporting cases exposed carrier dependencies: a direct route skipped the router that applies the AC response, a grouped node repeated completed work and re-initialisation restored exclusion under the study’s explicit re-enrolment requirement. RQ3: allocations, conditions and trade-offs. The requirement determined which allocations were acceptable (Table V). Three reachability tactics preserved participation on DeepSeek Harness under their tested conditions: fixed policyfirst order, consent after the chain and delegating approval. Effect prevention and the GEP duty admitted allocations that missed edits rejected elsewhere, such as the wrapper around dispatch and wider eligibility on OpenCode, whereas the every-edit requirement excluded them. Evaluation alone did not determine escalation handling. The check before the tool body* denied escalations, while published ACP executed an escalated edit without a new question. The study ACP variant requested fresh consent. For decision information, state kept outside the plugin instance or rebuilt from the host’s history held through the tested sequences. Preserving allocations introduced different costs: wider permission requests under native consent, renewed questions from the eligibility-only variant, a private field for the readiness dependency and upstream test failures for reconstruction. Five carrier questions. From the cases we derive five overlapping questions for assessing an allocation: four concern carrier failures and one concerns control. Reachability: is the required decision reached before a covered action executes and, where every attempt must be evaluated, also for attempts that another provider ends? Its first part restates complete mediation for a chain of providers. Eligibility: does the provider act on every request state that the requirement covers? Lifetime:

does the state a decision reads stay available and current for as long as the decision needs it? It covers state transfer when an update replaces state needed by a later decision. Interpretation: do readers and writers agree on format and meaning? Disagreement is a form of architectural mismatch. Control: who sets or changes the carrier’s order, lifetime, consent state or representation, and is it the provider that relies on it? Implications. For architects, choosing an allocation means asking whether the operations in use can rewrite its carrier. In the DeepSeek Harness chain a terminal ask or allow skips any policy behind it, much like first-applicable combination [43] but under an undeclared order. Harness designers can declare precedence or dependencies instead. Deny-overrides, as among Kubernetes validating admission webhooks [44], prevents an effect when a reached policy prohibits it. If a callback chain is policy’s only path, evaluating every admitted attempt requires policy before any step that can end the chain. Pattern catalogues can name each relationship’s carrier and the operations that may rewrite it. Assessors need records joined per action, since task success, plugin health and effect checks alone do not show whether policy evaluated an attempt. VIII. R ELATED WORK Patterns and conformance. Conformance checking compares intended and implemented architecture [45]–[47], also through model-based tests and run-time checks [48], [49]. Pattern contracts and event-based monitors check patterns at runtime and during reconfiguration [21], [50]. AgentArcEval evaluates agent architectures using scenarios informed by stakeholder input [51]. Our comparisons exercise counterparts of two harness patterns that Barbaste et al. identify [3]: Middleware Pipeline (LangChain middleware and the tool callback chain) and Event Sourcing (state derived from the session log). Composition and agent controls. Zhang et al. find unsafe combinations of individually safe updates to harness components [22]. Cordis manages declared dependencies reactively [52]. Our callback-order losses arose between two baseline plugins that declare no dependency on each other. Quiescence [18] and state transformation [19] support dynamic reconfiguration. In our cases, reapplication discarded provenance held in the replaced instance without such transfer. Loopjacking tests how approval binds to the executed action [23], whereas our participation comparisons test whether operations keep policy reachable. Zheng and Yang specify assume–guarantee contracts that carry provenance and action binding across composed agent controls [24], and AGATE decides provenance-based authorisation in one deterministic core across DeepSeek Harness, OpenCode and OpenClaw [25]. Khan’s machine-checked resume contract forbids repeating an effect on the same branch, as tested by our completed-edit contrast [53]. Our contribution is empirical: among existing native services and independently written plugins, the same providers and final settings gave different policy coverage after different operation histories, and whether a repair held depended on the operation sequence.

IX. T HREATS TO VALIDITY Construct. Requirements, code readings and expectations were derived from the pattern sources, provider documentation and pinned code with AI assistance, and separate analyses checked consequential readings, bindings and judgments against source texts and native records [54]. Some requirements are study choices, such as the every-edit requirement, RiskProof’s carry-over and Blackboard’s explicit re-enrolment, and another choice changes which judgments hold, not the observed effects. The prohibited edits that executed after the switch and the saved-rule operation establish loss of the GEP duty as well as the every-edit requirement. The switch, nativeconsent and decoder-fix versus reconstruction comparisons provide evidence that depends neither on the RiskProof and registered-representation* cases nor on any corrected analysis. Internal. Operator responses were programmed throughout, as were model responses outside the live-model comparisons, which repeated four GEP losses and the native-consent preservation in the tested tasks. The original validation of joins from recorded fields alone used one shared clock and trajectories without repeated calls sharing session, tool and complete arguments. Starts through public operations alone, with no study code in the host, showed the startup loss in all 32 runs, two earlier starts and ten each with no added load, CPU load or direct I/O. Every operation in Table III except the “always” reply ran with no edit in flight, so the judgments concern operations between calls. External. The switch and composition with other providers are documented as intended practice [10], [35]. The purposively selected cases show that these losses and preserving allocations occur in pinned released assemblies, not how often (companion Section IX). Participation evidence rests on one DeepSeek Harness pair, extended by the transfer cases, two OpenCode policy providers and one Claude Code hook plugin. Chain-ending approval plugins cause the loss only for the tools they cover and when they run before policy. The studied DeepSeek Harness releases are developer previews, and on rc.5 the published plugin archives were staged directly. Later Deep Agents and LangChain releases were compared from code only. X. C ONCLUSION The study shows that required relationships can fail while all participating providers remain active. In the principal case, the same plugins and settings gave different policy coverage after different operational histories, and a repair that survived one operation failed at the next. Allocations that kept the required order, or kept or rebuilt the needed state, held on their tested paths and operation sequences, and preventing prohibited effects admitted more allocations than evaluating every admitted edit. Architects should identify each relationship’s carrier, who controls it and which operations can change it, then test the chosen allocation against the routes and operation sequences in use. Acknowledgements. Codex and Claude aided writing, coding and analysis. The authors checked and remain responsible.

R EFERENCES [1] Microsoft, “Agent harness,” Microsoft Learn, Agent Framework documentation, accessed Nov. 4, 2026. [Online]. Available: https: //learn.microsoft.com/en-us/agent-framework/concepts/harness [2] Google Cloud, “What is an agent harness?” accessed Nov. 4, 2026. [Online]. Available: https://cloud.google.com/discover/agent-harness [3] 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:2609.00006v1, 2026. [Online]. Available: https://arxiv.org/abs/2609.00006v1 [4] J. Liu, X. Zhao, X. Shang, and Z. Shen, “Dive into Claude Code: The design space of today’s and future AI agent systems,” arXiv:2604.14228v3, 2026. [5] Australian Signals Directorate, “ASD releases new guidance on the agentic AI harnesses,” Australian Signals Directorate, release notice, published Sep. 11, 2026. Accessed Nov. 6, 2026. [Online]. Available: https://www.cyber.gov.au/news/asd-releases-newguidance-on-the-agentic-ai-harnesses [6] B. Xia, Y. Liu, Q. Lu, L. Zhu, D. Sejdinovic, and X. Xu, “AgentOps pattern catalogue: Architectural patterns for safe and observable operations of foundation model-based agents,” Information and Software Technology, vol. 200, 2026, art. no. 108307, doi: 10.1016/j.infsof.2026.108307. [7] Microsoft, “Memory system,” UFO3 documentation, commit a795552d976c, 2026. [Online]. Available: https://github.com/microsoft/ UFO/blob/a795552d976c4c019d7c2f778a0effb5cef7de6b/documents/ docs/infrastructure/agents/design/memory.md [8] H. P. Nii, “Part one: The blackboard model of problem solving and the evolution of blackboard architectures,” AI Magazine, vol. 7, no. 2, pp. 38–53, 1986, doi: 10.1609/aimag.v7i2.537. [9] DeepSeek AI, “DeepSeek Harness (dsh),” Historical release dshv0.1.0-rc.8 (tag target 141eb6fef83422698aef7a981029e843e8161534); npm package @deepseek-ai/dsh, versions 0.2.1-alpha.2, 0.2.1rc.2 and 0.2.1-rc.5, 2026, https://registry.npmjs.org/@deepseek-ai/dsh. [Online]. Available: https://github.com/deepseek-ai/deepseek-harness/ tree/141eb6fef83422698aef7a981029e843e8161534 [10] TapPass, “dsh-governance,” npm package @tappass/dsh-governance, version 0.2.1, commit ac9ccbc16ed2, 2026. [Online]. Available: https://github.com/tappass/dsh-governance [11] Il Harper, “dsh-tool-approval,” TypeScript source entry src/index.ts, version 0.1.0, rev. c01801a7e39c36515d8445747abff6a6388c1278, 2026. [Online]. Available: https://github.com/ilharp/dsh-tool-approval/ tree/c01801a7e39c36515d8445747abff6a6388c1278 [12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [13] OpenCode, “OpenCode,” Versions 1.18.30, 1.19.3, 2.0.32 and 2.2.5, 2026. [Online]. Available: https://opencode.ai [14] Warc0s, “opencode-permission-reviewer,” Version 2.5.0, npm package, 2026. [Online]. Available: https://github.com/warc0s/opencodepermission-reviewer [15] J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,” Proc. IEEE, vol. 63, no. 9, pp. 1278–1308, 1975, doi: 10.1109/PROC.1975.9939. [16] M. Calder, M. Kolberg, E. H. Magill, and S. Reiff-Marganiec, “Feature interaction: a critical review and considered forecast,” Computer Networks, vol. 41, no. 1, pp. 115–141, 2003, doi: 10.1016/S13891286(02)00352-3. [17] R. Douence, P. Fradet, and M. Südholt, “Composition, reuse and interaction analysis of stateful aspects,” in Proc. AOSD, 2004, pp. 141– 150, doi: 10.1145/976270.976288. [18] J. Kramer and J. Magee, “The evolving philosophers problem: Dynamic change management,” IEEE Trans. Softw. Eng., vol. 16, no. 11, pp. 1293–1306, 1990, doi: 10.1109/32.60317. [19] C. M. Hayden, E. K. Smith, M. Denchev, M. Hicks, and J. S. Foster, “Kitsune: Efficient, general-purpose dynamic software updating for C,” in Proc. OOPSLA, 2012, pp. 249–264, doi: 10.1145/2384616.2384635. [20] D. Garlan, R. Allen, and J. Ockerbloom, “Architectural mismatch, or, why it’s hard to build systems out of existing parts,” in Proc. ICSE, 1995, pp. 179–185, doi: 10.1145/225014.225031. [21] C. Krieger, U. Breitenbücher, M. Falkenthal, F. Leymann, V. Yussupov, and U. Zdun, “Monitoring behavioral compliance with architectural patterns based on complex event processing,” in Proc. ESOCC, 2020, pp. 125–140, doi: 10.1007/978-3-030-44769-4_10.

[22] Z. Zhang, Z. Liu, W. I. Lai, H. Chen, and D. She, “Compositional safety failures in harness evolution: Identification and runtime monitoring,” arXiv:2609.33123v3, 2026. [23] A. A. Kumar, “Loopjacking: Hijacking human-in-the-loop approval,” arXiv:2609.21081v1, 2026. [24] C. Zheng and G. Yang, “CONTINUITY: Security-context contracts for composable LLM agent controls,” arXiv:2609.05269v1, 2026. [25] X. Zhang, Z. Cheng, K. Liu, Z. Sun, S. Fan, T. Yuan, B. Yuan, W. Qiang, and D. Zou, “AGATE: Provenance-based runtime defense against compositional attacks on LLM agents,” arXiv:2609.30830v1, Sep. 2026. [Online]. Available: https://arxiv.org/abs/2609.30830v1 [26] P. Runeson and M. Höst, “Guidelines for conducting and reporting case study research in software engineering,” Empirical Software Engineering, vol. 14, no. 2, pp. 131–164, 2009, doi: 10.1007/s10664-008-9102-8. [27] N. R. Mehta, N. Medvidovic, and S. Phadke, “Towards a taxonomy of software connectors,” in Proc. ICSE, 2000, pp. 178–187, doi: 10.1145/337180.337201. [28] Agentic Control Plane, “ACP plugin for OpenCode,” npm package @agenticcontrolplane/opencode, version 0.5.2, 2026. [Online]. Available: https://registry.npmjs.org/@agenticcontrolplane% 2Fopencode/0.5.2 [29] hueyexe, “opencode-ensemble,” Source version 0.19.0, commit 269207ebc612a6ccb37ad2188fb52c35e7787e5c, and npm release @hueyexe/opencode-ensemble 0.20.0, 2026, published package: https://registry.npmjs.org/@hueyexe/opencode-ensemble/0.20.0. [Online]. Available: https://github.com/hueyexe/opencode-ensemble/tree/ 269207ebc612a6ccb37ad2188fb52c35e7787e5c [30] LangChain, “Deep Agents,” Versions 0.7.13 and 0.7.28, 2026. [Online]. Available: https://github.com/langchain-ai/deepagents [31] Anthropic, “Claude Code: Hooks reference and configure permissions,” Claude Code documentation, consulted for CLI version 2.1.317, accessed Nov. 3, 2026. Permissions: https://code.claude.com/docs/en/ permissions. [Online]. Available: https://code.claude.com/docs/en/hooks [32] M. Zechner, “Pi coding agent,” npm package @earendil-works/picoding-agent, version 1.5.0, with its plan-mode example extension, 2026. [Online]. Available: https://github.com/earendil-works/pi [33] Intutic, “Intutic,” Preserved source revision 33b83a43fd08, 2026. [Online]. Available: https://github.com/intutic/intutic [34] SiriLee, “dsh-edit-approval,” Version 0.2.2, studied source revision e78df1981dcdea89437ed7384380235b8722053b; npm release gitHead d85ea8c0c1e41be46ec37d7e009c9878201d86f2, 2026. [Online]. Available: https://github.com/SiriLee/dsh-edit-approval/tree/ e78df1981dcdea89437ed7384380235b8722053b [35] GoPlus Security, “AgentGuard,” npm package @goplus/agentguard, prerelease version 1.1.29-beta.1, source revision 649e42ae2e15, 2026. [Online]. Available: https://github.com/GoPlusSecurity/agentguard [36] A. Balboa, “dsh-airlock,” Version 0.1.0, rev. c7b38d89d8fc3998bf60ddb14e91d86e6f0d0ab5, 2026. [Online]. Available: https://github.com/krimvp/dsh-airlock [37] RiskProof Contributors, “dsh-riskproof,” Version 0.2.0, rev. a084a1a3711c169279aa63e78d9de25ca18001a1, 2026. [Online]. Available: https://github.com/onlyqzq/dsh-riskproof [38] Anthropic, “hookify,” Claude Code plugin, version 0.1.1, commit a7ba5b93db0c, 2026. [Online]. Available: https://github.com/anthropics/ claude-plugins-official/tree/a7ba5b93db0c/plugins/hookify [39] gigi206, “opencode-guard,” GitHub repository, commit d446ab1, 2026, accessed Nov. 4, 2026. [Online]. Available: https://github.com/gigi206/ opencode-guard [40] garnus, “permissions: V2 “Always allow” silently overrides configured “ask” across future project sessions,” OpenCode, GitHub issue 48456, Sep. 11, 2026. [Online]. Available: https://github.com/anomalyco/ opencode/issues/48456 [41] Tardfyou, “langchain 1.4.0: any after_model middleware using documented jump_to="tools" bypasses the HITL pending_tool_calls gate and re-executes rejected tool calls,” LangChain, GitHub issue 40492, Sep. 16, 2026, accessed Oct. 19, 2026. [Online]. Available: https://github.com/langchain-ai/langchain/issues/40492 [42] LangChain, “Interrupts,” LangGraph documentation, 2026. [Online]. Available: https://docs.langchain.com/oss/python/langgraph/interrupts [43] OASIS, “eXtensible Access Control Markup Language (XACML) version 3.0,” OASIS Standard, Jan. 22, 2013. [Online]. Available: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html [44] The Kubernetes Authors, “Admission control in Kubernetes,” Kubernetes v1.32 documentation, last modified Feb. 23, 2025, accessed Oct.

23, 2026. [Online]. Available: https://v1-32.docs.kubernetes.io/docs/ reference/access-authn-authz/admission-controllers/ [45] G. C. Murphy, D. Notkin, and K. J. Sullivan, “Software reflexion models: Bridging the gap between design and implementation,” IEEE Trans. Softw. Eng., vol. 27, no. 4, pp. 364–380, 2001, doi: 10.1109/32.917525. [46] L. Passos, R. Terra, M. T. Valente, R. Diniz, and N. Mendonça, “Static architecture-conformance checking: An illustrative overview,” IEEE Software, vol. 27, no. 5, pp. 82–89, 2010, doi: 10.1109/MS.2009.117. [47] H. Yan, J. Aldrich, D. Garlan, R. Kazman, and B. Schmerl, “Discovering architectures from running systems: Lessons learned,” Carnegie Mellon University, Software Engineering Institute, Tech. Rep. CMU/SEI-2004TR-016, Dec. 2004, doi: 10.1184/R1/6573176.v1. [48] B. Uzun and B. Tekinerdogan, “Architecture conformance analysis using model-based testing: A case study approach,” Softw. Pract. Exper., vol. 49, no. 3, pp. 423–448, 2019, doi: 10.1002/spe.2667. [49] D. Ganesan, T. Keuler, and Y. Nishimura, “Architecture compliance checking at run-time,” Information and Software Technology, vol. 51, no. 11, pp. 1586–1600, 2009, doi: 10.1016/j.infsof.2009.06.007. [50] J. O. Hallstrom, N. Soundarajan, and B. Tyler, “Monitoring design pattern contracts,” in Proc. Workshop on Specification and Verification of Component-Based Systems (SAVCBS), 2004, pp. 87–94. [Online]. Available: https://www.cs.ucf.edu/~leavens/SAVCBS/ 2004/papers/Hallstrom-Soundarajan-Tyler.pdf [51] Q. Lu, D. Zhao, Y. Liu, H. Zhang, L. Zhu, X. Xu, A. Shi, T. Tan, and R. Kazman, “AgentArcEval: An architecture evaluation method for foundation model based agents,” arXiv:2510.21031v1, Oct. 2025. [52] Y. Shi, W. Zhang, and T. Cui, “A programming paradigm for spatiotemporal composability,” arXiv:2608.25512v1, 2026. [53] S. Khan, “Resume means resume: A machine-checked conformance contract for checkpoint, interrupt, and resume semantics in workflow persistence layers,” arXiv:2608.03836v1, 2026. [54] S. Baltes, F. Angermeir, C. Arora, M. Muñoz Barón, C. Chen, L. Böhme, F. Calefato, N. Ernst, D. Falessi, B. Fitzgerald, D. Fucci, J. He, C. Treude, M. Kalinowski, S. Lambiase, D. Russo, M. Lungu, C. Martinez Montes, L. Prechelt, P. Ralph, R. van Tonder, and S. Wagner, “Guidelines for empirical studies in software engineering involving large language models,” Empirical Software Engineering, vol. 32, 2027, art. no. 64, published online Nov. 3, 2026, doi: 10.1007/s10664-026-109223. Consulted preprint: arXiv:2508.15503v8.

Related documents

• Agent Memory Distillation: Empowering Small LLM Agents with Hierarchical Teacher Memory#440386
• SetupX: Can LLM Agents Learn from Past Failures in Functionality-Correct Code Repository Setup?#229578
• Can Coding Agents Migrate to Post-Quantum Cryptography?#1048538
• Retrofitting Code Using LLMs to Support Exceptional Behavior#673589
• IPGeoAI: Transformer-Based Geolocation with LLM Semantic Fusion#927837