GitLab triage

A daily issue digest for developers and teams

Every morning, what changed in GitLab and what is expected of whom. Code builds the sections; a local model only adds summaries. Client data never sees the cloud, and code enforces it.

local only, enforced in code

The problem

Developers go through GitLab every morning to find out what changed and what is on them. The first version of the digest was built in n8n and sent issue descriptions to a cloud model. For projects of regulated clients that is not acceptable.

How it works

1
Window of changes
Works out the period to cover from the schedule and Czech public holidays. After a weekend it covers the whole weekend.
2
Reading GitLab
A read-only API, paginated and with limits. The token cannot change anything.
3
Code builds the sections
Assigned issues, sprint status and status changes are determined by deterministic code, not the model.
4
A local model adds context
For each item it writes what is expected of the assignee, and for risky ones a “needs attention” analysis.
5
Delivery
An HTML e-mail to the developer or a Markdown post to the team channel through a locked webhook.

Guardrails

Failure must not look like a quiet day: an error means an alert and a non-zero exit code, not an empty digest.
A model outage does not block sending; the digest goes out without summaries.
At most one digest per instance, day and channel, without retries.
Recipients only from configuration, checked at send time.
The model cache holds only a hash of the request and the answer, deleted after 24 hours. Issues are never written to disk.

A bigger model is not automatically better. The thinking model burned its token limit on reasoning and gave no answer; a smaller model without thinking does the same job in a fraction of the time.

Models and data

Before its first request the agent asks the gateway which backend serves the model. Unless it is local Ollama, it sends nothing. Data of client projects is kept in memory only and handled only by a local model. The rule is held by code, not discipline.

Gemma 3 12Blocal
summaries and analyses

What it touches

GitLab (self-hosted)our server
LiteLLM and local modelsour server
Own SMTP relayour server
Mattermostour server

Numbers from production

~20 min: to build the digest with analyses on a local GPU, so it runs at 8:00 and is ready before the day starts
~26 min: per run with a “thinking” model that spent its token limit reasoning without an answer; we replaced it with a smaller one
1: digest a day per recipient, no retries

Where we take it next

A shared package for all agents instead of copied code.
Gateway keys restricted to local models, so the rule holds on the gateway side too.
Secret-leak scanning in CI.

More case studies

local, drafts also cloud

IMAP triage

Sorting company mail and drafting replies

In the morning it is clear what is on fire. The agent sorts the NOC, CSIRT, billing and sales mailboxes and drafts replies to selected messages. It cannot send them.

no model

Day digest

A morning overview from company systems

One e-mail before the day starts: calendar, tasks, mail, GitLab and Mattermost. The agent calls no model itself; it assembles the output of the other agents.

local only, enforced in code

Delegator

Assigning tasks in plain text in chat

You tell a Mattermost bot what needs doing and who should do it. The model proposes a task, code checks the assignee and deadline, you confirm with a thumbs-up. Then the bot watches how the task goes.

no model

Expense hub

Re-billing company expenses

Statements for fuel, phones, insurance and internet arrive by e-mail and end up as an overview for each holder. No model: the parsers are deterministic and the totals match to the cent.

No-obligation consultation

Let’s find the first job for AI in your company.

An hour’s conversation about where your data lives, which processes slow you down and what of it may leave your network. You leave with a proposal for a first pilot, not a tool demo.

Write to meet@nux.cz Call+420 250 250 500