Automating the Engineering Work That Isn't Your Product | Mendral<br>Mendral runs thousands of agent sessions a day across our customers. Some are the work we built it for: reviewing code, fixing CI, triaging incidents. Others are automations our customers built themselves: recurring engineering chores, specific to one team, that nobody wants to do by hand.

Blaxel runs seven of them in production without having written a single one; they described each in Slack and an agent built it.

The work every team has, and the work only you have

Mendral ships with agents for the DevOps work every team has. It reviews code against your test history and your past incidents. It reads dependency changes for supply chain attacks. It keeps CI green and fast, and it triages incidents when prod breaks. We ship that on by default because every engineering team needs it, and none of it is what makes your product yours.

But every team also has work that's specific to them. Enforce that every PR links a tracking issue. Check that new features ship with observability. Post a changelog every Monday so the team knows what went out. No vendor ships these, because they're yours.

Before AI, that work had two homes. You hired platform engineers to build and run it, or you pulled product engineers off the product to do it by hand. Most teams can't justify the first and quietly resent the second, so the chores get done late, done badly, or not at all.

Automations are the third option.

Why we built them

Automations work because of what Mendral already is. It's a multi-agent system, and the agents share one memory and one set of connections into your stack: your CI, your code, your issue tracker, your observability and infra services. That access is why Mendral can review a diff against your incident history or open a fix PR when a build breaks. It's also why an automation can act on what it finds: open a PR, file an issue, comment on the diff, with the same connections the core agents use.

The access is the hard part. Once an agent can read your CI logs, see your past incidents, and write to your repo, pointing it at the work that's specific to your team is the easy part. That's also the work we couldn't ship as a feature, because it looks different at every company. So you describe it, and the agent builds it.

There's a second reason. A lot of the boring work is also what gives a team confidence to ship. A testing guide on every PR, observability on every new feature, a tracking issue that never gets skipped: these are the checks that let people merge without second-guessing, and they're the first to slip when everyone's busy. An agent holds them so they happen every time, which raises the bar on what reaches prod.

An automation is a small agent

An automation has four parts: a trigger, a prompt, a set of integrations, and the tools it's allowed to use.

The trigger is a cron schedule or a GitHub event like a PR opening or a push, with CI and Slack triggers on the way. The prompt is instructions, written the way you'd brief a teammate: "You are a daily Sentry triage agent. Surface unresolved errors that need attention today." Integrations are the services it can reach, like Slack, Sentry, and Linear. Every automation also gets the same built-in tools our always-on agents use: your filesystem, insights, web search, memory, and CI logs. Writing to GitHub (opening PRs, commenting, re-running CI, pushing branches) is off by default and sits behind an explicit permission.

Each automation runs as a scoped agent on the same harness as the rest of Mendral. It reasons at runtime against your real repo, your CI logs, and your history. It shares the same memory too, so what Mendral learns triaging your incidents sharpens the automation that files them.

There's a name forming for this shape. Steinberger's version: stop prompting coding agents, start designing the loops that prompt them. Boris Cherny, who runs Claude Code, says he doesn't prompt Claude anymore; loops do it for him. An automation is that loop. The trigger decides when the agent gets prompted, the prompt carries the intent, and the permissions bound what it can touch. The part nobody mentions is who designs the loop.

You don't design the loop. You describe it.

Blaxel didn't fill out that config form seven times.

For each job, someone described it to Mendral in Slack. "File our open insights into Linear as triage issues." "Make sure every PR has a Linear issue, and create one if it doesn't." Mendral wrote the prompt, picked the trigger, wired up Linear and Slack, and posted the whole thing back to approve. When it wasn't quite right, they edited it in the same chat until it was, then promoted it to a schedule or a PR trigger.

The engineer who wants the automation is the one who gets it. No platform-team ticket, no YAML to learn, no waiting a sprint. You describe the boring thing you keep doing, and the agent that already knows your stack builds it.

Seven automations, and...