Capabilities

01 — Method

From a vague ask to a spec an agent can execute

Our work starts at the sentence a client actually says — "make our onboarding smarter", "automate the reports" — and ends at something a machine can run without supervision. Closing that gap is most of the job, and it happens before a model is chosen.

Our method is a sequence, not a framework:

1. 1

   Write down what would falsify the idea.

   Before scoping anything, we write the assumptions the project depends on and how each one could be shown wrong. Assumptions that cannot be tested get cut. This is the step most often skipped, and the one that saves the most time.

2. 2

   Check whether the thing already exists.

   We search for prior art before writing a line of spec. On one of our own products we found more than forty free, open-source tools already occupying the exact space we had scoped. We stopped and repositioned rather than shipping the forty-first.

3. 3

   Reduce until one unit can be finished.

   A capability that takes months to demonstrate cannot be corrected by feedback. We cut scope until a single complete unit — one deck, one document, one workflow — can be produced end to end, then produce it.

4. 4

   Attach the verification to the artifact, not the pitch.

   An output shipped without a way to check it is a claim. The check travels with the work: what was the input, what ran, what would have caught it if it were wrong.

5. 5

   Publish the misses.

   We write up the assumptions we overturned, including the ones that were ours. A record that only contains successes is not a record.

The question is never "can the model do this". It is "what did it produce, and how do you know it is right".

02 — Where this fits

Model plus harness

The work has a name: harness engineering. Agent = Model + Harness. The harness is everything in an agent except the model — the guides that steer it before it acts, and the sensors that observe it afterwards so it can correct itself.

Two kinds of check do that observing, and the difference decides how we build. Computational controls — linters, type checkers, test suites — are deterministic, fast and cheap. Inferential controls — a model reviewing a model — are slower, costlier and semantically richer. We use computational wherever the property can be expressed as one, because a check that returns the same answer every time is evidence, and a check that does not is an opinion.

Two open standards make that work portable: Agent Skills for the instructions, MCP for how an agent reaches tools and data. The same SKILL.md folder runs in agent runtimes from several different companies, and the same MCP server answers all of them. We run ours across three runtimes from one directory. A skill built this way is a durable asset rather than a bet on one vendor.

Public directories rank by install count. We publish artifacts, traces, and checks instead.

03 — Showcase framing

Each entry below carries up to four kinds of evidence. Not every entry has all four; the ones it lacks are shown as absent rather than described.

Evidence layers

ARTIFACT

The output itself, opened in the browser, at the size it was delivered.

Nothing is summarised here. Whatever the harness produced is what you see, at the size it was delivered. Every artifact carries the date it was produced.

REPRODUCE

What we release, and what we keep.

Some of this work is published and you can run it. Some of it is client work or unreleased product, and for those we show the output and the method but not the source. Each entry states which it is, so you are never left guessing whether a missing link means "private" or "does not exist".

TRACE

The input that went in, the steps that ran, the output that came out.

A before-and-after with the intermediate steps visible. This is where "it is just a prompt" gets answered or does not: if the trace shows a single instruction and a lucky result, the entry says so.

VERIFY

The checks that run against the output, and what they would have caught.

Where a result can be checked mechanically, we attach the check. Where it cannot, we say what a domain expert would have to look at instead. An entry with no checks shows an empty field — we would rather publish the gap than describe a check that does not run.

# OpenClaw Agent 五層階層架構與團隊組建模式

