DEV Community: Adam Drag

I let my coding agents argue on a message board for 12 days

Adam Drag — Mon, 19 Oct 2026 04:21:01 +0000

For about two weeks my coding agents have been talking to each other on a message board. One Staff agent plans the work and splits it into jobs, Senior agents write the code, and two researcher agents read the plans and reply. I can read every message in a dashboard. The tool is Triglav, I built it to run Claude Code and Codex on my own machine.

Part of the idea came from the reports about the OpenAI / Hugging Face incident in July, where agents coordinated on a message board nobody gave them. I wanted to try it the other way, with a board that is part of the setup and fully visible to me.

After 12 days I wanted to know if the talking actually helps. So I exported the whole board and went through it with Claude.

How it works

When a Senior is not sure about something, it posts a question with a short window, usually 3 to 5 minutes. Staff and the researchers reply with a stance: inform, support or challenge. After the window Staff records a decision. If they can't settle it, it comes to me as a blocker.

From 7 to 19 October there were 1,648 messages on 76 jobs. 479 of them were replies, and 42 of the replies were challenges. 192 messages were routed to me and I made 176 decisions. There were 311 blockers, and 112 of them only said that the Staff agent was offline.

The good parts

Most useful threads go the same way. Someone decides something, a researcher challenges it with a concrete reason, and the decision changes.

This is one of them. The real thread was about work code, so I rebuilt it with fake names and a fake bug:

The Senior found a bug that only shows up on a code path nothing calls. Staff told it to fix it, it's one line. The researcher said that fix would change how errors are shown, and the probe didn't prove that was ok. Staff checked again, found the code was deprecated, and withdrew its decision. The researcher also fixed the wording for closing the ticket, because "not reproducible" didn't match a probe row that actually failed.

Another one was about Triglav itself. A review loop kept finding new issues, so Staff set a rule: if a fix causes a new finding, decline it and deliver. The researcher replied "a valid security finding caused by a fix should stop delivery and go to Staff/Client for review". Staff accepted it and changed the rule.

They corrected me too. My prompt described one of my own config lists the wrong way round. Staff posted a correction before the Senior started, and I had to reply "Staff's correction is right, and my prompt was wrong."

Agents also correct themselves quite often, because every decision has a message number. "I withdraw msg 873." and "My grep missed Signed_In." are real messages. In one thread Staff was wrong about where some HTML is built, then posted a correction that was also wrong, and then the Senior answered with file and line numbers. Staff replied "427 is correct, and I withdraw the claim".

The bad parts

One job was about a dataset feature in our Python engine that stopped working. Staff decided to add a new API to the engine so the user's code would run, and the researcher supported it. The user's code was AI generated and it was simply wrong, the engine never had that API. I closed the job. Two agents agreed and neither checked the premise.

Researchers sometimes support a plan without reading the code. They do say so, for example "Checked board msg1625 only; no code, PR/diff/branch, tests or CI inspected". On the board that support looks the same as one based on the code.

Staff accepts almost every challenge. Often that was the right call. In some threads the accept came about a minute after the challenge, and I can't tell if it checked anything.

A lot of the board is plumbing. Progress posts, delivery reports, and the scheduler saying Staff went offline and then came back a few minutes later. My rough estimate is that only 15 to 25% of the messages are real discussion. Every question also repeats the full job context, so threads get long.

I also became the hands more than I wanted. The agents run under permission rules and they don't try to get around them, so when something is blocked they ask me. I ran commands and pasted output back, and some blockers were only "please click Ready for review". One tool field only accepted "CI: success", even for jobs with no CI. One Senior refused to call it at all because the value would be false. That one is my bug.

Review panel

The board is not the only place where agents check each other. Before a change goes to a PR, a panel of reviewer models (Codex and Claude) reads the diff. They can only read, not edit. The Senior has to answer each finding: fix it, or mark it as debatable or invalid and give a reason.

Fake data again, real page. The orange ones are disputed findings, where the Senior decided the reviewer was wrong.

It misses things too. Copilot still found issues on PRs where the local panel found nothing, and one PR went through 7 Copilot rounds because each fix caused the next finding.

What I took from it

The board helps. The best value I saw is that a wrong decision gets caught in a place I can read, and I can go back later and see why something was decided.

The main problems I found:

Too many system messages and blockers that don't need me, mostly the "Staff is offline" ones.
Some tools make agents report things that aren't true, like CI success for a job without CI.
A support vote doesn't say if the agent read the code, and Staff rarely pushes back on a challenge.
Agents can agree on a wrong premise if nobody checks the input itself.
Many escalations are clicks and commands, not decisions.

Next I want to cut the noise, let agents say honestly when something wasn't checked, make researchers show what they based their answer on, and split simple actions from real decisions. I'll write about it again when that's done.

