What changes when standard functions leave the build?
An in-house agent build usually starts as one agent for one purpose and is stretched, because it exists, to cover functions it was not designed for: the same loop pointed at reconciliation, then at support tickets, then at content. Each extension widens the credential set, blends the records, and adds maintenance nobody budgeted. Migrating the standard functions to Digital FTEs on ftes.ai returns the built agent to the purpose that differentiates the product and gives each standard function a role with its own remit, scopes, budget, and record, with the governance layer already built.
The comparison piece on a Digital FTE against a custom build lists the layer; this guide is about the move.
What should you keep of the build?
The agent that is your product or your core capability, with whatever framework and provider the team chose, and the team's ownership of its governance layer, because that layer is part of the product. Keep the prompts, evaluations, and tooling the build produced for that purpose. Keep the lessons: the team knows what an approval gate has to feel like to a manager, which is useful in reading the Digital FTE's remit. And keep the connector question open: where the built agent needs a standard function's output, a Digital FTE can be exposed to it as an MCP server with the approval boundaries intact.
The Differentiation Line framework is the tool for deciding what stays.
What moves, and in what order?
First, draw the Differentiation Line across every function the build touches, with the engineering team, and list the standard functions on the hire side. Second, for each, cost the built layer honestly: the components it has, the components it lacks, and the maintainer. Third, choose the standard function with the clearest evidence under the First-Function Matrix, record its baseline, and hire the Digital FTE for it while the build keeps running that function in parallel for one cycle. Fourth, compare at the first review, retire the build's extension for that function, and reclaim the credentials it held. Fifth, move the next function; connect the built agent to any hired role it needs through the connector.
The built agent narrows with each move. That is the point.
- Differentiation Line drawn with engineering
- Built layer costed honestly per function
- One function hired, run in parallel for a cycle, then the build's extension retired
What breaks in the first cycle?
The assumption that the build had the whole layer. Put side by side, the comparison usually shows the build lacks a per-class autonomy ladder, an exportable audit trail with names, credentials scoped per property, tenant or property isolation on background jobs, a hard stop on spend, or a memory with provenance, because those were never the product and nobody was paid to build them. The security lead, reading the Digital FTE's twelve checks, asks the same questions of the build, and the answers are uncomfortable. The team's pride breaks a little too, and the honest framing is that they built the differentiating part well and were stretched to cover the rest.
The security checklist in the library is the list the comparison runs.
What does the record show after a quarter?
For each migrated function, the same outcomes any role shows: targets with evidence, cost per outcome against the baseline, which in this case includes the engineering hours the build consumed for that function, approval rate per class, and incidents. For the built agent, a narrower scope, a smaller credential set, and a maintenance line the team can name. For the roadmap, the hours returned, which the CTO can point to. And, where a connector was set up, a built agent that calls a hired role under the same gates rather than reimplementing it.
The CTO persona piece sets out what engineering's involvement becomes: a few hours at go-live and pull request reviews.
What should you refuse during the migration?
Migrating the differentiating agent itself; it stays built. Retiring a build extension before the parallel cycle, because the comparison is the safety. Letting the build keep credentials for a function it no longer runs. Skipping the honest costing of the built layer, because the roadmap argument depends on it. And treating the migration as a verdict on the engineering team; the verdict is on the decision to stretch, which was usually nobody's.
The Differentiation Line framework describes where the line usually falls and why engineering teams are glad of it.