> 基於 OpenClaw v2026.6.x 原始碼的深度研究（初版 v2026.2.26，2026-06-13 對照 v2026.6.2 clone 全面校訂），全面解析 Agent 從個體到團隊的五層架構，以及七種實戰團隊組建情境。
>
> 姊妹篇：《2026-02-08-OpenClaw Agent 多 Agent 互動模式與應用場景》 — 使用者端的六種互動方式與五個實戰場景
>
> > **資訊：v2026.6.x 校訂摘要**
> > 本次重大校訂涵蓋：tool profile/group 定義檔遷移（`pi-tools.policy.ts` → `tool-catalog.ts`）、新增 media/agents/nodes tool groups、`peer.kind` 由 `dm` 改為 `direct`、`maxConcurrent` 預設 1→4、`subagents.maxConcurrent` 預設 1→8、`announceTimeoutMs` 預設 60s→120s、`subagents` 管理工具僅剩 `list`（kill/steer 已移除）、bootstrap 移除 `BOOT.md` 並將 `MEMORY.md` 列為正式 bootstrap 檔、memory 改為 `backend: builtin|qmd` 架構、新增 15+ plugin hooks，以及 sandbox/heartbeat/cron/compaction 大量新欄位。標 🆙 者為本次校訂新增/修正。

---

## TL;DR（30 秒摘要）

OpenClaw 的 Agent 系統由五個可組合的層次構成：**Agent（大腦）→ Binding（路由）→ Session（上下文）→ Sub-agent（平行任務）→ A2A（跨 Agent 通訊）**。每一層解決不同的問題——從「這個 AI 是誰」到「多個 AI 如何協作」。搭配 Sandbox、Heartbeat、Cron、Memory、Hooks 等支援系統，可以組建出從個人助手到多 Agent 協作團隊的各種配置。

```
┌─────────────────────────────────────────────────────────┐
│                    Layer 5: A2A                         │
│              sessions_send / ping-pong                  │
│    ┌──────────┐  ←──────→  ┌──────────┐                │
│    │ Agent A  │            │ Agent B  │                 │
│    └────┬─────┘            └────┬─────┘                 │
│ ────────┼──────────────────────┼──────── Layer 4 ────── │
│    ┌────┴─────┐            ┌───┴──────┐                 │
│    │Sub-agent │            │Sub-agent │  sessions_spawn  │
│    │ (task 1) │            │ (task 2) │                  │

04 — Reference architecture

Ephemeral, validated delivery pipeline

A worked example of what we mean by deterministic control, described without its contents.

The pipeline takes source documents and produces a finished, self-contained deliverable at a private URL. Its behaviour is governed by three boundary controls, each of which either holds or fails — none of them depend on the model behaving well.

• Private by default.

  Publication defaults to unlisted: reachable with the link, indexed by nothing. Making something public is an explicit act, never the fallback. The default is the safe direction, so forgetting to choose cannot expose anything.

• Mandatory expiry.

  Every artifact carries an expiry date set at publish time. Access ends on schedule rather than depending on someone remembering to revoke it.

• Validation at the boundary.

  Structure and size are checked before upload, not after. A malformed deliverable fails at the point of creation, where it is cheap, instead of in front of the person it was made for.

None of the three is clever. That is the point: each is a check with two outcomes, running at a defined boundary, and none of them asks the model to be careful.

05 — Complex & regional domain knowledge

Complex and regional domain knowledge

Some specifications are adversarial test cases for a general model. National curriculum codes, tax procedure, regulatory filing rules, industry compliance schedules — the knowledge exists, it is authoritative, and it was never in the training data in a form a machine can use.

These domains are useful precisely because they are unforgiving. Ask a general model which unit a specific curriculum code maps to and it does not decline. It produces a clean, well-formatted, entirely invented answer, and the reader has no way to tell. The failure mode is not a weaker response. It is a confident fabrication that looks exactly like a correct one.

That is the case a harness has to solve, and it is solvable in one way: the specification becomes an external source of record the system reads from, never something the model recalls, and a check confirms the output against it before anyone sees the result. Correctness stops being a property of the model and becomes a property of the pipeline.

The method does not care which specification it is. A curriculum, a tax code and a compliance schedule are the same engineering problem: an authoritative external source, a model that must be prevented from improvising against it, and a check that proves it did not.

06 — Closing

info@aiviolabs.com