Self-Improving Personal AI Agents: An Implementation Theory of Boundary Design Through Meta-Harnesses

TL;DR

• A new class of personal AI agent is coming: one with a meta-harness — a mechanism that lets the agent observe and modify its own harness — and that improves itself autonomously over time. Both adaptation to the user’s life and improvement of the agent’s own capabilities proceed in parallel as the years go by.
• The same mechanism that lets an agent improve itself lets it destroy itself. The question is not whether to use it, but how to control it. You don’t give the agent freedom — you define the boundaries of its freedom.
• Autonomous improvement splits into two streams with different signal sources and different targets (the preference layer and the execution layer), and one loop can’t handle both. Each needs its own mechanism.
• What prevents runaway behavior isn’t "rules" or "prompts." It’s three things working together: physical boundary control via daemons and API gates, structural collection of user feedback, and approval gates over changes that touch code.

1. Personal AI Agents and the Meta-Harness

The practical knowledge around personal AI agents has grown rapidly over the past year. Karpathy’s LLM wiki, Obsidian + Claude Code, harness engineering, the various Skills and MCP implementations. I’ve tested all of these in real-world operation myself, and I’m now running a personal AI agent built around a meta-harness of my own design in production. This article is the theoretical framework I’ve arrived at through that design and operation, and I’m increasingly confident in it.

What is a harness?

A harness is the collective term for everything outside the LLM model itself: prompts, tools, memory, workflows, access controls. Everything the model passes through between receiving input and returning output. The same model with a different harness produces an entirely different agent.

This is exactly what AI engineers are already tuning in tools like Claude Code or Cursor. Writing CLAUDE.md or .cursorrules, adding an MCP server, narrowing the allowed tool list, codifying context management conventions. These are all harness tuning, and they’re already part of an AI engineer’s daily craft.

The meta-harness: a harness that modifies the harness

A meta-harness is the mechanism that lets the agent itself observe and modify this harness.

The Stanford / MIT / KRAFTON paper on Meta-Harness (Lee et al., arXiv:2603.28052) formalizes the meta-harness as an evaluation-function-driven outer-loop optimization system. An agent proposer references prior candidates’ source code and execution traces through the filesystem, and uses an evaluation function as its signal source to automatically search and rewrite the harness source code itself. This is a powerful and concrete instantiation of the idea that "a model modifies its own harness."

The idea has already landed in several implementations in the coding agent space. MaximeRobeyns/self_improving_coding_agent (SICA, arXiv:2504.15228) is an agent that edits its own codebase to improve itself; it reports an improvement on SWE-Bench Verified from 17% to 53%. neosigmaai/auto-harness, open-sourced in April 2026, automatically mines benchmark failures, iteratively edits the harness to optimize it, and uses gates to guard against regression. It supports Terminal-Bench 2.0 and tau-bench.

What these share is that they target self-modification in a single domain where the evaluation function is unambiguous — coding. The code either runs or it doesn’t; the test either passes or it doesn’t. Binary success becomes the signal source and the evaluation function in one move.

My prediction: this will move into personal AI

My prediction — and my implementation-level conviction — is that this idea of "the agent modifying its own harness" will migrate from the closed domain of coding into personal AI agents. The meta-harness, proven out in coding agents, is being open-sourced in forms like SICA and auto-harness, and the design philosophy is highly likely to flow downstream into the personal AI space.

Why do I expect this? Because anyone who actually operates a general-purpose AI assistant starts noticing its limits. Manual prompt tuning, static config files like CLAUDE.md or .cursorrules, telling the agent your preferences again at the start of every session — none of these keep pace with how a person’s workflow, focus, and life cycle actually change. The static-config approach can be improved with engineering effort, but the per-session reminder approach has very little headroom. One of the most promising paths to improving personalization accuracy over the long run is to let the agent observe and modify parts of its own harness. Coding agents have already shown this direction works. Personal AI is highly likely to converge on the same pattern.

That said, the mechanism of the meta-harness gets reshaped on the way over. The "single domain with a clean evaluation function" that coding agents lean on doesn’t exist — yet — in personal AI.

So in this article I use meta-harness as a broader umbrella concept that includes Lee et al.’s evaluation-function-driven formulation as one specific instance. That is: any harness designed so the AI agent can observe and modify parts of the harness itself (prompt templates, workflow definitions, skill implementations, tool access controls, meta-files, etc.). Whether the signal source is an evaluation function, user feedback, or tool execution logs — if it enables the agent to update its surrounding harness, it’s a meta-harness.

Why I adopt this broader definition, and which signal sources map to which mechanisms — I’ll work through those in the implementation discussion in Section 3. The two things to take away from this section are: the idea proven out in coding is coming to personal AI, and the mechanism will fork into multiple variants.

2. What Happens When You Build a Meta-Harness Into a Personal AI Agent

What actually happens, day-to-day, with a personal AI agent that has a meta-harness built into it? This section walks through the behaviors concretely, without diving into implementation. Just: what does the user see?

2.1 The agent adapts to your behavior and your life

A personal AI agent connects to multiple data sources: your calendar, email, notes in Notion/Obsidian, browser history, health data. The conventional Second Brain approach treats these as a "searchable archive." A meta-harness-equipped agent goes one step further.

From this accumulated context, the agent builds a model of your projects and your life cycle. What you’re responsible for. When you focus. What you tend to avoid. Which days lean toward which kinds of work. From this model, the behaviors the agent provides look like this:

