What does a CTO get that the team would otherwise build?
A production agent is a model call plus everything around it: a way to propose rather than act, a human approval step, an audit trail of decisions, secure handling of the credentials it uses, isolation between the properties it works on, metering and limits on spend, a memory a person can inspect and correct, and an interface where a manager reviews all of it. Most of that is product and platform work, and it changes as models, tools, and requirements change.
On ftes.ai that layer ships built: the approval gate and autonomy ladder, the audit trail, encrypted scoped credentials, organization and property isolation enforced on every query, the token wallet with a hard stop, the Brand Brain with provenance, and the workspace. Your team owns none of its maintenance.
How does it touch your systems?
Through connections your team reviews like service accounts: a dedicated account or token per role and tool, the narrowest permissions the tool allows for the remit, scoped to one property, encrypted before storage with a separately held key, never in logs or responses, disconnectable from the workspace in one logged action. For publishing to a site built as code, approved content arrives as a pull request your engineers review and merge; for any other stack, an open-source endpoint package installed in your own Next.js site receives approved articles at an endpoint you control, and every line of it can be read before installing.
The article payload is a contract mirrored on both sides, versioned and typechecked so it cannot drift silently. Background work runs as tracked jobs, not inline requests.
- Connections: dedicated, scoped, encrypted, revocable, logged
- Publishing: pull request, or the endpoint package on your infrastructure
- Contract: mirrored payload, versioned, typechecked
What should a CTO ask about providers and keys?
Ask which model provider processes the data: the platform runs on the Claude Agent SDK. Ask whether the vendor trains on customer data: no. Ask whether you can bring your own provider key so model usage runs on your agreement, billing, and data terms: yes, encrypted like every other credential, replaceable and removable by an owner or admin, logged, with the gates unchanged. Ask how tenant isolation is enforced: at the data layer, every query, including background jobs, with the AI layer of memory, drafts, and logs scoped the same way.
Ask whether the audit trail can be exported and whether a connector can expose a role to your own assistant or agent under the same gates: yes to both, with the connector credential shown once and rotated if lost.
What should a CTO refuse?
Refuse to let a role hold a person's login or a shared admin; dedicated accounts only. Refuse a publishing route that merges without your engineers; the pull request is the gate. Refuse to install an endpoint package you have not read. Refuse a vendor that cannot describe isolation at the data layer or name its model provider. And refuse to build the governance layer yourself for a standard function when it is not your product; that is a year of maintenance on something that does not differentiate you.
Each refusal is a line your security review would draw anyway.
How does it coexist with what your team builds?
Along the line of differentiation. Your team builds and owns the agent that is your product or your core capability, with whatever framework and provider it chooses, and owns the governance layer around it because that layer is part of the product. The rest of the organization hires Digital FTEs for reconciliation, screening, support, content, and search visibility, and manages them through the workspace. Where the two need to talk, a connector exposes a Digital FTE to your agent as an MCP server with the approval boundaries intact.
Engineering teams are usually glad of the arrangement, because reconciliation and support were never the work they wanted to own.
What do the first 30 days ask of a CTO?
About three hours. An hour to review the written answers to the security questionnaire and verify two of them yourself: fetch a page as a scriptless crawler, connect and disconnect a tool. An hour with whoever owns access to confirm the first role's connection scopes at the tools and record the confirmation. An hour, if the first role publishes, to agree the pull request convention or read and install the endpoint package. After that, the role is the business's direct report, and your team's involvement is the pull request reviews they already do.
The quarterly governance audit's connection review is the recurring hour, and it is the manager's to run with your access owner present.
What does the platform not do for a CTO?
It does not replace the agent that is your product, and it does not pretend the governance layer is unnecessary for one. It does not run inside your network; it runs its own work and touches your systems through scoped connections and the routes above. It does not grant itself access; every credential is one you created and can revoke. And it does not merge into your repository; your engineers do.
A CTO who wants a framework to build with should use one. One who wants the standard functions off the roadmap, governed, with an integration surface the security review will accept, has the mechanisms here.