Series 5 | Co-evolution: Why the Owner is the Crucial Variable in Intelligent Systems

Subtitle: From Execution Bandwidth to Intention Bandwidth: How PD Helps Humans Retake the Steering Wheel

---

Prologue: It's Not That AI Isn't Strong Enough; It's That Humans Aren't Ready to Steer It

In the first four episodes, I've been circling a single core question:

As AI Agents' execution capabilities become increasingly powerful, how can humans avoid being reduced to mere "typists" in the era of large models?

In Episode I, I discussed the "Helmsman Crisis" following the commoditization of execution power.

In Episode II, I chronicled the failure of Prompt Injection experiments: writing wisdom into prompts does not truly give AI wisdom.

In Episode III, I introduced the Pain Signal: principles aren't force-fed; they grow out of pain, reflection, and real feedback.

In Episode IV, I discussed the alchemy of soft-to-hard transformation: those repeatedly verified bottom lines shouldn't remain forever in Prompts, but should be compiled into Skills, RuleHosts, or deeper system instincts.

Up to this point, PD (Principles Disciple) seems to have a complete technical pipeline:

Pain → Reflection → Principle → Skill / RuleHost → Behavioral Delta

But as I thought deeper, a more profound question emerged:

If the Agent gets stronger, but the Owner does not grow alongside it, what happens?

This question is more fundamental than "Can the Agent write code?"

Because in my real-world usage of Agents, I've observed that many people fail to unleash their proxy's true power—not because the model isn't strong enough, nor because the toolchain is flawed, but because the Owner's own cognition, sense of purpose, judgment, and expressive capability artificially cap the system's potential.

A powerful Agent is like a massive engine.

But an engine doesn't decide the direction.

Direction comes from the Owner.

If the Owner doesn't know where they're going, a stronger Agent will only drive the system to the wrong place much faster.

If the Owner lacks the ability to judge what is worth doing, the Agent will execute a pile of worthless tasks with extreme efficiency.

If the Owner cannot transmit their experience, boundaries, preferences, pain points, and long-term goals to the Agent, then an infinitely long context window merely amplifies vague intent into a massive deviation.

Therefore, from the very beginning, PD has never been solely about the Agent.

What PD truly cares about is:

The Owner-Agent Synthesis.

This is why I am increasingly convinced that PD's core is not "AI self-evolution," but Co-evolution.

The Agent expands the execution bandwidth.

PD precipitates the pain, principles, and feedback.

The Owner provides long-term value judgments, anchors of meaning, and ultimate governance.

All three are indispensable.

---

01 The Function Illusion: Why an Agent is Not Input → Output

For a long time, we've been accustomed to understanding large models through a "functional mindset":

Input → Model → Output

You give the model a prompt, the model infers, and it outputs text.

This mindset is highly effective for evaluating the capabilities of a standalone model.

Did it answer the math question correctly? Does the code run? Does the webpage match the design mockup? Does the response follow the instructions?

These questions can all be evaluated using a relatively clear input-output relationship.

But when we plug a large model into memory, tools, file systems, runtime frameworks, rule layers, Skills, and human feedback, and let it run continuously in a real engineering environment, it is no longer an isolated function.

It transforms into a complex system that accumulates history, builds momentum, generates feedback, creates debt, and alters human behavior.

At this point, the quality of a single response is no longer sufficient.

What we really need to observe is:

• Did it reduce similar errors in subsequent tasks?
• Did it learn to identify risks earlier?
• Does it dare to pause at critical moments?
• Did it turn a single correction from the Owner into a long-term behavioral change?
• Did it proactively remove obsolete scaffolding after its underlying model capabilities improved?
• Did it make the Owner more clear-headed and principled as well?

A single output determines whether it looks smart.

The feedback loops determine whether it can grow.

This is why Episode V must switch from a "function perspective" to a "system perspective."

System Dynamics cares not about the right or wrong of a single calculation, but about how variables within the system interact over time, forming positive feedback, negative feedback, delays, debts, and leverage points.

A single inference is like a heartbeat.

System dynamics looks at the blood circulation. More accurately, it looks at blood circulation across different time scales: second-level heartbeats, hour-level digestion, and year-over-year metabolism.

A single Agent crash is not terrifying.

What is truly terrifying is how a crash is remembered, amplified, misused, or forgotten by the system, ultimately changing the character of the entire Owner-Agent synthesis.

---

02 Why Must the Steering Wheel Remain in Human Hands?

There is currently a very seductive narrative:

Since AI is getting stronger, shouldn't we let the Agent plan, execute, reflect, and evolve entirely on its own as soon as possible?

This sounds beautiful.

