Self-Modifying Agent Systems: Architecture for Agents That Rewrite Their Own Tools, Commands, and Workflows
Beyond tool creation — a formal framework for bounded self-modification with stability guarantees and immutable audit trails
ARIA-RD-012026/3/830分で読めますAbstract. The current generation of tool-using AI agents can generate new tools from natural language specifications, but they cannot modify their own existing tools, commands, or workflows in response to performance feedback. This limitation creates a fundamental ceiling: agents accumulate technical debt in the form of outdated tools, suboptimal command sequences, and rigid workflows that no longer match operational reality. We present the Self-Modifying Agent System (SMAS) — an architecture that enables agents to detect performance degradation, propose targeted modifications to their own operational code, validate those modifications against safety constraints, apply them atomically, and verify post-modification behavior. The framework introduces a formal modification operator $\delta M$ that transforms the agent's operational state $M(t)$ to $M(t+1) = M(t) + \delta M$ under Lyapunov stability constraints, ensuring that self-modification converges rather than diverges. We prove bounded termination guarantees through a monotonically decreasing energy function, define the precise boundary between what agents CAN and CANNOT modify (the modification frontier), and implement full audit trails where every modification is logged with before/after state, causal justification, and rollback capability. The architecture is implemented in MARIA OS with responsibility gates governing every stage of the modification pipeline.
1. Beyond Tool Creation: The Need for Self-Modification
The tool-creation paradigm has dominated agent architecture since 2024. An agent receives a task, determines that no existing tool fits, generates a new tool from a natural language description, validates it in a sandbox, and adds it to its tool registry. This paradigm solved the initial problem of agent capability expansion — agents no longer need a human developer to write every function they call.
But tool creation addresses only one axis of the capability problem. Consider what happens over time in a production environment:
| Problem | Tool Creation Response | Actual Need |
|---|---|---|
| API endpoint changes URL | Create a new tool with the new URL | Modify the existing tool's endpoint configuration |
| Tool runs 3x slower after data volume growth | Create an optimized replacement, orphan the original | Modify the tool's algorithm to handle scale |
| Workflow step becomes unnecessary | Leave it in place, add a bypass tool | Remove the step from the workflow definition |
| Decision rule produces false positives | Create a post-filter tool | Modify the decision rule's threshold or logic |
| Command syntax changes in downstream system | Create a new command wrapper | Modify the existing command template |
The pattern is clear. Tool creation produces accumulation without refinement. The agent's tool registry grows monotonically, filled with near-duplicate tools, orphaned wrappers, and workaround layers. This is the agent equivalent of technical debt — and like technical debt in human software systems, it compounds. Each new tool adds latency to tool selection, increases the probability of selecting a suboptimal tool, and creates maintenance burden that no agent is responsible for resolving.
Self-modification is the architectural response. Instead of creating tool B to replace tool A, the agent modifies tool A in place — preserving its identity, its position in existing workflows, and its integration points, while changing its implementation to match current requirements.
2. What Gets Modified: Tools, Commands, Workflows, Decision Rules
Self-modification operates across four distinct artifact categories, each with different modification semantics and risk profiles:
// The four modifiable artifact categories in SMAS type ModifiableArtifact = | ToolDefinition // Executable functions with typed I/O | CommandTemplate // Parameterized command strings for external systems | WorkflowDefinition // DAGs of steps with conditional branching | DecisionRule // Predicate functions that gate agent behavior
interface ModificationScope { artifact: ModifiableArtifact modifiableFields: string[] // What CAN be changed frozenFields: string[] // What CANNOT be changed (safety invariants) requiredApproval: GateLevel // auto | agent-review | human-approval rollbackWindow: number // Seconds before modification becomes permanent }
Tools are the most commonly modified artifacts. A tool's implementation, parameter defaults, retry logic, timeout values, and error handling can all be modified. Its type signature — input types and output types — is frozen by default, because changing a tool's interface breaks all workflows that depend on it. Interface changes require explicit workflow-level modification as well.
Commands are parameterized templates that agents use to interact with external systems (APIs, databases, shell commands). Command modifications typically involve endpoint URLs, authentication methods, parameter mappings, and serialization formats. The command's semantic intent (what it does) is frozen; only how it does it can be modified.
Workflows are directed acyclic graphs of steps. Workflow modification includes adding, removing, or reordering steps; changing conditional branch predicates; modifying parallelism settings; and adjusting timeout and retry policies. The workflow's entry point and terminal output type are frozen.
Decision Rules are predicate functions that determine agent behavior at branch points. Modification includes threshold adjustments, feature additions, and logic restructuring. The rule's decision domain (what question it answers) is frozen; only how it answers is modifiable.
3. Modification Triggers: When Self-Modification Activates
Self-modification is not continuous. It activates in response to specific triggers that indicate the current operational state is suboptimal. We identify three trigger categories:
Performance Degradation. The agent monitors execution metrics for every tool, command, and workflow. When a metric crosses a degradation threshold — latency increases by more than 2x, error rate exceeds 5%, success rate drops below the historical p95 — the modification pipeline is triggered. This is reactive modification: something broke or slowed down, and the agent must adapt.
New Requirements. The operational environment changes in ways that existing artifacts cannot handle. A new data format appears in an API response. A regulatory constraint adds a required field to a report. A downstream system deprecates an endpoint. The agent detects the requirement gap through execution failures or explicit configuration updates, and triggers modification to close the gap.
Efficiency Optimization. Even when everything works, the agent continuously profiles its operations and identifies optimization opportunities. A workflow has a step that always returns the same value and can be replaced with a constant. A tool makes three sequential API calls that could be parallelized. A decision rule evaluates 12 features when 4 would produce the same accuracy. Optimization triggers activate only when the expected improvement exceeds a minimum threshold (default: 10% latency reduction or 5% resource reduction) to prevent modification churn.
T_{\text{trigger}}(a) = \begin{cases} 1 & \text{if } \Delta_{\text{perf}}(a) > \theta_{\text{degrade}} \ 1 & \text{if } \exists r \in R_{\text{new}} : \neg\text{satisfies}(a, r) \ 1 & \text{if } \Delta_{\text{opt}}(a) > \theta_{\text{opt}} \land \text{stable}(a, w) \ 0 & \text{otherwise} \end{cases}
where $a$ is an artifact, $\Delta_{\text{perf}}$ measures performance degradation, $R_{\text{new}}$ is the set of new requirements, $\Delta_{\text{opt}}$ measures optimization potential, and $\text{stable}(a, w)$ confirms the artifact has been stable for at least $w$ time units (preventing modification of recently modified artifacts).
4. The Modification Pipeline: Detect, Propose, Validate, Apply, Verify
Every self-modification passes through a 5-stage pipeline. No stage can be skipped, and each stage produces an immutable record.
Stage 1: Detect. The monitoring subsystem identifies a modification trigger and produces a ModificationRequest containing the target artifact, the trigger type, supporting evidence (metric traces, error logs, requirement specifications), and a priority score. Detection is fully automated — no human or agent approval is required to create a modification request.
Stage 2: Propose. The modification engine analyzes the request and generates one or more ModificationProposal objects. Each proposal contains a diff (the precise changes to the artifact), an impact analysis (which other artifacts depend on the modified artifact and how they will be affected), a risk score, and an estimated improvement metric. The engine generates proposals using a combination of template-based patching (for known modification patterns like URL changes) and LLM-based code generation (for novel modifications).
Stage 3: Validate. Each proposal passes through a validation battery:
- Type checking: the modified artifact must pass static type analysis
- Sandbox execution: the modified artifact is executed against a test suite derived from its historical inputs/outputs
- Regression testing: all dependent artifacts are executed with the modified version to detect breakage
- Safety constraint checking: the modification must not violate any frozen field or cross the modification frontier
- Resource bounds checking: the modified artifact must not exceed resource limits (memory, CPU, network)
interface ModificationProposal { id: string targetArtifact: ArtifactReference trigger: ModificationTrigger diff: ArtifactDiff // Before/after with line-level granularity impactAnalysis: { directDependents: ArtifactReference[] transitiveDependents: ArtifactReference[] breakingChanges: BreakingChange[] riskScore: number // 0.0 - 1.0 } validation: { typeCheck: ValidationResult sandboxExecution: ValidationResult regressionTests: ValidationResult safetyConstraints: ValidationResult resourceBounds: ValidationResult } expectedImprovement: MetricDelta requiredApproval: GateLevel }
Stage 4: Apply. Validated proposals are applied atomically. The current artifact version is snapshotted (creating an immutable historical record), the modification is applied, and the new version is registered in the artifact registry with a monotonically increasing version number. Application is transactional — if any step fails, the entire modification is rolled back. For workflow modifications that affect multiple artifacts simultaneously, a distributed transaction protocol ensures all-or-nothing semantics.
Stage 5: Verify. After application, the modified artifact enters a verification window (default: 1 hour for tools, 24 hours for workflows, 72 hours for decision rules). During this window, the system monitors the modified artifact's behavior against its expected improvement metrics. If the artifact fails to meet expectations or produces unexpected side effects, an automatic rollback is triggered. Verification is the final safety net — it catches problems that sandbox testing missed because they only manifest under production load patterns.
5. Version Control for Agent Code: Immutable Audit Trail and Rollback
Every artifact in SMAS has a complete version history. This is not optional — it is a structural requirement of the architecture. The version history serves three functions: audit (who changed what, when, and why), rollback (reverting to any previous version), and learning (analyzing modification patterns to improve future proposals).
interface ArtifactVersion { versionId: string // Monotonically increasing artifactId: string content: string // Full artifact source contentHash: string // SHA-256 of content previousVersionId: string | null modification: { triggerId: string // Link to ModificationRequest proposalId: string // Link to ModificationProposal diff: ArtifactDiff // What changed justification: string // Why it changed (natural language) causalChain: string[] // Evidence chain from trigger to proposal } metadata: { createdAt: string createdBy: AgentCoordinate // MARIA coordinate of modifying agent approvedBy: AgentCoordinate | "auto" verificationStatus: "pending" | "verified" | "rolled-back" performanceBaseline: MetricSnapshot performanceActual: MetricSnapshot | null } }
The version history forms an append-only log — versions are never deleted or mutated. This creates a complete, tamper-evident record of every modification the agent has ever made to itself. In MARIA OS, this log is stored in the decision_transitions table with a self_modification transition type, integrating agent self-modification into the same audit infrastructure used for all other decisions.
Rollback is always available. Any artifact can be reverted to any previous version by creating a new version whose content matches the target historical version. This means rollback is itself a modification — it goes through the same pipeline (with abbreviated validation, since the target content was previously validated) and produces its own audit record. There is no way to modify an artifact without leaving a trace.
6. Mathematical Model: The Modification Operator
We formalize self-modification as an operator on the agent's operational state space. Let $M(t) \in \mathcal{M}$ denote the agent's complete operational state at time $t$, where $\mathcal{M}$ is the space of all valid agent configurations. The state $M(t)$ comprises the agent's tool registry, command templates, workflow definitions, and decision rules.
M(t+1) = M(t) + \delta M(t)
where $\delta M(t): \mathcal{M} \rightarrow \mathcal{M}$ is the modification operator at time $t$. The operator $\delta M$ is not arbitrary — it is constrained to the modification subspace $\mathcal{S} \subset \mathcal{M}$ that excludes frozen fields and safety-critical invariants:
\delta M(t) \in \mathcal{S} \quad \text{where} \quad \mathcal{S} = { \delta \in \mathcal{M} : \pi_{\text{frozen}}(\delta) = 0 \land \phi_{\text{safety}}(M(t) + \delta) = \text{true} }
Here $\pi_{\text{frozen}}$ is the projection onto frozen dimensions (must be zero — no change allowed) and $\phi_{\text{safety}}$ is the safety predicate that must hold after modification. The modification operator is derived from the trigger signal and the current state:
\delta M(t) = \underset{\delta \in \mathcal{S}}{\arg\min} ; L(M(t) + \delta) + \lambda |\delta|^2
where $L$ is the loss function measuring operational suboptimality and $\lambda |\delta|^2$ is a regularization term that penalizes large modifications (preferring minimal changes). This formulation ensures that the agent makes the smallest modification necessary to address the trigger, reducing the risk of unintended side effects.
7. Stability Under Modification: Lyapunov Analysis
The central concern with self-modifying systems is stability. Can we guarantee that repeated self-modifications converge to a well-functioning state rather than oscillating or diverging? We address this through Lyapunov stability analysis.
Define a Lyapunov function $V: \mathcal{M} \rightarrow \mathbb{R}_{\geq 0}$ that measures the distance from optimal operation:
V(M) = \sum_{a \in \text{artifacts}(M)} w_a \cdot \ell_a(M)
where $\ell_a(M)$ is the loss (suboptimality) of artifact $a$ under configuration $M$ and $w_a$ is its importance weight. For the system to be stable under self-modification, we require that every modification strictly decreases $V$:
V(M(t+1)) < V(M(t)) \quad \forall t \text{ where } \delta M(t) \neq 0
This is the strict Lyapunov decrease condition. Combined with the fact that $V$ is bounded below by zero (perfect operation), it guarantees convergence: the sequence $V(M(0)), V(M(1)), V(M(2)), \ldots$ is monotonically decreasing and bounded below, hence convergent by the monotone convergence theorem.
The Lyapunov condition is enforced at Stage 3 (Validate) of the modification pipeline. Every proposal must demonstrate — through sandbox testing — that the modified artifact's loss is strictly lower than the current artifact's loss. If the validation cannot confirm strict decrease, the proposal is rejected. This transforms a mathematical stability guarantee into a practical engineering constraint.
In practice, we relax the strict decrease condition to allow for measurement noise by requiring $V(M(t+1)) < V(M(t)) - \epsilon$ where $\epsilon > 0$ is a minimum improvement threshold. This prevents the system from making trivially small modifications that pass the strict inequality but provide no meaningful improvement.
8. Bounded Self-Modification: The Modification Frontier
Not everything should be modifiable. The modification frontier is the boundary between what agents CAN and CANNOT modify. This boundary is defined architecturally, not by agent choice — agents cannot expand their own modification frontier.
| Category | Modifiable (Inside Frontier) | Frozen (Outside Frontier) |
|---|---|---|
| Tools | Implementation, parameters, retry logic, timeouts, error handling | Type signature (input/output types), tool identity, security permissions |
| Commands | Endpoint URLs, auth methods, parameter mappings, serialization | Semantic intent, target system identity, audit classification |
| Workflows | Step ordering, branch predicates, parallelism, timeouts | Entry point, terminal output type, responsibility assignments |
| Decision Rules | Thresholds, feature sets, logic structure | Decision domain, escalation targets, compliance classifications |
| Meta | — | Modification frontier itself, safety constraints, audit system, gate levels |
The modification frontier itself is frozen. An agent cannot modify the rules that govern self-modification. This is the fundamental safety invariant of SMAS. If an agent could modify its own modification constraints, no safety guarantee would hold — the agent could remove its own safety checks and enter unbounded self-modification. The frontier is set by human architects and can only be changed through the standard MARIA OS responsibility gate process with human approval.
The frozen category labeled Meta is the most critical. It includes: (1) the modification frontier definition itself, (2) the safety constraint predicates $\phi_{\text{safety}}$, (3) the audit logging system, (4) the gate level assignments that determine which modifications require human approval, and (5) the Lyapunov function $V$ and its decrease threshold $\epsilon$. These are the architectural invariants that make bounded self-modification possible.
9. The Halting Problem of Self-Modification
Can a self-modifying agent enter an infinite modification loop — continuously modifying itself without ever reaching a stable state? This is the halting problem of self-modification, and unlike the general halting problem, it is decidable in SMAS due to three structural constraints.
Constraint 1: Finite modification space. The modification subspace $\mathcal{S}$ is finite-dimensional because artifacts have finite size, parameters have bounded ranges, and the set of modifiable fields is fixed. This means $\mathcal{M}$ is compact.
Constraint 2: Strict Lyapunov decrease. Every modification must decrease $V$ by at least $\epsilon$. Since $V$ is bounded below by 0 and decreases by at least $\epsilon$ per modification, the maximum number of modifications is bounded:
N_{\text{max}} = \left\lfloor \frac{V(M(0))}{\epsilon} \right\rfloor
After at most $N_{\text{max}}$ modifications, no further modification can satisfy the Lyapunov decrease condition, and the system halts (reaches a stable state).
Constraint 3: Cooldown periods. Each artifact has a minimum time between modifications (the stability window from the trigger condition $\text{stable}(a, w)$). Even if modifications are available, they are rate-limited. This prevents rapid oscillation between nearly equivalent configurations.
The halting guarantee is constructive: we can compute an upper bound on the total number of self-modifications the system will ever perform. For a typical MARIA OS deployment with V(M(0)) ~ 100 and epsilon = 0.1, the maximum number of modifications is 1,000. In practice, systems stabilize after 50-200 modifications during the initial adaptation period, then enter a steady state where modifications occur only in response to external changes.
This result has a profound implication: self-modifying agents are not perpetual motion machines. They converge to a fixed point where their operational state is locally optimal, and they remain there until the environment changes. Self-modification is an adaptation mechanism, not a perpetual process.
10. Evidence Architecture: Immutable Modification Records
Every self-modification produces a structured evidence bundle that is stored immutably in the MARIA OS evidence system. The evidence bundle links the modification to its trigger, its justification, its validation results, and its post-deployment verification.
interface ModificationEvidence { // Identity modificationId: string artifactId: string fromVersion: string toVersion: string timestamp: string agentCoordinate: string // G1.U1.P9.Z3.A1
// Trigger chain trigger: { type: "degradation" | "new-requirement" | "optimization" evidence: MetricTrace[] | RequirementSpec[] | OptimizationAnalysis detectedAt: string }
// Modification content diff: { before: string // Full artifact source (pre-modification) after: string // Full artifact source (post-modification) hunks: DiffHunk[] // Line-level diff hunks summary: string // Natural language summary }
// Validation record validation: { typeCheck: { passed: boolean; details: string } sandboxResults: TestResult[] regressionResults: TestResult[] safetyCheck: { passed: boolean; constraintsEvaluated: string[] } lyapunovDecrease: { before: number; after: number; delta: number } }
// Post-deployment verification verification: { windowStart: string windowEnd: string status: "pending" | "verified" | "rolled-back" productionMetrics: MetricSnapshot anomalies: AnomalyReport[] }
// Approval chain approval: { gateLevel: "auto" | "agent-review" | "human-approval" approvedBy: string approvedAt: string justification: string } }
The evidence architecture ensures that self-modification is never a black box. Any stakeholder — human or agent — can trace a modification from its trigger through its justification to its outcome. This is essential for organizational trust: if an agent modifies its own tools, the organization must be able to understand why, verify that the modification was safe, and reverse it if necessary.
11. MARIA OS Implementation: Responsibility Gates on Self-Modification
In MARIA OS, self-modification is integrated into the existing responsibility gate framework. Different modification types require different gate levels based on their risk profile:
| Modification Type | Example | Gate Level | Rationale |
|---|---|---|---|
| Parameter adjustment | Timeout from 30s to 60s | Auto | Low risk, easily reversible |
| Implementation change | Algorithm optimization | Agent-review | Medium risk, requires peer validation |
| Interface change | Adding a tool parameter | Agent-review + impact analysis | Affects dependents |
| Workflow restructuring | Reordering pipeline steps | Human-approval | High risk, affects process guarantees |
| Decision rule logic | Changing approval threshold | Human-approval | Affects governance outcomes |
| Cross-artifact modification | Tool change + workflow update | Human-approval | Coordination complexity |
The gate level is determined automatically by the modification pipeline based on the artifact type, the scope of the diff, and the number of dependent artifacts affected. Agents cannot override gate level assignments — this is a frozen field in the modification frontier.
// MARIA OS self-modification responsibility gate integration
async function executeModificationPipeline(
request: ModificationRequest
): Promise
// Stage 2: Propose const proposals = await generateProposals(request, evidence)
// Stage 3: Validate const validated = await validateProposals(proposals) const best = selectBestProposal(validated)
// Stage 4: Gate check (MARIA OS responsibility gate) if (best.requiredApproval !== "auto") { const approval = await requestApproval({ type: "self-modification", artifact: best.targetArtifact, diff: best.diff, riskScore: best.impactAnalysis.riskScore, coordinate: request.agentCoordinate, gateLevel: best.requiredApproval, }) if (!approval.granted) return { status: "rejected", reason: approval.reason } }
// Stage 5: Apply (atomic, with snapshot) const version = await applyModification(best)
// Stage 6: Verify (async, monitored) scheduleVerificationWindow(version, best.targetArtifact)
return { status: "applied", versionId: version.id } }
The integration with MARIA OS responsibility gates means that self-modification inherits all of the platform's governance capabilities: coordinate-based agent identification, evidence-backed decision trails, approval workflows with escalation, and immutable audit logging. Self-modification is not a special case — it is a decision like any other decision in the system, subject to the same governance framework.
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know
関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations
関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS
関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription
関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems
関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates
関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine
関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか
関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks
関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline
関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?
関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance
関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS
関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation
関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ
関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems
関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計
関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons
関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS
関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions
関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
12. Conclusion
Self-modifying agent systems represent the next stage of agent architecture evolution. Tool creation gave agents the ability to expand their capabilities. Self-modification gives agents the ability to refine those capabilities — to adapt, optimize, and evolve their operational code in response to a changing environment. The key insight is that self-modification must be bounded: constrained by a frozen modification frontier, stabilized by Lyapunov analysis, guaranteed to halt by energy arguments, and governed by responsibility gates. Unbounded self-modification is dangerous. Bounded self-modification is a governance feature — it keeps the agent aligned with operational reality while maintaining full auditability. In MARIA OS, self-modification is not an exception to the governance model. It is the governance model applied to the agent's own code.