Use case · AI Studio
Product & engineering
The engineering team that reads along: monitoring, root-cause analysis down to the line of code and hand-over-ready tickets in your ticket system.
01 · The brief
The first question is always the same.
Software operations have a recurring pattern: reports on the same topic pile up, and the first question is always the same: was there a release, are errors piling up, has a system failed? Answering it costs experienced engineers hours that are missing from the day-to-day.
Then there is the detail work between idea and implementation: sharpening requirements, thinking through edge cases, formulating test cases, documenting releases. Both are necessary, and both are structured enough for an agent team to prepare the bulk of it.
The brief: an agent team that reads along with software operations, follows anomalies to their cause in the code and delivers results where the engineering team already works. In our own software operations this team has been running on the production system since early 2026.
02 · What the team does
What the team does.
Monitors
Servers, error messages, response times and usage data come together in one weekly evaluation, with no staff involved. The report flags every new error for which nobody has yet created a ticket.
Narrows down
When something looks off, the agent checks in parallel what a person would have to check one after another: recent deployments, error patterns, system state, affected devices and interfaces. The result is not an alarm but a substantiated cause.
Proposes the fix
Not “something is wrong here” but a hand-over-ready ticket: cause, evidence, the affected file with line number, the function where the change applies. For a clearly defined change the finished lines are attached; for a more complex intervention the agent works out the change and presents it for review. What it cannot decide is explicitly marked as open rather than guessed.
Relieves support
Every incoming support ticket is automatically supplemented with the customer context. If the case turns technical, the agent follows the trail to the cause and presents a draft reply. A person checks and sends.
03 · How it works
How the agents work.
Connected to the existing tools: ticket system, code repository, hosting, log and error services. No additional tool, no second inbox.
Step 01
Read
Logs, error monitoring, deployment history and usage data are merged continuously.
Step 02
Narrow down
Anomalies are checked against releases, system state and affected devices until the cause is substantiated.
Step 03
Propose
The ticket is created in the team’s ticket system, in its template, assigned and linked, with a fix proposed at code level.
Step 04
Approve
The engineer reviews, decides the points marked as open and approves. The agent delivers in minutes; the pace after that is set by the release rhythm.
Set this process up in your company? Request a conversation →
04 · From practice
Three cases from our own operations.
A metric dropped and nobody knew why.
Profile names could hardly be changed any more, with no error message and no outage. The agent ruled out the last release as the cause while a second one searched the support tickets in parallel. The cause was a configuration: in the admin area, blocking patterns with single letters had been created, and because the application checks substrings, a single pattern blocked almost every name. Two hours after the analysis began the service was working again; the same evening a safeguard against recurrence was in place. Three agent teams found the cause together without anyone calling a meeting.
Sometimes the right answer is: don’t develop.
After an update, errors during checkout piled up. The obvious suspect was the company’s own new version. The agent broke the affected users down by device and operating system and found that most of them were running a pre-release version of the phone operating system that does not work with the platform provider’s payment library. No bug in the company’s own code, and not fixable by its own development. The result was not an engineering ticket but a draft reply for support and the go-ahead to roll the new version out fully.
A hole in the payment path that nobody had reported.
If a customer’s payment via the fallback provider failed, they stayed on that provider permanently. There was no way back to the working standard route. There were no complaints; the affected customers simply stopped buying. The agent found the gap while tracing the payment flow through the source code and wrote the ticket down to implementation level: the function to hook into, the existing helper that can be reused, the field to set, the flag for later monitoring. Three design questions it could not decide were marked as open. The change has been shipped.
05 · The outcome
What changes.
The first question after an anomaly (“did it come from the release?”) is answered before an engineer asks it. The analysis runs in minutes; the time after that is set by the team’s own review and release rhythm.
What arrives is not a concept but a proposal at code level in the team’s own ticket system. The engineer reviews and decides instead of starting from zero. In our own operations the agent team’s tickets have consistently turned into shipped code changes, and the weekly operations report has run without a gap since May 2026.
- Weekly report with no staff involved, flagging open errors.
- Causes substantiated rather than assumed, down to file and line.
- Tickets in your system, in your template, assigned and linked.
- Approval, prioritisation and deployment stay with the team.
06 · Who decides what
Who decides what.
find the anomaly → narrow down the cause → create ticket with proposed fix → assess and prioritise → apply the change → approve → test → measure the effect
The highlighted steps rest with people. That is not a statement of intent but set through the granted permissions: every agent gets exactly the rights its task requires and none beyond. How far it may go is a dial you set, per system and per agent, adjustable in both directions at any time.
And because agent teams err as employees err, usually not in the code but in the interpretation of numbers, a separate instance cross-checks every result. Whatever stands out is recorded as a fixed rule.
07 · Systems and access levels
Systems and access levels.
Our own set-up as an example. In your company, your corresponding system takes each place.
| System | Used for | Access level |
|---|---|---|
| Code and ticket system | Code, history, tickets, releases | read · write tickets and comments · merge requests depending on the level set |
| Application hosting | Application and instance state, deployments | read only |
| Log service | Request logs, response times, error rates | read only |
| Error monitoring | New errors, frequency, affected users | read only |
| Session recording | Drop-offs, devices, OS versions | read only |
| Support system | Support tickets, customer context | read · write internal enrichment |
| Analytics database | Metrics, revenue and user data | read only |
| Chat / messenger | Reports, warnings, summaries | read · send only in approved channels, otherwise draft for approval |
08 · Limits
What the agent is explicitly not allowed to do.
It does not deploy. No access to release or configuration variables of production; the corresponding calls receive an access-denied response.
It does not write production code without approval. Our own level is set to “up to the worked-out fix proposal”. The next step, submitting the change as a reviewable merge request, is a setting, not a project. Approval stays in review in every configuration.
It does not prioritise and does not decide on money or staff.
Every agent action is logged with a timestamp. Every machine-generated ticket carries a header line naming the person who triggered it; the tool enforces this.
Frequently asked
Frequently asked questions about this use case.
Does the agent team need access to our source code?
Read access, yes, otherwise it cannot trace causes to the line of code. Write permissions are limited to tickets and comments. Whether the agent may submit changes as merge requests is your decision via the access level.
Which tools do we have to introduce?
None. The team works with your ticket system, your code repository, your hosting and your log and error services. No additional tool and no second inbox is created.
How long does the set-up take?
The first configuration, usually operations monitoring with a weekly report, is set up as a fixed-price pilot in two to four weeks. After that the team grows to cover further tasks such as support enrichment or release documentation.
More use cases
Related use cases.
Operations & DevOps
The operation that knows where it will break before the peak: monitoring, database check and narrowing down in minutes instead of hours.
End-of-life mails to tickets
The email everyone receives and nobody handles: vendor end-of-life notices become verified tickets in your own ticket system, with deadline, priority and owner.
Marketing
Performance marketing end to end, analysis, creation and rollout in one system, with a human at the gate.
Does this sound familiar?
In a first conversation we look at your processes together and sketch out where an agent team would make the biggest difference. Free of charge and without obligation.