Rivermark: how the agent harness benchmark for social media and print graphics is structured

On October 29, 2026, a post about Rivermark appeared on Reddit — a homemade agent harness for social, marketing, and print graphics. The author assembled a benchmark of 112 requests and compared Claude Code + Sonnet 5.5 against DeepSeek and GLM Flash models on it. Below is what exactly was tested and what data the post lacks.

What an agent harness is and what it does for the model

An agent harness (harness — a layer of code around the model that decides which tool to call, in what order, and what to do with the result) is not a model. The model produces text or an image. The harness holds the loop: parse the request, assemble context, call a tool, check the output, repeat on error.

Example from the thread. Request: "need a square banner for the feed, brand kit attached." A brand kit is a file with a logo, fonts, palette, and usage rules. The model by itself will write text and possibly describe the composition. The harness must read the brand kit, substitute colors from it, choose a template, render the layout, check that the logo is not cropped or stretched, and return the file. Without the harness, there is no one to do this step.

Second example: an edit. The client asks to "make the logo bigger and remove the yellow." A model without tools will answer with the text "done." The harness must actually open the previous file, change the layer, and return a new version, not a description of a new version.

Why social media and print are harder for models than websites and apps

Web design has built-in feedback. Code can be rendered, a screenshot taken, compared with the layout. The model sees the result of its work in pixel form and can correct itself in the next iteration.

With print, feedback is more expensive. Bleed is needed (bleed — the margin beyond the layout edge that the print shop trims), CMYK (a subtractive color model for print, as opposed to RGB for screens), and resolution in dpi. An error is visible only after the print run.

Example. The model places a line close to the edge of a flyer. On screen it looks fine. After trimming, the line shifts or loses part of its letters. The harness must know about bleed from the rules, not guess from the image. How Rivermark checks these parameters is not stated in the available part of the post — there is no data.

How the set of 112 requests is structured

The author divides inputs into three classes. The first — there is a full brand kit. The second — there is only a link to the brand's website. The third — a request from scratch, without a brand kit and without a link.

The second class is methodologically the most interesting. Extracting a palette and typography from a live website is a separate task: you need to fetch the CSS, find the dominant colors, determine font pairs, discard service elements. The quality of this step can be measured separately from the quality of the layout, and then a failure at the output is not mixed with a failure at the input.

The third class tests something else — how much the harness makes up on its own. When there is no brand kit, any palette will be a runtime decision, not the brand's.

How points were counted, by which rubric, and who evaluated the layouts is not stated in the post — there is no data. This is the key hole: without a rubric, 112 requests turn into 112 subjective opinions.

Comparison of Claude Code + Sonnet 5.5 with DeepSeek and GLM Flash: what is known and what is not

It is known that the Claude Code + Sonnet 5.5 pairing is taken as the reference against which the others are compared. Claude Code here is not a model but a tool for launching an agent on top of the model; Sonnet 5.5 is the model itself. DeepSeek and GLM Flash are other models for the same loop. "Flash" in the name usually means a lightweight variant with an emphasis on speed and price.

What the post does not have: a single number. Neither on the share of suitable layouts, nor on the cost of one request, nor on the time to a finished result. Nor is there any variance between runs — and that matters because the same model on the same request produces different results.

What can be said from the structure of the test: 112 requests, one author, one subject area, three classes of inputs. Such a set is suitable for making an internal decision about "what to run the pipeline with." It is not enough to assert "model X is better than model Y" in the general case.

What to do about this

• Assemble your own set of several dozen requests taken from a real queue, not invented for a test.
• Fix the evaluation rubric before launch: what counts as a suitable layout, what counts as a reject, who judges.
• Split the evaluation into stages: brand extraction, composition, text, technical requirements. Otherwise it is unclear where exactly the model fell short.
• Check technical requirements with a separate automated test: bleed, color space, resolution, margins from the edge. This is cheaper than looking at the image with your eyes.
• Calculate price and time per one accepted layout, not per one request. A harness with a cheap model and three restarts can end up more expensive.