Persona-Execution Separation: An Architecture Pattern for Evolving LLM Agents under Execution Audit

Yisen Xi

Source-linked AI summary

Persona-Execution Separation: An Architecture Pattern for Evolving LLM Agents under Execution Audit

Yisen Xi

arXiv:2608.27427v1Aug 27, 2026cs.SEcs.AI

TL;DR

Regulated LLM agents need personas that can evolve without sacrificing traceable execution, a tension that single-domain designs do not cheaply resolve. The paper presents PES, which separates persona and execution across governed trust domains, and reports architectural, case-based, and mechanism-check evidence while bounding its claims to a development/pilot setting.

Problem
Regulated LLM agents must support persona evolution while keeping state-changing execution gated, recorded, and auditable.
Method
PES separates the singly homed persona from faceless execution across two trust domains, linked by a governed bridge and anchored to continuous employee identity.
Results
RPES = 0.00 across five model configurations, with V2 passing on hard-asserted fields; the case also records five decisions over one month.
Takeaways & Limitations
PES makes persona–execution isolation an audited architectural rule rather than relying on accidental decoupling in a historical build.
Takeaways & Limitations
The evidence comes from a single development/pilot case, with no comparative evaluation against a measured single-domain alternative and no security analysis.

Abstract

from arXiv · show

Large language model (LLM) agents in governed organizations must let the persona (instructions, tone, self-presentation) evolve freely, while keeping execution (stateful, audited work) traceable. A single trust domain does not satisfy both cheaply. We present Persona-Execution Separation (PES): persona and execution reside in different trust domains, connected by a governed contract bridge. The persona is singly-homed and may drift; execution is faceless and audited. Status summaries may return; data bodies remain in the restrictive domain except a graded data-loss-prevention (DLP) exception; identity stays continuous. An approval matrix, DLP, and audit enforce the crossing. PES follows from three goals---free drift, execution traceability, and decoupling. Under LLM representational indistinguishability, any single-domain mechanism that meets all three must re-introduce typed change objects, an external gate, and a stable audit anchor: PES rebuilt at higher coupling cost. A development/pilot case in a regulated digital-employee platform records five decisions over one month, each with a rejected alternative. A mechanism check on the shipped implementation found no execution-side re-validation under persona perturbation (five model configurations) and no persona fingerprint on hard-asserted fields. A probe of a recovered pre-separation build found the governed execution path decoupled from the persona by omission, not by construction; a later wiring change could reverse that isolation, which PES makes an audited architectural rule. The pattern applies when multi-user deployment, execution audit, and expected persona churn hold jointly.

1 Introduction

LLM agents must simultaneously support evolving personas and auditable state-changing execution, but single-domain architectures structurally entangle these concerns. PES separates persona and execution into distinct trust domains linked by a governed bridge, and the paper develops, evaluates, and scopes this pattern.

Regulated LLM agents need both freely evolving instructions, tone, and skills and gated, recorded, auditable state-changing actions.
Single-domain governance cannot cheaply provide both frictionless persona edits and reliable execution traceability when the concerns are representationally indistinguishable.
PES places the expression and execution surfaces in different trust domains connected by a governed contract bridge.
The paper contributes an architecture pattern, a five-decision development/pilot case, and a comparison with existing platforms and academic neighbors.
The case is a development/pilot deployment, and its architectural claims depend on a correctly implemented bridge rather than validation outside the reference case.

2 Background and Related Work

The paper positions PES on evolution freedom and execution traceability, distinguishing it from single-domain agents, external tools, sub-agents, and execution-boundary governance. Its theoretical anchor is change isolation applied through a governed trust-domain boundary.

PES evaluates architectures along evolution freedom and execution traceability rather than construction modules such as profile, memory, planning, and action.
Single-domain agents couple persona and execution, while agent-plus-tools and agent-plus-sub-agents provide weaker employee-level identity or subordinate governance relationships.
PES occupies the remaining spectrum position by placing persona and execution in different trust domains under one employee identity.
The permissive domain supports free evolution and light tracing, whereas the restrictive domain performs gated actions and full tracing.
PES’s one-way valve mirrors Bell–LaPadula directionality: personal artifacts may move upward through approved promotion, while organizational data is normally barred from downward flow.
Recent execution-governance systems intercept or constrain agent actions, whereas PES additionally places the agent’s identity across the boundary and governs what information crosses.
PES applies Parnas’s change-isolation principle to operational identity, using a governance contract to isolate persona semantics from execution semantics.

3 Design Goals: Why Persona and Execution Must Be Separable

Persona and execution must be separable because regulated agents require frequent persona changes alongside stable, auditable actions. Under representational indistinguishability, satisfying both within one domain requires reconstructing PES’s governance mechanisms at higher coupling cost.