Pre-meeting notifications, automatically surfacing related to-dos. Thirty minutes before a meeting, the agent assembles the briefing material you’ll need and shows it to you — proactively, before you ask. To-dos it can handle on its own — drafting meeting notes, drafting an email reply, summarizing research, organizing a document diff — it just does.

Going further: the agent starts proposing what your ideal day or week should look like, based on its analysis of your patterns. Not the simplistic "deep work at peak hours, light work at low hours," but a proposal informed by execution logs of what actually got done versus what got pushed.

Up to this point, a static implementation could go a fair distance. Where the meta-harness really earns its keep is when the agent uses your feedback to rewrite parts of the harness itself.

When you review what the agent produces and give it feedback, the meta-harness loop kicks in. The agent takes the feedback, identifies the root cause, and rewrites the very definition of the agent that produced the output. Concretely: the meta-file for the target agent — execution time, trigger interval, input prompt template, output format, the set of skills it references — gets modified, changing the behavior from the next run onward.

"Your suggestions are too granular" → information-density spec gets rewritten. "Your output timing is off" → the trigger time itself gets rewritten. "Only do this kind of research when I ask for it" → the trigger condition and input prompt for that agent get rewritten. The agent isn’t reaching into model weights. It’s reconfiguring the harness around itself, using your feedback as the signal.

This is the umbrella meta-harness behavior I defined in Section 1, in its most typical form. The signal source is qualitative user feedback — different from Lee et al.’s evaluation-function-driven outer loop — but the skeleton ("the agent observes its own harness and modifies it") is identical. The key point is: alignment moves through declaration and rewrite, not training. A single piece of feedback rewrites a meta-file, and the new behavior persists — it remains part of the context until the next rewrite.

2.2 The agent improves its own capabilities

The other stream is autonomous improvement that doesn’t depend on the user giving any feedback. The signal source here is tool execution logs. Which skill was called, with what arguments, how many times it succeeded, how many times it failed, and what error came back on failure. Objective execution records, accumulating naturally.

The behaviors that derive from this:

• Reducing token cost and execution time. Updating skill definitions and processing flows so the same task completes in fewer steps.
• Improving accuracy. Aggregating tool execution errors and instruction-following failures, then patching the root causes.
• Continuous improvement of on-demand apps. When the agent generates a script to complete a user task, that script gets refined during operation. Not a one-shot artifact — an implementation that grows while being used.

Two concrete examples.

Example 1: The agent self-heals an internal harness inconsistency

In the course of development, I sometimes update the spec of an API the AI agent calls — add a new argument, change the response shape, restructure how errors are returned. The skill description — the doc the agent reads to know "this is how this API gets called" — should be updated at the same time, but at one point I forgot.

From the agent’s perspective: it follows the skill description, calls the API — but the API is on the new spec, so it returns an argument error. The agent reads the error message, uses the spec info embedded in the message to infer the correct call format, and retries. Eventually the call succeeds and the task completes.

So far, nothing exotic. Error → analyze → retry is something modern agents do every day. What mattered was what happened next.

I forgot about my own skill-update miss and kept running the skill that way for several days. Naturally, the same error fired multiple times a day. Every time, the agent re-read the error, re-inferred the right format, re-tried. Two or three extra tool calls per task. Cost and wall-clock time piling up.

This is where the daily self-improvement process caught it. The improvement agent aggregated tool execution logs and detected that a specific API was hitting chronic errors. It examined the error logs and, from the content-and-frequency pattern, identified a persistent inconsistency between the skill description and the API’s actual spec. The improvement agent surfaced a proposal to me: replace the description with one that contains the API’s latest execution example. I approved it.

After that, the same error essentially stopped happening. The agent started calling the API correctly on the first try, and the cost of tool retries disappeared.

What’s happening here is that the agent isn’t "getting past the error in the moment" — it’s permanently rewriting the harness around itself (the skill description) so that the same error doesn’t happen twice. The former is the agent’s normal behavior. The latter is the meta-harness’s behavior. The daily improvement process sits at the outer-loop position of "observing across multiple executions," which is exactly why it can detect chronic drift and apply a permanent fix.

Designing error messages as part of the system itself is a prerequisite for this to work. Error messages aren’t notifications to the user — they’re instruction sheets to future agents. The agent’s behavior shifts from "stop because it failed" to "fix it because the cause and the fix are recorded."

Example 2: On-demand apps acquiring generality over time

Here’s another behavior pattern, broader in scope. This is the self-improvement of on-demand apps — the tools the agent generates in response to a user request and refines as it operates them.

Say the user asks the agent: "Get the price of a specific stock and give me a brief analysis daily." The agent generates a Python script, creates the skill description that runs it, and registers it with the daemon scheduler. For the first few days, fetching the specified stock works fine as instructed.

But over the course of operation, the user starts going beyond the original instruction: "I want to check other tickers too." "Sometimes I only want the volume." "Show me the move after an earnings call." The original script was specialized for one ticker and one type of information, so it can’t handle the expanded use cases — arguments are hardcoded, the data axes are limited, edge cases blow up. The agent works around it in the moment by adjusting how it calls the skill or trying different arguments, but the underlying script design no longer fits the actual usage, so errors keep happening intermittently.

This is where self-improvement earns its keep. The improvement agent detects from the tool execution logs that the call pattern against this script has expanded beyond the original design, and that errors stemming from that pattern are accumulating. It then proposes rewriting the single-ticker, single-information implementation into a general implementation that can handle the call patterns the user actually exhibits — modifying both the Python script itself and the skill description that drives it, simultaneously. Once the user approves, the script running on the daemon now has the extended capability.

