Architectural Evolution of a Workflow Agent Native Product: DxC's Boundary Redefinition

Phase 1: Skills as Virtual Employees, Agent as Workflow Engine

DxC (DeployX Content Workbench) is a product that completes WeChat official account content workflows through natural language. Its earliest design was straightforward: articles pass through research, briefing, outline, body, proofreading, title, visual, and delivery. Skills serve as the Agent's entry point for domain work, each encoding what to do, read, write, and when to pause for confirmation at each stage.

The author imagined Skills as a group of virtual employees, each corresponding to a role, with the Agent reading job descriptions and collaborating according to process. In real execution, however, Skills began to explain not only domain methods but also files, fields, commands, state, confirmation, and recovery. Although the CLI could deterministically execute each atomic action, the Agent still had to judge the current stage, choose commands, organize parameters, interpret errors, and decide whether to retry after failure.

The author attributed the problem to overly granular commands and began consolidating the CLI. In this round, stage judgment remained with the Agent.

Phase 2: CLI Consolidation, Agent Still Decides Orchestration

The first refactor reduced atomic commands, letting the CLI provide higher-level actions. DxC added immutable previews, confirmation snapshots, structured errors, idempotency, and delivery read-back. Many local problems disappeared.

Composition responsibility stayed on the host side. It had to decide whether to continue, preview, deliver, or repair; also to understand what a single call's ok meant — command success, stage end, or entire business completion. Seeing retryable, the Agent might interpret "technically retryable" as "should retry immediately".

External writes amplified this issue. When a request was sent but the result temporarily unknown, the Agent tended to retry. Regenerating body text usually meant rework; writing a WeChat draft again could produce a second real result.

After command consolidation, call count decreased, but the Agent still decided how to chain commands. The next refactor turned to domain action boundaries.

Where Is the Boundary of a High-Cohesion CLI Command?

The author's criterion: a single call must completely own a stable business result and all invariants that must be held while producing that result.

Take creating a WeChat draft. Splitting by existing APIs yields upload cover, upload body images, convert HTML, create draft, save delivery record — each with clear I/O and testability.

At this point the Agent must answer another set of questions: which version of body and cover does the draft bind? What if content changes after user confirmation? If draft creation times out but WeChat side may have succeeded, can we retry? If delivery record fails, does the draft count as created?

These questions collectively belong to "creating a user-confirmed, traceable WeChat draft".

A high-cohesion create-draft action should fully handle confirmation snapshots, tenant and authorization checks, asset processing, external write, result read-back, idempotency, and safe stop when result is unknown. The Agent expresses intent and triggers the action, without re-orchestrating internal steps.

A universal execute would make action intent, permissions, confirmation, and side-effect semantics fuzzy again. Reasonable action surfaces are usually small, with clear meanings, each fully guarding its own business result.

Anthropic's Agent tool design practice places design objects on high-value workflows and advises controlling tool count and clarifying action boundaries. This judgment aligns with DxC's experience; DxC's specific boundaries came from continuous adjustment in real execution.

Current DxC: Business and Technical Architecture Form a Panorama

DxC's natural language interface now consists of 14 Skills. One orchestrator Skill handles starting or continuing an article; eight process Skills cover research, briefing, outline, body, proofreading, title, visual, and delivery; five basic Skills manage project, knowledge base, quote library, memory, and creative persona.

DxC currently only closes the loop on WeChat drafts, not formal publishing or mass sending. The eight-stage process finishes an article; the five basic capabilities let subsequent creation reuse locally accumulated content and context. WeChat authorization, preview, and draft writing are centralized in the cloud.

The third-generation architecture has three boundaries: Agent only accepts work items as-is, without parsing, modifying, or rebuilding them; Skills carry methods and interaction, not replicating the machine state machine and full Schema; whether the WeChat side writes successfully is judged by authoritative cloud state and read-back.

Between user and Agent flow intent, content, choices, and explanations. Skills are domain UI, increasing the probability that the Agent does the right thing. State, permissions, and idempotency go to the deterministic application layer.

CLI parses parameters, calls application services, and expresses results via exit codes, stdout, stderr, and structured JSON. To the Agent it is a low-level domain capability; from code structure it is the adaptation entry to the domain kernel.

Shared domain kernel and Contracts hold state transitions, error types, permissions, confirmation, idempotency, and recovery. CLI, Server, and Worker obey the same machine source of truth. If MCP later exposes these actions, it should also call this kernel.

Locally stored are projects, article artifacts, local vector knowledge base, quotes, memory, and persona. Cloud holds secrets, tenants, WeChat authorization, async tasks, and external side effects. Interface timeout maps to "result unknown"; browser events only indicate open request; draft result and user confirmation are judged by authoritative state and receipt respectively.

DxC added no web configuration pages. Natural language continues to carry product interaction; articles, knowledge, and creative context accumulate locally. ADR records architectural decision rationale, AGENTS.md constrains development and collaboration boundaries, and runtime rejection of illegal states is still done by the domain kernel.

Four Principles for Agent-Friendly Tools

Does the Action Correspond to a Complete Business Result?

Tool names should express what the user wants to accomplish, not recite internal interface directories.