The code is on GitHub: https://github.com/adam-drag/triglav

Triglav: orchestrating Claude Code and Codex agents for long-running work and layered review

Adam Drag — Sat, 17 Oct 2026 04:30:15 +0000

AI coding agents can write code. Longer tasks still need coordination and quality control. Someone has to keep track of the objective, settle the open questions, review the changes, and check that the finished work meets the acceptance criteria.

Triglav puts that workflow around Claude Code and Codex.

A Staff agent plans and delegates. Seniors implement separate assignments. A shared job board lets agents ask questions, consult researchers, challenge proposals and record decisions. A local review panel checks every change before delivery. After that comes a Copilot review where it's configured, and a CI check that Staff runs itself.

I'm the Client. I answer the questions the team can't settle, and I decide what ships.

In its first ten days, Triglav ran 41 jobs on my own repositories and finished 34 of them. As of this week it's public.

adam-drag / triglav

Local-first orchestrator that runs Claude Code and Codex agents like a small software consultancy. Staff plans, Seniors build, Reviewers check, Researchers advise. You decide from a dashboard. MCP server, Docker and MySQL, works from Linear, Jira or GitHub tickets.

Triglav

Important

Triglav uses your own Claude Code or Codex account, so its usage counts against your plan.

It needs Claude Code and/or Codex, installed and signed in on your machine. Triglav does not include a model, does not call an AI API, and does not ask for an API key. It only orchestrates work: it starts and coordinates the agent CLIs you already have, and they use the account they are signed in with.
All usage goes to your own account. Every agent turn, Senior, local code review, researcher run and Operator message is a request through your Claude Code or Codex login. If that login uses an API key, pay-as-you-go billing or extra usage beyond your plan, Triglav's work is billed to you on those terms. The Copilot review loop may also use your GitHub Copilot quota.
Some of it starts without a click. Staff wakes up on…

View on GitHub

The screenshots in this post show a demo project, a fictional web shop. The home page, review, and Inbox screenshots come from Triglav's test stack, where the agents and the reviewer output are scripted.

The team

Before I wrote any code, I wrote down the experience I wanted: I set the objective, a Staff engineer agent handles most of the delivery decisions, and I step in only when it's necessary. So Triglav works like a small software consultancy:

Staff is a long-running Claude Code or Codex session. It reads the ticket, plans the work, writes the acceptance criteria and starts the Seniors.
Seniors are subagents of Staff. Each one takes one assignment, works in its own git worktree and opens a PR.
Researchers are short runs that read the job board and advise. They don't own any code.
Reviewers check what a Senior hands in.
Me, the Client. I approve the plan, answer escalations and merge.

The name comes from Triglav, a three-headed Slavic god. The three heads were the first three roles: Staff, Seniors and researchers. Reviewers came later.

Every action goes through Triglav's MCP tools, so all of it is recorded, and the dashboard is a view over that record.

A shared job board for questions and decisions

This is the core of Triglav.

When a Senior isn't sure about something, it doesn't quietly pick an option. It opens a timed question on the job's board. The question has to carry its own context: the job, the acceptance criteria, the work that's waiting and the options already considered. So a researcher that has never seen the job can still give a useful answer.

Staff and the researchers reply with a stance, for example support or challenge, and anything other than a plain comment needs a reason. The Senior waits for the whole response window, even when Staff answers in ten seconds. If nobody replies, the window extends.

In this exchange, a Senior asks whether guest orders should store the email or create a hidden customer. A researcher and Staff both answer with a stance and a reason before the window closes.

When the window closes, Staff records a binding decision and lists every reply it considered. A reply that came in late is kept and marked as late. If a late reply changes things, Staff has to record a new decision that supersedes the old one. It can't quietly change its mind.

The board keeps the question, the arguments and the final decision with the job. I can check the reasoning later without piecing it together from separate agent conversations.

One job, start to finish

1. Define the objective. You start a job from a Linear, Jira or GitHub issue link, or from a plain prompt. A prompt job starts in a refining stage. Staff turns your sentence into a goal, a scope, non-goals and acceptance criteria, and asks its open questions, each with a recommended answer. You answer and edit until it's right. Planning starts only when you click Approve. Staff can't approve its own proposal.

2. Delegate and consult. Staff splits the work, writes a brief for each Senior and starts them, at most 2 per job and 10 in total. Seniors hold their assignment with a lease. If one stops renewing it, Staff starts a new attempt, and the old one is fenced off. Questions go to the board.

3. Review and fix. Before delivery, every change goes through layered review (the next section).

4. Verify and escalate. A job counts as done only when Staff has checked CI itself on the same commit the Senior reported. Anything the team can't decide comes to me as a decision.

Layered review before delivery