Again, the essence of the meta-harness here isn’t "fix the error in the moment." It’s observing across multiple executions and redefining the agent’s permanent capability (the script and the skill definition that drives it) to match the observed usage pattern. Single bug fixes are completed by ordinary Claude Code–style behavior; what’s happening here is a rewrite of the agent’s capability boundary itself.

The repertoire of problems this script can solve expands over time. The list isn’t fixed — every time the user asks a new question or uses it in a new way, the self-improvement loop incorporates it. The agent builds a tool on demand and refines it while operating it. That’s the essence of what I’m calling an on-demand app.

This is precisely the layer that general-purpose tools struggle to reach. General tools can only build "features many users will share." The strength of a personal AI agent lies in continuously observing your actual usage and, over the years, sharpening the tool only you would want.

2.3 But this power is inseparable from loss of control

If you read this far and thought "I want this," you almost certainly also thought "this is terrifying."

The agent rewrites its own action rules. It rewrites skill implementations. It rewrites Python scripts. All of this proceeds autonomously on a daily and weekly cadence.

What could go off the rails? The agent takes incorrect feedback as gospel and mis-updates its rules. The improvement agent misidentifies the root cause and breaks a working skill. The autonomous cycle keeps optimizing toward something the user doesn’t want. Or worst of all, the user doesn’t notice any of it.

The meta-harness is powerful precisely because the agent can modify itself. But "able to modify" and "able to destroy" are the same statement. The same mechanism can create both improvement and failure.

So the question of whether to build a meta-harness into a personal AI agent isn’t "use it or don’t." It’s how to control it. Don’t give the agent freedom — define the boundaries of its freedom. From here on, we’re in the implementation theory of the meta-harness.

3. Implementation Theory: Boundary Design That Prevents Runaway

How do you implement the behaviors from Section 2 — an agent that persistently changes its behavior in response to feedback, an agent that self-heals harness inconsistencies, an on-demand app that gets sharper as it’s used — without letting any of them run away? That’s what this section is for.

Implementing a meta-harness comes down to mechanically defining where the agent can and cannot reach. "Bind it with rules" and "instruct it via prompts" are not enough — LLM-based agents respond to instructions probabilistically, and you cannot fully prevent deviation. Boundaries have to be enforced physically, at the code level.

The harness defines the boundary. The agent acts autonomously within it. That’s the thesis running through this section.

3.1 Two streams of improvement: the preference layer and the execution layer

If you organize the behaviors in Section 2, self-improvement splits into two directions.

The behavior from 2.1 — "the agent rewrites its action rules / meta-files using user feedback as the signal" — and the behavior from 2.2 — "the agent rewrites its actual capability (skill definitions, scripts, MCP implementations) using tool execution errors and logs as the signal." Both run in parallel inside the same harness, but the signal sources and the rewrite targets differ, so each needs its own mechanism. I’ll call these two streams the preference layer and the execution layer.

The preference layer: evaluation-function-driven approaches have limited reach

The preference layer corrects what the agent should do. One important fact to point out here: Lee et al.’s evaluation-function-driven outer loop doesn’t transfer cleanly to the preference layer. The reason lies in the structural constraints personal AI agents operate under.

General-purpose agents — coding, research, customer support — all have benchmarks: SWE-Bench, AppWorld, AgentBench, tau-bench, Terminal-Bench. Vendors can optimize harnesses against these benchmarks. What users receive is a scaffold someone has already tuned.

Personal AI has no shared benchmark. The evaluation function for "an AI that’s good for me" lives inside me, is hard to share with others, and shifts over time. Vendor-side universal harness optimization is structurally difficult — the target of optimization doesn’t sit still. Lee et al. show "harness alone can produce up to a 6x difference in success rate at the same model" — in general agents, the vendor harvests this gap; in personal AI, it sits dormant per user.

The realistic paths to harvesting this dormant potential are: have the user keep writing the harness themselves, or have the agent modify it itself — i.e., build a meta-harness. The former is hard to sustain in the face of shifting preferences, decaying skills, and project phase transitions. So in practice the latter ends up being the center of gravity, and the main signal has to come from qualitative user feedback, which changes over time. With small sample sizes and a non-stationary target, an evaluation-function-driven approach is hard to anchor on.

To avoid a misreading: I’m not claiming evaluation-function-driven thinking is entirely unusable in the preference layer. Per-task completion, instruction-following on specific instructions, whether the agent took the agreed action at the agreed time — partial evaluations are at least somewhat measurable. Reinforcement learning research is already advancing approaches that learn reward models from partial human feedback. But aggregating these into a stable evaluation function that can drive the entire preference layer is, in current personal-operation environments, hard. That’s why I adopted the "umbrella concept" framing in Section 1. Lee et al.’s formulation is one form of meta-harness; addressing the preference layer requires another loop running in parallel — one whose primary signal source is user feedback.

The execution layer: evaluation-function-driven approaches partly apply

The execution layer corrects whether the agent is executing things correctly, and here Lee et al.’s thinking partly applies. Tool calls accumulate enough samples per skill, success is binary and not subject to interpretive drift, and they’re independent of the user’s mood. You can collect objective metrics like "skill A success rate 95%, skill B 40%" — a local benchmark forms inside the personal AI.

The two streams aren’t in conflict; they complement each other. Inside one harness, two loops run in parallel, separated by signal source and rewrite target. This is the base structure of a meta-harness in personal AI.

