From Pi to DSH: How Agent Harness Evolves from Scalable to Self‑Growing

1. What is an Agent Harness

An Agent Harness connects the model, prompts, tools, memory, context, permissions and external environment, deciding what the model can see, call and store, and how each action impacts the system.

Agent 能力
=
模型能力
× 上下文组织
× 工具系统
× 运行时结构
× 生命周期治理

If the Harness is fixed, the Agent’s ability boundary is predetermined by developers even as the model improves; if the Harness can be extended, users and developers can continuously add tools, skills and workflows. True self‑growth requires more than an extension interface—it must let the Agent discover gaps, generate or import candidate abilities, safely activate them at runtime, verify effectiveness, roll back on failure, distill successful changes into reusable components, and retire obsolete abilities.

2. Pi: Minimal core for maximal extensibility

2.1 Minimal does not mean lacking capability

Traditional agents embed many built‑in features (planning, sub‑agents, permission checks, MCP integration, background tasks, long‑term memory, sandbox, todo system). Pi instead provides a tiny core and exposes extensibility points.

2.2 Four kinds of Pi extensions

2.2.1 Extensions – change runtime behaviour

Register tools and commands

Listen to tool calls

Intercept or modify behaviour

Alter context

Switch models

Add permission checks

Implement custom UI

Override built‑in tools

Connect external systems

2.2.2 Skills – inject on‑demand capabilities

When to use a method

How to execute a workflow

How to call external commands

How to handle a project type

How to check output quality

Skills are loaded on demand so the Agent does not keep all knowledge in context.

2.2.3 Prompt Templates – solidify interaction patterns

Code review

Architecture analysis

Release checks

Test generation

Fault diagnosis

Templates change the entry point and interaction structure.

2.2.4 Packages – distribute complete capabilities

Packages bundle Extensions, Skills, Prompt Templates and Themes and can be installed via npm, Git or a local path, even temporarily for a single run.

Pi Package
├── Extensions
├── Skills
├── Prompts
└── Themes

2.3 Key breakthrough: the Agent can modify the Harness

Pi encourages users to write extensions themselves, reload the Harness, and continue the task. The workflow changes from "human builds Harness → Agent uses Harness" to "human defines goal → Agent modifies Harness → Agent uses the modified Harness" – a step toward self‑growth.

3. Behaviour autonomy vs structural autonomy

3.1 Behaviour autonomy

Decide the next step

Choose which tool to call

Decompose the task

Modify files

Run tests

Adjust the plan based on results

Here the tool set is fixed in advance.

3.2 Structural autonomy

Create new tools

Install new components

Replace memory

Change context strategy

Adjust model router

Modify permission rules

Compose new execution flows

Unload ineffective components

Pi already opens a path for structural autonomy, but the extension mechanism mainly answers "how to add a new ability".

4. DSH: Runtime foundation for self‑growth

4.1 Context – explicit, traceable, reversible runtime operations

A component cannot access all system state directly; it must obtain needed capabilities through Context, which both decouples components and defines their ability boundaries.

Context
├── Model Registry
├── Tool Registry
├── Memory
├── Event Bus
├── Session
├── Logger
├── Storage
├── Permission
└── Environment

Examples of limited Context usage:

Model Registry
Task Metadata
Usage Metrics

Session Events
Embedding Service
Storage
Context Injector

Tool Registry
Credentials
Network
Logger

4.2 Effect and Cleanup – reversible changes

When a component joins the Harness it produces side effects such as registering a tool, starting a background task, or changing model routing. DSH requires each Effect to return a corresponding Cleanup function.

function activate(context) {
  const unregister = context.tools.register(myTool);
  return function cleanup() {
    unregister();
  };
}

More complex components may produce multiple side effects:

function activate(context) {
  const stopTool = registerTool(context);
  const stopListener = registerListener(context);
  const stopWorker = startWorker(context);
  const closeConnection = connectDatabase(context);
  return async function cleanup() {
    await stopWorker();
    stopListener();
    stopTool();
    await closeConnection();
  };
}

4.3 Temporal composability – safe trial and error

Effect and Cleanup give a component a full lifecycle: create → activate → run → deactivate → cleanup. This makes it possible to experiment with new abilities without permanently polluting the system.