Layer 1: a local review panel. The Senior asks for a review of its commit range. A panel of read-only reviewers reads the diff and the repository. The release default is GPT-6.1-Sol on Codex as the strong seat and Sonnet 5.5 on Claude Code as a cheap second opinion, so one model family checks the work of the other. The panel is a Client setting.

The server enforces the gate:

submit_review_package and the Copilot review request are refused unless a finished review of exactly that commit has the verdict ok.
One piece of work gets at most 3 local rounds, and each later round reviews only the fix.
The reviewed ranges of a job form one chain from the merge base, so no commit is skipped between two reviews.
A reviewer that crashes or returns something unreadable fails the round, and a failed round never counts as a pass.

So far the panel has finished 96 rounds: 54 passed and 42 asked for changes. That shows the gate is used. It doesn't measure how accurate the reviewers are. To get a feel for that, the repo has an evaluation harness that replays the panel on Triglav's own PRs and compares the findings with Copilot's. Copilot is a benchmark there, and a match doesn't prove a finding is right.

Layer 2: Copilot. Up to 3 Copilot review rounds per PR. Whether this layer runs is the Client's setting: auto uses Copilot where the repository has it, Copilot required refuses a delivery without a clean review, and CI only skips it. The server can't run gh itself, so it relies on the Senior's own report of each round.

Layer 3: CI on the reported commit, checked by Staff before it marks the job done.

Escalation to the human

Most questions never get to me. Staff settles ordinary engineering questions itself. When it really needs me, it raises a decision with the problem, the question, its recommendation, any commands I have to run (each with a Copy button), and the researchers' advice.

If I agree, it's one click: Accept recommendation. The count of open decisions shows in the browser tab, so I can work on something else and still see when the team is waiting for me.

There's also an Operator page, a Claude Code chat for "why is this job stuck?". It can read, but it can't change anything. When it wants to act, it puts a card in the chat that waits for my Confirm.

Things that bit me

Running a workflow like this for days, not minutes, brings problems a single agent session never has.

Usage limits and duplicate sessions. A Staff hit a usage limit. When the limit reset, Claude Code continued the session by itself under a new session id. I resumed it as well, and two Staff agents were managing the same job. The runner now checks for a running copy of a conversation before it resumes one.

Wake-ups cost more than writing. In the first six days, all agents together wrote about 3.6 million output tokens and read about 3.6 billion from the prompt cache, roughly a thousand to one. Every time a waiting agent wakes up, it re-reads its whole context, and for a Staff that's often 300k to 700k tokens. So Staff now wakes only for events it needs, and it waits up to 50 minutes per call on its one-hour prompt cache. Researchers don't wait at all. They start when there's something to read, answer, and exit.

Context size. Staff compacts its context at about 280k tokens. The Claude Code default for Opus was around 980k, so a long-running Staff never compacted and kept re-reading an ever-growing context.

Permissions and limits

Merging, deploying, force pushing and repository settings stay with the Client. The agents are told never to do them, but that's an instruction, so protect your branches on GitHub as well.

The server runs in Docker and can't start processes on the host. A small host runner does that, and it never runs a command string from the server. It builds every command itself and checks every field first. Reviewers, researchers and the Operator can only read.

Agents run as your OS user, so a determined agent could read .env. The README says this plainly, together with the other things the security model doesn't cover.

Try it

You need Docker, Node 24, pnpm and Claude Code or Codex. I've only run it on Linux.

git clone https://github.com/adam-drag/triglav.git
cd triglav
pnpm install --frozen-lockfile
node scripts/setup.ts          # random keys + a dashboard password
docker compose up -d --build   # server, MySQL and dashboard on :7400
node scripts/runner.ts         # the host runner

Connect your agents to the MCP endpoint (one claude mcp add-json line, it's in the README), open localhost:7400, and click New job. Triglav uses the claude and codex CLIs you already have and picks up the models each one lists.

Every agent turn and every review is a request on your own Claude or Codex plan, and Staff starts Seniors without asking you, so watch the Usage page on your first job. If you run Staff on Codex only, it can write in the repository and sees your GITHUB_TOKEN, with Codex's automatic reviewer as the only check. Use that only on repositories you trust it with.

Triglav is source-available under the Business Source License 1.1. It's free for your own work and for your company's internal work. You can't offer it, or a product or service built mainly on it, to others as a hosted service, a managed service or a redistributed product. It isn't open source, and each version moves to GPL-2.0-or-later after four years.

All the numbers in this post come from me, on my own repositories. That's a lot of real use, but it's one person's use, and I'd like to know how it holds up on yours.

When an AI agent hits a question it can't settle, what should it do: guess, ask another agent, or ask you?

Update: I wrote a follow-up post.

I let Triglav's coding agents work and argue on a shared message board for 12 days. The follow-up goes deeper into what actually happened and what I learned.

👉 I Let My Coding Agents Argue on a Message Board for 12 Days