Delivering a CRM with AI Agents at Every Stage of the Lifecycle

Most teams that say they use AI in development mean a coding assistant in the IDE. Code gets written faster, while requirements, planning, review, testing, and documentation run as before.

In a recent House of Angular client project, we tried a different setup, with agents involved in every stage. Over three months, we built a five-module CRM for a leading Polish distributor of ventilation and air-conditioning products, including a two-way integration with Comarch ERP XL.

The contract was fixed-price. The team consisted of two developers at half-time and a project manager at half-time. In our assessment, this scope would not have fit these resources with a conventional process. A CRM with a two-way ERP integration normally needs dedicated QA and a PM working close to full time just to keep requirements consistent.

Here, agents took over most of that work, and the team’s time went into decisions and implementation.

Let’s take a look at how we did it, step by step.

The pattern behind every stage

Each stage follows the same four steps:

The agent collects its context directly from Jira, meeting transcripts, documents, and the code.
The agent does the work, for example, drafting tickets, writing code, testing, or checking requirements.
A named person reviews the result and is responsible for it.
The approved result becomes the input for the next stage.

Agents read requirements directly from Jira

In this setup, agents have direct access to Jira and to the code. When a developer starts a ticket, the agent sees the epic, the story, its subtasks, the comments, and the decisions attached to them. It does not depend on what someone pasted into a chat window, so it can spot links between tickets that a person reading a single ticket would miss.

Anthropic’s AI-native SDLC playbook keeps requirements as versioned files next to the code. We kept them in Jira. Our PMs and clients already work there, non-technical people know the tool, and agents fit into the existing processes without moving anything.

Turning meeting transcripts into backlog items

Client decisions are made in meetings. Usually someone takes notes, someone else turns them into tickets, and the reasoning behind a decision gets lost along the way.

Here, an agent splits each transcript into threads, one per topic, with the relevant part of the conversation attached. The PM decides which threads become Jira tickets and how they are scoped. Topics raised in a meeting reach the backlog even when nobody wrote them down.

Questions before code

Before implementing, the agent uses a dedicated skill to read the ticket and ask the developer about anything missing or unclear. A developer reading a ticket often fills a gap without noticing it is one. The agent goes through the ticket point by point and asks about anything not specified. On this project, specification gaps came up at the start of a ticket instead of as rework at the end.

The agent adds every decision from that exchange to the Jira ticket as a comment, so the reasoning stays attached to the requirement.

Implementation

Agents write code against the ticket while the developer steers the work in the IDE. Technical documentation and mockups are generated from the same Jira requirements, which keeps them consistent with the code.

Continuous testing

A QA agent tests the application continuously and files bugs in Jira. Development phases overlapped: module two was still being retested while module three was being built. In a conventional process, a module that has passed acceptance is no longer tested, and regressions in it are found by the client.

The QA agent also reports conflicts between features and between decisions made at different times.

Auditing the specification

Separately from feature work, agents check the whole requirement hierarchy (epic, story, subtask) for contradictions and for differences between what was specified and what was built.

The audit found a conflict nobody had noticed. In answers given weeks apart, the client had described two different behaviours for quote clones when the base quote changed, and both ended up in the backlog. Checking that many linked issues by hand is not realistic, so without the audit the conflict would most likely have come up only during implementation.

Who is responsible

Agents do not merge, accept, or sign off on anything. They review the code, test changes in a running browser and run automated tests, and a developer checks the result before every merge. Client acceptance runs in separate stages, each with a named owner on the client side.

Agents also do not settle disagreements in the specification. When the QA agent found four discrepancies between the specification and the implementation, it did not file them as bugs or choose an interpretation. It passed them to the PM as decisions to make. An agent can show that two things disagree, but deciding which one is right is a business decision.

Feedback loops

Agents also help improve the process. We had them analyse the whole bug backlog, group the bugs and summarise the causes, then used those conclusions to update the agents’ own skills.

We repeat this at other stages too, for the QA agent, for backlog quality and for the artifacts produced at each step.

Where the bottleneck moved

Agents sped up building. They did not speed up deciding what to build.

On the ERP integration module, scope was still being discussed in mid-September, and the module was delivered at the end of that month. Once scope was agreed, implementation was not the constraint. The schedule depended on how clear the requirements were and how quickly the client could make decisions.

Because of that, we now agree on the groundwork during discovery: which artifact is the source of truth, who verifies what, and which tools the project uses.

What is automated at each stage

The repeatable parts of this project are now a set of agent skills we use on new projects.

Stage	What agents do	Who decides
Requirements	Split meeting transcripts into threads, draft Jira tickets from decisions	PM
Refinement	Question gaps in each ticket, record decisions in Jira	Developer, PM
Implementation	Write code, technical documentation, and mockups from the ticket	Developer
Review	Review code, exercise changes in a running browser, run tests	Developer, before merge
Testing	Test continuously, file bugs, raise specification conflicts	PM
Specification audit	Cross-check transcripts, documents and Jira for contradictions and drift	PM, client
Backlog hygiene	Merge obsolete subtasks, keep the hierarchy current	PM
Process improvement	Analyse the bug backlog and update agent skills	Team
Acceptance	None	Client

What to ask a delivery partner

Four questions help check whether a delivery partner actually works with AI agents. Our answers are in the second column.

Question	Our answer
How do agents get access to requirements?	Directly from Jira and the codebase.
What verifies agent output before it merges?	A developer reviews every change before merge, after agent review, browser tests and automated tests.
Does testing run continuously or only at module boundaries?	Continuously. Earlier modules are retested while later ones are built.
Who decides when the specification contradicts itself?	The PM and the client. Agents only report the contradiction.

Takeaways

Agents made the biggest difference in the work around the code, not just in writing it. They work well when they read the same tools the team uses, and stay safe when a named person owns every result. Once building gets faster, the schedule depends on how quickly the client decides, so that is where we now put effort at the start of a project.