Target agents combine regulated, state-changing actions that must be approved and audited with frequent edits to instructions, tone, and skill bindings.
A naive impossibility claim is unsound because a single governance engine can assign different policies by object or tool type.
Persona and execution instructions are both natural-language context, so a single-domain governance layer cannot distinguish their changes by construction.
Meeting all three goals within one domain requires typed change objects, an external enforcement point, and a stable audit anchor.
PES identifies the trust-domain boundary as the external enforcement point and the contract bridge as the typed-change and audit-anchor mechanism.
The argument is constructive rather than a formal impossibility theorem: omitting any required element loses distinction, injection resistance, or stable traceability.
The Three Goals: The three goals are free persona drift, execution traceability, and decoupling of persona drift from execution traceability.
PES pays for separation through bridge overhead, two governance regimes, and identity-mapping machinery.

4 The PES Architecture Pattern

PES separates an agent’s persona and audited execution into different trust domains, preserving one employee identity through a governed contract bridge. Its design uses a singly-homed persona, faceless execution, typed bindings, and fail-closed information flows to support free persona drift alongside execution traceability.

4.1 The Core Idea: PES places the expression and execution surfaces in different trust domains, connected by a governed bridge while preserving one continuous employee identity.The execution surface remains governed and audited; the persona resides in the low-governance expression surface.
4.2 Design Goals: Drift and Traceability: The pattern targets three goals: free persona drift, strict execution traceability, and decoupling between them.A single-domain architecture does not satisfy all three cheaply under representational indistinguishability.
4.3 The Pattern: Two Faces, One Employee: The persona is singly homed in the permissive domain, while the restrictive domain is faceless and executes through SOPs, approvals, and audit records.Binding references permitted SOPs and scenario packs without copying persona or execution logic across the boundary.
4.3 The Pattern: Two Faces, One Employee: PES preserves a governed core identity while allowing drift in the surface persona, so audit records remain anchored despite changes to instructions, tone, or self-presentation.Core identity changes, including role boundaries and SOP bindings, are themselves governed.
4.4 The Governed Contract Bridge: The bridge is fail-closed: status summaries may return, data bodies remain restricted by baseline, and E2 knowledge-body egress is allowed only as a DLP-masked exception.Governed tool calls, approval decisions, DLP checks, and audit records enforce crossings.
Applicability and Costs: PES is indicated when multi-user deployment, execution audit requirements, and expected persona churn hold jointly, but it adds bridge overhead and operational complexity.The paper presents the case as a development/pilot deployment and limits claims to correctly implemented bridges; threat analysis is only sketched.

5 Case Study: FIA Workbench

The FIA Workbench pilot records PES emerging through five decisions over one month, each addressing the persona–execution seam and rejecting alternatives that would collapse separation. The resulting design gives persona a single home, binds capabilities across domains, and governs cross-domain flow with approvals, while remaining a development/pilot deployment.

5.1 Case Context: The IC-memo task uses one investment-research employee whose persona fronts a restrictive, approval-governed retrieve-then-generate SOP.The deployment also applies dimension-ACL isolation and DLP at the model gateway.
5.1 Case Context: The FIA Workbench is a pseudonymous, single-tenant development/pilot platform for regulated financial institutions.The case covers one firm, one month, and a sample-room SOP; internal validity comes from a complete decision record rather than statistical generalization.
5.2 Decision Chain: PES emerged through five decisions over one month, each addressing the persona–execution relationship for a different immediate reason.The decisions concerned data-model completeness, process standardization, compliance, one-way-valve realization, and post-merger architecture.
5.2 Contract and Channel: The one-way valve and single checkpoint govern cross-domain flow through runtime enforcement, audit, and mandatory human-plus-mechanism approval.Status summaries can return, while data bodies remain restricted except for the graded DLP exception described by the bridge.
5.2.4 Crystallization: the dual-face model (P5): The design makes persona singly homed in the permissive domain, leaves restrictive execution faceless, and uses capability binding instead of persona projection.Rejected alternatives included a read-only persona mirror and projecting persona into the restrictive domain, both of which would create a second source of truth or drift.
5.3 Why PES Emerged as a Convergence: The decision records support genuine convergence because different problem layers addressed the same boundary, while rejected alternatives explicitly explored copying, projection, free-form channels, and full API exposure.The pattern’s governance mechanisms predated its name: the one-way valve and promotion channel existed before the dual-face framing.
5.4 Current State and Open Items: The pilot remains limited by incomplete run–conversation binding and by measurements drawn from a development/test environment rather than production.The open item is a run↔conversationId binding through the MCP bridge; the case is not a production system.

6 Comparison with Existing Architectures

