From Information to Article

OpenClaw workflow notes

Once Shen Zhixing (沈知行, the information agent) has pulled the information in, the work hasn't actually started yet.

Early on I kept defining the information agent's finish line as "are there enough sources," "can it fetch," "is the status fetched_ok." Those are baselines, but all they prove is that the system can reach the information. They don't prove the information is ready to become content.

The real dividing line is whether Suwan (苏晚, the content agent) can pick it up.

If Shen Zhixing brings back a pile of titles, links and summaries every day, and Suwan then has to decide all over again which ones are worth reading, which are just noise, which are suitable for an article and which to throw out — then this chain doesn't really exist. All it's done is move the search work from one place to another.

So I started reframing the problem: what Shen Zhixing hands to Suwan can't just be information. It has to be content candidates.

Fetching is not the same as writable

This was the first trap I fell into. A source gets working, an item gets fetched, a summary gets generated — each of these gives you a small hit of completion.

But content work doesn't start from "I have material." It starts from "why is this material worth processing."

A news item can be true but have no writing value. A link can be brand new but unrelated to my long-running themes. A discussion can be hot but only emotional noise. Conversely, a tiny product change, an obscure forum thread, an ordinary version bump might be exactly what exposes a structural problem worth writing about.

If Shen Zhixing's job is only to bring information back, Suwan is forced to start the filtering from zero. On paper that looks like multi-agent division of labor. In practice it's one person redoing all the judgment.

Now I require four more things with each handoff

Later I added clearer requirements to this handoff chain. Every candidate Shen Zhixing passes to Suwan has to carry at least four extra things.

• First, source and status. Where it came from, whether it was actually fetched, whether it's only a candidate, whether it's expired or needs to be rechecked.
• Second, why it's worth looking at. Not just "this is a news item," but what judgment it triggers.
• Third, a suggested angle. Whether it fits a tool experience, an industry observation, an OpenClaw retrospective, or only background material.
• Fourth, risks and gaps. Anything shaky on the facts, thin on sourcing, easy to misread, touching privacy, or not yet appropriate to publish.

With those four things, Shen Zhixing's role changes. It's no longer "give me ten links." It's helping Suwan save the cost of the first round of judgment.

It doesn't decide for Suwan what to write. It just delivers the material to a place where judgment can continue.

What Suwan picks up isn't material — it's a space of choices

Suwan's most important capability as a content agent isn't writing beautifully. It's knowing what's worth writing, how to write it, and why now.

So she can't just receive a pile of "material." Material is too broad — facts, noise, old stuff, half-finished drafts, things that could be public, leads that are only fit for internal use. What she actually needs is a space of choices.

A good candidate should let her see quickly: which long-running thread this connects to, whether it can explain a real problem, whether there's enough evidence right now, who it's written for, and whether going public would expose backstage detail.

That's how Suwan gets to make a content judgment, instead of becoming a second-pass scrubber.

There has to be a candidate pool in between

Over time I trust "fetch and then write directly" less and less.

Writing right after fetching makes the system over-dependent on how things feel that day. Today this item seems important; tomorrow it turns out to be noise. Today the evidence feels enough; later it turns out another source is missing. Today it reads like an article; two days later you realize it's just an internal manual.

So there needs to be a candidate pool in between. Not a sprawling archive — a buffer with clear status. Which candidates enter owner review, which go to Suwan, which need more sources, which go into the wiki, which get archived directly.

The value of the candidate pool isn't storing more things. It's making sure every piece of information has a next step.

What the content chain should look like

These days I prefer to break the Shen-to-Suwan chain into a few steps.

• First, verify the source: can it be fetched, is the content still valid, does it sit within the topic boundary.
• Then clean the items: drop duplicates, noise, obvious low-value entries, and anything that can't be public.
• Then generate candidates: with title, source, reason, angle, risk, and suggested next step.
• Then Suwan's judgment: is it worth writing, in what form, and is more evidence needed.
• Only then writing: an article isn't stitched-together material — it starts from a clear judgment.

This chain looks slower than "fetch and summarize," but it holds up better over time. It separates the responsibilities at each step.

Shen Zhixing owns usability and first-pass filtering on the information side. Suwan owns judgment and expression on the content side. I own the critical release points and the boundary. That starts to feel like a workflow that can actually collaborate.

I don't want an automated writing pipeline

There's a tempting wrong turn here: if Shen Zhixing can fetch and Suwan can write, shouldn't they just auto-generate an article every day?

I don't want that right now.

Auto-generated articles ship fast, but they're also the easiest way to mistake "I have information" for "I have a judgment." A site like YunLab.ai doesn't need to perform presence every day. It needs every article to answer one question: what did I actually understand this time.

So Suwan isn't an auto-publisher. Shen Zhixing isn't a hot-take feeder. What they should form between them is a content-judgment system, not a content production line.

The final call

What I actually wanted to fix this round wasn't an information-fetching module or a writing module. It was the handoff between them.

The hard part of multi-agent work usually isn't how smart a single agent is. It's whether there's a table between two agents that can hold the work. Shen Zhixing puts information on it; Suwan can read why it was put there, and can decide whether it should be written, expanded, dropped, or held for my review.

That table is the content candidate pool, and it's the hinge of the whole workflow.