I Built an AI Agent for Myself. My Colleagues Wanted to Use It. That Is Where the Problems Started.

The Ritual

Several times a week, the same ritual. I open our requirements management tool, pull up the module, and start going through each item — checking safety levels, comparing against the previous version, flagging missing fields, drafting review comments. A small change task: 30 minutes. A complex one: two to three hours. At peak, this consumes roughly 20% of my working week.

I’m a software architect in automotive. This is part of the job.

Then I built an AI agent to handle the preparation work. Now I start the agent before I sit down to review, and by the time I open the tool, the analysis is waiting — flagged issues, inconsistencies, suggested comments. My review time per task dropped to 10–40 minutes.

But that is not the story. The story starts when my colleagues said: “Can I use that too?”

What I Built

A tool, not a product. One command, one task ID. The agent fetches the change task, pulls the affected requirements, checks the obvious things — missing fields, ASIL inconsistencies, unchanged requirements that don’t reference their origin — and returns a structured report with suggested review comments.

The key thing that made this work: I was both the domain expert and the developer. No handoff, no requirements document, no gap between “what I meant” and “what got built”. The agent does exactly what I would do, because I wrote both the process and the code.

That turned out to be both the strength and, eventually, the problem.

Two People Were Enough

The first colleague who saw the agent asked: “Can I run this on my tasks?” Then a second.

They started relying on it. Questions came in — an ASIL check with a false positive, a requirement type the agent hadn’t seen, a report format that didn’t fit their workflow. Every question came to me.

Not because they couldn’t think for themselves — these are experienced engineers. But because the agent lived in my head. The checklist logic, the edge cases, the reasons a particular check works the way it does — none of that was written down anywhere. It existed in the code, yes. But reading code is not the same as understanding intent.

There is a term for this: bus factor. It measures how many people need to leave before a project collapses. Mine was one.

I didn’t need ten users to see the problem. Two was enough.

The Scaling Trap

The obvious move seemed to be: build a platform. Make it universal, self-configuring, something anyone can set up. A proper product.

I stopped after one weekend of sketching it out. A platform is a different thing entirely — a team, a roadmap, user management, onboarding flows, backward compatibility. It is not the next step after a domain agent; it is a separate product with a separate business case. Building one alone, on top of a full-time job as an architect, is a good way to end up with neither a working agent nor a working platform.

The real problem was not technical anyway. The real problem was that all the knowledge — what to check, why this rule exists, what the edge cases are, what “good enough” looks like for a safety-critical requirement — lived in my head and loosely in the code. The agent was a codification of my expertise. And expertise does not scale by writing more code.

This is the trap I don’t see discussed enough. Everyone talks about building agents. Fewer people talk about what happens after they start working. The moment an agent becomes useful enough that others depend on it, you stop being a developer and start being a support function. Growth that should feel like validation starts to feel like pressure.

What Actually Helps

I have not solved this. But I have identified what moves the needle and what does not.

What does not work is documentation. A README that explains how to run the agent does not transfer the knowledge that matters — why this check works the way it does, what edge case broke it, why this approach was chosen over the three alternatives. Documentation describes what exists. It rarely captures why.

Here is what does help.

Knowledge in files, not in heads

From the start I put the review criteria — the checklists, the rules, the severity levels — into YAML files, not Python code. It was a technical decision originally: easier to change without touching the logic. It turned out to be something more important. A colleague who knows the domain can read a YAML file. They can add a criterion, adjust a severity, fix a description. They do not need to understand the codebase. The knowledge is accessible without the expert.

This single decision shrank the category of “only I can change this” significantly.

One person, not a crowd

“Write better docs so anyone can contribute” is a fantasy. What works is identifying one specific person who uses the agent regularly, understands the domain, and is willing to spend a few sessions learning how it works. Not a user — a co-owner. Someone who can answer questions when I am unavailable and make small changes without breaking things.

I don’t have this person yet. Finding them is now more important to me than any technical improvement.

Capture the why, not the what

Every non-obvious decision in the codebase — why a check exists, what incident prompted it, what the alternative was and why it was rejected — deserves one sentence somewhere. Not a comment explaining what the code does. A sentence explaining why it does it. This is the information that disappears when the expert leaves, and it is the information a new person needs most.

The Bigger Pattern

My agent deals with requirements traceability, ASIL levels, ISO 26262 compliance. I built a second one for software architecture models — same pattern, different inputs. The domains are specific. The pattern is not.

Think about any field where expertise is deep, processes are established, and the work involves structured, repeatable judgment. Legal contract review. Financial audit preparation. Medical documentation. Manufacturing quality checks. In every one of these domains, there are people who could, today, build an AI agent that automates the preparation work they do every week.

The barrier used to be technical. It is not anymore.

When building tools required a development team, the bus factor problem was handled by organisational structure — teams, documentation practices, code reviews, handoffs. Inefficient, slow, lots of translation loss — but structurally resilient. Now the expert builds it directly. Faster, more accurate, no translation loss. But the organisational scaffolding that handled resilience never gets built. The expert moves on, gets promoted, changes roles — and the agent quietly dies.

We are at an early enough stage that most people building domain agents have not hit this wall yet. The agents are new, the user base is small, the expert is still around and motivated. The wall is coming. It is cheaper to build for it now than to face it later, when people depend on the tool and the expert is exhausted.

Finding the Second Guardian

If you are building something similar — an agent for your own domain, solving your own process problem — here is the one thing worth doing before anything else: find your second guardian.

Not a user. Not a fan. Someone who understands the domain well enough to know when the agent is wrong, and cares enough about the tool to help keep it alive. One person is enough to move the bus factor from one to two. That is not a small thing — that is the difference between a personal script and something that can outlast you.

The agents work. Now comes the harder part.

If you work in safety-critical software development and you have been thinking about building something like this — or already have — I’d genuinely like to compare notes. Connect with me on LinkedIn.