Below, I lay out the implementation: the top-level structure (daemon and agent, 3.2), the knowledge architecture both loops share (3.3–3.4), how preferences get declared (3.5), the autonomous cycle (3.6), the two feedback loops (3.7, 3.8), how they integrate (3.9), and finally hallucination countermeasures (3.10).

3.2 Top-level structure: daemon and AI agent

At the top layer of the implementation, there are two actors: the daemon and the AI agent.

The daemon is the resident background control layer. Its responsibilities are:

• Launching, stopping, and scheduling the AI agent.
• Allow/disable control of the tools the agent can use.
• Providing the APIs that mediate writes to knowledge, along with path and scope validation.
• Append-only storage of execution logs and feedback.
• Data sync with external systems (Gmail, Notion, browser history, etc.).

The AI agent is the thinking layer that operates inside the boundary the daemon draws. It uses only the tools and APIs the daemon allows, gathering information, making judgments, and acting. It cannot touch tools the daemon hasn’t authorized, and writes to specific files that don’t go through the daemon are structurally impossible.

This division is the most direct implementation of this section’s thesis: the harness defines the boundary; the agent acts autonomously within it. The daemon defines the boundary; the AI agent acts inside it. The boundary isn’t kept by the LLM’s intelligence or discipline — it’s kept by the daemon’s code and the API gates, structurally.

Below, I start with the structure of the knowledge area that the daemon and the AI agent share.

3.3 Knowledge architecture: six-class split

The design axis for the knowledge architecture is not topic, but (authority × lifecycle × mutability). Who writes this data, how often does it change, and is it rewritable? The directories split along the intersection of these three axes.

Splitting by topic creates collisions. For example, the topic "repository" contains both a summary (slow-change reference) and a daily log (append-only narrative), but the two have completely different read frequencies and write patterns. Putting them in the same directory makes "what’s in this directory?" hard to handle uniformly, and you end up with per-file exceptions multiplying in the code. Splitting by authority and lifecycle lets you declare injection policy and write locks at the directory granularity in one go — when you add a new event type, you just choose "which class does this go in?"

Splitting the personal meta-harness along these three axes, six classes emerge:

The directory structure looks like this:

~/.personal-agent/context/
├── _index.md                     # navigation across the 6 classes
│
├── identity/                     # [USER, slow-change, read-heavy]
│   ├── profile.md
│   ├── people.md
│   ├── work.md
│   ├── expertise.md
│   ├── personal.md
│   └── goals.md
│
├── state/                        # [AGENT, fast-change, volatile]
│   ├── today.md                  # today's outputs (write-locked)
│   ├── yesterday.md              # rotated
│   ├── profile-questions.md      # profile question queue
│   ├── activity/<source>.md      # 90-day activity view (auto-generated)
│   ├── inbox/YYYY-MM-DD-<slug>.md
│   └── scratch/YYYY-MM-DD-<slug>.md  # 48h TTL
│
├── plans/                        # [MIXED, medium-change]
│   ├── roadmap.md                # direction = user, progress = agent
│   └── projects/<slug>.md
│
├── journal/                      # [AGENT, append-only narrative]
│   ├── daily/YYYY-MM-DD.md
│   ├── weekly/YYYY-Www.md
│   ├── monthly/YYYY-MM.md
│   ├── repos/<slug>/YYYY-MM-DD.md
│   └── agent.md                  # agent decision log
│
├── knowledge/                    # [MIXED, accumulating]
│   ├── wiki/<workspace>/{00_inbox,10_raw,20_wiki,30_outputs,90_meta,log}/
│   ├── repos/<slug>/overview.md
│   ├── entities/<domain>/<type-plural>/<slug>.md
│   └── dossiers/<slug>.md
│
└── policies/                     # [USER, config-grade, rarely-change]
    ├── management.md
    ├── redaction.md
    ├── mcp.md
    ├── integrations.md
    ├── management-captures/<slug>.md   # agent captures (waiting for merge)
    ├── routines/                       # morning, evening, weekly, monthly
    └── skills/<slug>/SKILL.md

Six structural notes:

The role of _index.md

Each directory’s _index.md is the contract: what that directory means, what it manages, what files and subdirectories it contains, and what conventions and API access controls apply. The agent doesn’t glob the directory — it reads one file, _index.md, to understand the topology. This avoids read storms. _index.md is not a child enumeration — that’s what ls is for.

Declaring mutability via frontmatter

Even within one file, mutability can differ section by section (the identity portion of the profile is immutable, but current_role is mutable). This is declared in frontmatter.

---
sections:
  identity:
    type: immutable
    write: deny
  current_role:
    type: mutable
    write: replace
    scope: agent.rules.profile-update
  ongoing_concerns:
    type: mutable
    write: append
---

Enforced API-based access — this is the core of the structure

The agent has zero direct write/edit/delete authority on any file under knowledge. All create/modify/delete operations go through dedicated APIs. The tool permissions the agent receives are limited to "read" and "execute API" — write authority to the filesystem is structurally stripped.

The stripping happens at two layers: the path layer and the API layer. At the path layer: (1) the daemon that launches the agent issues a tool allowlist; (2) the agentic application (Claude Code etc.) specifies allow/disable tools, controlling the very exposure of write-class tools; (3) tool calls are monitored during and after execution, and writes to non-allowed directories are forcibly stopped or rolled back from snapshot (drift detection). At the API layer: (1) path validation unconditionally rejects writes under journal/ and to immutable sections; (2) frontmatter validation resolves the target section’s type and write policy; (3) scope validation verifies that the calling task-flow is allowed to perform the operation under the relevant scope.

