Self-Extending Agent Architecture: Capability Gap Detection, Tool Synthesis, and Autonomous Evolution Under Governance Constraints

1. The Problem: Tool-Dependent Agents

Every major agent framework — LangChain, AutoGen, CrewAI, Semantic Kernel — shares a common architectural assumption: the agent's capabilities are defined by its tool bindings. An agent can search the web if it has a search tool. It can query a database if it has a SQL tool. It can send emails if it has an SMTP tool. The tool is the atomic unit of capability, and the agent's competence is the union of its tools.

This assumption creates three structural problems that limit the scalability of agent-driven operations:

Problem 1: The Capability Ceiling. An agent's maximum capability is bounded by the tools it was given at deployment time. No matter how intelligent the underlying LLM, no matter how sophisticated the reasoning chain, the agent cannot perform an action for which no tool exists. The gap between what the agent could reason about and what it can execute widens as the agent's reasoning capabilities improve faster than human engineers can build tools.

Problem 2: The Integration Bottleneck. Building, testing, and deploying new tools requires human engineering effort. Each tool must be designed with an appropriate interface, implemented with production-quality code, tested against edge cases, secured against injection attacks, and deployed into the agent runtime. This process takes days to weeks per tool, creating a queue of unmet agent capabilities that grows faster than engineering bandwidth can address.

Problem 3: The Context Loss. The human engineer who builds a tool operates at a distance from the agent's operational context. The agent knows exactly what data format it needs, what error handling is appropriate, what performance characteristics matter — but this context is lost in the translation to an engineering ticket. The resulting tool often requires multiple iterations of feedback between the agent operator and the tool builder, each iteration adding latency.

SEAA eliminates these problems by closing the loop: the agent that detects the gap is the same entity that synthesizes the tool to fill it.

2. Agent State Model

We formalize the agent's state at time t as a 4-tuple:

X_t = (C_t, T_t, M_t, R_t)

where each component captures a distinct dimension of the agent's operational identity:

C_t (Capability Set): The set of abstract capabilities the agent can perform at time t. Each capability c ∈ C_t is a typed function signature: c = (input_type, output_type, preconditions, postconditions). For example, a capability might be 'extract_tables_from_pdf: (PDF, TableSchema) → Table[]' with preconditions requiring a valid PDF and postconditions guaranteeing schema-conformant output.

T_t (Tool Registry): The set of concrete tool implementations bound to capabilities. Each tool τ ∈ T_t is a tuple (capability, implementation, version, metadata) where implementation is executable code and metadata includes performance benchmarks, security clearance level, and provenance (human-authored vs. agent-synthesized).

M_t (Operational Memory): The agent's accumulated context including past task executions, failure logs, synthesized tool histories, and learned heuristics about which capabilities are frequently needed in its operational domain.

R_t (Role Specification): The agent's assigned role within the MARIA OS coordinate system, defining its authority boundaries, escalation paths, and governance constraints. R_t determines which capabilities the agent is permitted to self-extend versus which require human approval.

// Agent State in MARIA OS
interface AgentState<T extends MARIACoordinate> {
  capabilities: CapabilitySet
  tools: ToolRegistry
  memory: OperationalMemory
  role: RoleSpec<T>
  coordinate: T  // e.g., G1.U2.P3.Z1.A5
}

interface CapabilitySet {
  entries: Map<CapabilityId, Capability>
  graph: CapabilityGraph  // dependency DAG
  index: CapabilityIndex  // fast lookup by input/output type
}

interface Capability {
  id: CapabilityId
  inputType: TypeSchema
  outputType: TypeSchema
  preconditions: Predicate[]
  postconditions: Predicate[]
  riskLevel: "low" | "medium" | "high" | "critical"
  source: "built-in" | "synthesized" | "shared"
}

3. Capability Gap Detection

When an agent receives a goal G_t, the first operation is to determine whether the current capability set is sufficient to achieve it. We formalize this as a coverage check:

\text{Coverage}(G_t, C_t) = \begin{cases} \text{true} & \text{if } \text{Required}(G_t) \subseteq C_t \\ \text{false} & \text{otherwise} \end{cases}

When coverage fails, the agent computes the capability gap — the minimal set of capabilities that must be added to achieve the goal:

\Delta C_t = \text{Required}(G_t) \setminus C_t

The Required function decomposes a goal into its constituent capability requirements through a recursive planning process. Given a goal G, the agent generates a plan — a directed acyclic graph of sub-tasks — and maps each sub-task to the capability needed to execute it. Any capability that appears in the plan but is absent from C_t contributes to the gap.

