Most organisations should not choose between complete in-house delivery and complete outsourcing. They should own the goals, process knowledge, standards and decisions internally, then use an implementation partner where they lack the specialist capacity to get agents working reliably.
The strongest model is usually hybrid.
Your people understand the work. The partner understands how to turn that knowledge into a dependable implementation. The organisation retains ownership of what the agent is for and how it should operate.
The apparent choice is too simple
“Build or buy” makes sense when comparing two pieces of software.
An AI agent inside a business is different. Its value depends on organisational context that cannot simply be purchased:
- what the business is trying to achieve;
- how the work really happens;
- which sources are authoritative;
- what the organisation considers acceptable quality;
- who may make which decisions;
- and where the agent must ask or stop.
An external partner cannot own those choices on the organisation’s behalf.
At the same time, access to Claude, ChatGPT, Copilot or an automation platform does not give every employee the time and technical experience required to finish production work.
The practical question is:
Which parts must the organisation own, and which parts benefit from specialist implementation capacity?
What should always remain in-house?
Strategic direction
The organisation must decide what it is optimising for.
An agent can help analyse options, but it cannot resolve competing priorities the leadership team has avoided choosing. Without direction, AI accelerates activity rather than progress.
Process knowledge
The people doing the work understand the exceptions, workarounds, informal decisions and customer realities that rarely appear in a process map.
OECD case studies of workplace AI implementation found that workers often made important contributions because developers needed their understanding of the real work. Their involvement also helped develop acceptance and trust. (OECD)
This knowledge should be made explicit, but it should not be treated as something the organisation can permanently hand over to a supplier.
Ownership and decision rights
Every operational agent needs a human owner who can decide:
- what the agent is responsible for;
- what a correct result looks like;
- which rules are authoritative;
- what authority has been delegated;
- which exceptions require human judgement;
- and when learning should change the specification.
The owner does not need to approve every action. They need to remain accountable for the work.
Risk appetite and standards
The organisation must determine acceptable risk, approved systems, data access, quality standards and deployment patterns.
NIST recommends defining and documenting human and AI roles, oversight processes, task scope and responsibilities throughout the AI lifecycle. (NIST AI RMF Core)
A partner can help implement those controls. It should not quietly invent them.
Why employees get stuck building agents themselves
AI-literate employees can often create a convincing first version.
They know the process. They can describe the goal. They can connect a tool, test a prompt and demonstrate that the idea is possible.
Then the last part begins:
- handling edge cases;
- restricting permissions;
- validating inputs and outputs;
- protecting sensitive data;
- recovering from failures;
- integrating with authoritative systems;
- testing realistic conditions;
- documenting operation and ownership;
- and maintaining the capability as tools change.
The first version can feel like 80% of the solution. The apparent final 20% can require most of the time and expertise.
AI has democratised prototyping faster than it has democratised dependable implementation.
This is not a criticism of the employee. Their job is normally to run sales, operations, finance, customer service or HR, not become the production engineer for every useful idea they identify.
What an implementation partner should provide
A good partner contributes more than extra hands.
Production experience
The partner should know how to turn a demonstration into an operational capability, including testing, permissions, observability, exception handling, deployment and rollback.
Reusable production tools
Specialists build their own agents, specifications, checks and delivery patterns. A task that would require a client to discover every step can be completed more quickly because the partner has already developed the production machinery.
Cross-client pattern recognition
The partner has seen common failure modes, such as agents optimising a local output, asking for constant approval, inheriting unclear authority or producing work that never enters the system where delivery continues.
Elastic capacity
An organisation may need five small improvements this week and none the next. A partner can provide implementation capacity without requiring a full internal team for an uneven stream of work.
Technical range
The right response may be a browser-using agent or a fixed automation, a small app, a product change, a data interface or a combination. The partner should choose according to the work, not force every problem into its favourite tool.
The context problem with outsourcing
Traditional outsourcing has a predictable weakness.
The partner does not know enough about the organisation. To build one useful agent, it may need extensive meetings, documents and repeated clarification.
By the time the work is delivered, the business or technology may have moved on.
The answer is not to remove the partner. It is to make organisational context persistent.
A Business Blueprint records:
- goals and measures;
- roles and decision rights;
- systems and data;
- workflows and AI Loops;
- knowledge sources;
- permissions and guardrails;
- previous improvements;
- and observed results.
Each implementation begins from what the Business Improvement Factory already knows. The employee confirms assumptions and supplies what remains unclear rather than briefing the organisation from the beginning.
This creates a partner with implementation capability and an increasingly internal understanding of the business.
A practical division of labour
| Responsibility | Organisation | Implementation partner |
|---|---|---|
| Set business goals and priorities | Own | Advise |
| Explain the work and its exceptions | Own | Elicit and document |
| Name the accountable human owner | Own | Require |
| Define risk appetite and decision authority | Own | Translate into controls |
| Choose implementation architecture | Approve | Recommend and implement |
| Build, test and deploy agents | Participate where capable | Lead where specialist capacity is needed |
| Accept the result in real work | Own | Support |
| Monitor technical performance | Share | Share |
| Decide whether the business improved | Own | Help measure |
| Update the organisational specification | Share | Share |
The model keeps authority and learning inside the organisation while avoiding the expectation that every employee must become a developer.
Start with supervised delegation
Agents should be onboarded, not switched on.
The easiest starting point is often a demonstration of the existing process. An employee can record themselves performing the work and explain what they are considering.
The implementation team then turns that into:
- steps and goals;
- required information;
- a testable definition of done;
- approved tools and access;
- expected exceptions;
- and Act, Ask and Stop boundaries.
The employee supervises early runs. The agent handles more routine execution as it proves reliable. People retain the genuinely unusual cases and decisions.
Anthropic describes a similar control problem for agents: repeated action-level approvals can create friction and become easy to ignore, while meaningful control is often better exercised over the plan, permissions and points where the agent needs clarification. (Anthropic, 2026)
The goal is progressive delegation supported by evidence.
The first agent changes how people see the work
The return from an early agent is not only the hours it saves.
In one Busy Work implementation, an HR employee spent two days each month moving information between two legacy systems. Both systems lacked APIs and were expected to be replaced, so a conventional integration was too expensive.
A browser-using agent was set up in an afternoon to perform the transfer through the employee’s existing access. The employee checked its early work and helped it handle exceptions.
Within a week, that employee had identified another five processes where the same model could help.
The first implementation developed improvement literacy. AI stopped feeling magical or threatening. The employee could recognise suitable work, understand where people remained important and imagine a better version of the role.
One small agent created demand for the next improvement.
When should you build agents fully in-house?
Full in-house delivery is attractive when:
- the capability is central to competitive advantage;
- the organisation has sustained demand for a dedicated team;
- deep access to proprietary systems is essential;
- internal teams already possess strong agent engineering, security and product capabilities;
- the agent requires continuous product development;
- and the organisation can recruit and retain the necessary specialists.
Even then, external specialists may accelerate early architecture, evaluation or capability transfer.
When should you use an implementation partner?
A partner is useful when:
- valuable ideas repeatedly stall after the prototype;
- internal technology teams are focused on larger priorities;
- demand is important but uneven;
- employees understand the work but lack implementation time;
- the organisation needs to learn through several small builds before hiring a permanent team;
- or the work crosses agents, automation, product and organisational design.
The best initial engagement is usually a meaningful, bounded improvement that can enter real work quickly.
When is a hybrid Factory model strongest?
The hybrid model is strongest when the organisation wants distributed improvement without uncontrolled AI sprawl.
Employees closest to the work identify what could be better. Leadership sets direction and foundations. The platform preserves shared context. Internal and external specialists implement through common standards.
Set direction centrally. Make improvement decisions as close to the work as possible.
This is a federated improvement model. It combines freedom at the edge with coherence at the core.
Risks of using an external partner
Dependency
If only the partner understands the system, the organisation has exchanged one bottleneck for another. Specifications, ownership, code, access and operating knowledge should remain visible and portable.
Context loss
If learning stays inside project chats and individual consultants, every engagement starts again. Require updates to the organisation’s shared Blueprint.
Black-box implementation
The partner should explain what the agent can do, which sources it uses, how it is tested and where it asks or stops.
Tool bias
A supplier may try to solve every problem with the platform it resells. Architecture should follow the work and risk.
Outsourced accountability
The partner can build and operate the capability. The organisation still owns the business decisions and outcomes.
Questions to ask an implementation partner
- How do you turn employee process knowledge into a testable agent specification?
- What happens between the first demonstration and dependable production use?
- How do you define Act, Ask and Stop boundaries?
- How do you test realistic edge cases and recover from failures?
- Where will code, specifications and organisational knowledge live?
- How do completed builds make future implementation faster?
- How do you measure adoption and business outcomes?
- Can the organisation change models, platforms or partners later?
- Which decisions remain explicitly with the organisation?
Frequently asked questions
Is it cheaper to build AI agents in-house?
It can be when the organisation already has the right people and sustained demand. Costs also include discovery, security, testing, maintenance, employee time and the opportunity cost of delayed implementation.
Will an implementation partner understand our business?
Not automatically. The operating model should build persistent organisational context rather than relying on repeated project discovery. Employees and accountable owners must remain involved.
Should non-technical employees build their own agents?
They should be encouraged to shape, demonstrate and test improvements. Production deployment should use controls and specialist support proportionate to the agent’s access and potential impact.
Does using a partner mean outsourcing AI strategy?
No. The organisation should retain strategic direction, standards, ownership and decisions. The partner supplies implementation expertise and capacity.
Can the partner train our internal team?
Yes. A strong partner should leave specifications, reusable patterns and better internal capability behind. The goal is not dependence. It is a stronger organisational ability to improve.
Bottom line
Do not outsource the purpose, context or accountability behind your AI agents.
Do not assume every person who sees a valuable use case should also complete the difficult production work.
Own the direction and the work internally. Use specialist implementation capacity where it helps your organisation get useful agents working faster, safer and with less disruption to day-to-day delivery.
