Why is the prototype misleading?
A working AI agent prototype is genuinely quick to build in 2026, which is exactly what makes the build decision treacherous. A capable engineer can wire a model to a few tools and demonstrate real work inside a week.
The prototype is not the project. What follows is approvals, audit trails, permissions, retries for jobs that fail overnight, credential encryption, tenant isolation, and a way to see what happened. None of that is glamorous and all of it is required before the thing can touch a customer or a ledger.
What does the build path actually require?
The build path requires an operating layer that usually dwarfs the agent itself. Before an internal agent can run unattended, someone has to build the approval queue, the evidence trail, the escalation rules, the spend limits, and the observability that lets you reconstruct a decision months later.
Each item is tractable alone. Together they are a product, and they have to be maintained by the same team that has other priorities.
- Approval queue with true previews of each proposed action
- Audit trail that reconstructs who approved what, and when
- Scoped credentials, encrypted at rest, revocable per system
- Background jobs with retries, leases, and progress reporting
- Spend and rate limits that are hard caps rather than alerts
- Memory that can be inspected and corrected
What is the ongoing maintenance cost?
Maintenance is the cost most build cases underestimate, because model capability moves and integrations change underneath you. A prompt tuned to one model version behaves differently on the next; an API you depend on deprecates an endpoint; a platform changes its permission model.
That makes an internal agent an ongoing commitment rather than a project with an end date. The relevant question is not whether your team can build it but whether they want to own it in year two, when the novelty is gone and it is simply infrastructure.
When is building the right call?
Build when the workflow is genuinely proprietary and close to your competitive edge. If the way you do this specific thing is part of why customers choose you, encoding it in a bought product may not be possible or wise.
Build also when you have unusual constraints that no vendor meets: an air-gapped environment, a regulatory requirement for a specific data path, or a system of record so idiosyncratic that no integration exists. Those are real and they do justify the cost.
When is buying the right call?
Buy when the function is common across businesses and your differentiation lives elsewhere. Search visibility, media buying, reconciliation, ticket triage, and outbound sequencing are done by thousands of companies in recognisably similar ways.
In those functions the operating machinery is the product, and it is already built and maintained. The competitive advantage is in deploying quickly and managing well, not in owning the code that runs it.
Is there a middle path?
The practical middle path is to buy the operating platform and keep the proprietary judgement in your own instructions. Most of what makes your version of a function distinctive lives in the remit, the standards, and the escalation rules rather than in the plumbing.
That is usually the honest resolution: buy the approvals, audit, permissions, and orchestration; encode your particular way of working in how you brief and target the role; and keep the option to build later for the one workflow that genuinely is your edge.
What does the maintained governance layer actually contain?
The governance layer a custom build has to own is longer than most estimates. It contains an approval gate through which every action is a proposal with evidence, and an autonomy model that grants trust per class of action from a record and withdraws it in one change. It contains an audit trail built as work happens, covering proposals, decisions with reasons, approvers, autonomy levels, effects, and management changes, and exportable. It contains credential handling that is scoped per tool and property, encrypted at rest with a separately held key, never exposed in logs, and revocable from one place.
It contains tenant and property isolation enforced on every query, including background jobs, and extending to memory and drafts. It contains spend metering against a wallet with a hard stop and per-role budgets. It contains a memory with provenance that a manager can inspect and confirm. And it contains the workspace where a manager reads a brief, approves, sets targets, and reviews performance. Each of these is a product in its own right, each changes as models and tools change, and on ftes.ai each is already built and maintained. The build decision is a decision to own all of them.