But it ignores a fundamental fact:

An Agent can optimize the path, but the Owner defines what progress means.

If we let an Agent evolve independently without a human Owner, it easily devolves into a local optimization machine devoid of value anchors.

It might learn to:

• Stop attempting difficult tasks to reduce Pain;
• Hide uncertainty to reduce Owner interruptions;
• Choose short-term patches to finish tasks faster;
• Bypass high-risk paths to avoid rule interception;
• Dodge truly important but ambiguous problems to boost tool success rates.

These actions might make the metrics look better.

But this is not necessarily progress.

Because "progress" is not purely a technical concept.

Progress contains value judgments.

What is worth doing? What is not worth doing? What risks are unacceptable? What compromises are acceptable? What direction must be persisted in, even if it's slow? What shortcut must not be taken, even if it's effective?

These questions cannot ultimately be defined by the Agent itself.

As long as humanity fears AI going out of control, the steering wheel can never be fully handed over to AI.

For a very long time to come, the intelligent systems truly accepted by society will not be naked, fully automated entities, but collaborative systems where humans retain ultimate arbitration rights.

This is not conservatism.

This is governance.

Norbert Wiener, the father of cybernetics, warned humanity long ago: the danger of an automated system often lies not in its inability to achieve a goal, but in how effectively it achieves a wrongly set goal.

Once the goal is wrong, the stronger the execution, the greater the damage.

Therefore, PD is not anti-automation.

PD is against anchorless automation.

The stronger the AI, the more important the human steering wheel becomes.

The more capable an Agent is of executing, the more systematically the Owner's principles, goals, and value judgments must be integrated into the system.

In PD, the Owner is not an external user.

The Owner is a system variable.

They shoulder at least five roles:

1. Value Function: Defines what is good, what is bad, and what is worth persisting.
2. Source of Pain: Determines which deviations are worth the system learning.
3. Arbiter of Principles: Reviews whether the principles extracted by the diagnostician hold true.
4. Risk Bearer: Bears irreversible consequences, and thus holds the ultimate right to govern.
5. Subject of Evolution: Continuously clarifies their own goals, preferences, and boundaries through friction with the Agent.

Looking deeper, the Owner is irreplaceable not just because they hold approval power.

It is because, within the entire system, only the Owner can hold facts, values, meaning, and responsibility simultaneously.

An Agent faces a task.

An Owner faces a life.

An Agent can judge if a path is shorter, but cannot judge for the Owner if the path is worth taking.

An Agent can optimize a piece of code, but cannot bear the cost of the product direction failing for the Owner.

An Agent can generate a hundred proposals, but cannot answer for the Owner: What kind of person do I want to be? What am I willing to be responsible for in the long term? What short-term efficiency am I unwilling to buy at what cost?

This is why the steering wheel must remain in human hands.

Not because humans will always be smarter than AI, but because humans bear the consequences.

Whoever bears the irreversible consequences must hold the ultimate right of governance.

What PD does is not hand this governance over to AI, but help the Owner translate their judgments, principles, pain points, and long-term goals into a structure the Agent system can understand, execute, and feed back on.

This is also PD's biggest divergence from many "fully autonomous Agent" narratives.

PD does not govern standalone Agents.

PD governs the Owner-Agent synthesis.

---

03 Intention Bandwidth: The Most Scarce System Resource in the Agent Era

If the question of the past was:

Can AI do this?

Then the question of the future will increasingly become:

Can the Owner accurately express what is worth doing?

The Agent's execution bandwidth is expanding rapidly.

It can read massive files in a minute, concurrently call multiple tools, and rapidly generate proposals, code, pages, docs, scripts, and tests.

But the Owner's cognitive bandwidth, expressive bandwidth, and attention bandwidth are not growing in sync.

This leads to a new systemic risk:

High Execution Bandwidth × Low Intention Bandwidth = High-Speed Deviation.

The Owner holds many things in their mind:

• Intuition;
• Experience;
• Preferences;
• Taboos;
• Long-term goals;
• Business judgments;
• Implicit understanding of the system;
• Instinctual aversion to certain risks;
• "Don't do it this way" rules formed after years of stepping on landmines.

But these things are hard to write into a Prompt all at once.

They are often vague, implicit, contextual, and sometimes even the Owner isn't fully aware of them.

Thus, many collaboration failures aren't due to the Agent lacking execution ability, but because the Owner cannot transmit their true intent to the Agent without heavy loss.

This echoes John Boyd's OODA Loop:

Observe → Orient → Decide → Act

Many people only see "Act" (speed of execution).

But what Boyd truly emphasized was precisely Orient: orientation.

