One afternoon, one AI agent, one mail server with no expert left

The situation

An Ubuntu mail server running Postfix, in production for years, grown and adapted over time. And nobody left in the building who knew it — the colleague who had set it up and maintained it was gone.

This is not an edge case, it is the normal state of affairs in mid-sized companies. Systems outlive the people who built them. What remains is configuration files somebody wrote a certain way years ago for good reasons, and a team unwilling to touch them because nobody knows what depends on what.

The usual escape routes are both expensive. Buying in external Postfix expertise solves the immediate problem and leaves exactly the same gap as before. Replacing the system is a project nobody wants to start for a mail server that is, after all, running.

The approach

One working session with the IT team — on the real problem, on the real server, not on a constructed example.

The AI agent was given shell access to the system. It could read logs and configuration itself, run diagnostic commands, make changes and restart services. The team sat alongside, followed every step, and could intervene at any point.

The content of the session was explicitly not “here is how you operate this tool”. It was about the working method:

• How to describe a problem so an agent can start on it — symptom, timing, what changed most recently, rather than “mail isn’t arriving”
• How to check what the agent claims before believing it. An agent explaining a Postfix directive can explain it wrongly; the counter-check is in the configuration and the log, not in the answer
• Where to stop it. Which steps you let run, and which you understand first before allowing them
• How to record the outcome, so the next person does not start from zero again — which is the actual problem behind the vanished knowledge

Where it could have gone the other way

Full shell access on a production mail server — and that is the opposite decision to almost everything else in this portfolio.

The systems I build deliberately hold back. The licence reporting recommends and never acts. The cost portal changes nothing in the cloud. The password portal refuses to release a secret it cannot log. In all of those, restraint is correct.

Here it was not, and the difference is not technical — it is supervision.

An automated system runs unattended, repeatedly, over cases nobody is looking at. There every write is a risk that multiplies. A supervised working session is the opposite of that: a person is sitting next to it, sees each step, knows the context, and can stop. Denying the agent execution here would only have meant somebody retyping what was already on screen — which buys transcription errors, not safety.

The risk was still real, and three things made it acceptable: it was one supervised session, not a standing arrangement. Postfix changes are configuration files and service restarts, so they are reversible — no data being deleted. And the team could have performed every step by hand; what was missing was the knowledge of what to do, not the permission to do it.

Where any one of those three conditions is absent, the decision does not transfer.

The result

The Postfix problem was solved that same afternoon. But that is not the result that matters.

The result that matters is that the team adopted the method and now applies it to other systems where the in-house knowledge is gone. The repaired mail server was the occasion, not the product — what was delivered was the ability to approach an unfamiliar system without first being a specialist in it.

What this way of working does not do belongs in the description too: the agent is no substitute for understanding. It shortens the path to a root cause, but anyone who does not check its claims has merely swapped one dependency for another — from the colleague who left to a model that sounds plausible. That is exactly why checking the claims was the longest part of the session, not executing them.