AI Project Management: Why building AI agents is just another IT project

A few months after generative AI became practical enough to build with, something interesting started happening on our side of FlexiProject – the business team, not the engineering one. Without writing any code, we suddenly had agents quietly running parts of our daily work: preparing client offers, filling in contract data, pulling Search Console reports, updating our product backlog after client meetings, helping us manage the website. Building them turned out to be the easy part. What we didn’t expect was that AI project management, treating each agent as a real software project, with a plan, a shared branch, tests and a delivery step, would matter just as much as anything our engineers had ever shipped. This is the story of what we learned, in the order we learned it.

In this article, you will learn:

Why building AI agents is, in practice, just another IT project
The five phases every AI agent project should go through
How MVP, agile and Scrum fit AI agent work
The mistakes we made along the way, and how to avoid them
How to stop two people from rebuilding the same agent in parallel

How a Business Team Started Building AI Agents

Building AI agents even though we’re not IT

The interesting twist of the last two years is that you no longer need a development team to ship working AI. A business person who can describe what should happen, and copy a few example inputs, can build an agent that does real work. We didn’t plan to become builders. We kept hitting tasks where the answer was obviously “this could be done by an agent”, so we started building. The first one took an afternoon. The second one took an afternoon. Then the trouble started – not with the building, but with everything around it.

The agents we built

The list grew faster than we expected. We have an agent that auto-fills client data into our standard contracts. An agent that prepares first-draft offers based on a sales conversation summary. An integrator that imports a client’s Excel project list straight into their FlexiProject environment. An assistant that helps us manage parts of our website. An agent that pulls Google Search Console data for our domain and turns it into a readable weekly summary. An agent that, after meetings with clients, updates our product backlog with what specific companies feel is missing, so feature ideas don’t get lost between a call and the next planning session. And dozens of smaller ones, single-task helpers that someone built for themselves, kept improving, and eventually shared with the team.

When the same agent was being extended in parallel

The friction didn’t come from the agents we built once and forgot about. It came from the agents that actually mattered. Two people would take a useful agent, each have a separate idea for how to improve it, and start extending it independently. A week later we had two versions: different prompts, different tools wired in, different edge cases caught – and no clean way to merge them. It was the same problem developers solved decades ago with Git: you cannot have two people working off a shared starting point and improving it in different directions without a branching model. We just didn’t think we needed one. Agents were “easy”. The phrase AI project management hadn’t entered our vocabulary yet.

Why AI Agent Development Is, Fundamentally, IT Project Management

Building agents is trivially easy

The first lesson is the most uncomfortable one: building an agent is genuinely easy. Anyone reading this could open a model and have something working within an hour. The demo will look magical. The first three users will love it. And that is exactly the moment the project becomes hard, because shipping a demo is not shipping a tool the company can rely on. The gap between “works on the inputs I tried” and “works on the inputs the whole company throws at it” is enormous, and the model itself does nothing to bridge it. Bridging it is what AI project management is for.

A business team building AI agents has to learn IT project management

When a non-IT team starts building software, and an agent is software, it inherits every problem engineering teams have spent fifty years learning to handle. Requirements need to be written down. Architecture needs to be designed. Code, or prompts, or tool definitions need to live somewhere shared. Tests need to exist. Changes need to be reviewed before they go live. Skipping any of these doesn’t make them disappear; it just moves the cost forward in time. The good news is the playbook already exists. The disciplines that make IT projects succeed apply unchanged when a business team builds agents. The only new ingredient is evaluation – the AI-specific version of testing.

Get started

The AI Agent Project Lifecycle

1. Initial analysis – what problem are we actually solving?

Every agent worth building starts with an analysis phase that has nothing to do with AI. Who is going to use this? What do they do today, step by step? Which of those steps actually hurts? What does “done well” look like – measurably? Before we built the offer-preparation agent, we wrote down the exact manual sequence the sales team followed, marked which steps were repetitive and which required judgment, and only then decided what the agent should and shouldn’t do. The analysis took longer than the build. That ratio is normal.

2. Planning – scope, integrations, shared branch

Planning is where you decide three things: inputs and outputs, the integrations the agent will touch, and, most importantly, where the work lives. If two people are going to contribute, they need a shared definition of “main”. That can be a single document with the canonical prompts and tool definitions, a repo, a skill folder – the format matters less than the agreement. Pick it on day one. Decide what the agent will not do, write it down, and stick to it; scope creep is the most common reason agents become unmaintainable.

3. Development – the deceptively easy part

The build itself is fast. That’s the trap. You’ll write your prompts, hook up your tools, run a few examples, and feel 80% done. You’re more like 30%. The remaining 70% is everything you haven’t tested yet: the weird inputs, the long inputs, the inputs in another language, the cases where one tool returns an empty result, the cases where the user changes their mind mid-conversation. None of this is visible from the inside of the build.

4. Testing – and then re-testing

This is where agents differ most from classic software, and where most teams cut corners. An agent passes a test today and might fail the same test tomorrow because you changed a single line in the prompt or because the underlying model was updated. The discipline you need is regression evaluation: a saved set of inputs with expected behaviors, run automatically, or at least systematically, after every change. Without this, you only learn about regressions when a user trips over them.

5. Delivery and handover

An agent that is never officially delivered is an agent that becomes legacy on day one. Delivery means writing the user-facing documentation, defining what success looks like in production, and setting up a way to monitor whether the agent is still useful three months later. We learned this one the slow way – see the next section.

MVP, Agile and Scrum in AI Projects

MVP first – start with the smallest useful agent

