What decision does the Differentiation Line frame?
Whether a given AI agent should be built by your engineering team or hired as a Digital FTE. The question arrives at technology leaders as a false binary: either we build agents or we buy them. The frame replaces it with a line through the list of candidate agents, and most companies find that one or two agents belong on the build side, because they are the product, and the rest belong on the hire side, because they are functions every company has and nobody's roadmap should carry.
The comparison of a Digital FTE with a custom build in the library lists what the governance layer contains; the frame is about which side of the line each agent falls on.
What are the four questions?
Differentiation: is this agent part of what customers buy from you, or a capability your competitors also have, or is it a standard function, reconciliation, support, screening, content, that exists in every company? Layer: will you build, test, and secure the approval gate, the audit trail, credential handling, tenant and property isolation, metering with limits, a provenance-visible memory, and a manager's interface, because a model call without them is a demo? Maintenance: who owns that layer in eighteen months, as models, tools, and requirements change, and what does that person not build instead? Coexistence: if you build one agent and hire others, can they talk through a connector that keeps the approval boundaries, so the build does not have to absorb every function?
Answer the four for each candidate agent, not for the company as a whole.
- Differentiation: product, or standard function?
- Layer: will you build the governance around the model?
- Maintenance: who owns it in eighteen months?
- Coexistence: can built and hired agents connect under the gates?
How does the worked example read, with the inputs left blank?
Candidate agents: [agent A], [agent B], [agent C]. For [agent A]: differentiation, it is [the product feature customers pay for]; layer, the team will build gate, trail, credentials, isolation, metering, memory, and interface, estimated at [engineer-months]; maintenance, [named owner], costing [fraction] of their time; coexistence, exposed to hired roles through [connector] if needed. Verdict: build. For [agent B]: differentiation, it reconciles [system] against [system], a standard function; layer, the estimate above would be repeated for no product benefit; maintenance, nobody wants it; coexistence, not needed. Verdict: hire as a Finance Controller FTE. For [agent C]: differentiation, it answers customers from [help center], standard; verdict: hire as a Customer Support FTE, with [agent A] able to call it through the connector under the same approval gates.
If the layer estimate for a standard function is blank, it is because nobody has costed it, which is the usual reason build looks cheap.
Why does the layer decide most cases?
Because the model call is the smallest part of a production agent and the layer is the largest, and the layer is what changes. The approval gate has to fit how managers actually review; the audit trail has to satisfy the next auditor; credentials have to be scoped, encrypted, and revocable; isolation has to hold on every query including background jobs; metering has to stop at a limit; memory has to show provenance; and the interface has to be one a non-engineer manages from. On ftes.ai that layer ships built and maintained, and the engineering team's part is confirming scopes and, for publishing to code, reviewing pull requests. For an agent that is your product, you want to own all of it. For reconciliation, you do not.
The CTO persona piece sets out what that layer asks of engineering at go-live: about three hours.
Where does the line usually fall?
Build: the agent that is the product or the core capability, one or two per company, with whatever framework and provider the team chooses. Hire: finance reconciliation and receivables, first-line support and knowledge base upkeep, recruiting screening and scheduling, CRM hygiene and qualification, search visibility, social presence, and content production. Connect: where the built agent needs a hired role's output or the reverse, a connector exposes the Digital FTE as an MCP server with its approval boundaries intact, so the build stays narrow. The comparison with agent frameworks in the library gives the framework-side view of the same line.
Engineering teams are usually glad of the line, because reconciliation and support were never the work they wanted to own.
How is the frame applied?
List every agent anyone in the company has proposed or built. For each, write the four answers with the brackets filled, and insist that the layer estimate for any build candidate include every component and a named maintainer. Draw the line. Build the agents above it as engineering projects with their own specs. Hire the functions below it as Digital FTEs, managed by the functions' own leaders, with engineering's involvement limited to scope confirmation and pull request review. Where a built agent needs a hired role, set up the connector. Re-run the frame when a new agent is proposed; the answer is usually hire, and occasionally build, and the frame makes either defensible.
The refusal the frame enforces is building a standard function because the engineering team can; the roadmap cost is the argument.