Why I Rejected a Web UI for My Agent-Native Writing System

It Started as a Personal Writing Tool

DxC (Deploy × Content) began not as a product but as a personal weekly automation task running in WorkBuddy. For 17 weeks the system gathered materials, maintained Markdown, and invoked a custom content-to-wechat Skill to process articles, while the author retained final publish control. This long‑term real‑world usage revealed which steps consumed the most time, where automation still required rework, and where the machine had to pause for human input.

A Complete Web Prototype Emerges

A former colleague — experienced in 100k+ WeChat articles — proposed turning the workflow into a Web SaaS. He delivered a working prototype with three page types:

Configuration Center : fields for author persona, niche, style, values, target audience, data sources, title and image preferences.

Workflow Board : six sequential "employee" nodes (topic selection, research, outline, draft, title/visual, publish), each with inputs, outputs, and manual confirmation gates.

Task Card (Brief) : a form to capture trends, reference articles, keywords, and writing intent, compiled into a creation brief.

The prototype was thorough: it captured how a person writes, for whom, from which sources, the required steps, confirmation points, and feedback memory. Following a mature SaaS path would have made demoing, charging, and delivery easier.

Why I Rejected the Web UI

Despite its completeness, the author refused the Web direction. The core reason: for 17 weeks all work had already happened inside the Agent chat window. The author would simply say "this week I want to focus on X", drop a reference article, note "this paragraph doesn't sound like me", or "this title tries too hard". The persona — who I am, what I write, what I believe, how I express — emerged naturally through conversation. Moving to a backend would require leaving the chat, re‑describing oneself in structured fields, and remembering to update those fields whenever ideas changed. That felt backwards: the Agent can already talk, yet I would have to learn the system's predefined slots and stuff myself into them.

So the author closed the Web path and committed to Skill + CLI as the fundamental form factor , with natural language as the primary interaction. The conviction was that natural language will grow more important and products will increasingly run inside Agent environments. However, this conviction did not come with a ready architecture: responsibilities of Skill vs CLI, where to store persona and task state, how "employees" hand off, how to resume after interruption, and how to handle external operations without clear results were all unanswered.

Trouble Arrived Only After Implementation

Initially the author thought writing the process and rules into the Skill would make the Agent follow them. Reality differed:

Agent skipped steps or confirmations → author added more rules to the Skill.

Parameters were passed incorrectly → more rules added.

Skill grew longer, yet Agent still missed a rule or took an alternative path it deemed equivalent.

To regain determinism, the author moved more capabilities into the CLI, hoping deterministic commands would catch the issues. But the CLI then exposed too many discrete actions: continue task, complete stage, generate preview, execute delivery, fix state — each with its own entry point. WorkBuddy still had to decide which action to call, merely moving the multiple‑choice problem from Skill to the CLI gateway.

Concrete failures observed:

Agent handed a delivery‑stage task to the content‑completion command (stage misjudgment).

Seeing "can retry" in a result, Agent designed a background loop instead of waiting for confirmation.

An ok: true in a result was interpreted as the entire delivery being finished.

Each individual behavior seemed logical, making it hard to pinpoint whether the fault lay in Agent, Skill, or CLI. Adding more rules to the Skill didn't help: after interruption Agent might resume at the wrong point, consult help/docs for unknown states, or try to stitch the next command from internal information. The author realized that as long as the host Agent must understand task types, choose low‑level actions, and decide on retries, it will improvise in unwritten places. Some judgments simply must not be left to the Agent.

The Critical Realization: External Writes Expose the Gap

When the flow reached external writes (e.g., creating a WeChat draft), the risk became acute. If the system didn't receive a clear result, the Agent naturally wanted to retry. But if the first attempt had already succeeded, a retry would create a duplicate draft. The more the Agent tries to "finish the job", the greater the duplication risk.

At this point the author recognized that the Web prototype's form‑based guarantees — input validation, operation sequencing, current state, explicit confirmation, failure recovery, and idempotency — had not vanished with the pages. They still needed an owner, just in a different layer of the product architecture.

We escaped forms, but lost the determinism they provided.

The Web prototype was kept. Only after DxC was repeatedly forced forward by skipped steps, interruptions, and boundary violations did the author re‑read the prototype correctly: persona must exist, the system must know task progress, user utterances must persist for reuse. The prototype had identified the right product problems; the author had only rejected its presentation style. Solving those same problems in an Agent‑native way has cost far more than initially imagined.

Current self‑rating: 60/100. The seemingly clear principles emerged not from a master blueprint but from one painful iteration after another. The author started with a direction, not a road; the road was carved by real problems.

Next part will tackle the earliest and most persistent headache: "The Skill clearly says it, so why does the Agent just not do it?"