Every agent we built that succeeded started as the smallest useful version of itself. One task. One input. One output. We resisted the temptation to add the second use case until we’d seen the first one survive contact with real users. The agents that struggled were the opposite: ambitious from day one, with three capabilities none of which worked all the way through. Big-bang agents fail for exactly the same reasons big-bang software projects fail; the form factor doesn’t change the math. If you take only one rule from this article, take this one: an MVP for an AI agent is small enough that one person can describe it in three sentences and run it end-to-end on a real example by the end of a day. Everything after that is iteration.

Why agile fits AI agents naturally

Agents are unusually well-suited to agile work because they are unusually unpredictable. You cannot fully specify an agent up front the way you specify a payment form or a report. You make a small version, you watch it work in the real world, you see where it fails, you fix the next thing. Trying to design the perfect agent on paper before building it is the fastest way to build the wrong agent. Iteration isn’t a project management preference for AI; it’s a structural requirement – the same Plan, Do, Check, Act rhythm Deming described decades ago for any process that needs to keep improving, just applied to agents whose behavior you cannot fully predict.

Running agent work in Scrum sprints

We treat each significant agent as a small Scrum-style stream of work. There’s a backlog of capabilities the agent could have. Each sprint picks a small number of them. The sprint demo is the agent itself, run on real inputs from the team that will use it. If the demo isn’t convincing, the work continues; the cadence forces a real conversation between the builder and the users instead of a months-long silent build.

Mistakes We Made

Building before analyzing

Because building is so fast, it feels efficient to skip straight to it. It isn’t. Agents we built without a clear analysis ended up technically working while solving the wrong problem; the team using them was polite about it for a while and then quietly went back to doing the work manually. An afternoon of analysis would have saved a week of building.

Trusting the model to figure it out

This was our most consistent error and the hardest one to unlearn. We assumed that if we gave the model the task in plain language, it would design a good solution. It often didn’t – not because the model was weak, but because we hadn’t done the design work ourselves. The model has no view of your company’s context, your existing data, your unwritten conventions, the system around the task. The more of that you give it, a real analysis, a real architecture, the structure you want it to follow, the better the result. The model is excellent at execution. It is not your architect.

Going big-bang instead of starting with an MVP

Every time we tried to launch a fully featured agent on day one, the result took longer to build, was harder to debug, and was abandoned more often than the small versions we’d grown deliberately. Big-bang felt faster. It wasn’t.

Two people developing the same agent in parallel

This was the Git moment. Two people, the same agent, different ideas, different branches in their heads, no shared “main”. A week later, two versions that wouldn’t reconcile. We now treat every meaningful agent the same way developers treat code: one canonical version, an explicit branching model when more than one person works on it, and an explicit merge step. Or, if the ideas truly diverge, a deliberate decision to split into two separate agents instead of pretending they’re still one.

No initial documentation – users didn’t know what the agent did

The first internal users of our skills kept asking the same questions: what does this thing actually do, what do I have to pass in, what does the output look like, when should I use it versus the previous version. We thought the agent was self-explanatory. It wasn’t. We now write a short user-facing description for every agent at handover – what it does, what to feed it, what to expect, what it doesn’t do. It costs ten minutes and prevents weeks of confused use.

Get started

Frequently Asked Questions About AI Project Management

Is AI project management different from regular IT project management?

The disciplines are the same – analysis, planning, build, test, deliver, iterate. The differences sit inside the build and test phases: outputs are non-deterministic, behavior can drift when the model or prompts change, and “testing” becomes “evaluation against a saved set of cases”. Everything around those phases looks like a normal IT project.

Do I need a project management tool to manage AI agent development?

You need a place where each agent lives as a project: with a plan, a current version, an owner, and a delivery state. Whether that place is a project management system, a wiki, or a folder structure matters less than having one. For teams running many agents in parallel, a real PM system pays for itself quickly.

How big should an MVP agent be?

Small enough that one person can describe it in three sentences and run it end-to-end on a real example by the end of a day. If you can’t, the scope is too big and the MVP is something narrower inside it.

How do you stop two people from building the same agent in parallel?

You don’t stop two people from contributing – you make it explicit where the canonical version lives, who owns the merge, and when divergent ideas should become a deliberate fork into two separate agents. The lesson from software engineering applies one-to-one: a shared branch, with an agreed merge process.

When does an agent become legacy?

The moment no one is responsible for evaluating whether it still helps. An agent that no one is checking on quietly degrades, the world around it changes, the inputs evolve, the underlying model is replaced, and one day it’s wrong and no one notices. Legacy isn’t an age, it’s a state of neglect.

Conclusion

The exciting part of building AI agents, the model, the prompts, the moment a demo works for the first time, is the smallest fraction of the work. The unexciting parts are what turn a demo into a tool the whole company can rely on: a clear analysis, a real plan, a shared branch, regression tests, documentation, and an iteration rhythm that keeps the agent useful long after the first version shipped. None of this is exotic. It is exactly the discipline that has been making IT projects succeed for decades, applied without dilution to a slightly newer kind of software. The teams that adopt that discipline early end up with agents they trust. The teams that skip it end up rebuilding the same agent twice. Treating each agent as a real project, with a plan you can lay out, revisit and improve, is what AI project management means in practice. We do that in FlexiProject, where every agent gets its own project record with a clearly written plan of action; whatever system you choose, treat each agent as a project, not an experiment.

Dominik Wrzosek

General Manager at FlexiProject

Dominik is an expert in project management and a graduate of the Warsaw University of Technology. He leads the development of the FlexiProject system, translating business needs into practical solutions that support project teams. He has experience implementing FlexiProject in organizations of various sizes, combining technical expertise with a business-oriented approach to effective project planning and execution.