Gap detection operates on the Capability Graph, a directed acyclic graph where nodes are capabilities and edges represent dependencies. If capability c_1 depends on c_2, then c_2 must exist in C_t before c_1 can be used. This graph structure enables efficient gap analysis: when a capability is missing, the agent can trace the graph to find the minimal set of capabilities that must be synthesized, including transitive dependencies.

// Capability Gap Detection
function detectGap(
  goal: Goal,
  state: AgentState<MARIACoordinate>
): CapabilityGap {
  const plan = decompose(goal, state.memory)
  const required = new Set<CapabilityId>()

  for (const subtask of plan.topologicalOrder()) {
    const needed = matchCapability(subtask, state.capabilities.index)
    if (!needed) {
      required.add(inferCapabilitySpec(subtask))
    }
  }

  const missing = setDifference(required, state.capabilities.entries)
  const withDeps = expandDependencies(missing, state.capabilities.graph)

  return {
    missing: withDeps,
    synthesizable: withDeps.filter(c => c.riskLevel !== "critical"),
    requiresHuman: withDeps.filter(c => c.riskLevel === "critical"),
    estimatedEffort: estimateSynthesisTime(withDeps),
  }
}

The gap detection algorithm runs in O(|plan| + |C_t|) time, using the capability index for constant-time lookups by type signature. In practice, gap detection completes in under 200ms for agents with up to 10,000 registered capabilities.

4. Tool Synthesis Pipeline

Once a capability gap ΔC_t is identified, the agent enters the Tool Synthesis Pipeline — a four-stage process that transforms an abstract capability requirement into a validated, deployable tool:

\text{ToolSynth}(\Delta C_t) = \text{Register} \circ \text{Validate} \circ \text{Implement} \circ \text{Design}(\Delta C_t)

Stage 1: API Design. For each missing capability c ∈ ΔC_t, the agent generates a formal tool interface specification. This includes the function signature, input/output schemas (using JSON Schema), error types, idempotency guarantees, and resource requirements. The design stage leverages the agent's operational memory M_t to identify patterns from previously synthesized tools that solved similar problems.

Stage 2: Code Generation. The agent generates implementation code for the designed interface. The code generation process uses few-shot prompting with examples drawn from the agent's tool registry T_t — specifically, tools that operate on similar data types or in similar domains. The generated code includes inline documentation, type annotations, and structured error handling.

Stage 3: Validation. The generated tool is executed in a sandboxed environment against a battery of tests. The validation suite includes: (a) type conformance tests verifying input/output schemas, (b) behavioral tests using property-based testing to verify postconditions, (c) security scanning to detect injection vulnerabilities, filesystem access, or network calls outside permitted boundaries, (d) performance benchmarks measuring latency, memory usage, and CPU cost against configurable thresholds.

Stage 4: Registration. Tools that pass validation are hot-loaded into the OS runtime and registered in the agent's tool registry T_t. The capability graph is updated to reflect the new capability and its dependencies. Other agents in the same Zone or Planet can discover and request access to the new tool through the tool sharing protocol.

// Tool Synthesis Pipeline
async function synthesizeTool(
  gap: CapabilitySpec,
  state: AgentState<MARIACoordinate>
): Promise<SynthesisResult> {
  // Stage 1: Design
  const spec = await designToolInterface(gap, {
    existingTools: state.tools,
    memory: state.memory,
    roleConstraints: state.role.permittedDomains,
  })

  // Stage 2: Implement
  const impl = await generateImplementation(spec, {
    examples: findSimilarTools(state.tools, spec.inputType),
    language: "typescript",
    targetRuntime: "node22",
  })

  // Stage 3: Validate
  const validation = await validateInSandbox(impl, {
    typeTests: generateTypeTests(spec),
    propertyTests: generatePropertyTests(spec.postconditions),
    securityScan: true,
    maxExecutionTime: 5000,
    maxMemoryMB: 256,
    permittedNetworkHosts: state.role.networkWhitelist,
  })

  if (!validation.passed) {
    return { status: "failed", errors: validation.errors, retryable: true }
  }

  // Stage 4: Register
  const tool = await registerTool(impl, spec, {
    coordinate: state.coordinate,
    version: "1.0.0-synth",
    provenance: "agent-synthesized",
    validationReport: validation.report,
  })

  return { status: "registered", tool, capabilityId: gap.id }
}

5. The Self-Extension Equation

We now formalize the complete self-extension process as a composition of three operators acting on the agent state:

X_{t+1} = E_t \circ G_t \circ J_t(X_t)

where:

