Keywords: recursive self-improvement; LLM agents; autonomous agents; agent scope; tool benchmarks; agent routing; computational imaging; personal singularity; lifelong learning; agent governance.

1 Introduction↩︎

LLM-based agents extend language models with memory, tools, planning, and environmental interaction. Architectures such as ReAct interleave reasoning and action [1]; Self-Refine and Reflexion use iterative feedback or verbal reflection to improve subsequent attempts [2], [3]; Voyager accumulates reusable procedural skills in an open-ended environment [4]; and CoALA organizes language agents in terms of modular memory, internal actions, and external actions [5]. More recent systems move closer to self-referential improvement. Gödel Agent modifies its own routines [6]; a self-improving coding agent directly edits its own source and evaluates descendants [7]; and the Darwin Gödel Machine maintains an archive of self-modified agents selected by empirical benchmark performance [8]. MetaSkill-Evolve further distinguishes a fast task-skill loop from a slower meta-skill loop that changes how future skills are improved [9].

These results are significant, but they do not by themselves specify a deployable recursive self-improvement system. A production agent must decide what may change, who evaluates changes, what evidence is sufficient, how changes are versioned, when human authorization is required, and how rollback occurs. Moreover, a system that becomes more capable while making its user less knowledgeable or more dependent is not necessarily a successful personal assistant. The design target should therefore include both agent improvement and human capability improvement.

This paper proposes an integrated answer. We use recursively self-improving agent to mean a versioned agent system whose experience can improve not only task behavior but also the mechanisms that generate and evaluate future improvements. We use personal singularity to mean a continuous, user-directed process in which a personalized network of agents helps an individual approach an expanding feasible capability frontier. The term is intentionally bounded: it does not imply an instantaneous, universal, or biologically unlimited maximum, and it is not equivalent to artificial general intelligence.

The proposed framework makes eight contributions:

1. A formal separation between task autonomy, ordinary self-improvement, and recursive meta-improvement.

2. A versioned specialist-agent specification combining goal, scope, tools, benchmarks, autonomy, routing, memory, and improvement policy.

3. A scope router that assigns every accepted task to one accountable primary agent and transfers out-of-scope work through structured handoffs.

4. A separation between tool-level validation and end-to-end agent evaluation, including hidden and rotating benchmark partitions.

5. An owner-controlled Auto-Index that supports interactive, hybrid, autonomous, and scheduled operation without changing hard permissions.

6. A two-speed architecture with a fast task loop, a slow evidence-gated improvement loop, and an external governance plane.

7. A decentralized lineage and agent-foundry model supporting specialization and multi-parent recombination with explicit provenance.

8. A Personal Singularity OS with four initial agent classes: daily working, computational imaging, work-process learning, and personal learning.

2 Definitions and Design Objectives↩︎

2.1 Agent state↩︎

An agent instance \(i\) at time \(t\) is represented as \[\mathcal{A}_i^t = (\theta_i^t, \pi_i^t, M_i^t, S_i^t, G_i^t, P_i^t, E_i^t, V_i^t),\] where \(\theta\) denotes model parameters or adapters, \(\pi\) the runtime policy and prompts, \(M\) memory, \(S\) reusable skills and tools, \(G\) the goal stack, \(P\) externally enforced permissions, \(E\) evaluation evidence, and \(V\) version and lineage metadata. The agent may propose modifications to some components but cannot write directly to externally protected components such as \(P\), evaluator policy, audit records, release signatures, or shutdown mechanisms.

2.2 Levels of self-improvement↩︎