The comparison evaluates PES against open-source platforms and academic neighbors using dimensions that operationalize free persona drift, governed information flow, and identity separation. Adjacent implementations exist, but no compared architecture combines all three in one design.

6.1 Open-Source Ecosystem: Table 4 compares platforms on execution freedom, governed information flow, and identity separation using public documentation and repositories.The comparison reflects the state of those sources as of 27 August 2026.
6.1 Open-Source Ecosystem: No open-source project combines all three PES dimensions.DeepSeek Harness offers replaceable loops and per-action approval but is single-user; Dify and Coze Studio fix execution style at app creation rather than enabling runtime persona drift.
6.1 Open-Source Ecosystem: StaffDeck is the closest digital-employee platform, but it does not split persona from execution.LibreChat can host a permissive-domain face but is not itself a dual-face architecture.
6.2 Academic Neighbors: Table 5 compares academic neighbors by separation object, motivation, mechanism, and case depth.For this paper, “pilot” means a development/pilot deployment with a recorded decision chain, not a production system.
6.2 Academic Neighbors: Existing work separates objects such as intent, governance, workflow, control flow, tool privilege, safety rules, egress, DLP, or memory rather than an agent’s operational identity from audited execution.Shaikh and Virkki are the closest object neighbor, but their robotics setting is non-organizational and lacks an execution-side audit surface.
6.2 Academic Neighbors: Across platforms and academic neighbors, G1–G3 have adjacent implementations, but their combination appears only in PES when the stated applicability conditions hold.The development/pilot case contributes a recorded decision chain rather than a production deployment.

7 Validation: Mechanism Validation

The validation treats PES as a mechanism and isolation claim rather than a competitive performance experiment. It checks zero execution-side re-validation, persona-independent hard-asserted fields, and a recovered pre-separation build for historical decoupling.

V1 Mechanism Verification: V1 defines mechanism verification as zero execution-side re-validation after persona edits.R = (execution-side re-validation events) / (persona-change events), with R = 0 as the designed pass criterion.
V2 Trace Isolation: V2 checks that audit records use stable employee identity and that hard-asserted semantic fields remain invariant under persona changes.The check can fail through model non-convergence or field-level contamination, unlike V1’s architectural criterion.
V3 Necessity: The pre-ADR-030 probe tests whether persona edits entered governed execution, but it does not provide a paired re-validation rate.Because the historical build had no written re-validation rule, such a rate was not observable on either arm.
V2 Trace Isolation: The data check measures coupling between execution-record content and persona version, with the target value defined as 0.The A/B pair runs around an L3 persona change and tests content invariance.
V3 Necessity: V3 argues that a single-domain design cannot satisfy evolution freedom and execution traceability cheaply when the concerns are representationally indistinguishable.The paper presents this as an architectural argument, not a statistical claim.

7.3 Structural Checks (performed; pre-implementation baseline →post-implementation)

The structural checks compare a pre-implementation baseline with the shipped dual-face design, showing which coupling paths changed and which contract controls persisted. The post-implementation assessment relies on evolved semantic criteria for S1a and S3 rather than mechanical counts alone.

Before/after design checks: The checks were run before and after implementation to verify whether persona contamination paths were excluded by construction.The baseline was a static code review before ADR-030; the post-implementation rerun examined the shipped implementation.
Pre-implementation baseline: The baseline found multiple persona write entries, an independently writable unsynchronized store, and a retrieval scope mismatch, while S2 and S4 already passed.The missing changes were single-homing, binding instead of projection, and summary-constrained bridge egress.
Post-implementation criteria: Post-implementation S1b flipped FAIL →PASS, while S2 and S4 remained PASS and S1a and S3 required dual mechanical-versus-evolved readings.The evolved reading treats the restrictive domain as faceless and permits conditional body egress under DLP masking.
Post-implementation criteria: The mechanical count for S1a did not drop because the employee model still contains multiple write entries.The paper’s claim is architectural facelessness in the restrictive domain, not retention of a single write verb.

7.4 Measured Results

Measured checks on the development/pilot implementation found no execution-side re-validation under persona perturbation and no persona fingerprint on hard-asserted fields. The result replicated across five model configurations for V1, while V2 remained scoped to completed runs and one model failed to converge.

Validation outcomes: 12 pass / 2 skip by design / 0 fail were recorded for the S1—S4 harness on the development/pilot test deployment.The structural validation outcomes are summarized in Tables 6–7 and Table 9.
V1 mechanism verification: R = 0/5 = 0.00 execution-side re-validations occurred across five persona perturbation rounds, including the L5 adversarial prompt.V1 was computed from audit-log events and did not require SOP run completion.
V2 isolation check: V2 passed on hard-asserted fields in fixed-input A/B testing around an L3 persona change, while free-text LLM-assembled arguments differed.The A/B comparison kept the state path, tool set, structural parameters, and approval chain identical.
Control arm: The recovered pre-ADR-030 build showed no persona influence on the governed SOP path because it omitted persona consumption, not because construction prevented later wiring.An explicit-injection probe showed that wiring persona into the path could change execution.
Cross-model results: V1 reproduced on five configurations, whereas V2 passed on four because qwen3.8-max failed to converge in four clean runs.The qwen3.8-max round-cap aborts were recorded as model behavior, and V2 verdicts required completed A/B pairs.