Internal steps that must jointly complete a business result should be owned by a single domain action. A universal execute would blur permissions, confirmation, and side-effect semantics.

Good action surfaces are usually small, with clear meanings, and avoid multiple similar tools that force the Agent to guess which to pick.

How Much Internal Context Must the Agent Understand?

Tool design often shifts complexity elsewhere: fewer commands, but parameters require the Agent to carry project state, stage, file locations, content hashes, and multiple internal IDs.

The Agent ends up maintaining the product's internal model.

For long processes, a better approach is to give the Agent an opaque, verifiable, expirable context handle. It can represent the state and constraints needed for the current stage, but the Agent has no responsibility to parse, modify, or rebuild it.

Outputs follow the same rule. Don't return a block of explanatory text that the Agent must reason about to judge business state. Inputs and outputs should be verifiable; results should clearly distinguish: action failed, awaiting user confirmation, current stage complete, entire business complete, and external result unknown.

As of August 31, 2026, the verified MCP official draft already provides protocol foundations for I/O schemas, structured results, and tool execution errors. Domain state remains partitioned by the product.

Can Side Effects Be Identified Before Call and Reconciled After?

Before calling a tool, the Agent should know whether it is read-only, reversible write, irreversible write, or an external action affecting the open world. High-risk operations need explicit permissions and human confirmation; safety cannot rest on a single sentence in the tool description.

An idempotency key represents a complete call intent. Same key, same intent can return semantically equivalent results; same key but changed body, WeChat account, or target action must be rejected.

AWS's idempotent API practice emphasizes the relationship between caller request identifiers and business intent, and discusses late requests and identifier lifecycles. These details matter more for Agent tools because Agents easily treat "retryable" as an action suggestion.

Safe recovery first judges whether the previous side effect might have already occurred. If undeterminable, preserve evidence, stop, reconcile.

Has Business Logic Been Duplicated in the Adaptation Layer?

When the same domain action is exposed via CLI, it needs stable exit codes, stdout/stderr, JSON, and local state visibility. When exposed via MCP, it needs tool discovery, description, schema, connection, and protocol vs. execution errors.

Transport differences stay in the adaptation layer; the business state machine is shared by both entry points. If CLI and MCP disagree on delivery state judgment, the product already has two sources of truth.

Why DxC Ended Up Using Opaque Work Items

DxC is a typical Workflow-type product. An article isn't finished in one call; it includes user selection, modification, confirmation, preview, and external delivery.

Early DxC split these contexts into parameters passed to the Agent. Result: the host had to know current stage, input resources, confirmation state, and next command, and persist them across conversation turns.

Work items let the product maintain context continuity itself; the host only passes them through, no longer understanding or assembling internal parameters.

A work item can bind current stage, input resources, context fingerprint, dynamic constraints, confirmation state, and unique next action. If tampered, expired, used across stages, or upstream body changed, the program rejects directly. The Agent only returns it as-is, no read, no modify, no recovery attempt.

This approach needs three supporting mechanisms.

First, CLI returns a unique mechanical next action. When creation is needed, the Agent can still judge freely; when state must advance, no more multiple-choice questions.

Second, results use discriminated structures. Call success, stage complete, awaiting confirmation, business complete, and result unknown are expressed distinctly.

Third, confirmation and idempotency both bind intent. User confirms an immutable snapshot; if body or cover changes, old confirmation invalidates. Idempotency key binds a complete side-effect intent.

Work items suit cross-stage, recoverable processes with external side effects. One-off Q&A, open exploration, and stateless tools usually don't need them. Applicability depends on whether the process truly requires long-term context and recovery capability.

Five-Layer Verification

Static contract check: whether Skill provides clear, conflict-free current action.

Domain kernel and CLI test: state machine, invariants, discriminated results, idempotency, error semantics.

Artifact evidence verification: real body, preview, and confirmation snapshot consistency.

Host smoke test: real Agent reads Skill, passes handle as-is, and stops at stop points.

External acceptance: independent read-back of WeChat draft side effects; local success cannot substitute.

Core state is managed by program; seams between Agent, natural language UI, and external systems can be tested independently.

This Solution Does Not Eliminate Uncertainty

Creation, research, comparison, and explanation still have uncertainty, and should retain that space. DxC reclaims stage, state, permissions, confirmation, recovery, and side-effect ground truth.

This architecture has costs. Domain kernel grows heavier; machine contracts need continuous maintenance; state migrations need versioning; validation costs with real hosts and external side effects rise. These costs are observable, testable, and regressable. Having every host Agent re-implement the workflow makes risk harder to control. When an Agent again guesses the next step, assembles internal parameters, or judges external write results, check whether program responsibilities remain on the host side.

DxC is actually not complex; a Web UI would have been much faster. The overall architecture is now stabilizing, boundaries and responsibilities clarifying; future iterations will stay within scoped ranges.

The entire evolution process, I feel, is very valuable. This is my first strict Agent Native system; though not complex, it went through much friction, experienced the uncertainty of natural language interaction, and learned how to better partition deterministic boundaries so that Agent, Skill, CLI/MCP each do their jobs — not only eliminating LLM uncertainty but also preserving its room to play. I believe it's a very good practice worth more people referencing, completely different from traditional architectural thinking.