What Building a Production CRM With AI Agents Actually Looks Like

There is a difference between generating code and taking responsibility for a production workflow. The first is a demo. The second is a commitment. Most of the conversation about AI agents in software delivery blurs that line, which is why so many teams start agentic projects with the wrong expectations.

The public Connectere project summary is a useful anchor. Connectere is a full-stack real estate CRM for a UK property services company. The summary describes settlement lifecycle automation, agent and client management workflows, and ongoing maintenance handled with Workforce agents. This piece is not a case study in the sales sense. It is an operator's view of the method that makes that kind of engagement work, and the same method applies to any serious piece of operational software.

A CRM is an operating system, not a set of screens

The first discipline is conceptual. A production CRM is not a collection of screens. It is an operating system for the business. Every workflow inside it encodes a decision the business has made: how a settlement moves from stage to stage, who can touch which record, what happens when something stalls.

When you treat a CRM as screens, you ask an agent to generate forms and tables. When you treat it as an operating system, you ask a different question first: what does this business actually do, end to end, and where does the software carry that load? The build follows from the answer.

Map the workflow before you scope a single task

The build loop starts with mapping. Before any agent writes anything, the team traces the real workflow as the business runs it. Not the idealised version, and not the one implied by a competitor's demo. The actual sequence of events, handoffs, and exceptions.

That map defines system boundaries. It tells you what belongs in the product, what belongs to a human, and what belongs to an external tool. Without it, agent tasks have no edges, and an agent without edges will fill the gap with plausible guesses. Plausible is the most expensive word in production software.

Give agents context, scope, and a review bar

This is where the method becomes concrete. Agents are most useful when they are given four things: explicit system context, a bounded task, review criteria, and a named human who stays accountable for the result.

System context means the agent knows the workflow map, the boundaries, and the conventions of the codebase it is changing. A bounded task means it is asked to implement one well-defined piece, not to "build the CRM." Review criteria means the definition of done exists before the work starts, in the form of acceptance criteria tied to the workflow, not to the code. Human accountability means someone specific owns the decision to ship, every time.

This is the same operating discipline described in the wider model for a small AI-native product team: the leverage comes from structure, not from the raw speed of generation.

Keep humans on the release decision

A point worth stating plainly: agents participating in delivery does not remove product leadership from the build. Leadership remains responsible for workflow design, for priority, for acceptance criteria, and for the final production decision.

That responsibility is not ceremonial. When an agent's output is reviewed against acceptance criteria, the reviewer is checking the software against the business, not just against a linter. Did the settlement flow handle the stalled case correctly? Does the agent and client view match how the team actually works? These are product judgements. They do not delegate well.

Why maintenance is the real test

Production software changes as the business changes. Processes shift, regulations shift, the team learns what the first version got wrong. A CRM that cannot absorb change cheaply becomes the thing the business works around instead of works on.

This is where the value of an agentic delivery system actually lives. Not in a one-off code generation moment, but in repeatable loops: investigate the change, implement it inside the same bounded-task discipline, review it against criteria, ship it, and maintain. The loop is the product. The first version of the software is just the loop's opening output.

Teams evaluating agent-assisted delivery often fixate on the build. The build is the easy part to demo. Maintenance is where the method either pays or collapses, because maintenance is where scope discipline, context, and review criteria get tested hundreds of times instead of once.

A checklist before you start

For teams considering agent-assisted delivery of operational software, these are the questions I would want answered before a single task is scoped:

1. Do we have a written map of the workflow the software must carry, including the exceptions?

2. Have we drawn system boundaries: what the product owns, what people own, what external tools own?

3. Can every agent task be stated as a bounded unit of work with acceptance criteria written in advance?

4. Is there a named human accountable for each release decision, and do they have the context to make it?

5. Do we have a maintenance loop, not just a build plan?

If the answer to any of those is no, the bottleneck is not the model. It is the method. Fix the method first. The agents will do exactly as well as the structure you put around them, and production software is unforgiving about the difference.