How I Manage an ERP Project with AI: A Multi-Agent Software Development Methodology

Introduction

Across more than two decades in the field, I’ve watched the same thing happen again and again: a software project slows down, the budget creeps up, and the moment a client asks for something out of the ordinary, all the flexibility disappears. The traditional model was clear enough — a long analysis phase, large development teams, know-how sitting in one person’s head, and iterations that dragged on for months. Adding a single feature could take weeks, because the person who wrote the code was on another project, the tester was on yet another, and the third person who had to sign off was on leave.

Over the past year, something changed that picture completely: AI is no longer just a “helper tool.” It has become a layer that actively writes code, runs independent audits, and offers architectural recommendations. But here’s the real question: is having AI write code enough, or is managing AI a discipline in its own right? I’ll share my answer in this article, because these days I don’t run an ERP project alone — I run it with an AI team that I coordinate.

Using AI Tools or Managing Them?

The gap between the two is roughly the gap between being a “user” and being an orchestra conductor. Asking ChatGPT a question and copying the answer is one way to use AI — a useful one — but it won’t carry a project from start to finish. Without knowing what a given model does well, where it falls short, at which stage it tends to slip, and which task belongs to which model, you simply won’t get to a solid result.

I think of AI as a pipeline: a defined sequence, agents that each bring a different kind of expertise, and a coordination layer that turns each agent’s output into the next one’s input. That layer is called the “human architect” — that is, me. This distinction, between using tools and coordinating them, is what really decides whether a project wraps up in two weeks or eight months.

When a client says, “So you get AI to write your code,” my correction is always the same: no, I coordinate several AIs at once, and I don’t accept any of their output without auditing it first. It’s a distinction that matters, because a project’s quality lives or dies on how carefully that coordination is set up.

The Multi-Agent Pipeline: How It Works

On an ERP customization project, the pipeline I run breaks down into roughly five roles, each handled by a different AI or a human.

• Large context language model — reads the entire codebase, the database schema, and the existing integrations as one whole. Without a layer that can “see” hundreds of thousands of lines at once, there’s no reliable way to map where a system actually stands today. I use it to produce topology reports, chart dependencies, and surface recurring patterns.
• Architectural consultant AI — the layer where I make the high-level calls. Where should a function live, which shared service should it lean on, which design pattern fits, how should we set the technical standard? These are the questions that matter most to me. This is also where I design the instructions — the prompts — that go to the next agent.
• Development AI — the agent that does the actual writing. It creates files, changes existing code, and iterates against the specs the architectural consultant produced. Human intervention here is minimal, but nothing it produces moves to the next stage without being audited.
• Audit AI — the pipeline’s quality gate. It reads the generated code with a fresh eye, hunts for security vulnerabilities, checks the business logic, and flags anywhere the business rules have been broken. The agent that wrote the code can’t audit it — auditing always happens with a second pair of eyes.
• Human architect (me) — the layer that runs the pipeline itself. I decide which task goes to which AI, which output is good enough, and which change makes it to the live environment (prod). Responsibility to the client sits entirely with me, because none of the tools understand the business context the way I do.

Why the Human Architect’s Role is Critical

AI is surprisingly good at writing code. But there are still five things it can’t do:

• Understand the business requirement. When a client says “we want to tighten up the warehouse,” working out what they actually mean takes the context of hundreds of similar projects. AI can’t build that context on its own; I built it over years, and I’m the one who carries it into the pipeline.
• Make architectural trade-off calls. Every technical choice has a price — speed today costs you flexibility tomorrow, a standard approach costs you customization. Weighing those against the client’s priorities is an architect’s judgment call, not a model’s prediction.
• Sign off on going live. Moving to production always carries responsibility. If something breaks, the one who answers for it isn’t an AI — it’s me. That’s why the approval stays with a human.
• Take responsibility to the client. Business relationships run on trust. The client trusts a solution I’ve signed off on, not an AI’s raw output.
• Route the right task to the right tool. Which AI is good at which job, at which stage which model slips, which combination gives the best result — that knowledge builds up in someone who has run the pipeline long enough, and it becomes the pipeline manager’s real expertise.

Quality Assurance: Every Line Audited

In traditional software projects, code review — the written code being read and checked by another developer — often ends up optional. If the team is small, the schedule is tight, or priorities shift, it’s the first step to get skipped. In my methodology there’s no such option: every function, every change, every new file goes through an independent AI audit. And the audit report comes with line references, so exactly what kind of issue turned up on which line is documented in black and white.

That keeps errors from reaching the live system. A security vulnerability, a wrong business rule, a needless piece of duplicated code — it gets caught before it ever leaves the pipeline. For me this isn’t a nice-to-have but a cornerstone of the method, because an ERP system runs critical business processes, and in systems like that even the smallest error can bring production to a stop.

Which Projects Is This Suitable For?

This multi-agent pipeline approach really pulls ahead in a few scenarios:

• Custom module development on ERP — when you want to extend an existing platform to fit your own business needs, work that takes traditional teams months comes down to weeks.
• Warehouse, production, and quality screens — tailored interfaces for operational processes, exactly where rapid iteration pays off.
• Integration with existing systems — writing the bridge code that gets two different systems talking is one of the places an AI-supported pipeline is at its strongest.
• Air-gap / closed network environments — even where there’s no internet access and security is strict, certain parts of the pipeline can run offline.
• Critical sectors, including defense — the areas that demand the highest audit discipline. Paradoxically, multi-agent AI produces the most value here, precisely because every output is already subject to independent audit.

Conclusion and Call to Action

This methodology democratizes software development. It used to be that an SME had to put together a ten-person team, wait six months, and set aside a large budget for enterprise-quality custom software. Now the same quality is achievable in a few weeks. But please don’t misread it: this isn’t “hand it to AI and let it write itself.” It’s an approach that takes coordinating the right architecture, making the right calls, and building real audit discipline.

If you have an ERP project and it looks like it could be solved this way, let’s set up a discovery call. We’ll talk through the system, the need, the expectations — and if it genuinely fits, we’ll map out a roadmap together.