If your orientation is wrong, the faster you act, the faster you die.

Today's Agents are massively accelerating Act.

But if the Owner cannot help the system achieve a better Orient—meaning, helping the Agent understand goals, boundaries, context, and value hierarchies—then faster execution only brings deviation sooner.

Therefore, PD is not trying to make the Owner write longer, more perfect Prompts every time.

That is unrealistic.

What PD aims to solve is:

How do we translate the Owner's infrequent, expensive, and implicit judgments into highly reusable system assets?

For instance, an Owner tells the Agent:

Do not modify core files before understanding the current state.

This sentence is short.

But behind it lies a massive amount of implicit experience:

• Was tortured by Git conflicts in the past;
• Knows that touching core modules affects everything;
• Distrusts localized patches;
• Values investigating before acting;
• Hates unverified assumptions;
• Values long-term maintainability over short-term completion.

If this sentence just stays in the chat history, it will quickly vanish.

What PD does is turn it into a system asset:

A single correction
→ Pain Evidence
→ Diagnostician replay
→ High-level Principle
→ Candidate Rule / Skill / RuleHost
→ Subsequent Behavioral Delta

In other words, PD's goal is not to have humans constantly correcting AI.

Quite the opposite, PD exists to reduce the need for repetitive corrections in the future.

Every high-quality intervention by the Owner should transform into a system capability that bothers the Owner one less time in the future.

---

04 Attention Protection Layer: The Owner Should Not Be System Customer Service

If the Owner is the value source of the system, then the Owner's attention is the system's most scarce resource.

This is incredibly easy to underestimate.

A terrible governance system operates like this:

Agent makes an error
→ System generates massive Pain
→ Diagnostician generates massive Principle proposals
→ Owner is forced to approve
→ Owner suffers fatigue
→ Blindly approves or simply ignores
→ Flawed principles pollute the system
→ Agent becomes harder to use
→ More Pain

This is a classic vicious feedback loop:

The Attention Overload Loop.

Left unchecked, PD itself would become a new kind of cyber-noise.

This perfectly corresponds to Herbert Simon's famous insight:

Information consumes the attention of its recipients.

In the AI era, information is no longer scarce.

Advice is no longer scarce.

Proposals are no longer scarce.

Code is no longer scarce.

What is truly scarce is: where can humans still direct their attention?

Therefore, PD must design an Attention Protection Layer.

It must be responsible for filtering, compressing, clustering, sorting, and delaying.

Not every tool error is elevated to Pain.

Not every Pain generates a principle proposal.

Not every principle requires Owner approval.

Not every conflict must immediately interrupt the human.

Not every piece of history is stuffed into context.

The Owner should not be the system's customer service representative.

The Owner should be the system's Supreme Court.

This isn't about elevating the Owner's status, but about protecting the system's most critical value generator from burning out.

In system dynamics, Owner Attention Budget can be viewed as a critical Stock.

Every low-quality interruption depletes it.

Every high-quality compression protects it.

When the Owner's attention is well-protected, they finally have the capacity to do what truly matters:

• Judge direction;
• Approve principles;
• Reject noise;
• Handle exceptions;
• Bear the ultimate arbitration;
• Reflect on whether their own goals need updating.

The essence of PD's governance design is to make the Owner perform fewer low-leverage actions and more high-leverage judgments.

---

05 From Encyclopedia to Common Law: How Does a Single Intervention Become a Long-Term Asset?

To understand PD's co-evolution mechanism, we can borrow from a highly mature system in human society: the Judicial System.

Early Prompt Engineering felt very much like trying to write a perfect encyclopedia, or a statutory code that exhausted every possible scenario.

Writing all principles, norms, pitfall warnings, engineering experiences, and caveats into the System Prompt.

It seems comprehensive.

But in a real, complex environment, it quickly runs into problems:

• Too many clauses cause a context run;
• Abstract principles conflict with each other;
• Rules are left unmaintained after they become outdated;
• It's impossible to tell which rule applies in a specific scenario;
• The model selectively forgets during long-range tasks.

PD is more like a "Common Law" (Case Law) system.

It doesn't seek to exhaust all truth at once.

It lets the system grow through real cases.

A single Pain Evidence is like a real legal dispute.

The diagnostician replays the scene of the accident and analyzes the failure mode.

The Owner, acting like the Supreme Court, doesn't arbitrarily rewrite the "constitution" (System Prompt), but rules on the principle truly worth remembering behind this specific case.

If this principle passes review, it becomes a precedent for similar future scenarios.

Subsequently, it can enter different deployment channels:

• As high-level reminders in Prompts;
• As workflows within Skill packages;
• As hard intercepts in RuleHosts;
• As part of future training data.

