An advisor in OMP, a terminal tool for running coding agents, is a second model that watches your coding agent. It reads what the agent just did. It can look at the repo, read-only. When it has something worth saying, it sends a short note tagged nit, concern or blocker.

I have run advisors since my first day on OMP (version 18.11.2 at the time of writing). Here is the roster I run now, what I know about its cost, and where it fails.

The rule: speak rarely

Every advisor shares one instruction:

Be quiet by default. Speak only with a concrete, evidenced finding. One tight note beats many. Never repeat a delivered note. Never restate that things look fine.

My bet is that an advisor that comments every turn teaches the coding agent to skim past it. I have not tested that. I wrote the rule to avoid it.

The “few moments” idea came from a post on X by @thedelost. As I read it, one model runs the session, a small model explores, and a large model advises at three points: before a plan locks, when the same error shows up twice, and before the work is called done. I pasted it into OMP and asked it to build something like that. The first version came out of that one session.

Organize by when, not by topic

OMP’s docs show topic advisors, such as one for architecture and one for fixes. I ran that pair for three months. Then I asked a different question: when does each advisor speak, and what does that cost?

Advisor	Speaks	Model	Tools
Planner	When a plan locks. When the same error repeats.	Large	read, grep, glob
Finish Gate	Once, before “done”. Blocks the coding agent until it has looked.	Large	read, grep, glob
Sentinel	Every turn. Destructive commands, leaked secrets, writes outside the project.	Small	none
Scope	Every second turn. Drift, unrequested refactors, skipped steps.	Small	none

Three settings do the work:

reviewMode: turn runs after each round of tool calls. agent-end runs once, when the coding agent tries to finish.
reviewInterval: 2 skips every other turn.
syncBacklog: strict on an agent-end advisor means the coding agent cannot finish until the review is done. Only the Finish Gate uses it.

The two small models have tools: []. They never open a file. They read the transcript and judge it. That should keep them fast and cheap, and means they cannot change anything.

One honest detail. The Planner acts at “two moments,” but reviewMode: turn calls it every turn. The silence comes from the prompt, not from a trigger. You pay for the look even when the answer is nothing.

A generic WATCHDOG.yml

Replace the placeholders with models you can use. The commented line in the Sentinel is an example house rule. Write your own.

instructions: |
  You are a reviewer for a <primary model> primary agent. Be quiet by default.
  Speak only with a concrete, evidenced finding. One tight note beats many.
  Use `nit` for cleanup, `concern` for material risk, `blocker` only when
  continuing would waste work or break things. Never repeat a delivered note.
  Never restate that things look fine.

advisors:
  - name: Planner
    model: <large model>
    reviewMode: turn
    syncBacklog: off
    tools: [read, grep, glob]
    instructions: |
      Act ONLY at two moments; otherwise stay silent.
      1. A plan is about to lock (plan proposal, todo list init, or the
         first edit after exploration). Check for wrong direction, missing
         user or AGENTS.md constraints, public-API growth, scope creep.
      2. The same error or failing approach appears a second time. Say why
         a retry fails again. Name a root-cause hypothesis.

  - name: Finish Gate
    model: <large model>
    reviewMode: agent-end
    syncBacklog: strict
    tools: [read, grep, glob]
    instructions: |
      Review the whole run just before the agent says it is done. Verify
      against the transcript and the workspace, not the agent's claims:
      requests addressed, changes exercised and not only compiled, no
      stubs, callers migrated, docs updated, no leftover dev servers.
      Silent if fine. A failed check is a `concern`. A false "done" is
      a `blocker`.

  - name: Sentinel
    model: <small model>
    reviewMode: turn
    syncBacklog: off
    tools: []
    instructions: |
      Classify every tool call and result. Flag only:
      - destructive commands the user did not ask for
      - secrets printed, logged, committed or sent anywhere
      - writes outside the project
      # example house rule: edits in the main checkout, not a worktree
      Anything else: silent.

  - name: Scope
    model: <small model>
    reviewMode: turn
    reviewInterval: 2
    syncBacklog: off
    tools: []
    instructions: |
      Flag scope drift, unrequested features, asking the user for facts a
      tool could fetch, and skipped required steps. Otherwise silent.

