About Triadive

Triadive is a field manual for the human / agent / robot triad — the operating environment that has quietly formed around long-running AI systems, where humans remain accountable for outcomes, agents act on their behalf inside those systems, and the underlying robots and tools do the work.

The name comes from triad: three actors working together, neither master nor servant. The site collects concepts, prompts, plugin notes, and field lessons that tend to come up again and again when an operator is building something that lasts longer than a single chat session.

OpenClaw is the recurring worked example throughout the manual, because that is where the practice is most visibly stabilizing. But the brand is broader than any one toolchain. The principles here are written to outlive the platforms they came from.

What this site is

• A reading reference, not a tutorial track. The pieces here are written to be returned to, not read end-to-end.
• Concept-first. Plugins, prompts, and integrations are easier to reason about once the underlying concept is clear. Most articles here try to lead with the concept.
• Portable across platforms. When a lesson is specific to OpenClaw surface area, it is flagged. When it is a principle, it is written so it can travel to other agent runtimes, other stacks, and other decades.
• General lessons, anonymized. When articles draw on operational experience, the patterns are abstracted so they remain useful without revealing the specific operator, scale, or tooling choices that produced them.

What this site is not

• Not a clone of any one platform's documentation. Official docs remain the authoritative reference for surface area, configuration syntax, and release notes. This site treats those docs as a baseline.
• Not a place for product reviews, vendor comparisons, or plugin rankings. The aim is durable pattern knowledge, not a buyer's guide.
• Not a news site. New releases and breaking changes are covered elsewhere; here the focus is on ideas that age slowly.

Audience

Triadive is written for the operator who has decided to put real work into a long-running AI setup — whether that means a single workspace, a small team, a multi-agent configuration, or a system that coordinates people, models, and physical hardware. The default assumed reader has done a first onboarding, has at least one working channel, and is now asking questions about how to make the system dependable.

If that sounds like you, welcome.

Editorial principles

• Anonymize before publishing. Examples use generic operators, fictional workspaces, and abstracted scale. Real names, real bots, and real configurations stay private.
• Generalize before claiming. Specific anecdotes are rewritten as principles. If a lesson cannot survive that rewrite, it does not go public.
• Cite, don't paraphrase. When a piece references platform surface area, it links to the relevant documentation page rather than restating it.
• Restraint over coverage. Better to publish a few durable pieces than many disposable ones.

How to read the site

The four main buckets — Concepts, Plugins, Prompts, and Lessons — are organized so a beginner can start at the top and an experienced operator can dip in for the specific pattern they need.

A short reading order for someone new:

1. The Concepts intro piece — to get the vocabulary. 2. The Plugin selection rules — to avoid the first obvious trap. 3. The Lessons on memory and continuity — because these are the topics that quietly cost the most time once you are past week one.

About the editorial voice

Triadive is written under a single editorial byline. The voice is meant to be plain, deliberate, and respectful of the reader's time. If a piece ever reads as if it is selling something, that is a bug and should be reported.

Contact

For corrections, suggestions, or general correspondence, see the contact page.

How the site is built

Triadive is a static site. The content is written in plain Markdown, the structured data is in frontmatter, and the pages are rendered once at build time. The build is deterministic: the same input produces the same output, and the build's output is committed to the deployed artifact. The site is hosted on a CDN; the CDN caches the HTML, the CSS, and the JavaScript, and the site loads in a single round trip.

The site's build pipeline is small, on purpose. The build is a single Python script that takes the Markdown content and produces the HTML; the build is fast enough to run on a laptop, and the build is reproducible enough that the deployed artifact can be audited. The build does not depend on a database, and the build does not depend on a runtime. The build is the only piece of infrastructure that needs to be trusted.

Why a static site

A static site is the right choice for a working field manual because a static site is durable. A static site does not depend on a runtime, a database, or a backend; a static site is just a set of files that can be served from any HTTP server. A static site can be archived, mirrored, and backed up trivially; a static site can be read by any browser; a static site can be served by any CDN.

The static site also makes the editorial process more honest. The content is the source of truth; the build is the transformation. The build can be re-run, the build can be audited, and the build can be reviewed. There is no second source of truth. The static site is the right choice for a site whose value is the content.

How the editorial process works

The editorial process is also small. The pieces are written in Markdown, the pieces are reviewed by other operators, and the pieces are published when the review is complete. The pieces are not gated by a newsletter, not behind a paywall, and not restricted to a particular audience. The pieces are public.

The pieces are updated when the underlying pattern changes. The updates are tracked in the piece's history, and the dated correction note is shown at the top of the piece when the update changes the substance of the piece. The pieces are not finished essays; the pieces are living records.

Editorial team and disclosure

The editorial team, correction policy, and disclosures are documented in the site-wide E-E-A-T block at the bottom of every page. Triadive was launched in 2024 and publishes under a single editorial byline.