How to Build a Continuous Learning Loop with OpenPond

A useful learning loop does not need to begin with a model that rewrites itself. Start with repeated facts, a stable review process, durable history, and a human follow-up surface.

Ducky Capital's daily Hyperliquid trade review is one concrete example. The design is reusable by any client integrating OpenPond.

The architecture

OpenPond owns the published Profile release, action catalog, sandboxed runtime, and Saved Work scheduler. The client application owns users, task history, workflow bindings, authorization, and private capability resolution.

That boundary matters. OpenPond does not need a copy of the client's user database, and the client does not need to recreate an agent runtime inside its web application.

1. Publish a source-visible Profile

Keep instructions, schemas, tests, and evals in a normal public repository. Ducky's example lives in duckailabs/ducky-capital-skills and uses the public OpenPond Agent SDK.

The Agent action declares the capability it needs—such as recent-hyperliquid-fills—but does not know how the client maps a user to a wallet. Inputs stay portable and bounded, for example a 24-hour lookback and a selected environment.

2. Install the Profile and pin its actions

An administrator installs the Profile for the client account. The client reads the published action catalog and pins the expected action key and release metadata. Do not accept arbitrary agent identifiers from the browser.

This makes every invocation inspectable: the client knows which source release ran, which input schema was used, and which artifacts were returned.

3. Let OpenPond schedule; let the client own Tasks

Saved Work is the scheduler. The client stores only an owner-scoped binding between its user and the OpenPond definition. When a schedule fires, OpenPond sends a signed, verifiable callback. The client validates the binding and upstream run before doing any private work.

Each Workflow remains a stable definition. Its occurrences appear in a Recent Tasks table and open the durable Task where the report, logs, outputs, and follow-up conversation live.

4. Lease the smallest private capability

The published Agent should not receive database credentials, wallet keys, or a general client API token. Instead, the client grants one run a narrow capability:

The client resolves the authenticated owner to the appropriate wallet addresses, fetches fresh fills, normalizes the result, and expires the capability with the run. No signing authority crosses this boundary.

5. Persist the result where people already work

Stream progress events into the Task and persist the compact event list with the final Markdown report. Group noisy command output under expandable work rows while keeping failures visible. The same Task can then answer follow-up questions with the report and previous conversation as context.

This is already a continuous improvement loop:

• fresh facts arrive on a schedule;
• one versioned process reviews them;
• results and evidence remain inspectable;
• the user adds corrections and context;
• later runs can be compared against earlier decisions.

A refiner can eventually propose a new Agent release from accumulated eval evidence, but it is a separate promotion process—not a prerequisite and not an automatic mutation of production behavior.

Production checklist

• Keep workflow ownership client-user scoped.
• Verify callbacks against both the local binding and upstream Saved Work run.
• Pin Profile actions instead of trusting browser-supplied agent IDs.
• Lease read-only, one-run capabilities with explicit time windows.
• Persist reports, logs, action keys, release metadata, and artifact references.
• Separate recommendation actions from wallet execution authority.
• Gate schedules and interactive runs through the same product entitlement and allowance.

That is the pattern: OpenPond schedules and runs inspectable work; the client retains identity, data authorization, and the user-facing Task.