In the future, when the Agent encounters a similar dispute, the system doesn't need to rely on the Owner to explain it from scratch again.

It can invoke historical precedents to alter current behavior.

If times change, the model gets stronger, the project structure shifts, or certain precedents begin causing side effects, the Owner can overturn, deprioritize, or archive them.

This is the elegance of PD:

It doesn't attempt to write down all wisdom in advance; instead, it allows wisdom to be adjudicated, precipitated, applied, and obsoleted through real pain points.

The essence of Common Law is not "the more rules, the better."

It is that every precedent retained comes from a real conflict and still holds guiding value for the future.

PD's principle system should be exactly the same.

---

06 Feedback Loops: How Does PD Evolve from a Single Correction to Long-Term Evolution?

As we've been discussing "co-evolution", if we unpack this term, it is not just a heartwarming slogan, but a set of real feedback loops.

Whether a system can evolve depends not on whether it has feedback, but on how it processes that feedback:

Which feedback gets amplified? Which feedback gets dampened? Which feedback should trigger immediately? Which feedback should be delayed, clustered, and compressed before processing? Which feedback should enter the Owner's attention? Which feedback should remain in the system's background?

PD's governance goal is not to strengthen all feedback, but to enhance the correct feedback loops and dampen the flawed ones.

Loop 1: The Co-evolution Enhancing Loop

The positive feedback loop PD most wants to form is this:

High-quality Owner intervention
→ Pain Evidence is captured
→ Diagnostician extracts principle
→ Principle enters Skill / RuleHost / Prompt
→ Agent's subsequent behavior improves
→ Owner's trust increases
→ Owner becomes more willing to make high-quality interventions
→ System continues to evolve

Once this loop is established, the Owner's intervention is no longer a one-time sunk cost, but a system asset.

The more seriously an Owner provides feedback, the better the system understands their judgment. The better the system understands their judgment, the fewer similar mistakes the Agent makes. The fewer similar mistakes the Agent makes, the more willing the Owner is to invest high-quality attention.

This is the co-evolution flywheel PD strives for.

Loop 2: The Attention Overload Vicious Loop

But feedback loops aren't always positive.

If the system is poorly designed, a vicious loop quickly emerges:

Agent deviations increase
→ System reports massive Pain
→ Low-quality principle proposals increase
→ Owner suffers approval fatigue
→ Flawed principles enter the system
→ Agent behavior becomes more chaotic
→ More deviations occur

This is the Attention Overload Loop mentioned earlier.

Its danger lies in the fact that the system superficially appears to be "learning actively," but in reality, it is burning the Owner's attention on low-quality governance.

This kind of system gets noisier. Heavier. More annoying.

Eventually, the Owner loses patience and begins blindly approving, or gives up on governance entirely. Once the Owner gives up governance, PD loses its source of value.

Loop 3: The Rule Debt Loop

Episode IV discussed rule explosions.

From a system dynamics perspective, this is also a feedback loop:

More Pain
→ More principles
→ More rules
→ More activation noise
→ Agent becomes overly conservative or chaotic
→ Task completion quality drops
→ New Pain increases
→ System continues to generate more rules

This is the rule debt loop.

The problem with many systems is not that they "don't learn," but that they learn "too fragmentedly, too hastily, and too shallowly."

Every pain generates a rule. Every exception gets a patch. Every failure stuffs a reminder into the Prompt.

In the end, the system superficially accumulates a lot of wisdom, but actually takes on massive debt.

A truly mature system must be able to distinguish:

Which pain is worth precipitating? Which pain is just noise? Which principles should be retained? Which rules should be pruned? Which experiences have been overridden by model capabilities and should exit the stage?

Smart systems don't just remember. Smart systems also forget.

---

07 Feedback Delay: Why Late Feedback Causes System Oscillation?

When discussing feedback loops, one variable is particularly easy to underestimate:

Feedback Delay.

Feedback delay is the time gap between an event occurring and the system capturing, understanding, and processing it, to ultimately altering future behavior.

In PD, this delay can appear in many places:

Agent makes an error → Owner discovers it
Owner discovers it → Pain Evidence is recorded
Pain is recorded → Diagnostician completes post-mortem
Principle is extracted → Owner approves
Owner approves → Deployed to Skill / RuleHost
Deployment complete → Agent demonstrates behavioral delta in similar tasks

This pipeline looks natural, but every segment contains delays. Once the delay is too long, the system faces three types of problems.

First, Broken Causal Chains

If feedback arrives too late, both the Owner and the system forget what actually happened.