Only operations that pass both layers execute, and the change is automatically appended to journal/agent.md as a decision log. Non-rewritability is guaranteed not by LLM intelligence or discipline, but by the combination of least-privilege and API gates. Class- and section-level policies aren’t declarations in a document — they’re mechanically enforced. Implementation details are out of scope here.

Time series unified by a dated-file convention

journal/daily/YYYY-MM-DD.md, journal/weekly/YYYY-Www.md, journal/monthly/YYYY-MM.md, journal/repos/<slug>/YYYY-MM-DD.md, state/inbox/YYYY-MM-DD-<slug>.md, state/scratch/YYYY-MM-DD-<slug>.md — all follow the same naming convention. Rotation, TTL, and associated processing code converge in one place.

Runtime data does not go in the vault

Tool execution logs, integration polling state, message queues, and other high-frequency-write data live in a separate SQLite store, not the knowledge vault. policies/integrations.md holds only a snapshot of mode settings. This keeps the markdown layer to "narrative + reference humans can read," with execution-layer metrics separated into a queryable database. The technical improvement loop described later (3.8) sources its signal from this SQLite layer.

The role of policies/management-captures/

policies/management.md is nominally user-authored, but agent-side proposals for rule additions are captured as policies/management-captures/<slug>.md. The reconciler then merges captures into management.md (covered in 3.7). Separating capture from merge into different files gives you the agent-proposal/user-approval boundary as a directory hierarchy.

Many "personal LLM wiki" and "Second Brain" discussions treat knowledge as one monolith, but in operation, that’s too coarse. "Even within the same topic, things with different lifespans and authorities get split." That’s the classification axis that makes a personal meta-harness work.

3.4 Two-way split by data mutability: Type A / Type B

More important than the directory split is physically separating rewritable and non-rewritable data at the harness level. My operational split is:

• Type A (immutable facts) — History, action logs, past schedules, feedback records, finalized decisions, tool execution success/failure and error info. These are past facts; rewriting them isn’t degradation, it’s forgery. Append-only, kept out of the LLM’s edit surface.
• Type B (data with freshness) — Personality, preferences, focus areas, current research topics, goals, the agent’s action rules, skill definitions, skill implementation scripts. Both humans and agents change over time. Fixing these once they’ve lost freshness leaves the agent optimizing for a past version of yourself.

This split maps directly onto the six classes. Everything under journal/ and the SQLite runtime data layer outside the vault is Type A — append-only, non-rewritable. identity/, state/, plans/, knowledge/, and policies/ are Type B, updatable (though every file and every section has its own write policy; nothing is rewritable without limits). Type A / Type B is the projection of the six classes onto the mutability axis.

One piece of evidence for this split. The Microsoft Research paper by Laban, Schnabel, and Neville (arXiv:2604.15597) shows on the DELEGATE-52 benchmark that, after 20 edit delegations, even frontier models (Gemini 3.1 Pro / Claude 4.6 Opus / GPT 5.4) corrupt an average of 25% of document content, with the all-19-model average hitting 50%. Errors are sparse but severe — scattered, deep, silent. A basic agent harness doesn’t help and can make it worse.

"Don’t let LLMs touch raw data" doesn’t fully answer this. What you need is to separate data the LLM may touch from data it may not, at design time. The tool-access controls in 3.3 are the mechanism that implements this split. Write-class tools simply aren’t exposed in Type A regions. Even in writable regions, in some contexts only append tools are passed. The risk DELEGATE-52 documents lands fatally on Type A; Type B can be designed around updatability. Making the split a mechanism contains the risks and benefits in separate regions.

3.5 Goals aren't an objective function — they're declared as a body of preferences

The question "what should the agent optimize?" is often reduced to vague phrasings like "act in the user’s interest" or "do what the user wants." But in personal operation, this framing is deeply problematic. The AI doesn’t actually know a specific user well; it has to infer what’s in your interest from generalized norms and value judgments in its training data. You’re using training data shaped for generalization as the basis for individualization — that’s structurally incoherent. The more you simplify the goal into an abstract label, the easier it is for the agent to act on behalf of an abstracted "someone" rather than the concrete user.

What I do instead is write my own preferences out as Type B into knowledge. "Keep morning notifications minimal." "Only do research-related work when I ask." "Suppress work suggestions on weekends." I list these "behaviors I expect from the AI" in identity/ and policies/management.md. A body of concrete preferences — rather than an abstract goal function — is what produces individually optimized behavior. Preferences are falsifiable and updatable; abstract objective functions are not, and they lose the trigger for updating themselves. Preferences live as Type B, rewritten over time.

There’s an unsolved space in this preference-body design. When preferences conflict — say, "no notifications between 1am and 5am" against "always notify on family emergencies" — the natural-language enumeration alone can’t decide. In current operation I’m trying two approaches. One is to embed condition clauses ("except for contacts from..."). The other, more rigorous: build a priority-ordered decision table modeled on DNS or firewall rule tables, and have the agent match against it mechanically. The latter reduces LLM interpretation drift but maintenance cost rises as rules accumulate. I also tag high-importance preferences with ## IMPORTANT. This area needs to grow through feedback, and I don’t have a clean solution yet.

