Most agencies in our market sell AI as a deliverable: a chatbot, an assistant, an automation. Very few say whether AI touches their own delivery. At Polargate it does, in a specific and fairly boring way. This page describes the machinery we actually run, with the numbers we actually have, including the parts that do not work.
What happens when a ticket arrives
Polargate runs client maintenance through a multi-tenant ServiceDesk, in production since 17 July 2026. A client sends an email or opens a ticket in their portal. From there:
- The email arrives through our support domain, with DKIM and DMARC checks and signed reply tokens, so a reply from the client's mailbox attaches to the right ticket and to nothing else.
- A triage agent classifies it: what kind of change it is, which repository it touches, how risky it looks, how many hours it should consume. This step runs on a large model and costs about 0.05 USD per ticket.
- If the ticket is a candidate for automation, a fix job is dispatched as a GitHub Actions run inside that client's repository. The worker is one canonical workflow kept in our own repo, and each client repo carries a fifteen-line stub that calls it. The agent works through the Claude Code CLI with a hard cap of 80 turns.
- The job posts a diff back through a callback, and stops. It waits.
- A human, today the founder, reviews that diff in Mission Control, our internal console: approve, ask for a replan, adjust the hour or risk estimate, draft a reply to the client, or cancel the whole thing.
- The change is merged and deployed by a human, behind the usual gates: typecheck, tests, build, and a look at the real page on desktop and on a 375 pixel phone.
Hours consumed post against the client's contract, which has two pools, maintenance and urgent, with any surplus rolling into proactive improvements instead of evaporating. The client sees their plan, their consumption and their invoices in the portal. They never see our internal knowledge base: that access rule is enforced in the database, not in a policy document.
One ticket, two executors
Every ticket can be closed in two ways: the automated lane, which spends API credit, or manually by a senior engineer working in Claude Code, which spends none because it runs inside an existing subscription. Same queue, same ticket, two executors. In practice, small bounded changes go through the automated lane, and anything that needs judgement about the client's business goes manual.
Parallel audits, and a sceptic for every finding
Build work uses a different loop. Once a change is written, we fan out audit agents by dimension: correctness, architecture and reuse, interface and platform guidelines, accessibility, responsive behaviour, performance, and security including row-level policies. Then every raw finding is handed to a separate agent whose only job is to refute it.
That refutation pass is not decoration. Numbers from our own runs:
- An Android push crash investigation: 14 agents, 20 raw findings, 8 verified, and none survived contact with the code. The real cause was elsewhere.
- A golf club site, two rounds before merge: 37 raw findings and 4 confirmed, then 26 raw and 3 confirmed.
- A hotel website in August 2026: 55 agents across 6 areas, 48 findings, 48 confirmed, 0 refuted. Sixteen were live bugs, including only one of two room types present in the prerendered HTML, English routes served with lang="es", and visitor counters served as zero.
- An internal operations platform: a 74-agent audit produced 59 confirmed findings, fixed through an 11-agent fan-out.
- An offline-first mobile app needed 11 audit rounds, with findings going 42, 28, 9, 15, 11, 4.
Two lessons come out of that table. Raw agent output has a high false positive rate, so the refutation step is what makes it usable at all. And the confirmation rate swings wildly, from 48 out of 48 on one codebase to 4 out of 37 on another. A run that confirms nearly everything usually means nobody had audited that code before.
The stop rule is two consecutive clean passes with zero blockers. "Verified" means build, typecheck and tests green plus the interface opened in a browser, because green gates lie: a tsconfig whose root matched no files gave one project a passing typecheck for months, and two deploys shipped green past a lint step that never returned a failing exit code.
The knowledge base underneath
Agents are only as good as their context. Polargate keeps a per-entity knowledge base in Postgres: text chunks with embeddings and an HNSW index, scoped by entity and project, with a shared global library folded into every search and a wall between client, internal and personal knowledge. Our own tools reach it through an MCP server exposing more than 100 tools: knowledge read and write, tickets, hour balances, invoices, contacts, releases, the fix queue.
In practice this means the triage agent already knows the client's stack, the decisions taken, and what broke last time. It also means the usual failure mode is knowledge, not model: when a proposed fix comes back wrong, it is almost always because a fact was missing from the knowledge base.
What a fix costs
- Triage: about 0.05 USD per ticket.
- The first real end-to-end fix shipped through this pipeline, on a client portal in July 2026, cost 0.31 USD in model spend.
- Worker infrastructure: nothing. GitHub Actions minutes in repositories we already pay for. We considered a dedicated worker host and rejected it as oversized for one or two tasks a week.
- A daily spend cap sits in the database. When it is reached, the lane stops.
So model spend per fix is a matter of cents. That is the honest headline and also the least interesting number, because the cost that matters is senior review time, and it does not go to zero. Somebody who understands what breaks the client's business still has to read the diff. What the agent removes is the drafting: reading the codebase, reproducing the issue, writing a first version, drafting the reply. That is what makes senior quality viable on a retainer that starts at 850 EUR a month, where a studio with a payroll would have to charge more or staff it with juniors.
What the agents are not allowed to do
These limits are welded into the database, not written into a prompt:
- Never reply to a client on their own. Every client-facing message is reviewed and sent by a person.
- Never deploy. No agent holds production credentials.
- Never exceed the daily spend cap.
- Never run destructive migrations or touch authentication, roles or secrets.
The general boundary: reversible decisions belong to the agent, irreversible ones stop and ask. A human reviews and merges every change. This is not a reassurance we add at the end of an article, it is the reason the system can be pointed at a client's production repository at all.
If you are thinking of building this
- Start with the desk, not the agent. Automation with no ticket system and no hour accounting has nothing to attach to.
- Build the refuter before you trust the auditor.
- Put the caps in data, not in prompts. A prompt is a suggestion, a database constraint is not.
- Measure your false greens. A verification gate that cannot fail is worse than no gate.
- Budget the human review honestly. It is now the expensive part, and it is the part clients are actually paying for.
Polargate works this way on Care retainers from 850 EUR a month, and new engagements start with a fixed-price Discovery Sprint from 4,900 EUR.