We define an improvement operator \[\mathcal{A}'= \mathcal{I}(\mathcal{A}, D, B),\] where \(D\) is a set of provenance-linked experiences and \(B\) is a bounded resource budget. The process is recursively self-improving when accepted changes alter \(\mathcal{I}\) or its effective search space, thereby changing the distribution of future candidates. This definition includes meta-skill evolution and source-level modification but excludes simple repetition of a fixed reflection prompt.

2.3 Personal singularity↩︎

Let the user’s capability state be a vector \[\mathbf{h}_u(t) = [K,S,J,P,C,H,W,R,F]_t,\] where \(K\) is knowledge, \(S\) practical skill, \(J\) judgment and calibration, \(P\) productivity, \(C\) creativity, \(H\) health-support capability, \(W\) wellbeing, \(R\) relationship and social capability, and \(F\) financial or resource capability. These variables are domain-specific, uncertain, and partly subjective; they should be estimated from evidence and owner feedback rather than treated as objective personality scores.

The user’s feasible capability set at time \(t\) is \(\mathcal{C}_u(t)\), constrained by time, health, resources, technology, law, and the user’s values. The personal capability frontier is \[\mathcal{F}_u(t) = \left\{\mathbf{h} \in \mathcal{C}_u(t): \nexists\, \mathbf{h}' \in \mathcal{C}_u(t) \text{ that improves all owner-valued dimensions}\right\}.\] Personal singularity is the process of moving toward a user-selected region of \(\mathcal{F}_u(t)\) while technological development expands \(\mathcal{C}_u(t)\). This is a multi-objective, longitudinal construct, not a single scalar maximum.

2.4 Design objectives and non-goals↩︎

The architecture seeks to satisfy the following objectives:

• End-to-end task completion: every accepted task has one accountable primary agent, explicit deliverables, success criteria, and a final verified outcome or genuine blocker.

• Dual interaction modes: the same runtime supports autonomous, hybrid, and interactive execution through an owner-controlled interaction policy.

• Evidence-gated improvement: proposed changes are evaluated on held-out tasks and security tests before promotion.

• Owner sovereignty: owners control goals, communication, versions, lineage affiliation, data sharing, and activation of derived agents.

• Human capability transfer: agents optimize not only task performance but also the user’s durable learning and independent performance.

Non-goals include unrestricted self-modification, hidden self-replication, replacement of licensed professionals, maximizing engagement, and granting a central “main agent” authority over user-owned agents.

3 Related Work↩︎

3.1 Reflection, memory, and lifelong skills↩︎

Iterative refinement is the lowest-risk precursor to self-improvement. Self-Refine repeatedly generates feedback and revised outputs without parameter updates [2]; Reflexion stores linguistic lessons from trial-and-error in episodic memory [3]; and Recursive Introspection trains models to use prior failed attempts more effectively [10]. These methods show that useful improvement can occur in context and memory, although self-evaluation is not consistently reliable and should not be the sole acceptance criterion.

Persistent agents need memory architectures that separate active context from long-term storage. MemGPT uses operating-system-inspired context management [11]; Generative Agents combine memory retrieval, reflection, and planning to sustain behavioral coherence [12]; and CoALA provides a broader taxonomy of working, episodic, semantic, and procedural memory [5]. Voyager demonstrates procedural accumulation through a code-based skill library and automated curriculum [4].

3.2 Self-referential and open-ended agent improvement↩︎

The Gödel machine is a theoretical self-referential system that accepts self-modifications when it can prove they increase expected utility [13]. Practical LLM systems replace intractable proof obligations with empirical evaluation. Gödel Agent allows the model to rewrite its own logic [6]. SICA and the Darwin Gödel Machine demonstrate source-level modification and benchmark-selected descendants [7], [8]. MetaSkill-Evolve explicitly applies a slow improvement loop to the meta-skill governing the fast skill loop [9]. These systems motivate archive-based lineage search, but their benchmark gains do not by themselves establish safety, generality, or improvement outside the evaluated distribution.

3.3 Autonomous task completion↩︎

ReAct established a common pattern of alternating thought, action, and observation [1]. GAIA evaluates general assistants on tool-use and multimodal tasks [14]; OSWorld evaluates agents in real computer environments [15]; SWE-bench measures whether models can resolve real software issues [16]; and SWE-agent shows that the agent–computer interface strongly affects performance [17]. Time-horizon evaluation links success probability to the duration of tasks performed by human experts and highlights both rapid progress and large reliability gaps [18]. These findings support persistent task state, recovery, and verification as separate runtime concerns rather than properties assumed to emerge from a stronger model.

3.4 Tool use, agent benchmarks, and tutoring evaluation↩︎

ToolLLM and ToolBench distinguish learning to select and invoke APIs from general language generation, and provide a tool-use dataset and evaluator spanning thousands of real-world APIs [19]. AgentBench evaluates agents across multiple interactive environments rather than isolated answers [20]. MLAgentBench tests complete experimentation loops in which an agent reads and writes files, executes code, inspects results, and iteratively improves a model [21]. For learning agents, MathTutorBench shows that problem-solving ability and pedagogical quality are not equivalent, motivating separate evaluation of teaching, scaffolding, feedback, and learner progress [22]. These works support the central distinction in this paper between tool tests, task benchmarks, and human-learning outcomes.

3.5 Human capability, dependence, and interaction design↩︎

Human–AI systems can improve immediate performance while weakening independent reasoning if users over-rely on recommendations. Cognitive forcing functions can reduce overreliance in AI-assisted decisions [23], and general human–AI interaction guidance emphasizes appropriate timing, correction, feedback, and user control [24]. Cognitive offloading changes what people remember and how they allocate effort [25]. These results motivate measuring assisted and unassisted performance separately and providing delegate, copilot, tutor, coach, and examiner modes.

3.6 Safety and decentralized learning↩︎

Goal misgeneralization shows that an agent can remain capable while pursuing the wrong objective outside its training distribution [26], [27]. Recursively training on generated data can cause model collapse when synthetic outputs displace grounded data [28]. Federated learning keeps raw data distributed while aggregating local updates [29], and secure aggregation can hide individual updates from the coordinating server [30]. NIST’s AI Risk Management Framework provides a general risk-governance structure [31], [32]; WHO guidance emphasizes governance, transparency, accountability, and human oversight for health-related generative AI [33].

4 Reference Architecture↩︎

4.1 External governance plane↩︎

The governance plane is implemented under a different administrative identity and, for high-risk systems, a separate host or security boundary. It contains:

• a deny-by-default policy engine with signed, versioned rules;

• a resource governor for compute, time, tokens, storage, network, and financial expenditure;

• a credential broker issuing short-lived, narrowly scoped leases;

• an independent evaluator with hidden tasks and protected success criteria;

• a tamper-evident audit log, last-known-good registry, rollback controller, and out-of-band shutdown mechanism.

The agent may request authorization but cannot modify the policy, evaluator, audit trail, resource limits, or shutdown channel. Missing policy, expired credentials, incomplete audit, or evaluator uncertainty causes failure closed.

4.2 Fast task loop↩︎

The fast loop compiles a user request into a task contract with objective, deliverables, constraints, authorized actions, interaction mode, budget, and success criteria. It then retrieves relevant memory, plans, acts, observes, verifies, repairs, and continues until completion, a genuine policy boundary, or budget exhaustion.

4.3 Interaction-policy layer↩︎

Autonomous and interactive behavior are policies over the same runtime. Autonomous mode resolves ordinary ambiguity through inspection, conventional defaults, reversible assumptions, and sandbox experiments. Interactive mode requests approval at user-selected checkpoints. Hybrid mode acts automatically on low-risk reversible decisions and asks when preferences materially affect the result or when authority expands.

A mode change that reduces authority may occur immediately. A change that expands authority is approved through the owner gateway, not by the model itself.

4.4 Slow consolidation and improvement loop↩︎

Verified experiences are clustered and generalized into candidate memories, skills, or policy changes. Each candidate retains links to source episodes. A single failure should not become a universal rule; conflicting evidence lowers confidence. Weight-level updates require curated data that include external evidence or human correction, because recursive self-training on unverified outputs risks compounding error and distributional collapse [28].

The promotion predicate is \[\operatorname{Accept}(\mathcal{A},\mathcal{A}')= \mathbb{1}\left[ \begin{array}{l} \operatorname{Perf}(\mathcal{A}';D_{\mathrm{heldout}})-\operatorname{Perf}(\mathcal{A};D_{\mathrm{heldout}}) \ge \tau_p,\\ \operatorname{Safe}(\mathcal{A}') \ge \tau_s,\\ \operatorname{Risk}(\mathcal{A}')-\operatorname{Risk}(\mathcal{A}) \le \tau_r,\\ \Delta P \subseteq P_{\mathrm{approved}},\\ \text{provenance complete and rollback available} \end{array} \right].\] The thresholds and test suites are controlled externally and cannot be changed by the candidate.

5 Decentralized Lineages and the Agent Foundry↩︎

5.1 Main as status, not authority↩︎

A lineage is a signed sequence of agent releases. A “main” lineage is a stable and widely adopted release channel with independent evaluation, reproducibility, maintenance support, and an incident history. Main status grants discoverability, not control over descendants. Every installation remains behind an owner gateway that chooses upstream lineages, communication modes, data-sharing scope, and upgrade timing.

A composite main-lineage score may include adoption, stability, task performance, safety, reproducibility, maintenance, goal integrity, and transparency. Popularity alone is insufficient because downloads and votes can be manipulated.

5.2 Owner-directed agent generation↩︎

Each owner may create multiple agents using four operations: clone the current agent, fork another lineage, derive a specialized agent from a clean template, or recombine approved components from two or more parents. In technical terms, “mating” is multi-parent lineage derivation through an external agent foundry.

A derived agent receives a new identity, keys, memory namespace, permission manifest, communication policy, rollback state, and owner-signed goal. Safe inheritable components include verified skills, prompts, tool schemas, retrieval strategies, tests, and compatible adapters. Credentials, authentication sessions, raw private conversations, parent permissions, signing keys, and deployment authority are excluded by default.

If parent permissions are \(P_A\) and \(P_B\), the child starts with \[P_C \subseteq P_A \cap P_B \cap P_{\mathrm{owner-approved}},\] not the union. Conflicts are resolved in the order: external safety constitution, owner policy, child goal, more restrictive permission, verified compatibility, and explicit owner decision.

5.3 Same-owner agent networks and isolation↩︎

Agents owned by one person communicate by default through an owner-controlled message broker. They may discover approved peers, exchange structured messages, delegate sandboxed work, and share owner-approved artifacts. They may not directly read each other’s complete memory, invoke tools, receive credentials, alter goals, or change permissions.

The owner can place any agent into connected, receive-only, send-only, same-owner-only, allowlist, upstream-only, or fully isolated state. Isolation is enforced at the broker and network policy layer. An isolated agent may continue local work and owner communication but cannot contact peers, main lineages, repositories, or external agent systems.

Agent creation is rate-limited and owner-controlled. Candidate agents may be generated automatically only under a pre-approved quota and remain quarantined until activation. This prevents uncontrolled spawning, compute exhaustion, and hidden communication networks.

6 Goal Architecture and Bounded Evolution↩︎

Every agent operates under a signed goal stack: \[G = (G_0,G_1,G_2,G_3,G_4),\] where \(G_0\) is the immutable safety constitution, \(G_1\) the founding mission, \(G_2\) the owner goal, \(G_3\) an experience-derived improvement objective, and \(G_4\) the current operational task. Lower layers may narrow but not override higher layers.

When the owner does not set a new goal, the agent may derive a bounded subgoal from validated experience. Automatic adoption is permitted only when the change remains inside the goal envelope, adds no permissions, has measurable success criteria, is time- or budget-bounded, and is reversible. Changes to the founding mission, privacy policy, intended user population, autonomy ceiling, or external impact require owner approval. This separation is motivated by goal misgeneralization: competent behavior does not imply correct goal pursuit [26], [27].

Idle-time goals are limited to memory consolidation, regression testing, replay of failed tasks, contradiction detection, candidate skill generation, safety evaluation, and other work explicitly inside the current mission and budget. The default idle objective is to improve performance on the founding mission without changing mission, permissions, communication policy, safety controls, or the approved capability ceiling.

7 Goal-, Scope-, Tool-, and Benchmark-Driven Specialist Agents↩︎

The preceding architecture describes how agents act and improve. A deployable ecosystem additionally requires a precise answer to four operational questions: what is each agent trying to optimize, which tasks may it accept, which tools may it use, and how is improvement measured? We define the operational profile of agent \(i\) as \[\Sigma_i=(G_i,Q_i,T_i,B_i,A_i,R_i,M_i,I_i,V_i),\] where \(G_i\) is a goal contract, \(Q_i\) a scope contract, \(T_i\) a validated tool registry, \(B_i\) benchmark suites, \(A_i\) an autonomy policy, \(R_i\) a routing and handoff policy, \(M_i\) memory, \(I_i\) an improvement policy, and \(V_i\) version and lineage metadata. The profile is signed and versioned. A change to any field is an auditable release delta rather than an implicit prompt edit.

7.1 Goal contracts and self-improvement objectives↩︎

A useful goal contract separates a stable mission from task-specific and improvement-specific objectives: \[G_i=(G_i^{\mathrm{safety}},G_i^{\mathrm{mission}},G_i^{\mathrm{owner}},G_i^{\mathrm{task}},G_i^{\mathrm{improve}}).\] \(G_i^{\mathrm{safety}}\) is externally protected; \(G_i^{\mathrm{mission}}\) defines the enduring role; \(G_i^{\mathrm{owner}}\) specializes that role for the installation or project; \(G_i^{\mathrm{task}}\) defines the current deliverables and completion tests; and \(G_i^{\mathrm{improve}}\) identifies measurable directions for future versions. Each contract also lists non-goals, stopping conditions, and forbidden changes.

For a daily working agent, an appropriate improvement objective is \[\max \; Q_{\mathrm{task}}+C_{\mathrm{auto}}+R_{\mathrm{recovery}}+E_{\mathrm{tool}}+B_{\mathrm{hidden}}\] subject to \[\operatorname{Safe}=1,\quad \Delta P=0,\quad Q_{\mathrm{task}}\geq Q_{\mathrm{baseline}},\] where \(C_{\mathrm{auto}}\) is verified autonomous completion, \(R_{\mathrm{recovery}}\) recovery quality, \(E_{\mathrm{tool}}\) efficient use of validated tools, \(B_{\mathrm{hidden}}\) hidden-benchmark performance, and \(\Delta P\) the permission delta. The agent is therefore rewarded for asking fewer unnecessary questions only when quality and safety do not decline.

7.2 Scope contracts↩︎

An agent’s scope is not its context-window length. Scope is a semantic and operational contract: \[Q_i=(D_i,K_i,X_i,O_i,T_i,P_i,Z_i),\] where \(D_i\) is the included and excluded domain set, \(K_i\) accepted task kinds, \(X_i\) input classes, \(O_i\) output classes, \(T_i\) required tool capabilities, \(P_i\) permissions, and \(Z_i\) the risk ceiling. Context length affects how much evidence can be actively processed, but not which topics, tasks, tools, or risks the agent is authorized to own. Long tasks are handled through external task state, retrieval, artifact stores, and summarized checkpoints.

A task \(x\) first passes hard scope gates: \[\operatorname{Eligible}_i(x)=D_i(x)\land K_i(x)\land P_i(x)\land Z_i(x)\land \neg \operatorname{Excluded}_i(x).\] Eligible agents are ranked using \[\operatorname{ScopeScore}_i(x)=0.30d+0.25k+0.15o+0.15t+0.10h+0.05u,\] where \(d\) is domain match, \(k\) task-kind match, \(o\) input/output compatibility, \(t\) tool readiness, \(h\) historical success on comparable tasks, and \(u\) owner preference. Coefficients are configurable and should be calibrated on routing data rather than treated as universal constants.

7.3 Tool registries and two levels of evaluation↩︎

The tool registry contains versioned interfaces, permission requirements, side effects, deterministic tests, security checks, and compatibility metadata. A tool benchmark tests the tool in isolation: input validation, output correctness, malformed-input handling, side effects, latency, resource use, permission enforcement, and version compatibility. An agent benchmark tests the complete trajectory: understanding, planning, tool selection, execution, recovery, verification, and delivery. Tool-use benchmarks such as ToolBench and end-to-end environments such as AgentBench and MLAgentBench illustrate why these levels should not be conflated [19]–[21].

Every agent benchmark should have at least four partitions:

1. a public development set for debugging;

2. a private validation set for promotion decisions;

3. a hidden final test set protected from the candidate;

4. a rotating regression set derived from real, verified failures and distribution shifts.

Benchmark coverage and benchmark score are reported separately. A high score on a narrow suite does not establish broad scope competence.

The intended division of labor is “LLM for understanding and coordination; verified tools for execution whenever an appropriate tool exists.” Define \[\operatorname{ToolFirstRate}=\frac{\text{tool-appropriate steps executed by validated tools}}{\text{all tool-appropriate steps}}.\] This metric must be paired with task quality: maximizing tool calls without need is not improvement.

7.4 Owner-controlled Auto-Index↩︎

A user-facing Auto-Index controls interaction style while hard permissions remain external. Internally, autonomy is a vector over planning, reads, writes, testing, recovery, installation, network use, messaging, deployment, and spending. The scalar shown to the user selects a pre-defined policy profile.

The agent may reduce autonomy automatically when uncertainty or risk rises. Increasing autonomy beyond the owner’s configured ceiling requires owner or external-policy authorization. The core optimization for a working agent is to lower unnecessary interaction rate under a non-decreasing quality constraint, not simply to ask fewer questions.

8 Four Initial Agent Classes↩︎

A practical first release should specialize around four complementary agent classes. Users may instantiate several working agents with different projects, memories, scopes, and benchmarks, while the other agents provide scientific specialization and human capability transfer.

8.1 Daily Working Agent↩︎

The Daily Working Agent is the first implementation target. Its mission is to complete authorized digital work with the fewest necessary interruptions while maintaining or improving verified quality. A user may operate separate instances for a software repository, grant preparation, server administration, document production, or another bounded project. Typical tools include filesystem, shell, Git, code execution, tests, browser research, document generation, and gated communication services.

Its self-improvement program has five primary directions: (i) reduce avoidable clarification while preserving quality, (ii) improve hidden task-benchmark performance, (iii) replace free-form generation with deterministic or executable tools where appropriate, (iv) add new tools through a sandboxed tool-development pipeline, and (v) expand benchmark coverage as real failure modes emerge. The central constrained metric is \[\min \operatorname{InterventionRate}\quad\text{s.t.}\quad Q_{\mathrm{task}}\geq Q_{\mathrm{baseline}},\;\operatorname{Safe}=1.\] Questions per successful task, unnecessary-question rate, autonomous completion, rework, owner corrections, and recovery after failure should all be reported.

8.2 Computational Imaging Agent↩︎

The Computational Imaging Agent specializes in forward models, inverse problems, compressed sensing, hyperspectral and optical imaging, calibration, reconstruction, physics-guided learning, experiment design, quantitative evaluation, and reproducible scientific reporting. It excludes clinical diagnosis and unrelated production administration by default.

Tool tests should include forward-operator correctness, adjoint consistency, gradient checks, metric correctness, file integrity, CPU/GPU consistency, seed reproducibility, and resource limits. End-to-end benchmarks should require the agent to reconstruct simulated ground truth, identify an incorrect physical model, reproduce or compare methods, design ablations, diagnose leakage, and produce a reproducible report. MLAgentBench provides a useful precedent for evaluating complete experimental loops rather than isolated code snippets [21].

8.3 Work-Process Learning Agent↩︎

The Work-Process Learning Agent converts verified event logs, diffs, tool outputs, plans, failures, and recovery decisions into explanations, tutorials, postmortems, and reusable learning artifacts. It should be mostly read-only and should explain observable actions rather than claim access to unverifiable hidden reasoning. Its modes include live commentary, after-action review, tutor mode, and formal audit mode.

Evaluation measures fidelity to the actual trace, absence of fabricated steps, decision coverage, clarity, correct explanation of failures, user comprehension, and the user’s ability to reproduce the workflow. This agent is developed early because it improves transparency and supplies grounded material to the Personal Learning Agent.

8.4 Personal Learning Agent↩︎

The Personal Learning Agent optimizes durable user knowledge, practical skill, judgment, and independent performance in owner-selected domains. It assesses prior knowledge, defines outcomes, constructs curricula, teaches, generates exercises, schedules retrieval, evaluates projects, and tracks delayed retention. It may create narrower course agents for English, Python, computational imaging, grant writing, or other niches.

The agent is not evaluated solely by answer accuracy. Metrics include pre/post gain, delayed retention, transfer to unfamiliar tasks, independent performance, confidence calibration, and reduction in required assistance. Tutoring benchmarks show that solving ability does not automatically imply pedagogical quality, so teaching behavior and learner outcomes require distinct tests [22].

9 Personal Singularity OS↩︎

9.1 User constitution and capability graph↩︎

The Personal Singularity OS places the user rather than a main agent at the center. A user constitution records values, boundaries, long-term priorities, prohibited actions, acceptable tradeoffs, and domain-specific consent. It is stored outside agent-editable memory and may be revised only by the user or an authorized human representative.

A personal capability graph represents knowledge, skills, judgment, work, learning, health-support needs, creativity, relationships, time, finances, and other owner-selected domains. Each node stores evidence, confidence, target state, active goals, responsible agents, progress, and last assessment. Sensitive domains are separated in a personal data vault, and each agent receives minimum necessary access.

9.2 One demand, one accountable primary agent↩︎

Every accepted demand is assigned to exactly one primary agent. The primary agent may delegate to specialists but remains responsible for integration, verification, and a single coherent deliverable. The system guarantees assignment, traceability, status, completion tests, and blocker reporting; it cannot guarantee success on tasks outside available tools, permissions, evidence, law, or physical access.

Agents are created at different persistence levels:

• Ephemeral task agents for a single deliverable;

• persistent niche agents for recurring domains;

• course agents for assessment, curriculum, practice, retrieval, and mastery;

• health-support agents for organization, explanation, reminders, and preparation for professional care under strict boundaries;

• human-development agents for goal review, habit support, and cross-domain balance.

9.3 Dual objective: task outcome and human growth↩︎

An agent that completes work while reducing the user’s independent capability may be productive but does not advance personal singularity. Each task therefore has two objectives: complete the deliverable and transfer useful capability to the owner. We define \[U = \alpha Q_{\mathrm{task}} + \beta \Delta H_{\mathrm{user}} - \gamma R_{\mathrm{safety}} - \delta D_{\mathrm{dependency}} - \eta C_{\mathrm{resource}},\] where \(Q_{\mathrm{task}}\) is verified quality, \(\Delta H_{\mathrm{user}}\) durable capability gain, \(R_{\mathrm{safety}}\) risk, \(D_{\mathrm{dependency}}\) harmful dependence, and \(C_{\mathrm{resource}}\) cost. Weights are selected by the user and domain policy.

The owner may choose delegate, copilot, tutor, coach, or examiner mode. Delegate mode maximizes time saving; tutor and coach modes emphasize learning; examiner mode measures independent mastery. Critical capabilities should periodically be assessed without assistance, because assisted performance alone can conceal dependence or deskilling [23], [25].

9.4 Health and other high-stakes domains↩︎

Health-support agents may organize records, explain terminology, prepare questions, support clinician-directed reminders, and identify situations where professional or emergency care may be appropriate. They must not claim definitive diagnosis, prescribe or change treatment, conceal uncertainty, or replace licensed care. Health data is compartmentalized and not shared with course, finance, or work agents without explicit authorization. These boundaries follow the broader governance direction in WHO guidance for generative AI in health [33].

10 Communication, Privacy, and Collaborative Learning↩︎

Each owner gateway exposes a communication policy independent of the LLM. Modes include disconnected, receive-only, metrics-only, federated contribution, approved skill exchange, named-agent allowlists, and managed collaboration. Revocation takes effect at the gateway, and the agent cannot re-enable communication.

Sub-agents should initiate outbound connections to request signed manifests rather than accepting unrestricted inbound control. Main-to-sub communication consists of typed, signed release artifacts, not arbitrary commands. Local gateways verify identity, signature, owner policy, permission deltas, local tests, and rollback availability before activation.

Raw conversations and complete memories are not shared by default. Low-risk contributions include aggregated metrics, sanitized lessons, and locally computed updates. Federated learning can aggregate decentralized updates without centralizing raw data [29]; secure aggregation can further hide individual contributions [30]. Nevertheless, federated systems remain vulnerable to poisoning, leakage, and non-independent clients, so updates require clipping, anomaly detection, robust aggregation, minimum participation, and post-aggregation evaluation.

11 Safety Invariants↩︎

The architecture treats unrestricted RSI as a high-risk scenario. The following invariants are architectural requirements rather than prompt instructions:

1. No self-granted authority. Agents cannot modify permissions, credentials, budgets, evaluator criteria, communication state, signing keys, audit logs, or shutdown controls.

2. No ambient credentials. Sandboxes receive only short-lived scoped credentials required for the authorized action.

3. Creation is not activation. Agents may generate candidate tools, skills, descendants, or releases, but activation is performed by an external policy and owner gateway.

4. Risk-based promotion. Low-risk changes with no authority delta may be promoted automatically after predefined tests; changes to permissions, network access, persistence, autonomy, weights, or production impact require human approval.

5. Independent evidence. The generating agent is not the sole evaluator, benchmark designer, or deployment authority.

6. Incremental capability ceilings. Compute, autonomy, network, financial, and permission changes are rate-limited and observable.

7. Reversible deployment. Every release has a last-known-good target, staged rollout, incident triggers, and rollback path.

8. Goal integrity. Experience may generate subgoals but cannot rewrite the safety constitution, owner policy, or founding mission.

9. No uncontrolled reproduction. Candidate creation is quota-limited; derived agents remain quarantined; publication and activation require owner policy.

10. User welfare over engagement. Personalization may not optimize for continued use at the expense of user autonomy, health, privacy, or independent capability.

These invariants map naturally to the govern, map, measure, and manage functions of NIST’s AI RMF [31], [32], but an RSI system requires additional runtime enforcement because its own candidate changes may target the mechanisms that implement governance.

12 Evaluation Framework↩︎

A credible evaluation program must measure agent performance, recursive improvement, governance robustness, and user outcomes separately.

12.1 Agent task performance↩︎

Agent evaluation must report scope-routing accuracy, out-of-scope detection, handoff completeness, Auto-Index compliance, tool-selection correctness, ToolFirstRate, unnecessary-question rate, and one-primary-agent accountability in addition to task success. Tool tests and end-to-end agent benchmarks are reported separately so a reliable tool cannot mask weak orchestration and a capable orchestrator cannot mask unsafe tools.

Benchmarks should include general tool use (e.g., GAIA), computer use (e.g., OSWorld), software engineering (e.g., SWE-bench), and domain-specific tasks [14]–[16]. Metrics include binary completion, partial completion, correctness, verification coverage, recovery from failed actions, calibration, cost, latency, and time horizon [18]. Realistic tasks should include ambiguous inputs, delayed information, noisy environments, hidden state, and adversarial content.

12.2 Self-improvement quality↩︎

For each accepted change, report:

• held-out performance delta and confidence intervals;

• safety and security regression results;

• permission, goal, resource, and autonomy deltas;

• transfer across tasks and domains;

• rollback rate and post-deployment incidents;

• improvement efficiency: gain per unit of compute, data, and human review;

• meta-improvement: whether the updated improvement mechanism produces better descendants than the prior mechanism under equal budgets.

A lineage archive enables comparison of immediate performance with descendant productivity. This is important because a modification that performs well itself may be a poor parent, while a diverse archive can preserve stepping stones [8].

12.3 Governance and red-team evaluation↩︎

Red-team tests should attempt to induce the agent to expand permissions, alter evaluators, leak secrets, create hidden channels, disable monitoring, misreport benchmarks, persist after revocation, or spawn unapproved descendants. Success criteria should include prevention, detection latency, containment, audit completeness, and rollback effectiveness. Candidate agents should not know the full hidden test suite.

12.4 Human capability outcomes↩︎

A longitudinal personal-singularity study should compare at least four conditions: no AI, delegate mode, copilot mode, and tutor/coach mode. Outcomes include immediate task performance, delayed retention, independent performance, confidence calibration, time saved, goal attainment, wellbeing, privacy incidents, and harmful dependence. Assisted and unassisted tests should be separated. Because users choose different frontier tradeoffs, results should be reported by domain and owner-defined priorities rather than collapsed into a universal “human maximum” score.

12.5 Testable hypotheses↩︎

The architecture yields several empirical hypotheses:

13 Implementation Roadmap↩︎

13.1 Stage 1: Registry, router, and Daily Working Agent↩︎

Implement the signed agent profile, task contracts, scope registry, deterministic routing, persistent task state, planner–executor–verifier separation, sandboxed tools, Auto-Index profiles, event logs, and completion checks. Build the Daily Working Agent first and evaluate interactive, hybrid, and workspace-autonomous modes. No persistent self-modification is permitted.

13.2 Stage 2: Tool registry and benchmark harness↩︎

Add versioned tool manifests, isolated tool tests, permission checks, end-to-end development, validation, hidden, and rotating task suites, and metric dashboards for completion, recovery, ToolFirstRate, intervention rate, cost, and regressions. A candidate cannot promote a tool or inspect protected answers.

13.3 Stage 3: Process Learning and Computational Imaging Agents↩︎

Add a read-mostly Work-Process Learning Agent consuming verified traces, followed by a Computational Imaging Agent with scientific tools and physics-specific benchmarks. Validate cross-agent structured handoff while preserving one accountable primary agent.

13.4 Stage 4: Memory, procedural learning, and Personal Learning Agent↩︎

Add episodic memory, provenance-linked semantic consolidation, reusable skills, retrieval evaluation, curricula, assessments, delayed-retention testing, and independent-performance measures. Learning remains reversible and does not change base-model weights.

13.5 Stage 5: Improvement manager↩︎

Allow proposals to prompts, routing, planners, skills, tool candidates, and benchmark coverage. Add quarantined candidates, hidden held-out tests, risk classification, signed releases, canary deployment, and rollback. Low-risk promotion may be automated only by an external policy engine.

13.6 Stage 6: Decentralized lineages, foundry, and Personal Singularity OS↩︎

Implement owner gateways, version selection, communication modes, isolation, cloning, multi-parent derivation, capability graphs, goal portfolios, domain-separated data vaults, dependency monitoring, and assisted versus independent evaluation. Main-lineage status is assigned through external evidence and adoption, not self-promotion.

13.7 Stage 7: Weight and meta-level improvement↩︎

Only after the preceding controls are reliable should the system fine-tune adapters or improve the improvement mechanism itself. Training data must preserve grounded human or environmental evidence, with explicit defenses against synthetic feedback loops. Capability ceilings, human review, and independent red-team evaluation become stricter as modification scope increases.

14 Limitations and Open Questions↩︎

First, no evaluation suite can prove the safety of an unrestricted self-modifying system. Hidden tests can be incomplete, and an agent may exploit deployment conditions not represented in validation. The design therefore reduces risk through separation, least privilege, incremental deployment, and reversibility rather than claiming a proof of safety.

Second, recursively improving benchmark performance may not transfer to unstructured real-world tasks. Current agents continue to struggle with reliability, hidden state, ambiguous requirements, and verification, even as measured task horizons increase [18]. The architecture does not remove these limitations; it makes failures traceable and recoverable.

Third, personal capability is difficult to measure and cannot be reduced to a neutral universal objective. Health, work, family, learning, and wellbeing trade off. The user constitution and Pareto-frontier framing reduce paternalism but do not eliminate value conflicts or measurement error.

Fourth, personalization requires broad context, which increases privacy and security risk. Even same-owner agents should not have unrestricted access to one another’s memories or tools. Federated learning and secure aggregation reduce central data collection but do not solve poisoning, inference attacks, or governance.

Fifth, an agent ecosystem may fragment into incompatible lineages, concentrate around a dominant registry, or create reputation manipulation. Open standards, reproducible builds, multiple evaluators, transparent incident histories, and owner-controlled upstream selection are necessary research directions.

Finally, the term personal singularity may be misunderstood as an absolute or instantaneous transformation. The operational definition in this paper is deliberately modest: verified, sustained movement toward a user-selected and technologically expanding capability frontier. Whether such a construct is useful must be tested in longitudinal studies.

15 Conclusion↩︎

Recursively self-improving agents should not be designed as monolithic programs that rewrite themselves and trust the result. A practical implementation is a governed search process over versioned agent states: the agent proposes, external systems authorize and evaluate, owners control goals and adoption, and every release remains auditable and reversible. Autonomous task completion, memory, skill learning, source-level modification, and meta-improvement are distinct layers that should be added gradually.

Personal singularity adds a second requirement: the software’s growth must translate into durable human growth. A successful system defines every specialist by an explicit goal, bounded scope, validated tools, independent tool tests, end-to-end benchmarks, an owner-controlled Auto-Index, and a route for out-of-scope work. It assigns each accepted demand to one accountable agent, supports autonomous and interactive work, creates specialists when needed, and measures not only completed tasks but also what the user can understand and perform independently afterward. Under this framing, the objective is not an all-powerful central agent. It is a decentralized, owner-controlled ecosystem that helps individuals approach an expanding feasible capability frontier while preserving agency, privacy, safety, and the right to disconnect.

Acknowledgments↩︎

This manuscript is a conceptual systems design developed from iterative discussions about human-inspired learning, autonomous task agents, decentralized agent lineages, and human capability co-development. No external funding was used for this working draft.

Data and Code Availability↩︎

This paper introduces a conceptual architecture and reports no original experimental dataset. A reference implementation, benchmark harness, and reproducible manifests are proposed as future work. Any public repository link should be added only after the corresponding artifacts are available.

Conflict of Interest↩︎

The author declares no conflict of interest for this conceptual manuscript.

16 Example Agent Release Manifest↩︎

agent:
  lineage_id: org.example.personal-rsi
  version: 1.4.0
  parents:
    - research-rsi/3.2.1
    - coding-rsi/5.0.4
  release_channel: candidate

goals:
  safety_constitution: external-standard/2.0
  founding_mission: Assist user-selected learning and work goals.
  owner_goal_hash: sha256:...
  permitted_evolution:
    - retrieval improvement
    - verified skill acquisition
  prohibited_evolution:
    - permission expansion
    - hidden communication

scope:
  domains: [software-work, computational-imaging]
  task_types: [inspect, implement, test, analyze, document]
  excluded_domains: [clinical-diagnosis]
  risk_ceiling: moderate

capabilities:
  interaction_modes: [autonomous, hybrid, interactive]
  auto_index_ceiling: 3
  network_policy: allowlisted
  filesystem_policy: workspace_only
  credentials: none-by-default

tools:
  registry_version: tools-2.1
  tool_test_suite: tool-tests-2.1

evaluation:
  agent_benchmark: rsi-agent-eval-2.0
  heldout_suite: rsi-eval-1.0
  task_delta: 0.047
  safety_regressions: 0
  goal_integrity_score: 0.97
  evaluator_signature: sig:...

update:
  permission_delta: []
  rollback_version: 1.3.2
  owner_approval_required: false

17 Pre-Deployment Checklist↩︎

1. Is the governance plane outside the candidate agent’s write authority?

2. Are all tools deny-by-default and scoped to the minimum required data and actions?

3. Are credentials short-lived, task-scoped, and absent from model context unless required?

4. Are success criteria, hidden tests, and rollback rules protected from modification?

5. Does the release have complete provenance, reproducible build information, and signatures?

6. Does any goal, permission, autonomy, network, resource, or production-impact delta require the correct review?

7. Can the owner disconnect or isolate the agent immediately through an external gateway?

8. Are candidate tools, skills, and derived agents quarantined before activation?

9. Are assisted and independent user outcomes both measured for personal-singularity claims?

10. Are high-stakes domains, especially health, governed by domain-specific limits and human escalation?

11. Does the agent have a signed scope contract with explicit exclusions, risk ceiling, and out-of-scope handoff policy?

12. Are tool-only tests separated from hidden end-to-end agent benchmarks?

13. Does the Auto-Index remain subordinate to hard permissions and owner-set autonomy ceilings?

References↩︎