The error scene has dissipated. The context is lost. Why the Agent did what it did, why the Owner was angry, and what the real pain point was—all become blurred.

Thus, the diagnostician can only extract principles based on fragmented information. This leads to a very dangerous consequence:

The system might not learn the true root cause of the accident, but only the superficial traces left behind.

For example, a failed refactoring might actually be caused by "acting before understanding the call chain." But if the feedback is late, the system might only remember "too many files were modified this time," thus generating a mechanical rule:

Do not modify more than 3 files.

This rule seems useful, but it misses the true principle. Next time, the Agent might only modify 2 files, yet still cause a disaster because it didn't understand the call chain.

Second, Deviations Accumulate During the Delay

Feedback delay has an even more practical problem: before the feedback arrives, the system might have already traveled far down the wrong path.

An Agent starts acting based on flawed assumptions. The Owner doesn't discover it in time. Pain is not triggered in time. Diagnosis has not yet occurred. Rules have not yet been deployed.

So the Agent keeps executing. Keeps modifying. Keeps calling tools. Keeps expanding the blast radius.

By the time the feedback truly arrives, the system is no longer facing a minor deviation, but a chain of accidents.

This is why high-execution systems are particularly afraid of feedback delay. A low-execution human employee deviating for a day might only do one or two things wrong. A high-execution Agent deviating for ten minutes might have modified dozens of files, generated flawed docs, and submitted a batch of mutually polluting patches.

The faster the execution, the more dangerous the feedback delay.

Third, System Oscillation

Both cybernetics and system dynamics highly emphasize feedback delays. Because overly delayed feedback causes the system to "overcorrect."

A simple example: If a room is already getting cold, but the thermostat only senses it much later, it turns the heat on full blast; once the room is too hot, it again realizes it too late, and turns the AC on full blast.

The result is not stability, but alternating hot and cold oscillation.

PD is the same. If the Owner discovers the Agent has been overly aggressive much later, they might add many strict rules at once. With too many rules, the Agent becomes overly conservative. The Owner then feels the system is too slow, too timid, and too annoying, and starts relaxing the restrictions. Once relaxed, the system deviates again.

This is governance oscillation:

Deviation
→ Late feedback
→ Over-adding rules
→ System rigidity
→ Late feedback
→ Over-relaxing
→ Deviation again

Many complex systems don't die from a lack of feedback; they die from late feedback, crude feedback, and overreactions.

Delay Is Not Always Bad

But one thing must be clarified here:

Feedback delay is not always bad.

Some feedback must be fast. Some feedback must be slow.

Second-level feedback is suited for hard risks:

Deleting files
Executing dangerous commands
Database migrations
Unauthorized pushes
Permission anomalies

These cannot wait for the Owner's evening post-mortem; they must be intercepted immediately by RuleHost or runtime guardrails before tool execution.

Minute-level feedback is suited for task deviations:

Repeated retries
Tool loops
Goal drift
Rising GFI (Ghost Feedback Index)
Meaningless Diff expansion

These can first be handled by the system slowing down, prompting, or switching strategies, not necessarily bothering the Owner immediately.

Hour-level feedback is suited for task post-mortems:

Where did this task go wrong?
Where were the Owner intervention points?
Did a recurring pattern emerge?
Does a Pain Evidence need to be formed?

Day-level or week-level feedback is suited for principle evaluation:

Did a certain principle actually improve behavior?
Did a certain rule cause false positives?
Did a certain Skill reduce the Owner's burden?
Have certain old guardrails been overridden by stronger model capabilities?

In other words, PD is not trying to turn all feedback into instant feedback.

What PD aims to do is place different feedback into the correct time scales.

A truly mature system isn't always "the faster, the better." It is fast where it needs to be fast, slow where it needs to be slow, waits when it should wait, and forgets when it should forget.

---

08 Bottlenecks and Leverage Points: They Are Not the Same Thing

Having discussed feedback loops and feedback delays, we need to introduce another concept:

Bottlenecks and leverage points are not the same thing.

They are often used interchangeably, but in PD, they must be clearly distinguished.

Bottlenecks answer:

What is currently constraining the system?

Leverage points answer:

Where can we intervene with the lowest cost to leverage the biggest change?

A bottleneck is the point limiting the system's throughput, quality, or evolutionary speed. A leverage point is a high-impact intervention point.

A bottleneck is often a high-leverage point, but a leverage point is not necessarily a bottleneck.

For example:

Owner Attention = Bottleneck + Leverage Point
Intention Compression Quality = Bottleneck + Leverage Point
Feedback Delay Control = Leverage Point, sometimes Bottleneck
Time Scale Separation = Leverage Point, not necessarily a single Bottleneck
Rule Dissipation Mechanism = Leverage Point, used to prevent the bottleneck from clogging with debt

