Build in-house or with a partner

The IT manager of a mid-sized company has three people on the team. This week they fixed an email outage, renewed licenses, gave access to four new hires, handled a security alert and answered forty tickets. The board asks for a plan to put AI agents into operations before year-end. He knows how to do it. What he doesn't have is time, or a team that can dedicate itself to it without neglecting everything else.

It's the last composite of this season. The pieces we covered — interfaces, definitions, evaluations, security and traceability as each case requires — need people responsible for building and maintaining them. The question is who has the capacity to take them on.

The real bottleneck

Technical competence is only part of the decision. Even when IT knows the systems well, its time may already be committed to keeping them running. Building and maintaining the pieces each agent needs takes assigned capacity and knowledge that must be kept current: models, protocols, evaluation and security.

Asking that of a team that fights fires all day risks delaying the project or degrading the support it already provides.

When building in-house makes sense

Building internally may be the better choice when the company can dedicate a stable team to it, when technology is part of its value proposition, or when scale justifies having its own specialists in data, AI and security. In those cases, the learning curve is an investment that stays in the company.

When a partner makes sense

A partner may make sense when IT can't free up people without affecting operations or specialized capabilities are missing. A partner may also help coordinate processes spanning teams. That does not guarantee speed: assess experience, scope, integration time and future dependency against building with the internal team.

A good partner doesn't replace your IT team. It takes them out of the firefighter role and puts them in the decision seat.

How to tell a good partner from a bad one

• It builds on your logic, not its template: the modules reflect how your company works.
• It works with your team, not alongside it: IT takes part in decisions and knows how everything works.
• It leaves capability behind: documentation, full access and transferred knowledge, not a black box.
• The contract specifies access to and export of data, rules and records in documented formats, with verifiable timelines and exit terms.
• It measures results in your operations, with the same metrics the business uses, not its own.

What's never delegated

You can delegate the build and some technical operations. The company should retain the ability to decide on its data, rules and priorities, with access and exit terms in writing. The previous season ended with an idea: the advantage doesn't come with a license. This one closes with a practical consequence: don't leave it locked inside a vendor's platform either.

One possible model is mixed. A partner helps build and maintain shared components; the internal team retains the rules, priorities and relationship with the business. The contract should define documentation, access, knowledge transfer and maintenance responsibilities. Over time, the company can take on more work if it has the capacity.

Thank you for joining us for this second season.

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.