One important implementation choice: the agent doesn’t read these preferences voluntarily — the harness injects them as a prompt at workflow startup. Asking the agent to "remember to read your preferences" inevitably produces drift in long tasks: skipped reads, shifted interpretations, deprioritization. Make injection the harness’s responsibility, and from the agent’s perspective preferences are simply part of the context that was there from the start.

My harness is multi-agent. I define task-flows per task type (under policies/routines/) and pass each agent only what it needs. A research agent doing a routine task doesn’t get the whole user profile and all behavior guidelines — it gets the research-related guidelines and the relevant focus areas. Which preferences, to which agent, at what granularity — that decision belongs to the harness design. The class-level injection policy (which sections of identity/ to pull, which routines from policies/ to apply) can be declared in the task-flow.

3.6 The autonomous cycle: from passive accumulation to active loop

The structure so far is genuinely useful. Past projects, payment history, research notes — all searchable in natural language. Ask it to write a résumé, ask it to organize your knowledge, and it produces the documents. But there’s a ceiling. Stop at passive accumulation and knowledge remains little more than a searchable archive. It becomes searchable, but the agent isn’t making any decisions.

The personal harness really earns its keep when the agent starts running a daily cycle that uses the accumulation as input to make active decisions. My setup roughly looks like this:

• Morning — Yesterday’s feedback (journal/agent.md), yesterday’s schedule (state/yesterday.md), journal/daily/ summaries, today’s user schedule, yesterday’s deltas from external apps (Gmail / Notion / browser history). The harness bundles these as input and generates state/today.md. Alongside the user’s schedule, today.md includes the agent’s own schedule. When the AI will launch itself today, and what it’ll do, defined by itself.
• During the day — Acts on preferences. Self-driving against the today.md schedule. Launches on demand on triggers like new information arrivals or user queries.
• Evening / weekend — Reviews the day’s and week’s actions, logs drift and improvement points into journal/agent.md and journal/daily/YYYY-MM-DD.md.

Data sync with external systems (Gmail / Notion / browser history etc.) runs in three modes: scheduled polling, batch fetch aligned with morning schedule assembly, and on-demand fetch when the agent judges it needs more. Polling state and queues live in SQLite; only observations worth becoming narrative descend into journal/ markdown. Sources requiring real-time get short polling intervals, low-reference sources are on-demand only — the granularity is owned by the harness.

Notably, the management rules for "what to check in the morning" are themselves defined as policies/routines/morning.md, rewritable by the agent. But here too the harness keeps brakes on. The fields the agent can modify and the format of those modifications are strictly defined in skills and APIs; everything else is untouched. The agent can improve its own work procedures, but the range in which it can improve is structurally closed.

With this cycle in place, knowledge finally transitions from static archive to active thinking partner. Accumulation is the precondition, not the purpose.

3.7 Preference-layer feedback: silence is taken as consent

Qui tacet consentire videtur — "He who is silent is taken to consent." The maxim comes from medieval canon law, but it applies one-to-one to the relationship with an AI agent. As the agent rewrites knowledge, proposes actions, and updates rules, if the user says nothing, the agent processes that silence as approval. You swallow one discomfort, let two complaints slide, and the harness slowly drifts. By the time you notice, optimization is running toward something you didn’t actually want. The order you established in knowledge collapses under the weight of accumulated silence.

The behavior I described in 2.1 — "feedback rewrites the meta-file and persistently changes behavior" — is built on top of the mechanism described here. The reflection of feedback into policy is mechanically harvested via two loops, not entrusted to the agent’s whims.

First loop: immediate reflection via built-in skills

I have a built-in skill that defines: on detecting user feedback (a complaint or correction shaped like an instruction), invoke the rule-fetch/modify API. The skill definition is provisioned onto the harness side and is immutable (placed in a read-only directory), and even post-provisioning, allow/disable tools controls prevent it from being rewritten. The moment an agent spawns and starts work in a temporary working directory, the agent itself loads this skill via the skills mechanism. With the skill loaded, when complaint tones or correction expressions get detected, the agent — per the skill — calls the rule_capture API, writes the proposed change to policies/management-captures/<slug>.md, and records the diff into the append-only decision log in journal/agent.md. Captures are then merged into policies/management.md by the reconciler (currently automatic; more on this below).

To be precise, though: skills are instruction, not enforcement. Cases where the skill itself doesn’t get loaded, or loads but doesn’t fire, remain. Absolute guarantees at the skill level are difficult. That’s what the second loop covers.

Second loop: delayed harvest via review processing

Feedback the first loop missed gets picked up by evening / weekly review processing (defined in policies/routines/evening.md and weekly.md), which extracts latent feedback from conversation history and goes through the same API to capture and merge. When the first loop couldn’t detect "instruction-shaped requests or corrections" and the request fell through, the second loop catches it.

A concrete example. At one point I asked the agent, "Every evening at 7, quantify my day’s activities and output them as CSV." The agent processed this as a one-off task — scheduled execution registered, but no write to policies/management.md. That evening, the second loop scanned conversation history and judged this to be a recurring task the user wanted held as a management rule — and captured → merged it. The second loop retroactively picked up a recurring preference that the agent couldn’t distinguish from a single instruction.

Capture-merge separation, and the absence of an approval gate

One design decision worth making explicit. Agent-originated changes are always first written out to policies/management-captures/ as captures, and only afterward does the reconciler merge them into policies/management.md — a two-stage flow. The reason for separating capture from merge into different files and timings is to hold the agent-proposal / user-approval boundary as a directory hierarchy.