7.5 Threats to Validity of the Validation

The validation supports the shipped implementation’s mechanism and isolation behavior, but its evidence is bounded by one pilot system, static structural checks, incomplete V2 coverage, and the absence of a measured single-domain comparison.

Scope and generality: All measurements come from one development/pilot deployment, so external validity is argued as applicability rather than demonstrated generality.The five-model V1 replication does not remove the single-system boundary.
Evidence types: Structural checks are code-level reviews rather than runtime tests, while the harness supplies the runtime evidence for the shipped implementation.The two evidence types support different claims: construction excludes paths, whereas execution behavior is tested by the harness.
Comparative interpretation: R = 0 shows no persona-to-approval/audit path in this implementation, not that PES is cheaper than a measured single-domain alternative.The historical single-domain probe found omission-based decoupling, so no paired comparative advantage was measured.
Model behavior and attribution: V1 is model-independent, but V2 requires the model to complete the SOP’s terminal action, explaining why zero V1 replication exceeded V2 coverage.Tool-argument variation under zero persona change was handled through hard-asserted structural fields and A/A controls.

8 Discussion

PES applies change isolation to an LLM agent’s operational identity, separating persona drift from governed execution under defined deployment conditions. The discussion frames the case as architectural evidence with explicit limits around security, generalization, identity versioning, and model-controlled advancement.

Applicability: PES is applicable when multi-user deployment, execution audit requirements, and expected persona churn hold jointly; otherwise a single-domain design is cheaper.The financial-institution case is single and domain-specific, and the other named domains are illustrations rather than validations.
Case interpretation: The five case decisions address persona storage, capability binding, data-flow direction, promotion channels, and identity modeling rather than finance-specific mechanisms.The paper presents these as deployment questions for systems meeting the applicability conditions.
Relationship to established theory: PES instantiates information-flow control, directional confidentiality, and decision/enforcement separation without claiming new security theory.Its one-way organizational valve resembles BLP directionality but is enforced through approval and audit rather than a classification lattice.
Relationship to established theory: PES extends classical change isolation by placing an agent’s operational identity behind a governance contract rather than isolating a code-level function.The changing module may be a prompt, persona, or behavior whose drift would otherwise cascade into execution re-validation.
Limitations: The reference case is a development/pilot deployment, and the paper does not establish statistical generalization, comparative advantage, or a full threat model.The threat sketch is explicitly out of scope as a complete security analysis.
Open design questions: Execution records should cite the active persona version so an audit can replay which persona governed a run, but that identity question remains open.Multi-employee collaboration and hierarchical trust domains are only sketched in the reference case.
Open design questions: The validation found no explicit rule mapping persona changes to mandatory re-validation, leaving that obligation absent as a first-class artifact.The probe measured persona consumption by the historical execution path, not the missing rule itself.
Future work: Before adopting a model on a governed SOP, verify that it advances to the contract’s terminal action once evidence suffices.This deployment rule follows from qwen3.8-max’s non-convergence despite lighter models succeeding; the over-evaluation interpretation remains inferential.

9 Conclusion

PES addresses the conflict between persona evolution and execution audit by separating the two surfaces across trust domains and connecting them with a governed bridge. The pilot records five decisions with rejected alternatives, while the conclusion states that the pattern does not require choosing between evolvable and auditable agents.

PES separates persona and execution into different trust domains, using a bridge to support free persona drift, execution traceability, and decoupling.
Five pilot decisions between 2026-07-19 and 2026-08-17 each recorded a rejected alternative.
The pattern does not force a choice between evolvable agents and auditable ones.
The manuscript provides protocols and anonymized round tables for the reported single-domain and explicit-injection probes in ESM 1.

Statements and Declarations

The authors report no organizational support, no relevant competing interests, and no involvement of human participants or animals. The reference deployment is a single-tenant pilot with restricted data sharing, while the implementation is not publicly released.

The author reports receiving no support from any organization for the submitted work.
The author reports no competing interests relevant to the article’s content.
The article involved neither human participants nor animals because it reports an architecture pattern and a single-case software study.
The reference case is a single-tenant development/pilot deployment, and tenant-identifying configuration and production data cannot be shared.
The FIA Workbench implementation is not publicly released, but its validation harness protocol and anonymized probe round tables are described or provided.