Building in-house vs hiring an agency
Straight answer: if you have engineers with agent experience and spare capacity, build in-house — you keep the knowledge and the knowledge compounds. The thing teams underestimate isn’t the build. It’s the evaluation infrastructure and the maintenance.
Last updated:
Build in-house when
- The workflow is core to your competitive position
- You have engineering capacity that isn’t already committed
- You expect to build many agents over time
- Your data or regulatory position makes external access genuinely difficult
- You want the capability to live inside the company permanently
Hire an agency when
- You need the first one working before you can justify hiring
- Your engineers are excellent but have never shipped an agent
- The integration surface is unfamiliar — CMMS, TOS, PMS, historian
- You have one or two workflows, not a programme
- Speed matters more than capability building
What in-house teams consistently underestimate
- 01
Evaluation infrastructure. A good first agent is achievable for a strong team. A regression suite that catches quality drift six months later is a different discipline, and it’s the one that gets skipped. Without it you can’t tell whether your agent is degrading — and agents degrade quietly rather than loudly.
- 02
Model deprecation. The model you launch on will be retired. Migration isn’t a config change; behaviour shifts in ways you need tests to detect.
- 03
Integration edge cases. The demo works against clean API responses. Production hits pagination, rate limits, partial failures, timeout behaviour and the field that’s nullable in practice but not in the docs.
- 04
Escalation design. Deciding when an agent should stop and ask is a product problem, not an engineering one, and it’s where trust is won or lost.
- 05
The 70% trap. Most agent projects reach 70% capability quickly and then stall. The last 30% — edge cases, error handling, escalation quality — is most of the work and all of the trust.
Honest cost comparison
| In-house | Agency | |
|---|---|---|
| First agent, elapsed | 3–9 months including learning | 6–12 weeks |
| First agent, cost | Salary + opportunity cost | Fixed, quoted from audit |
| Second agent | Much faster | Faster |
| Knowledge retention | Full | Partial unless you plan for it |
| Ongoing maintenance | Yours | Retainer or yours |
| Risk of stalling at 70% | High without prior experience | Lower |
The hybrid most people should choose
Hire for the first workflow. Have your engineers embedded in the build, not observing it. Take the eval suite, the documentation and the runbooks. Build the second one yourselves with support.
This is what embedded engineers exist for, and it’s the option we’d point most capable teams toward. Several clients have taken our audit document and built it themselves. That’s a fine outcome.
Frequently asked questions
Isn’t it against your interest to recommend in-house?
Clients we shouldn’t have taken churn, complain and cost more to service than they pay. The referral from an honest no is worth more than a bad engagement.
Can we start in-house and bring you in if we stall?
Yes, and it’s common. Stalling usually happens at integration or evaluation, both of which are recoverable.
What if we take your audit and build it ourselves?
Then the audit did its job. It’s written to be useful to any competent engineering team.
How do we know if our team is ready?
Ask them to describe how they’d detect quality drift in a deployed agent three months after launch. If there’s a confident, specific answer, they’re ready.
If we’re the wrong choice, we’ll say so
The audit includes the disqualification list. Several clients have taken the document and built it themselves, which is a fine outcome.