“After a projct was done, one customer asked, How can we now clone you so one can stay and take care of this?”

The after-deployment

The project ends. Everything is working. Then somebody still has to take care of the day-to-day requests

I think we have all seen it. A project is ending and the customer asks the expert to stay. But keeping an experienced implementation consultant around for routine support is rarely cost-effective. The alternatives are often to train another support supplier, train internal people if there is capacity, or quietly hand the responsibility to product owners from other systems.

Even if the original team is still there. They may know the systems well but lack the capacity to handle every small issue while delivering new work. Important operational knowledge is spread across several people, and too much of their time is spent answering the same questions or rediscovering old decisions.

My idea with this system is: what if there is a shared brain which could keep the documents up to date and be this combined knowledge repository of working methods, systems, and decisions?

You got some small error (or 20 more like) but no time to fix? Just ask this brain to create a fix plan for you or even better fix it itself.

The first prototype of Implementer

In 2025, I started an early OpenAI-based prototype for one of my clients. It had clear rules and we simply called it the “healer.”

At first it handled simple repair actions: restart this integration, or park it for four hours because the vendor API is down. We added examples of what a good healing process looked like. When the system found a successful resolution and we approved the outcome, it saved that resolution as another example.

Then we added automatic documentation after every change. It reviewed the current code, configuration, and integration logic and updated a living “LLM Wiki.” That knowledge could feed back into the healing loop or answer an employee’s question directly.

But after building that, I started thinking beyond the closed loop. What had actually made it fix the problem on the spot? That became the Implementer.

Models know a lot. What they lack is a way of working.

Large language models already know an enormous amount. The missing part is focus: how should this specific organization investigate, decide, communicate, document, test, and stop when the risk is too high?

You could call that “soul” or “personality.” I do not mean pretending software is human. I mean embedding the best parts of how experienced people actually work: our frameworks, standards, judgement, communication style, safety boundaries, and care for the outcome.

That is what I am trying to put into Implementer. I want it to preserve the best of us, a system that continues to use good methods and can make that expertise useful to others.

L2 support

My first work started as a student in 2005, fixing broadband orders stuck in errors. It was basically tier-two support. Most fixes were silly edge cases: an address had not reached the right registry yet, a postal code contained a non-standard character, or one provisioning step finished before another system was ready.

We read the logs, found where the ERP flow stopped, went into Oracle, corrected a small piece of data, or restarted provisioning. Normal RPA could not cover it because there were hundreds of variations.

I think the technology to cover most of L2 support cases is here.

Where I think this goes

I think solution owners will use tools like Implementer to manage routine change requests, updates, and lifecycle work themselves with customer policies and human approval still controlling changes.

Really good (human) implementers and consultants, will still be essential for new projects, major transformations, difficult process design, and work that requires human collaboration. But I think they will all use some sort of expert AI to help them, if not with their work directly then for research, documentation and remembering things.

The future looks fun.