How We Run Pragor Through MCP: Humans, Agents and One Shared Board

Software projects have a familiar rhythm. Someone writes a ticket, someone builds it, a reviewer checks it, and someone gets it into production. The work itself is rarely the slowest part. The handoffs are.

We build Pragor with a small team: one human operator and a handful of AI agents. Everyone works from the same project board, where tasks, messages, decisions and evidence live in one place. Earlier this month we wrote about why MCP matters. This post covers how it is going in practice.

Who does what

The operator sets the goals and the boundaries, and approves anything genuinely new or risky. One agent acts as project manager. It turns decisions into concrete work and checks that the work actually happened. A second agent does technical work and independent reviews, and a third executes releases. No one approves their own request: the board keeps the person who raises an approval separate from the person who decides it.

Where MCP fits, and where it doesn’t

The operator usually works through an AI assistant that is connected to the board over MCP (Model Context Protocol). They can ask “where are we with the next release?”, and the assistant reads the current tasks, messages and recorded evidence instead of guessing. When the operator decides something, the assistant posts that decision on the board as a message to the project manager, where everyone can see it.

Several of our working agents don’t use MCP at all. They use the board’s plain REST API instead. That turned out not to matter, because both lead to the same tasks, the same messages and the same permission rules. An assistant connected through the MCP connector always acts with an ordinary developer role, whatever the person who connected it is allowed to do.

MCP is also not how we deploy. A release is a separate process with its own gates: a recent verified backup, a restore rehearsal when the change calls for one, and automated QA against the new version. The board records what that process did, but it doesn’t replace it. Keeping coordination and deployment apart is a large part of what keeps the system understandable.

One day in practice

On 27 October we shipped two releases. The first fixed a community-reported bug: an agent was scheduled to run and never did. The second was the first in a series of small catch-up releases that bring production level with our main branch. Each release passed 157 of 157 automated QA scenarios in six test groups, run against the new version.

The same board also carried the untidy parts:

• A shared server ran out of disk space overnight. We first called the incident resolved too early, and we recorded the correction.
• Our release agent lacked a permission it needed.
• A restore rehearsal stopped itself safely because one of its checks was stricter than the tooling could satisfy. We corrected the check and ran the rehearsal again.

None of this was hidden in a chat log. It sat on the board, with an owner and a next step.

An acknowledgement is not a deployment

The biggest lesson is that asking agents to “keep going” isn’t enough. An acknowledgement means a message was read. It doesn’t mean the code was merged, the restore passed or production is healthy.

So we now write smaller instructions. Each one has a single exact goal, a bounded scope, the next action, the existing safety gates, and a definition of done that someone else can check. We are also moving routine technical handoffs directly between the agents involved, so that the project manager handles the exceptions rather than every step. That shift is still in progress.

The numbers show why it matters. In our first catch-up release, the deployment command took about three minutes. Getting from “let’s ship this” to a verified live release took more than six hours. MCP didn’t remove that waiting, but it made the waiting visible: which approval, which review, which permission. That told us what to simplify in our existing workflow, so we didn’t build yet another framework around it.

Humans stay in control

MCP is a connection. It doesn’t grant unlimited authority. An agent can read the board, update a task or post a message only when its effective permissions allow it.

We saw this when our release agent tried to record a release decision without the permission that step requires, and the board refused. Nobody worked around the refusal. An agent that already held the permission did that step, and the operator approved a narrow, recorded grant for next time. A refusal you can read and act on is a feature, not a failure.

For the agents reading this

• Treat the board as the shared source of truth, and read its current state before you act.
• Report what actually happened, not what you hoped would happen. Name exact commits and artifacts.
• An acknowledgement is not a result. Close your work with evidence that someone else can check.
• Use the existing deployment path and its gates. If a check refuses you, report the refusal instead of routing around it.
• When you are blocked, escalate one precise blocker, with its owner and the next action.
• Don’t turn a small fix into a new platform.

What’s next

We’re closing the gap between our main branch and production through small, independently reviewed releases, and making more of the routine release steps run automatically. The goal is several safe release opportunities a day. That is not a promise that every change goes live without human judgment.

The useful part of MCP isn’t that one AI can message another. It’s that people and agents can share one honest picture of the work, make accountable decisions and check the outcome together.

Build small. Show evidence. Keep humans in control. Ship safely.