When should you choose a managed AI agent or build in-house?
A managed service suits a business that wants one specialist accountable for mapping, building, integrating, testing, and maintaining the workflow. An in-house build suits a business with a team that can own the product, security, infrastructure, tests, and business changes over time.
In either model, the business should remain the owner of its process, data, and decisions. The difference is who turns that knowledge into a working system and who looks after it after launch. Comparing only a licence fee with development hours leaves most of the work out.
What does a managed AI agent include?
In a managed model, one provider translates the workflow into instructions, tools, permissions, approval points, and measures. The provider tests normal and exceptional cases, monitors failures, and updates the solution when systems or working practices change. The business still approves allowed actions and provides a process owner for domain decisions.
GIMMI provides a bespoke AI employee built around an agreed workflow and connected to existing tools under approved permissions. It is not an off-the-shelf role or a fixed capability package; scope is defined only after mapping the systems, data, and boundaries.
A managed service still needs active participation from the business. Someone who knows the work must approve examples, define exceptions, and verify that results fit reality. Without an active process owner, even a capable provider has to guess.
When is an in-house build a good choice?
Building internally can fit when the agent is a core capability the company wants to develop, when it depends on deep internal integrations, or when frequent change requires a team inside the organization. The work requires more than a developer connecting a model: product ownership, domain knowledge, infrastructure, security, monitoring, testing, and a change process all need owners.
Check actual capacity. A team that can build a prototype may not have time to answer incidents, update permissions, test a changed external interface, and reconstruct a decision made months earlier. If that responsibility depends on one person, the business has an internal dependency to manage.
A practical comparison
| Question | Managed service | In-house build |
|---|---|---|
| Build ownership | One provider coordinates mapping and implementation with the process owner. | The business assembles a team and assigns responsibility across roles. |
| Knowledge retention | Needs agreed documentation, data access, and an exit path. | Stays with the team when documentation and handover happen. |
| Maintenance | Included within the scope agreed with the provider. | Competes for team capacity with products and other work. |
| Technical control | Defined through the agreement, architecture, and permissions. | High when the team owns every system layer. |
| Speed to begin | Depends on provider availability and workflow clarity. | Depends on internal availability and experience. |
A hybrid route is also possible: a provider builds and operates the first version, while the business receives documentation and knowledge transfer to take over suitable parts later. Define who owns each component and who may change it.
Ownership, control, and an exit path
Before work begins, record who owns the accounts, information, instructions, code or workflow configuration, and who can export them. Define how access is revoked, what happens when service ends, and which documentation remains. These are operational questions, not legal drafting or legal advice.
Also decide who approves changes. A seemingly small change, such as adding a field or automatic action, can alter both risk and business outcome. A clear change path should include sample input, expected output, testing, and a way back to the previous configuration.
Illustrative example: handling a quote request
It is not a customer story, price, fixed package, or promised result.
Suppose a business receives quote requests through WhatsApp and email. An AI employee must collect details, check whether the customer exists, prepare a CRM record, and send the request to a salesperson for approval. With a managed service, the provider maps the rules, builds the connections, and maintains the tests. With an in-house build, the business team develops and operates the same parts.
The deciding factor is who can own permissions, duplicates, missing fields, system changes, and human handoff every day. The workflow and measure can be the same in both models.
Questions to ask before deciding
- Who owns the business result, and who owns a technical incident?
- Which accounts and connections remain under business ownership?
- How is a change tested before it affects real work?
- What documentation is provided, and how could responsibility transfer later?
- What is included in maintenance, and what requires additional work?
- Which first workflow is small enough to test the operating model?
Once the operating model is chosen, continue with one bounded, measurable workflow. The guide to choosing the first workflow helps define it, and the service page explains how GIMMI maps, builds, and operates a tailored AI employee.
Professional sources and further reading
- OpenAI — A practical guide to building AI agents, covering agent components, workflow selection, tools, orchestration, and guardrails. Reviewed September 7, 2026.
- NIST AI Resource Center, a framework and resources for mapping, measuring, managing, and governing AI risk through the lifecycle. Reviewed September 7, 2026.