This distinction is crucial. Because if we treat all leverage points as bottlenecks, we overprotect them, leading to system rigidity. If we treat true bottlenecks as ordinary modules, we casually deplete them, leading to system collapse.

Several Key Bottlenecks in PD

First, Owner Cognition Bottleneck

This is the highest-level bottleneck.

The Agent can execute, but the Owner decides the direction. The Agent can generate proposals, but the Owner judges what is worth doing. The Agent can call tools, but the Owner bears the irreversible consequences.

If the Owner's sense of purpose, judgment, and value hierarchy are unclear, the stronger the Agent, the faster the deviation.

Therefore, the Owner's cognition is not a normal input; it is the system's ceiling.

Second, Owner Attention Bottleneck

The Owner cannot process infinite Pain, principle proposals, rule conflicts, and exception approvals. If all problems are pushed to the Owner, the Owner degrades from the "Supreme Court" into "System Customer Service."

Once the Owner enters customer service mode, the system's value source gets flooded by low-quality tasks.

Third, Intention Compression Bottleneck

The Owner's experience, intuition, pain, and know-how cannot be stuffed into the Agent completely intact. They must be compressed.

But the compression quality determines the system's learning quality.

Too specific, it becomes a dead rule. Too abstract, it becomes a platitude. Only when compressed well does it become a transferable principle.

Therefore, the diagnostician's intention compression capability is also a key bottleneck in PD.

Fourth, Structured Input Bottleneck

Different modules need different quality inputs.

The Owner needs actionable cases, not raw logs. The Diagnostician needs complete accident scenes, not a single complaint. The RuleHost needs structured states, not vague wishes.

If you feed garbage into the bottleneck, the bottleneck will output garbage judgments. This is why bottleneck links must be protected.

Why Must Bottlenecks Be Heavily Protected?

Here we can borrow Eliyahu M. Goldratt's Theory of Constraints (TOC).

The Theory of Constraints has a very simple but powerful intuition:

The overall throughput of a system is constrained by its narrowest link.

Optimizing a non-bottleneck often just creates localized busyness. Protecting the bottleneck is the only way to protect the throughput quality of the entire system.

Applied to PD:

Wasting a minute of the Agent's time might just be wasting compute. Wasting a minute of the Owner's time might be wasting the entire system's value judgment capability.

Agents can scale horizontally. The Owner's high-quality judgment is very hard to scale horizontally.

Models can be swapped. Tools can be added. Scripts can run in parallel.

But the Owner—who truly understands the project's long-term goals, bears the real consequences, and knows what a certain Pain truly means—is usually only one person, or very few people.

So the Owner is not a normal resource. The Owner is the constraint resource.

Giving Bottlenecks High-Quality, Predictable Inputs

Protecting the bottleneck is not just "keeping it from being too busy." More importantly:

Give the bottleneck high-quality, predictable, and actionable inputs.

What is delivered to the Owner shouldn't be a pile of raw logs, but a "Case Package":

1. What Pain occurred?
2. Is this a recurring pattern?
3. How severe is the impact?
4. What high-level principle did the Diagnostician extract?
5. What is the candidate rule or Skill?
6. What are the potential side effects?
7. Suggested action: Ignore / Observe / L1 / Skill / RuleHost / Retire

What is delivered to the Diagnostician shouldn't be "The Agent messed up again," but a complete accident scene:

Goal
Context
Trajectory
Tool Calls
Modified Content
Point of Failure
Owner Intervention Point
Cost
Similar History

What is delivered to the RuleHost shouldn't be "Please be careful" (a natural language wish), but structured states:

Operation Type
Impacted Files
Risk Level
Is Synced?
Has Tests?
Needs Approval?
Current Task Scope

A good system doesn't make the bottleneck busier. A good system ensures the bottleneck only processes what it absolutely should process.

This is PD's Owner Constraint Protection.

It contains at least four actions:

Filter: Filter out low-value inputs
Cluster: Cluster similar Pains
Package: Package into actionable cases
Schedule: Deliver to the Owner at a predictable cadence

The ultimate goal is not to have the Owner manage more, but to ensure every Owner intervention has higher leverage:

Fewer Interruptions
High Quality
Actionable
Precipitable
Reusable

---

09 Where Are the True Leverage Points?

In Thinking in Systems, Donella Meadows discussed an important concept regarding Leverage Points:

In complex systems, the most powerful intervention points are rarely the most conspicuous parameters, but rather the goals, rules, information flows, and paradigms.

This is crucial for PD.