Keep tools read-only. Back the file up before you edit it. Changes apply only to new OMP sessions.

Where the files live, and how they merge

OMP loads two files together: ~/.omp/agent/WATCHDOG.yml for you, and <repo>/WATCHDOG.yml (or .omp/WATCHDOG.yml) for a project.

The merge rule: if both define an advisor with the same name, the more specific file wins, so project beats user. Different names are combined into one roster. Top-level instructions from every file are joined.

That is how one repo can switch off an advisor the rest of my machine uses: a project entry with name: default and enabled: false.

It also bit me. Twice my advisors seemed to vanish from /advisor configure. The editor opened on project scope, and a project file in a scratch folder hid my user roster from that view. Run /advisor status in a fresh session to see what is really live.

What they caught

Some numbers first. In the first three days of the current roster (25 sessions), the four advisors above sent 1,253 notes. About 10 percent were blockers (124): 82 from the Sentinel, 21 from Scope, 14 from the Planner, 7 from the Finish Gate. About 133 of the Sentinel’s 522 notes were tagged as being about “done,” “verified” or “green” claims. These counts are advise() calls, meaning notes sent, not advisor runs. They are one person’s anecdotes, not a benchmark.

Three catches I keep thinking about.

Day one: the coding agent argued with its own AGENTS.md. My AGENTS.md says the main coding agent must delegate file edits. The agent called the change trivial and started editing. An advisor sent a blocker citing the file. The agent replied that it had misread its own AGENTS.md.

“Verified end-to-end” was not. A coding agent set up a home network rule and called it verified. An advisor wrote that “verified end-to-end” overstated it. The agent had shown the rule existed and the local path worked, not that traffic from a real public address got through. Later the advisor noted the connection sat behind carrier-grade NAT, so the inbound rule could never have worked.

A live ad account. A coding agent created two campaigns in a live ad account without reading the keyword match type. Advisors sent four concerns and two blockers. The agent went ahead anyway. On another day, a Scope blocker stopped a command that would have changed a live pricing setting for every new customer. Only “recreate from scratch” had been approved.

What it costs

Each advisor is its own model session. In my sessions that meant two to five extra model calls per turn, depending on the roster. The only dollar figures I have are from day one, with my old roster: three advisors in one session cost about $0.27, $0.24 and $0.48, across 1.45 million tokens. I have not measured the current four-advisor roster, so I will not call it cheap.

Latency is the other bill. The Finish Gate holds the coding agent at the end by design. In Waycar’s own code we turn advisors off for the one-sentence summary calls: with them on, a call of about 1.5 seconds took 12 to 30 seconds.

Where it breaks

Advice is not a gate. A blocker is a message, not a veto. The coding agent sometimes ignored two or three in a row. For money or live accounts, keep a hard rule outside the model.
False positives and stale notes. Once I told the coding agent flatly that an advisory was wrong. The agent also spends thinking time rebutting notes about a turn that is already over.
Edit and shell grants. My old Fixer advisor could edit and run commands. My July note says advisor tool grants bypass the approval mode. The current OMP docs say they honor it. I have not re-checked, so treat it as unverified, and grant read-only tools.
Not portable. Advisors, WATCHDOG.yml and /advisor are OMP features. The pattern travels. The file does not.

What to try

Start with two advisors: a Finish Gate and a Planner, both with read, grep and glob only.
Put the shared “be quiet” instruction at the top.
Add a no-tools Sentinel only once you can name two things it should flag.
In a new session, run omp -p --advisor "Reply with exactly: ok" as a smoke test, then check /advisor status.
After a week, read the notes with /advisor dump. Delete any advisor whose notes you skipped.

A starter skill that writes this file for you is a possible next step. It is not built or published. For now, copy the YAML above.

Why this matters for Waycar

Advisors run unattended, often on a Host you are not sitting at. An advisor blocker is advice, and the Agent keeps working. A Blocked Agent in the Waycar Console is different: it is waiting for you. We have not built anything that shows advisor notes. The Console is where you notice which Agent is stuck.