Engineering

The Directional Reviewer: from "read everything" to "write one line"

Three redesigns in five days, driven by the lab.

Kirtiman Sharma5 November 20264 min read
  • Process
  • AI quality
  • Cost
The Directional Reviewer: from "read everything" to "write one line". Engineering on the YuktiBOS articles pages.

The Directional Reviewer (DR) is an AI role that reads how a client's work is going and tells the other workers what to do this week. Its design changed shape three times in five days. Here is why.

The starting point: three posts, Rs 381

On 30 October we looked at why three Mukika daily posts had cost Rs 381 over three days (Rs 165, Rs 153 and Rs 64). The causes, read from the code:

  • Every AI call read about 60,000 tokens: skills up to 100,000 characters, facts up to 48,000, working memory and a learning log. The direction brief added one sentence on top.
  • The reviewer was pass or fail, and "pass" meant nearly perfect, so drafts were rejected again and again.
  • When retries ran out, the work was parked as "waiting for you".
  • Prompt caching was not used. Working memory was placed in front, which breaks caching.
  • The DR itself saw only task titles and statuses, and facts cut to 900 characters. It could not see the voice guide, the design system, finished work or scores. Its daily cap of Rs 500 covered about seven client runs.

One correction in my own notes: I had claimed retries grow in cost. That was wrong. The task page added up each try's cost into a running total, so each try's real cost was about Rs 12 to 13.

Step one: a scored review (live 30 October)

A scored review replaced the pass-or-fail one. Hard rules must pass. Minimums: hook 6, voice 6, call to action 5, total at least 70. At most three drafts, each revision working from the best draft. At the cap, if no hard rule is broken, the post goes to approval marked "below target". If one is broken, the day is skipped with a reason. Never "waiting for you".

Version 2: the DR reads everything (31 October)

On 31 October I told my collaborator: take decisions, review and critique them, and build. The v2 decisions were:

  • The DR reads much more: voice guide, brand system, design summary, milestones, the last 14 days of work, content with review scores, skipped days, my edits and rejections ("said versus did"), and measurement data. Budget about 60,000 input tokens per client run.
  • It outputs instructions, not a sentence: three to six bullets per role, a direction pack for content streams, and three measurable weekly goals with a number and a data source.
  • Refresh weekly, or on a change. No human approval of packs. Averages first: for the first two weeks a lower pass mark, then raise it by 5 when the first-pass rate reaches 70%.
  • A fixed anchor set of approved and deliberately broken posts guards against the judge grading itself.
  • The DR's daily cap goes from Rs 500 to Rs 1,500.

My principles were: it reads everything, it never runs daily, the target is 80 to 90% (inside a range, not perfect), and no human bottleneck.

The reversal (4 November)

Then the Content Lab and the blind human review came in. The review found that the clean Human brief, with no agent prompt and no DR text, scored best for posts. The long DR text in every writer call did not earn its place.

So on 4 November, four decisions (ADR-495 to 499):

  1. The DR acts at planning. When it commissions work, it names which of the week's three goals each task serves. Code copies that goal, as one short line like "Newsletter sign-ups (40 sign-ups)", onto the task. The line is never invented. No valid goal means no line.
  2. The writer gets one goal line, not the long text. The dr Lab switch stays so the Lab can compare, but its default is now off.
  3. The checker scores the finished piece against its goal line, adding one part, "Serves its goal", and flags drift.
  4. The DR only advises. It never starts, edits, rewrites or rejects a human-written piece, and a human piece is never scored into "below target". With no AI key it is silent and the last good pack stays. Weekly numbers show the stream and the client, never a person's name.

The lesson

I designed the DR to read everything because everything seemed relevant. The evidence said the writer does not want what the planner wants. The planner needs the whole picture. The writer needs one sentence about what the piece is for. Moving the long text to where decisions are made, and keeping a thin thread to where words are written, fits that.

What's still open

The comparison "Human brief plus DR text" against "Human brief" has no recorded result in my docs. The Lab variant exists to run it. The anchor set and the five weekly numbers were designed; I have not verified they are live. And the reviewer in the human read was an AI editor, not a person.

Numbers at a glance

ItemValue
Three posts, 27 to 29 OctRs 381 (Rs 165, Rs 153, Rs 64)
Tokens read per call, beforeabout 60,000
DR facts cut900 characters
Real cost of one tryabout Rs 12 to 13
Scored review minimumshook 6, voice 6, call to action 5, total 70
DR daily cap, before and proposedRs 500, then Rs 1,500
ADRs for the move to planning495 to 499
Want to try it, or tell us what to build?

We are onboarding a small number of businesses for early access, and we read every feature request.

More in engineering

See it on your own business.

We are onboarding a small number of businesses for early access. Tell us what you do and what you would like off your plate.