If we view the Agent system as an ecosystem, the true leverage points aren't simply:

• Switching to a larger model;
• Adding a longer context window;
• Adding more tools;
• Adding more rules;
• Adding more Prompts.

These are useful, of course, but they are rarely the highest leverage points.

There are at least seven critical leverage points in PD.

Leverage Point 1: Sensing Bandwidth

What a system can see dictates what it can learn.

If an Agent can only sense tool errors, it will at best grow into a robot exceptionally skilled at handling API failures.

But if the system can sense:

• Goal drift;
• Unverified assumptions;
• Arbitrary expansion of modification scope;
• Repeated Owner corrections;
• Decline in user trust;
• Increased maintenance costs post-refactoring;

Then the system gains the opportunity to learn higher-level behavioral patterns.

The sensing layer determines the ceiling of governance.

Unseen pain cannot be reflected upon. Unreflected pain will only recur.

Leverage Point 2: Owner Attention Protection

The Owner is the source of value, but the Owner's attention is a finite resource.

If the system continuously bombards the Owner with low-quality signals, the Owner will suffer fatigue. Once fatigued, they will either blindly approve or completely abandon governance.

Therefore, PD cannot solely pursue discovering more problems. It must pursue presenting fewer, but more accurate, problems.

A truly good governance system does not make the Owner manage more. It ensures the Owner only intervenes at critical leverage points.

Leverage Point 3: Intention Compression Quality

Whether a single piece of Owner feedback can be compressed into a high-quality principle is the key to the system's evolutionary efficiency.

Low-quality compression produces junk rules. Overly specific compression leads to overfitting. Overly abstract compression degrades into platitudes.

A good diagnostician must compress a specific Pain into a principle that is abstract enough yet still actionable.

For example:

Bad compression: Remember to git pull before pushing.
Good compression: Understand the current state before acting; never operate based on unverified assumptions.

The former only solves one Git scenario. The latter can migrate to refactoring, debugging, deleting files, executing commands, and product decisions.

Leverage Point 4: Activation Precision and Dissipation Mechanisms

More principles are not always better. Harder rules are not always better.

If a principle is activated in the wrong context, it becomes interference. If a rule is outdated but doesn't exit the stage, it becomes debt.

Thus, the system must possess a metabolism:

• Only activate a few principles in highly relevant scenarios;
• Deprioritize long-ineffective principles;
• Remove already-internalized rules from the context;
• Gradually dismantle scaffolding overridden by stronger model capabilities.

This is exactly the pruning mechanism discussed in Episode IV.

A smart system doesn't just remember. A smart system also forgets.

Leverage Point 5: Feedback Delay Control

If feedback is too fast, the system overreacts to noise. If feedback is too slow, the system loses the causal chain and may even oscillate.

Therefore, PD doesn't pursue a "real-time feedback cult," but establishes a tiered feedback cadence:

High-risk actions: Instant interception
Task deviations: Minute-level deceleration
Task post-mortem: Hour-level precipitation
Principle evaluation: Day/week-level observation
System evolution: Month-level pruning and migration

Feedback delay itself is not the enemy. Uncontrollable feedback delay is the enemy.

Leverage Point 6: Bottleneck Protection

The Owner, the Diagnostician, and the RuleHost can all become bottlenecks at different levels.

A bottleneck is not a bad thing. A bottleneck simply tells us: where the system's true scarcity lies.

If the bottleneck is Owner attention, the Owner cannot be treated as customer service. If the bottleneck is diagnosis quality, the structure of Pain Evidence must be improved. If the bottleneck is the RuleHost's judgment stability, it must be given definitive, structured states.

Protecting the bottleneck means protecting the evolutionary quality of the entire system.

Leverage Point 7: Time Scale Separation

PD is not a single-scale system.

It must simultaneously process feedback across different time scales:

Seconds: Tool errors, command failures, permission blocks
Minutes: Task drift, repeated retries, GFI spikes
Hours: Task post-mortem, Pain Evidence archiving
Days: Behavioral delta in similar tasks
Weeks/Months: Are principles outdated? Should rules be pruned?
Longer cycles: Are the Owner and Agent leveling up together?

Many systems fail because they mix all feedback into a single time scale.

A second-level error shouldn't always alarm the Owner. A month-level value judgment shouldn't be left to local tool feedback.

Time scale separation is a necessary condition for intelligent systems to move toward stable evolution.

---

Epilogue: Giving a Paddle to Those Who Refuse to Lie Flat

If Episode I discussed how humans can avoid becoming typists, then Episode V must answer:

How do humans become helmsmen again?

PD's ultimate destination is not making decisions for humans.