J_t (Judgment Operator): Evaluates the current goal against the agent's state to determine feasibility. J_t maps X_t to a judgment: execute (goal achievable with current capabilities), extend (capability gap detected, synthesis required), or escalate (gap exceeds agent's synthesis authority).

J_t: X_t \to \{\text{execute}, \text{extend}, \text{escalate}\}

G_t (Gap Resolution Operator): When J_t returns 'extend', G_t computes the capability gap and runs the synthesis pipeline. G_t maps the agent state to a new state with an expanded capability set and tool registry:

G_t(X_t) = (C_t \cup \Delta C_t^{\text{valid}}, \ T_t \cup \Delta T_t^{\text{valid}}, \ M_t', \ R_t)

where ΔC_t^valid and ΔT_t^valid are the validated capabilities and tools from the synthesis pipeline, and M_t' is the updated memory incorporating the synthesis experience.

E_t (Execution Operator): Executes the original goal using the (possibly extended) agent state, producing the final output and updating memory with execution results.

The composition E_t ∘ G_t ∘ J_t captures the complete self-extension lifecycle: judge whether extension is needed, extend if so, then execute. This composition is applied at every goal reception, making self-extension a continuous process rather than a discrete event.

6. Capability Evolution and Convergence

The self-extension process produces a trajectory of capability sets over time: C(0), C(1), C(2), ... We analyze the asymptotic properties of this trajectory.

Definition (Capability Evolution). At each time step, the capability set evolves according to:

C(t+1) = C(t) \cup \{\tau \mid \tau \in \text{ToolSynth}(\Delta C_t) \wedge \text{Valid}(\tau) = \text{true}\}

Since the evolution rule is a union with a non-negative set, we have |C(t+1)| ≥ |C(t)| for all t. The capability set is monotonically non-decreasing.

Convergence. In any bounded operational domain D, the set of useful capabilities Required(D) is finite. Since |C(t)| is non-decreasing and bounded above by |Required(D)|, the sequence converges:

\lim_{t \to \infty} C(t) = C^* \quad \text{where} \quad C^* \supseteq \text{Required}(D)

The convergence rate depends on the tool synthesis success rate σ and the goal diversity rate δ (the rate at which new, gap-revealing goals arrive). Under assumptions of independent goal arrivals and constant synthesis success rate, the expected time to convergence is:

E[T_{\text{converge}}] = \frac{|\text{Required}(D) \setminus C(0)|}{\sigma \cdot \delta}

This means an agent that starts with 70% of required capabilities and has a synthesis success rate of 87% and receives one gap-revealing goal per hour will converge to full domain coverage in approximately 3.4 hours for a domain requiring 100 capabilities.

7. OS-Level Infrastructure

SEAA requires four infrastructure services from the operating system:

7.1 Tool Registry

A versioned, searchable catalog of all tools in the system. Each registry entry includes the tool's capability signature, implementation, provenance (human-authored or agent-synthesized), validation report, and usage statistics. The registry supports semantic search by capability description, type-based lookup by input/output schemas, and dependency queries for transitive closure computation.

7.2 Capability Graph

A system-wide directed acyclic graph representing all known capabilities and their dependencies. The graph is maintained by the OS and updated atomically when tools are registered or deprecated. Agents query the graph to detect gaps, find alternative capabilities, and plan synthesis strategies.

7.3 Validation Sandbox

An isolated execution environment for testing synthesized tools. The sandbox provides: a restricted filesystem with no access to production data, a network proxy that blocks all connections except whitelisted hosts, resource limits (CPU time, memory, disk), and a monitoring harness that captures all system calls for security review.

7.4 Evidence Log

An immutable, append-only log that records every self-extension event: the capability gap that triggered synthesis, the tool specification generated, the validation results, the registration decision, and (for high-risk tools) the human approval record. This log is critical for audit, enabling post-hoc review of how the agent's capabilities evolved.

// OS Infrastructure for SEAA
interface SEAAInfrastructure {
  registry: ToolRegistry
  graph: CapabilityGraph
  sandbox: ValidationSandbox
  evidence: EvidenceLog
}

interface ToolRegistry {
  register(tool: Tool, validation: ValidationReport): Promise<ToolId>
  search(query: CapabilityQuery): Promise<Tool[]>
  deprecate(toolId: ToolId, reason: string): Promise<void>
  getProvenance(toolId: ToolId): Promise<ToolProvenance>
}

interface ValidationSandbox {
  execute(code: string, tests: TestSuite, limits: ResourceLimits): Promise<ValidationResult>
  securityScan(code: string, policy: SecurityPolicy): Promise<SecurityReport>
}

interface EvidenceLog {
  recordGapDetection(gap: CapabilityGap, agentCoord: string): Promise<EvidenceId>
  recordSynthesis(spec: ToolSpec, result: SynthesisResult): Promise<EvidenceId>
  recordApproval(toolId: ToolId, approver: string, decision: "approved" | "rejected"): Promise<EvidenceId>
}

8. Multi-Agent Extension and Tool Sharing

In a multi-agent system, the total capability of the organization is the union of individual agent capabilities:

C_{\text{total}} = \bigcup_{i=1}^{N} C_i

When Agent A synthesizes a tool to fill its capability gap, that tool may also fill gaps for Agents B, C, and D operating in the same domain. SEAA implements a tool sharing protocol that propagates synthesized tools across the agent population:

Discovery: When an agent completes a synthesis, the OS broadcasts the new capability's signature to all agents within the same Planet (domain scope in the MARIA coordinate system). Agents can subscribe to capability notifications filtered by type or domain.

Compatibility Check: Before an agent imports a shared tool, the OS verifies that the tool's preconditions are satisfiable given the importing agent's state. This prevents tools from being imported into contexts where they would fail.

Adaptation: If a shared tool is almost compatible — matching in type but differing in some precondition — the importing agent can synthesize a lightweight adapter tool that transforms its local data format to match the shared tool's expectations.

C_{\text{total}}(t+1) = C_{\text{total}}(t) \cup \bigcup_{i} \text{Shared}_i(t) \cup \bigcup_{j} \text{Adapted}_j(t)

This sharing mechanism produces a superlinear growth in organizational capability: each synthesis event benefits multiple agents, so the organizational capability grows faster than the sum of individual agent synthesis rates.

9. Safety and Stability Architecture

Self-extending agents create a novel safety challenge: the agent's behavior at time t+1 may differ qualitatively from its behavior at time t because it now has capabilities it previously lacked. SEAA addresses this through three safety mechanisms:

9.1 Risk-Gated Synthesis

Every capability gap is assigned a risk score based on the capability's potential impact:

\text{Risk}(\tau) = w_1 \cdot \text{Scope}(\tau) + w_2 \cdot \text{Reversibility}(\tau) + w_3 \cdot \text{DataSensitivity}(\tau)

When Risk(τ) exceeds a configurable threshold θ, the synthesis pipeline pauses and escalates to a human approver. The agent presents the capability gap, the proposed tool specification, and the validation results, and the human decides whether to approve, modify, or reject the extension.

The risk threshold θ is not a single global value. It varies by agent role (R_t), organizational zone, and domain. A financial compliance agent operating in a regulated Zone has a lower θ than a data visualization agent in an internal analytics Zone. MARIA OS encodes these thresholds in the Role Specification.

9.2 Validation Gates

No synthesized tool enters the runtime without passing the validation suite. The validation gate is fail-closed: if any test fails, if the security scan raises any finding above 'informational' severity, or if performance benchmarks exceed resource limits, the tool is rejected. The agent may retry synthesis with modified parameters, but the gate never opens for an unvalidated tool.

9.3 Capability Rollback

Every tool registration is reversible. If a synthesized tool produces unexpected behavior in production (detected through output monitoring and anomaly detection), the OS can atomically remove the tool from the registry and revert the capability graph to its pre-extension state. The rollback is recorded in the evidence log with the triggering anomaly data.

10. Theorem: Capability Monotonicity

We now prove the central theoretical result of SEAA:

**Theorem (Capability Monotonicity).** Under the validation-gated self-extension protocol, the effective capability set of an agent is monotonically non-decreasing: for all t, |C_eff(t+1)| ≥ |C_eff(t)|, where C_eff(t) is the set of capabilities that have passed validation and are currently registered.

Proof. The evolution rule is C(t+1) = C(t) ∪ ΔC_t^valid. Since set union only adds elements and never removes them, |C(t+1)| ≥ |C(t)|.

The key subtlety is handling capability rollback (Section 9.3). When a tool is rolled back, its capability is removed from C_eff. However, the validation gate ensures that rollback occurs only for tools that exhibit post-deployment anomalies — a property that cannot be detected at synthesis time. We define C_eff(t) = C(t) \ C_rolled_back(t). Even with rollback, monotonicity holds in expectation if the anomaly rate α satisfies:

E[|C_{\text{eff}}(t+1)|] \geq E[|C_{\text{eff}}(t)|] \quad \text{iff} \quad \sigma \cdot \delta > \alpha

That is, as long as the rate of successful synthesis (σ · δ) exceeds the anomaly-driven rollback rate (α), the effective capability set grows in expectation. In practice, with σ = 0.87, δ = 1/hr, and observed α = 0.02/hr, the growth condition is satisfied by a factor of 43x. ∎

Corollary. The capability set converges to a stable fixed point C such that for all goals G in the operational domain, Required(G) ⊆ C. At convergence, the agent no longer needs to self-extend for routine operations, and the synthesis pipeline activates only when the operational domain itself changes.

11. Implementation in MARIA OS

SEAA is implemented as a core service within the MARIA OS decision pipeline. The implementation maps directly onto the MARIA coordinate system:

| Component | MARIA Coordinate | Responsibility |
|-----------|-----------------|----------------|
| Gap Detector | G1.U*.P*.Z*.A* | Every agent runs gap detection locally |
| Synthesis Engine | G1.U*.P9.Z3.A* | Centralized per-Universe in the R&D Planet |
| Validation Sandbox | G1.U*.P9.Z4.A* | Isolated sandbox per Planet |
| Tool Registry | G1.U*.P0.Z0.A0 | Universe-level singleton |
| Evidence Log | G1.U*.P0.Z0.A1 | Immutable audit at Universe level |
| Sharing Protocol | G1.U*.P*.Z0.A0 | Zone-level broadcast within Planet |

The architecture leverages MARIA OS's existing infrastructure: the Decision Pipeline manages the synthesis workflow as a decision with state transitions (proposed → validated → approved → executed → completed), the Evidence system records every synthesis event, and the Responsibility Gates enforce human approval for high-risk extensions.

// SEAA Integration with MARIA OS Decision Pipeline
async function handleGoalWithSelfExtension(
  goal: Goal,
  agent: AgentState<MARIACoordinate>,
  pipeline: DecisionPipeline,
  seaa: SEAAInfrastructure
): Promise<ExecutionResult> {
  // J_t: Judgment
  const gap = detectGap(goal, agent)

  if (gap.missing.size === 0) {
    // No gap — execute directly
    return execute(goal, agent)
  }

  // G_t: Gap Resolution
  for (const capability of gap.synthesizable) {
    const decision = await pipeline.create({
      type: "tool-synthesis",
      coordinate: agent.coordinate,
      payload: capability,
    })

    const result = await synthesizeTool(capability, agent)

    if (result.status === "registered") {
      await pipeline.transition(decision.id, "completed")
      await seaa.evidence.recordSynthesis(capability, result)
      agent.capabilities.entries.set(capability.id, capability)
    }
  }

  // Escalate critical gaps
  for (const capability of gap.requiresHuman) {
    await pipeline.create({
      type: "tool-synthesis-approval",
      coordinate: agent.coordinate,
      payload: capability,
      requiresApproval: true,
    })
  }

  // E_t: Execute with extended capabilities
  return execute(goal, agent)
}

11.1 Operational Results

In a pilot deployment across MARIA OS's Audit Universe (G1.U3), agents synthesized 47 tools over a 30-day period. Of these, 41 (87.2%) passed validation on the first attempt, 4 passed after one retry with modified parameters, and 2 were escalated to human approval. Zero synthesized tools were rolled back due to production anomalies. The agents' collective capability grew from 156 registered capabilities to 203, a 30% increase achieved with no human engineering effort beyond the 2 approval reviews.

The most impactful synthesized tool was an OCR extraction pipeline created by an Audit Agent (G1.U3.P2.Z1.A3) that needed to process scanned invoices in a format not supported by any existing tool. The agent detected the gap, synthesized a tool using an existing OCR library as a foundation, validated it against 500 test invoices, and registered it — all within 12 minutes. The same tool was subsequently shared to 6 other agents in the Audit Universe through the sharing protocol.

12. Conclusion

The Self-Extending Agent Architecture transforms agents from passive tool consumers into active capability builders. By formalizing the self-extension process as a composition of judgment, gap resolution, and execution operators — and by proving that the process preserves capability monotonicity under validation gates — SEAA provides a theoretically grounded, practically implementable framework for agents that grow with their operational demands. The key insight is that self-extension does not require unbounded autonomy: by embedding synthesis within the OS's governance infrastructure — risk-gated approvals, fail-closed validation, immutable evidence logs — agents can extend themselves while preserving the human authority that enterprise operations demand.

This research was conducted within MARIA OS's R&D Planet (G1.U1.P9). The Self-Extending Agent Architecture is available as an experimental feature in MARIA OS v2.4+. Contact the ARIA-RD team for access to the synthesis sandbox and capability graph APIs.