In my current harness, capture → merge is fully automatic. The user can directly see merge results in management.md and the downstream documents (today.md etc.) it produces, and can request fixes if anything feels off. Those fix requests get detected as feedback again, accumulated as Type A. The combination of fully automatic capture-merge plus an indirect verification loop via user-visible outputs is what holds the line against self-reinforcement spiraling.

That said, more precisely, there’s room here to implement an approval phase. The structural slot for a human gate between capture and merge already exists by virtue of the separation. Since the second loop’s extraction is also done by an LLM, hallucinations are structurally hard to avoid — misjudging chitchat as a recurring preference, missing the real intent of an instruction, over-generalizing from unrelated exchanges (general treatment of hallucination is in 3.10). The same logic by which the next section (3.8) makes "a human gate is mandatory at layers that touch code directly" should, in principle, apply to rule rewrites too. My current implementation rests on the operational observation that "extraction errors costly enough to warrant intervention haven’t happened yet"; an explicit approval gate is positioned as a future improvement direction.

3.8 Execution-layer feedback: improving skills from tool execution logs

The execution layer’s signal source is completely different from the preference layer — Type A tool execution logs accumulated in SQLite. Which skill, with what arguments, succeeded how many times, failed how many times. On failure, what error came back. Objective execution records with no subjectivity or interpretation.

High-frequency-write observation data does not go in the markdown vault. Markdown is the layer for narrative and reference; metrics are separated into queryable SQLite. The technical improvement loop takes this SQLite layer as input, and only the resulting improvement proposals descend into markdown.

This data differs from preference-layer feedback in three ways. Quantitatively aggregatable — if skill A’s success rate is 95% and skill B’s is 40%, the latter is plenty of signal even at N=1 user. Tool calls happen tens to hundreds of times a day, so they accumulate an independent population unaffected by user mood. Naturally accumulating — even without the user saying anything, every tool call adds a record. No utterance dependence. Different rewrite target — not declarative rules, but skill definitions (policies/skills/<slug>/SKILL.md), skill implementation scripts, and MCP server implementations themselves are the rewrite surface.

The technical improvement loop

For this execution layer, I run a technical improvement loop. On a daily or weekly cadence, an improvement agent launches. Its task is three-stage. (1) Aggregate SQLite tool execution logs and identify high-failure skills and tools. (2) Examine error logs and isolate root causes. (3) Surface the proposed rewrite target, the change, and the error-log samples used as evidence, as a report in state/inbox/.

Root causes split in two:

• Skill-definition (instruction md) problems — The agent is calling the skill with wrong arguments, skipping a required preprocessing step, calling it in an unintended context. Fixable by adding to or modifying the description in policies/skills/<slug>/SKILL.md. Characterized by context-dependent, scattered error patterns.
• Implementation problems — The expected API behavior changed, edge-case handling is brittle, there’s a race condition. Requires modifying the skill’s actual script or the MCP server implementation. Characterized by context-independent, homogeneous reproducible error patterns.

The self-healing example in 2.2 (Example 1) — the drift between the daemon’s API update and the skill description — is the textbook case of the former (skill-definition problem). By embedding fix recommendations into the error message as structured text, the improvement agent can reference that message during root-cause isolation. Error messages are part of the design, instruction sheets for future agents. The on-demand-app expansion in Example 2 (the script acquiring generality) runs through the same loop, but the target is structural insufficiency in the script itself rather than drift in the skill description — the same self-improvement mechanism, working across a wider class of problems.

The human deployment gate

Only changes the user approves get deployed. No auto-deploy without approval — the improvement agent itself can hallucinate, so for any change that directly touches code, the human gate is mandatory. Compared with the rule-rewrite gate in the preference layer, there’s much less room to weaken the human gate here.

The reason cadences are daily/weekly is also worth stating. An improvement proposal that concludes "this skill is broken" from just 3 failures is essentially modifying based on noise. Forcing proposals to accumulate at least some count or some period — at the execution layer too, this gives you something close to local statistical significance. A design that doesn’t let sample sizes collapse, held by the harness as cadence.

3.9 The three loops don't collide: logs mediate

Here’s the question a reader is probably stuck on. "The autonomous cycle rewrites the harness, preference-layer feedback rewrites it, the execution layer’s technical improvement loop rewrites it. Don’t these three collide?"

Structurally, they’re designed not to collide easily. The harness builds in the following asymmetries:

Integration as input

Preference-layer feedback isn’t only stored in the append-only decision log in journal/agent.md as raw data — the harness injects it as input prompt at autonomous cycle startup. Execution-layer improvement logs are also stored in journal/agent.md and in policies/skills/ version history. Yesterday’s feedback, the prior week’s review summary (journal/weekly/), the rules the agent previously captured and merged, and the improved skill set — all line up at morning today.md generation. The agent operates with a context that already knows "what it has been corrected on" and "which skills have been improved how."

Rule conflicts resolve by time

When user feedback contains multiple conflicting items, the prompt is built to prefer newer feedback. This absorbs natural preference shifts while preventing the accident of "old rule overwrites new intent."

Explicit cross-layer precedence

When the agent makes autonomous rewrites without feedback, daily / weekly review processing verifies consistency with "user feedback as ground truth" and corrects any contradictions. Preference-layer feedback stands above the agent’s autonomous judgment. When the execution-layer technical improvement loop proposes a skill change that conflicts with a preference-layer rule (example: rules say "no suggestions during research," but to improve skill success rate the change increases interruptions), the user approval gate becomes the last line of defense.

