What is a model tier?
A model tier is the choice of which underlying language model a Digital FTE uses for its work. On ftes.ai it is set per FTE in the Setup tab, and the tiers carry honest labels describing relative cost and capability rather than product names that imply more than they deliver.
It is the single setting with the largest effect on both cost per outcome and quality of output, which is why it deserves a deliberate choice rather than a default left unexamined.
What does a higher tier buy?
A higher tier buys better reasoning on complex, ambiguous, or multi-source tasks: a Research Analyst synthesising a large document set, a Market-Entry Strategist weighing barriers, a Content FTE writing a long piece that must pass the fact gate on the first attempt. It costs more tokens per unit of work.
For those tasks, the higher cost is often recovered in fewer send-backs, because a draft that is right the first time costs less human time than one that needs two revisions.
When is a lower tier the right choice?
A lower tier is the right choice for routine, well-specified work where the pattern is clear and the approval history is long: exact-match reconciliation, first-line support replies from a well-maintained knowledge base, CRM field fills from public sources, interview scheduling.
On those tasks a higher tier adds cost without adding quality, and the send-back rate will show no difference. The saving is real and compounds over a month of daily work.
- Higher tier: synthesis, strategy, long-form drafting, ambiguous judgement
- Lower tier: matching, routine replies, field fills, scheduling
- Signal to move up: send-backs rising on hard tasks
- Signal to move down: quality flat and cost high on easy tasks
How do you choose per role?
Choose from the role's task mix. A role that is mostly routine with occasional hard tasks can run a lower tier by default, and missions that need more can be launched at a higher tier. A role that is mostly synthesis and judgement should start on a higher tier and be reviewed after a cycle.
The choice is not permanent. Review it each cycle from usage per role and the send-back reasons in the approval record: if hard tasks are coming back for revision, move up; if easy tasks are consuming more than they should with no quality difference, move down.
What about bringing your own key?
Organizations with their own model provider agreements can bring their own key, so the Digital FTE's work runs against the organization's account rather than the platform's wallet for that provider. Keys are encrypted at rest and never appear in responses or logs, as the BYOK guide on ftes.ai describes.
The tier choice works the same way with your own key; the difference is who is billed for the model usage. The approval gate, fact gate, and audit trail are unchanged.
What does a labelled example of tier selection look like?
As a labelled example: a Finance Controller FTE spends most of its tokens on exact and near-exact matches with clear evidence, so it runs on a lower tier by default, and its close mission, which involves proposing accruals with reasoning, can be launched at a higher tier for those days alone. A Research Analyst FTE synthesising many sources into a cited brief runs on a higher tier by default, because a brief that is right the first time costs less human time than one sent back twice. A Customer Support FTE answering from a well-maintained knowledge base runs on a lower tier, with the escalation summaries it writes rarely needing more.
The review after a cycle reads two things per role: usage in tokens and the send-back reasons. Hard tasks coming back for revision on a lower tier argue for moving up; easy tasks consuming heavily on a higher tier with no quality difference argue for moving down. The tier is changed in Setup, logged, and reviewed again the following cycle. No tier is permanent, and the honest labels in Setup exist so the choice is made on cost and capability rather than on a name.