Every council now feels the pressure to do something with AI, and sooner or later that pressure lands on a single fork in the road. Do you hire people and build agentic tools in-house, or do you bring in a partner to run an AI transformation for you? It is the build vs buy question councils have always faced with technology, except the stakes are higher and the skills are scarcer.

In 2025, the LGA’s State of the Sector research found 95% of councils using or exploring AI, but only 7% describing themselves as leaders using it at scale, which tells you the deciding step is rarely the ambition. It is how you resource the build.

What does building AI in-house actually require?

Building is not one cost, it is three. There is the build itself, the ongoing maintenance, and the scarce talent that both depend on. The first is the one everyone plans for. The other two are where in-house projects quietly run aground. Here is what each of the three actually costs.

  1. The build. Standing up the agent itself. This is the visible, planned-for cost, and the part every business case captures.
  2. Maintenance. An agent is not a document you finish and file. It drifts as policy, data and services change, and someone has to keep it accurate, which is the step most in-house builds underfund.
  3. Talent. Engineers who can build and maintain production agents are expensive and hard to hire, competed for by every sector with deeper pockets than local government.

None of this means building in-house is wrong. It is the right call in specific conditions.

If the workflow is non-statutory and low-risk, if the data stays firmly inside your walls, if you already have a capable data and engineering team with genuine spare capacity, and if you have budgeted for the maintenance rather than just the build, then owning it end to end can be the better long-term position. The failure mode is building for control you are not resourced to keep.

When does buying or partnering win?

Buying wins when the binding constraint is capacity, not ambition. Across UK local government, only around 2% of IT capacity is typically free for change work, and in-house AI capability is rare, which means the honest question for most councils is not whether they could build this but whether they could build it this year, on top of everything else, and keep it running. When the answer is no, a partner who has already built the thing is buying you time you do not have.

It also wins on risk. In statutory workflows like SEND or Adult Social Care, a fragile in-house pilot is not a low-stakes experiment, it is a live service that affects residents. This is where proven products earn their place. AI that drafts Education, Health and Care Plans is already used by 40 councils and returns around 75% of caseworker drafting time on average, which is a very different starting point from a blank repository and a new hire.

A useful way to test any partner is to ask which of three things is true of what you need. Either it already exists and can be switched on at a fixed price, or it has been done before and can be fitted to your data, or it is new ground that has to be built with you. A good partner will tell you honestly which one you are in, rather than quoting every request as bespoke.

Is build vs buy really a binary?

For AI in councils, it usually is not. The most sensible route for a mixed problem is to buy what is already proven and co-build only the part that is genuinely new to you, which is how the council deployments that work have tended to come together.

Wigan is a good example. The Adult Social Care assistant that began as bespoke work, shaped over six months of embedded co-design with a champion group of social workers, is now a repeatable asset other councils can adopt. Its use of AI in Adult Social Care supported, rather than drove, an Outstanding CQC rating, with more than 300 social workers using AI daily and Needs Assessment drafting time cut by around half. The same foundation has since carried into housing, HR and governance. That is the ladder in practice: bespoke to repeatable to product.

The reason this matters for the build vs buy decision is that it dissolves the worst objection to buying, which is lock-in. If what you buy is co-built with your own staff on your own data, the line between their tool and our tool gets thin by design.

How should a council actually decide?

Run each candidate workflow through a short list of questions before you commit either way:

  • Is it statutory or resident-facing, where failure is costly?
  • Does it already exist as a proven product somewhere, or is it genuinely new ground?
  • Do you have real in-house capacity, not just interest, and have you budgeted for maintenance as well as the build?
  • How sensitive is the data, and can it stay in your tenancy under either route?

Your answers usually point clearly toward build, buy, or the co-build middle.

To be straight about who is writing this: Agilisys sits on the buy-or-partner side of this decision, so weigh that. What we would argue is that the decision should be made on capacity and risk, not on a preference for owning everything or outsourcing everything. When we work inside a council, the standard we hold ourselves to is that the system keeps working with or without us. We build your capability, not your dependency, the data stays in your tenancy, and your team can run what we leave behind.

The mistake is treating build vs buy as a matter of principle. It is a matter of fit. Pick the route that gets a real service into production without leaving you dependent on something you cannot run, and be willing to build some of it and buy the rest. When you have decided, ask the same blunt question of either path: a year from now, does it still work, and can we run it ourselves?

Key takeaways

  • Build in-house when the workflow is lower-risk and non-statutory, and you already have the data, skills and budget to maintain it.
  • Buy or partner when speed to production, statutory risk, or scarce AI talent is the binding constraint.
  • It is rarely a pure binary: a sensible route buys what is already proven and co-builds what is genuinely new.
  • Whatever you choose, insist you own and can run the result after the build is done.

Frequently asked questions

Should a council hire an in-house AI team?

Only if you have non-statutory, lower-risk workflows to justify it and can fund ongoing maintenance, not just the initial build. AI engineers are scarce and expensive, and local government competes for them with better-paid sectors. Many councils get further by partnering first and building in-house capability alongside a proven system.

Is building AI in-house cheaper than buying?

Rarely, once maintenance is counted. The build is the visible cost; keeping an agent accurate as policy and data change is the recurring one most projects underfund. Buying a proven product removes the build cost and the drift risk, though you should still insist the result stays in your tenancy and your team can operate it.

What can councils buy off the shelf versus build?

Buy what already runs in production elsewhere, such as EHCP or Needs Assessment drafting, where a proven agent exists across multiple councils. Reserve building for workflows genuinely unique to your authority. The middle path, co-building on a proven foundation, covers most cases and avoids both a blank-page build and rigid vendor lock-in.

Sources