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.

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