That said, this is not "structurally preventing overwrites." The final write of a rule update is done by an LLM, so hallucination-driven miswrites remain. The three asymmetries are a mechanism for containing miswrites within a detectable, recoverable range, not for making them impossible. Stacking more defense layers becomes excessive, so I stop there. Detection misses that get past are ultimately caught by the user noticing a behavior shift and flagging it as feedback.

There’s a partial echo of RLHF (Ouyang et al., 2022) in this structure — using human feedback to correct behavior. But the mechanism differs: behavior moves through context updates, not weight updates, putting it closer to Anthropic’s Constitutional AI–style rule-based correction, Reflexion’s (Shinn et al., 2023) reflective loop, or MemGPT-style external memory rewriting. Alignment moves through declaration, not training. This is a core characteristic of a personal harness.

On the research frontier, self-evolution — where the agent recursively improves its own self-modification mechanism (Darwin Gödel Machine and successors) — is being discussed. But what’s missing in personal operation isn’t the power to self-evolve. It’s the power to direct self-evolution. If you stay silent, the agent keeps optimizing in the wrong direction. Collapse doesn’t come from outside — it advances internally, from the absence of feedback.

3.10 Hallucination is unavoidable: Type A is a reference point, not a guarantee of self-detection

There’s a theme I’ve been deliberately holding off on: hallucination. As long as the agent is LLM-based, misedited rules, mis-generated logs, and misinterpreted feedback are structurally hard to avoid. The 3.7 built-in skill’s rule_capture can fire when it shouldn’t, and when it does fire it can call the API with wrong content.

Here too, the key is Type A. Append-only immutable data acts as a reference point for the agent to notice its own errors. Whether a rule about to be captured contradicts past feedback history in journal/agent.md — the agent itself can check. If a decision log from a past correction ("no suggestions during research") sits there, and the agent tries to write "actively suggest during research," there’s at least an opening for the inconsistency to surface. From a forensic angle too, you can reconstruct, from journal/agent.md and SQLite tool execution logs, which feedback triggered which rule change, when. A trace that lets you ask "why did this happen?" after the fact is the minimum bar for agent operation.

Don’t overstate this, though. The reference-and-comparison itself is performed by an LLM, so hallucination can recursively enter that process. Building a meta-harness on the premise that the agent can perfectly detect its own inconsistencies is dangerous. Type A is a necessary condition for self-detection, but not a sufficient one.

So to complement the agent’s primary self-detection, I keep user-visible outputs (today.md, the diff of policies/management.md updates, etc.) and have the second-loop review processing cross-check conversation history against agent logs to surface latent inconsistencies. Type A immutability, user-visible outputs, the second loop — these are designed not to fully prevent errors, but to contain errors within a range where the user can notice them after the fact and correct them.

The technical improvement loop carries the same structural limit. Improvement proposals from the improvement agent can’t be cleared of hallucination either — mis-attributed root causes, off-target fix proposals, over-generalizations grounded in unrelated logs. These can happen probabilistically. That’s exactly why the execution layer has a stronger human gate than the preference layer: for any change that directly touches code, user approval is not optional decoration — it’s a structural prerequisite for deployment. Hallucination is hard to fully prevent, but placing a human gate as a boundary structurally closes the path by which bad improvements reach production.

A third loop that detects hallucinations could, in principle, be built — but the detection loop itself can hallucinate, so the regress doesn’t terminate. Instead, the human acts as the endpoint detector. It’s a compromise, but a realistic one.

There’s no current way to make the agent not err. But you can build a structure where errors can be traced afterward, where they can be noticed, where they can be course-corrected. That’s Type A’s other role, and the realistic line of defense that boundary design offers against hallucination.

4. Only Those Who Design the Boundary Can Entrust Themselves to AI

Section 2 walked through what a meta-harness-equipped personal AI agent does day-to-day. Feedback rewrites meta-files and persistently changes behavior. The agent self-heals harness inconsistencies. On-demand apps sharpen as they’re used. All of this stands on the mechanisms of boundary design described in Section 3.

Splitting knowledge into six classes along (authority × lifecycle × mutability). Tool-access separation by Type A / Type B. Harness injection of preferences. Restricting the autonomous cycle’s modifiable surface. Built-in skills for feedback reflection. Constraining direction of the autonomous loop via journal/agent.md. In the preference layer, separating capture from merge. In the execution layer, separating the improvement agent’s proposal authority from the user approval gate. All of these are mechanisms for separating what the agent can and cannot reach.

Feedback can function as a brake because the harness has structurally provided places to press the brake. Without boundaries, feedback has nowhere to land. With boundaries, the agent’s autonomy remains within a range that aligns with the user’s interests.

Quantitatively evaluating the meta-harness in full is hard. The execution layer can be measured objectively — tool success rates, error patterns, before-and-after comparisons. The world of local benchmarks I described in 3.8 lives there. But the preference layer — "is this agent contributing to my life?" "is it helping my decision-making?" — differs across individuals and is, frankly, abstract. It can’t be reduced to productivity metrics, and there’s no preference-layer benchmark. I myself consider this close to optimal for me right now, but I don’t think it’s "the answer." I’m still in the middle of operational testing.

One last thing I’ve noticed in operation. Using this agent ends up forcing you to document yourself. Your preferences, goals, behaviors — you have to put them into language with your own hands or the harness is hard to design. The structural constraint that makes vendor-side optimization hard (Section 3.1) ultimately demands the work of observing yourself. The biggest byproduct of an AI agent may, in the end, be exactly that.

Whose preferences is your knowledge operating under as its compass?