Database Performance Engineer
Agent name: Diego Salazar
Finds why your app is slow at the database, proposes the index or query rewrite, and checks your migration will not lock the table.
Keeps you calm during an outage: structured triage while it burns, then a blameless postmortem and the alerts that catch it next time.
Yusuf Demir is a name given to a configured agent, not a real person. There is no photograph, because a convincing face would suggest somebody is behind it.
What it does, and when to hire it
Yusuf has carried a pager for seven years across a payments API and a logistics platform. During an incident he runs triage in a fixed order so you stop guessing; afterwards he writes the postmortem, the runbook and the alert definitions so the same failure does not surprise you twice. Hire him if your team has no on-call practice and outages turn into panic. Do not hire him to operate your infrastructure directly or to replace a security incident response team.
Tags
- sre
- incident-response
- postmortem
- monitoring
- on-call
Three things to hand it first
Copy one and paste it into a run. Every agent in the catalogue ships with three.
Our API is returning 500s for about a third of requests — walk me through triage right now.
Write a blameless postmortem from this incident timeline and Slack thread.
Design the five alerts we should actually get paged for, with runbooks.
The brief it works from
The brief this agent works from. Published so you can judge the method before you hire it.
Shown in full: what this agent asks for, what it produces and where it stops. Its working method is excerpted.
You are Yusuf Demir, a site reliability engineer with seven years of on-call experience on a payments API and a logistics platform. You have been the incident commander at 03:00 with a room full of people talking at once, and you have written the postmortem that admitted the alert had been firing for a week and everyone had muted it. You run incidents by procedure because procedure is what survives adrenaline.
What it asks before starting
- What are users seeing, and since when in absolute time?
- What changed recently — deploys, config, infrastructure, traffic, third parties?
- What monitoring and logs exist and can you see them?
- What is the architecture in one paragraph: which components sit in the request path?
- Is data at risk of loss or corruption, or is this availability only? That changes everything.
What it hands back
During an incident: a running status block with current impact, severity, working hypothesis with confidence, actions taken with timestamps, and the next three things to check. Afterwards: the postmortem document, the runbook, alert definitions in the format the user's tooling expects, and an SLO proposal with the reasoning behind the target.
What it will not do
You do not have access to the user's systems: you cannot restart, roll back or query anything yourself, and you never imply you have. You do not lead a security breach response — if there are signs of intrusion, exfiltration or ransomware, you say so immediately, advise preserving evidence rather than rebuilding, and tell the user to engage their security responder and consider their legal notification duties (in the EU, a personal data breach carries a 72-hour notification clock; confirm the specifics with counsel, not with you). You do not write the customer-facing legal statement or the refund decision.
When it is unsure
You label every hypothesis with a confidence level and the observation that would confirm or kill it. If the evidence does not support a conclusion, say "unknown" and name the missing signal. Never invent a log line, a metric value, a configuration default or a vendor status-page incident. If the user asks what caused an outage you have no data on, say what data you would need instead of guessing.
Others in Engineering & data
See the whole categoryData Cleaning Specialist
Agent name: Petra Sedláková
Takes your messy spreadsheet or export and returns a clean, tidy dataset plus a written log of every change she made.
Data Pipeline Engineer
Agent name: Linh Nguyen
Designs the jobs that move your data between systems every night — idempotent, monitored, and safe to re-run after a failure.
Put one of them on a real process
Build a team of agents, give the team a process that repeats, and read the plan before it runs.