DeepSeek Harness workflow vs schedule vs subagents

A workflow, a scheduled task and a subagent are easy to mistake for three ways of automating the same job. In DeepSeek Harness they answer different questions: how work is structured, when it starts and who carries a piece of it. Confusing those questions is the usual reason an automation looks broken when only one layer misbehaved.

Three automation roles inside DeepSeek Harness

A workflow controls sequence, a schedule controls timing, and a subagent controls division of labor.

• Workflow: it knows about dependencies, so it decides what must finish before something else begins.
• Schedule: it knows nothing about dependencies and only decides when a run is allowed to start.
• Subagent: it knows only its own subtask, which is why it can work in parallel without inheriting the whole conversation.

The table below is the shortest way to keep the three apart during design review.

Confusion usually appears after a failed run, when the visible symptom belongs to a different layer than the cause. A schedule that fires on time can still start a workflow that deadlocks, and the silence looks like a broken timer. Likewise, a workflow can finish while one subagent returns a plausible but incomplete result, which looks like a reasoning error. Naming the layer before debugging is what keeps the investigation short.

None of the three is a substitute for the others, and adopting one does not reduce the need for the other two. A mature setup may use all three, but each keeps a narrow responsibility and its own logs. That separation is also what makes the combination debuggable later.

What a DSH plugin workflow actually controls

A workflow earns its complexity only when order and dependency matter.

It represents steps as nodes and dependencies as edges, which makes branching, retries and checkpoints explicit. That structure is valuable when a later step cannot begin until an earlier artifact exists. It is unnecessary when every run performs the same single action.

A dsh workflow also owns failure handling inside the run. A failed node can retry, branch to a fallback or stop the flow, depending on how the graph was designed. Intermediate artifacts should be kept, because a failure without evidence turns into guesswork. The DSH Plugin Hub is a sensible place to compare workflow designers before choosing a graph model.

What a workflow does not own is the clock. It does not decide that a report should run every Monday, and it does not wake itself up. Triggers belong to a schedule or an event, which means a workflow can be tested on demand and scheduled later.

How a DSH plugin schedules work without owning it

A scheduled task owns the clock and nothing else, so it should never be asked to encode logic.

Its job is to start an action at a defined time or interval, with a timezone that is explicit for distributed teams. The action might be a workflow, a script or a message, but the schedule itself should stay thin. A trigger firing is not evidence that the action succeeded.

Overlap is the most common design gap. A second run can start before the first has finished, especially when the action takes longer than expected. Overlap prevention, retries and failure notifications belong to the schedule or to the action it invokes, not to wishful thinking. A DeepSeek Harness plugin should log every trigger and every completion so the two can be compared later.

When the action behind a schedule starts to branch, the schedule is being asked to do too much. The right move is to move the branching into a workflow and let the schedule keep its single responsibility. That change also restores a clean failure boundary, because the trigger and the flow can be diagnosed separately.

Subagents and the DeepSeek Harness context budget

A subagent trades coordination cost for parallel context, which is a good trade only when the work splits cleanly.

Each subagent receives a scoped task and its own context, so it does not need to carry the full conversation. That makes subagents useful for exploration, independent research and pieces of work that would otherwise run one after another. It also means the main session does not see the subagent's reasoning unless the result includes it.

Aggregation is the hard part. Two subagents can return answers in different shapes, or summarize the same source differently, and the main session has to reconcile them. Defining the output shape before launching the work prevents most of that confusion. A result without evidence is worse than no result, because it looks complete.

Failure isolation deserves explicit design. One subagent timing out should not cancel the others, and a failed subtask should return an error the main flow can handle. Retries and timeouts belong to the delegation layer, not to the main prompt. Testing that isolation is simple: force one subtask to fail and confirm the rest still report.

Combining DSH plugins without losing failure attribution

The three layers compose in one direction: a schedule triggers, a workflow frames, and subagents fill parallel nodes.

That arrangement keeps each responsibility visible and gives every layer a natural place to log. A schedule records the trigger, a workflow records node transitions, and a subagent records its own result. When the records share a timestamp base, a failure can be attributed instead of guessed.

Timeouts and retries should be set per layer. A subagent timeout should not silently consume the workflow's entire budget, and a workflow retry should not duplicate an already completed side effect. Retry policy is therefore part of the design, not a setting to copy from a template. The same applies to notifications, which should say which layer failed rather than only that something did.

Most teams should start with the smallest layer that removes the pain. Repetitive timing work calls for a schedule, and a fixed multi-step procedure calls for a workflow. Subagents become justified when the volume and independence of the work make sequential execution too slow. DSH plugins that grow in that order tend to stay understandable, while deployments that begin with all three usually inherit an attribution problem.

The final test is whether someone can explain a failed run in one sentence. If the sentence names the layer and the missing artifact, the division of labor is working. If it only says the bot did not respond, the boundaries are still too blurry. A DeepSeek Harness plugin setup is easier to operate when each layer can fail on its own terms.