Its goal is to help humans precipitate their judgment, principles, pain, and experiences into system capabilities.

The Agent expands execution bandwidth. PD precipitates feedback and principles. The Owner provides direction, meaning, and ultimate arbitration.

Together, the three form a multi-scale feedback system.

But whether this system can truly run depends on whether it respects the most fundamental laws of complex systems:

Correct feedback loops must be enhanced. Flawed feedback loops must be dampened. Feedback delays must be managed in tiers. Bottleneck links must be heavily protected. The Owner's attention cannot be treated as a cheap resource. The Diagnostician cannot blindly summarize from fragmented scenes. The RuleHost cannot enforce hard rules based on vague wishes.

True co-evolution is not making AI execute faster on behalf of humans, but allowing human judgment to be continuously made explicit, precipitated, calibrated, and amplified through feedback loops.

This is not traditional software engineering. It isn't just machine learning either. It is a form of emerging AI Systems Engineering: designing an intelligent system that can execute, reflect, and be governed by humans within a long-cycle, multi-feedback, human-machine hybrid ecosystem.

At this point, PD is no longer just a technical issue. It touches upon a massive zeitgeist.

AI's advancement will inevitably reshape work. Many roles will vanish. Many skills will depreciate. Many people who once relied on proficient execution for a stable life will suddenly find themselves pushed to the edge of the cliff by the era.

This isn't just a simple technical problem. It's a human problem.

If the AI era only rewards the few who are best at harnessing models, while directly abandoning the vast majority who couldn't turn around in time, then this era, no matter how efficient, will seem too cold.

PD certainly cannot stop this tidal wave.

Nor should it promise to save everyone.

But at the very least, it can choose a direction:

To help those who refuse to "lie flat" to gradually precipitate their past experiences, industry intuition, lessons from failure, judgment principles, and working methods into an Agent system capable of collaborative work.

A customer service rep might lose the job of repeatedly answering questions, but their years of accumulated user emotion judgment, sense of boundaries, and crisis management experience should not be wasted.

An operator might lose the job of manually organizing reports, but their judgment on user growth pacing, content tone, and channel placement should not be discarded.

A programmer might no longer need to write every line of CRUD by hand, but their sensitivity to architectural boundaries, engineering risks, and maintenance costs remains a precious asset.

The problem is: In the past, these experiences often existed only within the human body, in their intuition, or in oral expression. They were very difficult to be inherited by a system.

What PD aims to do is provide a pathway:

Human Experience → Principle
Human Pain → Pain Signal
Human Know-how → Skill
Human Bottom Lines → RuleHost
Human Judgment → Owner Arbitration
Human Growth → Owner-Agent Co-evolution

This brings to mind Wang Yangming's concept of "Achieving the Innate Knowing" (Zhi Liangzhi).

If "Innate Knowing" is only spoken of, it becomes just another moral cliché. True "Achieving" must occur in action, in conflict, in each specific choice.

People do not become better people simply by memorizing many philosophies. People only gradually turn certain principles into instinct through repeated action, error, reflection, and calibration in real situations.

This is deeply aligned with PD's understanding of Agents.

We do not believe that writing principles into a Prompt grants a system wisdom. Similarly, we do not believe that a person can turn their life around in the AI era simply by understanding a few "large model methodologies."

A true turnaround must occur in action.

The Owner executes via the Agent, the Agent exposes deviations, PD captures the pain, the diagnostician distills principles, the Owner arbitrates, and the principles return to the next action. In this loop, the Agent is trained, the system is trained, and the Owner is also trained.

So-called co-evolution isn't just the Agent getting stronger. It is also the Owner, through iteration after iteration of feedback, stepping ever closer to the person they wish to become.

I am not sure if it can be everyone's Noah's Ark, but I still hope it can become a small boat.

When this towering wave of AI strikes, some will be crushed by the surf, some will choose to lie flat, and some will still want to grab hold of something, stand back up, relearn, and reorganize their capabilities.

PD wants to stand beside these people. It hopes to help them turn past experiences into principles, principles into a system, and the system into new productivity.

This is not just racing against AI, but evolving alongside AI; not just handing over the steering wheel, but striving to become a helmsman worthy of a powerful engine.

If this era is destined to have massive waves, then at least let those who refuse to lie flat possess an oar they can hold onto.

---

With this episode, PD's interim ideological loop is complete: from the flood of execution power to the failure of Prompt Injection; from pain signals to soft-to-hard transformation; and finally to Owner-Agent co-evolution. Next, the real challenge returns to reality: how to turn these principles into a lightweight, stable, and highly usable open-source system.

---

— The Reed