How I Put an OpenClaw Multi-Agent Workflow into Production on WeCom

The short answer is that OpenClaw becomes useful to an enterprise only after the interaction surface, agent roles, skills, deterministic actions, permissions, and human handoff have been separated.

In an anonymized cross-border logistics workflow, I run two agents inside the WeCom groups where employees already work. A customer agent receives and normalizes inquiries. A supplier agent coordinates supplier matching, quotation work, and the return path. This is a production-running workflow, not a demo, but I do not publish the client identity, location, operating volume, commercial terms, or business outcomes. This note is limited to operating facts, reusable methods, and failures I personally encountered.

This is not an installation tutorial. Most of the work that determines whether an agent can survive production begins after installation.

Why OpenClaw: surface first, control second, model intelligence third

1. Put the agent where the work already happens

The employees in this workflow already operate in WeCom. Moving them into a new AI console would create adoption work before solving business work.

OpenClaw gave me a way to connect an agent runtime to the existing surface while keeping control of workspaces, skills, scripts, and the data layer. The WeCom team now maintains an official OpenClaw plugin, but connectivity is only the entry point. It does not create a production operating model by itself.

2. Whoever owns the result must own the deterministic controls

Semantic interpretation and choosing the next bounded capability can belong to a model. Writes, deduplication, state changes, amounts, and data integrity belong in deterministic code and database constraints.

Do not ask a prompt to carry responsibility that belongs to a database. Do not ask a model to carry accountability that the organization has not assigned to a person.

3. Compare model intelligence last

Once the workflow boundary, validation rules, knowledge, and scripts are explicit, many normal cases require less model capability than expected. Designing the operating system first and routing models second has been more reliable than sending every request to the strongest model.

The five-layer production architecture

Layer	Owns	Must not own
WeCom surface	messages and the employee’s existing work context	business rules
Agent	role context and orchestration across capabilities	every implementation detail
Skill	one independently understandable, testable, upgradeable capability	hidden changes to unrelated state
AGENTS.md and operating rules	collaboration, allowed skills, stop and escalation rules	a large body of volatile domain knowledge
Deterministic scripts and database	writes, locks, deduplication, state, validation, and audit	open-ended semantic judgment

The customer and supplier agents are not separate for the sake of calling the system “multi-agent.” They represent different operating perspectives, knowledge, and action boundaries. I add another agent only when a role needs its own persistent context, tool set, or responsibility boundary.

Three rules for separating agents and skills

Agents follow roles and responsibility

An agent represents a perspective that must remain stable across a workflow. It knows whom it serves, which segment it handles, and when it must transfer work to another agent or a person.

Skills follow independently testable capability

A capability belongs in a skill when I can give it sample inputs, inspect the outputs, and upgrade it independently. Field normalization, domain knowledge retrieval, supplier candidate matching, and quotation material preparation are examples.

If I can only tell whether a skill works by watching the whole system “seem to succeed,” it is probably too large.

Domain knowledge uses progressive disclosure

Loading the complete domain manual into every request is wasteful and noisy. A knowledge skill first maps the current scenario to a small set of relevant reference files. The calling agent then reads only those files.

This separates knowledge from architecture: a role’s knowledge can change without rewriting the collaboration structure.

Why I discarded the first version

The first version was not completely broken. It was worse: it worked often enough to encourage a growing prompt that mixed business rules, process order, exception handling, and output format. Every new exception could weaken an earlier rule. I appeared to be tuning a model, but I was maintaining an untestable program in natural language.

I replaced it by:

1. mapping triggers, inputs, decisions, writes, handoffs, and acceptance from the real work;
2. placing judgment in agents and skills while pushing mandatory actions into scripts and database constraints;
3. making cross-agent routing and stopping conditions explicit instead of leaving them to improvisation.

If an agent project begins by accumulating rules in one system prompt, the work probably has not been decomposed far enough.

The production failure prompts cannot fix: retries after an ambiguous response

During the integration between the two agents, an external action completed but its response was not parsed correctly. The model interpreted the parse failure as an execution failure and retried, producing duplicate writes. A prompt saying “do not call twice” was not a reliable control.

I added three layers:

1. Business idempotency keys and locks. The same key returns the existing result instead of calling the external service again.
2. Parser fallback. A secondary path distinguishes an unreadable response from an unexecuted action.
3. Explicit exit codes. Success, server rejection, network or parse failure, and invalid input are separate machine-readable states.

If the external service does not provide find or create semantics, the caller must guarantee idempotency. A mandatory safeguard should be a script the model invokes, not an instruction it may forget.

Human handoff is a formal node

The agent stops on missing critical fields, conflicting rules, unclear permission, irreversible action, high-risk external commitment, or an unknown accountable owner.

A usable handoff includes:

• the original request and confirmed fields;
• knowledge sources and versions used;
• actions already taken and their outcomes;
• the stop reason and risk;
• the one decision required from the person;
• the node from which the workflow should resume.

“Please review” transfers effort, not context. See the full human handoff checklist and AI agent human-owner assignment method.

When I would not recommend OpenClaw yet

I would stop before implementation when:

• the team cannot define an input, output, and acceptance threshold;
• no owner can approve rules, permissions, and exceptions;
• a high-risk system requires broad access without least privilege or rollback;
• an existing SaaS already solves the problem reliably and an agent only adds maintenance;
• nobody will own logs, failure samples, knowledge versions, and regression after upgrades.

Sometimes the most valuable advice is: you should not solve this technical problem. First ask whether it constrains a business outcome.

My 12-point production check

1. The surface is where employees actually work.
2. Every agent has a distinct role, boundary, and stop condition.
3. Every skill can be tested independently.
4. Knowledge is loaded by scenario and carries a version.
5. Writes, deduplication, and state changes use deterministic code.
6. Every external action has an idempotency key.
7. Permission expands progressively from read-only.
8. Exceptions reach a named person with complete context.
9. Logs show which knowledge and actions produced the result.
10. Upgrades replay previous failure samples.
11. Every owner has a backup and degradation path.
12. The team knows when automatic execution must stop.

Download the OpenClaw enterprise production checklist (CSV).

Evidence and disclosure boundary

• Production fact: two agents operate inside an anonymized cross-border logistics workflow on WeCom.
• Reusable method: surface-first selection, five layers, agent/skill boundaries, idempotency, handoff, and release checks.
• Real failures: the first prompt-heavy architecture was discarded; an ambiguous response caused repeated external calls during integration.
• Not disclosed: client identity, location, staffing, operating volume, supplier or quotation data, cost, fees, and business outcomes.
• No universal claim: this is one production context, not evidence that OpenClaw fits every company or guarantees the same result.

Continue with how to decompose a freight inquiry workflow, the five-level permission matrix, or the pilot priority scorecard.

Official references

• OpenClaw Skills documentation
• OpenClaw multi-agent documentation
• The OpenClaw plugin maintained by the WeCom team