t₀: Harness original state

t₁: Component enters → register tool, start service, inject context

t₂: Component runs

t₃: Component exits → remove tool, stop service, revert context

t₄: Harness returns to predictable state

4.4 Coeffects – make dependencies first‑class runtime data

Coeffects declare what external capabilities a component needs. The runtime can decide whether the component can be activated, and can automatically deactivate it when a required capability disappears.

Component = {
  coeffects: ["embedding-model", "vector-storage", "session-events"],
  effect(context) {
    // activate memory
    return cleanup;
  }
}

Activation logic:

if (all dependencies satisfied) {
  activate component;
} else {
  keep component inactive;
}

if (dependency disappears) {
  run cleanup;
}

4.5 Spatial composability – avoid unordered accumulation

Components are not hard‑coded in a fixed order; they form a dynamic dependency graph. When a capability appears, dependent components activate; when it disappears, they are safely removed.

Credential → GitHub Provider → GitHub Tool → Repository Agent

4.6 From dynamic recomposition to a self‑growth loop

DSH defines five stages that turn a mere extension system into a controlled self‑growth process.

Discover ability gaps (e.g., missing tool, unsupported protocol, insufficient memory, unsuitable model, missing validation, security constraints, high latency).

Generate or import candidate abilities (write new tool, create new skill, install a package, wrap an external API, compose existing components, replace a memory provider, adjust model router, create a new workflow, launch a sub‑Agent, add an adapter layer).

Activate candidates in an isolated Context, specifying allowed directories, network services, credential access, tool registration rights, global‑state mutation limits, resource caps, execution time limits, and required effect registration.

Validate the activation (task completion, unit‑test pass, no regression, no undeclared side‑effects, permission scope, cost reduction, success‑rate improvement, no context bloat, no conflict, complete cleanup). Outcomes: keep, modify & retry, or rollback.

Persist successful abilities as reusable components with metadata (implementation, capability description, coeffects, permissions, validation records, version, provenance, metrics, effect, cleanup) and later evaluate, upgrade or retire them.

5. Core differences between Pi and DSH

Goal: Pi – build an open, customizable Agent Harness; DSH – build a runtime that supports dynamic changes.

Ability source: Pi – Extensions, Skills, Prompt Templates, Packages; DSH – runtime components and their dependencies.

Change initiator: Pi – user/developer (Agent can assist); DSH – user, system, or Agent.

Component organization: Pi – extension resources & packages; DSH – dynamic dependency graph.

Activation: Pi – load, temporary load, reload; DSH – activate based on Context & Coeffects.

Lifecycle: Pi – centered on extension loading and configuration; DSH – symmetric Effect ↔ Cleanup management.

Dependency governance: Pi – handled by extension code and package managers; DSH – explicit runtime dependency handling.

Failure handling: Pi – depends on extension implementation, process or session boundaries; DSH – component‑level rollback via Cleanup.

Evolution direction: Pi – from fixed product to open platform; DSH – from open platform to controlled self‑growth.

Core value: Pi – make the Harness easy to change; DSH – make the Harness safe to change continuously.

6. From extensible to self‑growing: what is still missing

The three evolutionary stages are:

Fixed abilities (model + static prompts + static tools).

Open extensibility (stable core + Extensions + Skills + Packages + open API).

Controlled self‑growth (stable core + gap detection + candidate generation + dynamic runtime + explicit dependencies + reversible effects + isolated validation + automatic rollback + ability consolidation + continuous retirement).

7. Self‑growth is not unlimited growth

Uncontrolled addition leads to tool bloat, duplicated capabilities, version conflicts, ever‑expanding permissions, context overload, unreadable routing, lingering listeners, and unpredictable behaviour. Sustainable growth requires four capabilities: add, select, clean up, and forget.

Increase
+
Select
+
Cleanup
+
Forget

8. Conclusion

Pi proves that an Agent Harness can be an open, user‑customizable platform. DSH takes the next step by turning every change into an explicit, traceable, reversible runtime operation, enabling Agents to discover gaps, generate candidate components, experiment safely, and solidify only validated abilities. Only when an Agent can add, verify, roll back, clean up and retire capabilities does the system truly move from "scalable software" to a "sustainably self‑growing system".