What does the myth say?
That AI agents are infrastructure: something engineers build, wire to your systems, monitor, and maintain, and therefore something a business team cannot have until the engineering roadmap has room. Under this belief a head of support or a finance lead who wants an AI employee files a ticket and waits, and the pilot is scoped, built, and eventually abandoned when priorities change. The belief is accurate for one way of getting an agent and wrong for the other.
The examination is about which way is which, and what each asks of whom.
Where does the belief come from?
From the fact that the first business agents were built in-house with frameworks, by engineers, and that most public discussion of agents is about building them. From vendors whose products are developer platforms and require code to deploy. And from the correct intuition that anything touching a ledger or a helpdesk needs someone technical to have looked at it. Each of these is real, and each describes a build rather than a hire.
The belief survives because few business leaders have seen the hire version.
What is true in it?
That an agent you build needs an engineering team, for the model call and for everything around it: the approval gate, the audit trail, the credential handling, the isolation, the metering, the memory, the interface, and their maintenance as models and requirements change. The comparison of a Digital FTE with a custom build in the library lists what that layer contains. That even a hired Digital FTE needs a technical person for a few hours: confirming connection scopes at the tools, and agreeing the pull request convention if the role publishes to a site built as code. And that security review, whoever does it, is real work.
The myth's error is in assuming the hire version needs what the build version needs.
What does the mechanism actually ask of a business team?
The manager of the function hires the role from the workspace and the first-run wizard opens: pre-filled from what the platform already knows, company, site, profile, what other FTEs learned, and asking only for what is new to this function, the remit, the escalate list, the targets it proposes. Connections are made by entering a dedicated, scoped account for each tool, created by whoever owns access, and the platform encrypts and stores it. The role proposes a Day-One plan and starts. From then on the manager reads the morning brief, approves in the Approvals tab, sends back with reasons, and runs the monthly review in Performance.
No code is written. The manager's skill is management, which is the skill the role is designed for.
- Wizard: pre-filled, asks only what is new
- Connections: dedicated scoped accounts, entered, encrypted
- Management: brief, approvals, send-backs, monthly review
What does it ask of engineering?
About three hours at go-live. An hour with whoever owns access, confirming that each connection is a dedicated account with the narrowest permissions the remit needs, and recording it. An hour to read the security questionnaire answers and verify two mechanisms personally. And, only if the role publishes to a site built as code, an hour to agree the pull request convention or to read and install the open-source endpoint package in the site. After that, engineering's involvement is the pull request reviews they already do, and an hour per quarter in the connection review. The CTO persona piece in the library sets this out from engineering's side.
Nothing runs inside your network, and nothing needs maintaining on your side.
How can you check for yourself?
Run the first-run wizard for one role and count who had to be in the room: the manager of the function, the person who owns access to the tool for one scoped account, and nobody else. Time it. Then list what engineering was asked to do, and confirm it fits in an afternoon. Compare with the engineering estimate for building the same function, including the governance layer, and with the maintenance line afterwards. If the role publishes to code, watch the first pull request arrive and be reviewed like any other.
The comparison with agent frameworks in the library gives the build-versus-hire line for teams that also build agents as their product.