What if a task contains both T1 and T3 sub-tasks? How is the overall task classified?

Decompose it further before classifying. The Framework operates at the task level, not the workflow or function level. A task that contains both T1 and T3 sub-tasks is not a task — it is a workflow that has not yet been fully mapped. Break it into its smallest executable steps. Each step gets its own classification. The T1 steps go into the Execution Layer . The T3 steps go into the Judgment Layer. The Exception Architecture specifies the handoff between them: what the agent prepares, at what point it stops, and what the Steward receives when ownership transfers. The goal of this decomposition is to concentrate the Steward’s involvement on the genuine judgment moments and strip away the preparation work that agents can handle autonomously. A T3 step often becomes a five-minute Steward decision once the surrounding T1 sub-tasks have been handled by the Execution Layer.

Can a task be reclassified over time, and if so, how?

Yes — T2 tasks are the primary reclassification candidates. A T2 task that generates escalations for a given exception class is, by definition, showing the Steward which conditions the architecture does not yet handle autonomously. Each time the Steward resolves a T2 exception and encodes the resolution into the Operational Ledger and the Exception Architecture, that exception class becomes a known condition with a prescribed resolution path. When the Escalation Rate for that class falls below the T1 threshold (1:100), the class has been reclassified as T1 through operational experience. This is the primary mechanism by which MTTI extends over time in a well-designed autonomous business: T2 exception classes are progressively encoded as T1 resolution logic, reducing Steward involvement without changing the Intervention Threshold. T3 reclassification is rarer and requires a genuine change in the conditions that made the task T3 — a regulatory change removing the human mandate, or a technology advance making previously non-deterministic judgment encodable as a rule.

How does the tier classification connect to model selection and Intelligence Arbitrage?

Directly. Intelligence Arbitrage — routing each task class to the cheapest model capable of executing it at the required quality level — is only available for T1 and standard-execution T2 tasks. T1 tasks are the primary target: they are fully deterministic, high-volume, and their quality threshold is evaluable by logic, which means the same output can often be produced by a small, cheap model rather than a frontier model. The T1 classification is therefore the first input to the model routing decision. T3 tasks that involve genuine reasoning, relational judgment, or creative assessment may require frontier model capability for the agent support layer, but since the Steward owns the completion, this is a tooling decision for the Steward rather than an architectural one. The tier classification precedes the model selection decision: you cannot run Intelligence Arbitrage without a task classification that tells the routing layer which tier each task belongs to.

The Arco Task Tier Classification Framework

What this Framework does

The Arco Task Tier Classification Framework evaluates any task in a business’s Revenue Loop and assigns it to one of three tiers: T1 (fully automatable), T2 (bounded human judgment required), or T3 (human ownership mandatory). The input is a specific, named task. The output is a tier assignment with a defined Intervention Threshold, confirmed throughput economics, and a prescribed architectural approach. The tier assignment is the architectural decision that determines whether a task belongs to the Execution Layer or the Judgment Layer — and therefore how it is governed under the Stewardship Model.

Apply this Framework to every task in the revenue loop before designing the system architecture. A misclassified task is the most common source of Escalation Rate failures and premature MTTI degradation: a T2 task engineered as T1 produces silent errors the system cannot catch; a T1 task governed as T2 surrenders Workforce Arbitrage that the architecture could have captured. The tier must be correct before the Intervention Threshold is set.

Before you apply this Framework

Understand the following Arco concepts before classifying any task: Deterministic Outcome (the minimum condition for T1), Systemic Resistance (the mandatory T3 indicator), Exception Architecture (the design tool that governs T2), and Judgment Layer / Execution Layer (the architectural binary the tier assignment determines). Read the live lexicon entries before proceeding. In addition, define the task at a step level before classifying it — not as a workflow or a function. "Customer onboarding" is a workflow containing T1, T2, and T3 tasks. "Verify submitted identity document against three-field schema" is a task. The Framework operates at the task level, not the function level.

The classification

Criterion

Can the correct outcome of this task be evaluated by logic — without human preference, aesthetic judgment, or subjective assessment — on every standard execution?

Evaluate

Define what a successful completion of this task looks like. Is that definition binary (correct/incorrect, complete/incomplete, within-threshold/outside-threshold)? Can an automated system evaluate the output against a rule without human review? Apply the Deterministic Outcome test: if two executions of the same task receive identical inputs and produce different outputs, is one of them definitively wrong by rule?

T1 Success/failure is binary and evaluable by logic on every execution.

T2 Standard executions are deterministic; a defined class of exceptions is not.

T3 Success depends on judgment, preference, or assessment that cannot be reduced to a rule.

Output

✓ Pass

T1 Success/failure is binary and evaluable by logic on every execution.

T2 Standard executions are deterministic; a defined class of exceptions is not.

✗ Fail

T3 Success depends on judgment, preference, or assessment that cannot be reduced to a rule.

Criterion

Do the inputs to this task vary in ways that require different logic paths on a significant proportion of executions?

Evaluate

Map the input schema for this task. Identify: (a) what varies between executions, (b) whether that variance is bounded by a classifiable schema (known exception classes) or unbounded (novel conditions on each execution). A task with bounded variance can be governed by Exception Architecture: a defined set of exception classes each with a prescribed resolution path. A task with unbounded variance cannot.

Output

✓ Pass

T1 Inputs follow a standard schema. Variance is minimal and classifiable.

T2 Inputs vary within a bounded range. Exceptions are classifiable and governable by Exception Architecture.

✗ Fail

T3 Inputs vary in ways that cannot be pre-classified. Each execution may present novel conditions requiring human interpretation.

Criterion

Does this task require genuine human assessment — relational judgment, creative evaluation, ethical reasoning, or non-deterministic decision-making — at the critical path on any standard execution?

Evaluate

Distinguish between judgment that is definitional (i.e., the task cannot be completed without a human making a call that logic cannot replicate) and judgment that is habitual (i.e., a human currently makes a call that could be replaced by a rule). Habitual judgment is a candidate for reclassification as T1 or T2 through Exception Architecture. Definitional judgment is T3. Ask: "If we encoded the best human decision for this type of case as a rule, would the rule produce the correct output on the next 100 standard executions?" If yes, the judgment is habitual. If no, it is definitional.

Output

✓ Pass

T1 No human judgment required. End-to-end autonomous execution on every standard case.

T2 Judgment required only for defined exception classes. Standard executions are autonomous.

✗ Fail

T3 Human judgment required at the critical path on standard executions. The task cannot be completed autonomously by rule.

Criterion

Is human involvement in this task mandated by law, regulation, professional licensing, contractual obligation, or a social/relational requirement that the customer specifically purchased?

Evaluate

Review the applicable regulatory framework, contract terms, and professional standards governing this task. Identify any clause, standard, or expectation that requires a human to be accountable for the outcome. If present, Systemic Resistance overrides all other criteria. Note the distinction: a task that a human currently performs is not necessarily one a human must perform. A task where a regulation names "qualified professional" or "authorised signatory" or similar as a requirement for the output to be valid is T3 regardless of how deterministic the underlying work is.

Output

✓ Pass

No Systemic Resistance → Proceed to tier assignment.

✗ Fail

Systemic Resistance present → Task is T3 regardless of Criteria 1–3. A human must own this task. Agents may assist with sub-tasks (data retrieval, document preparation, output formatting) but cannot own the completion.

Tier assignment

Combine the four filters to assign the tier. If filter 4 identifies Systemic Resistance, the task is T3. Otherwise:

T1 — Fully Automatable

All three of the following must be true: Filter 1 is fully deterministic, Filter 2 shows standard or minimal variance, Filter 3 requires zero human judgment on standard executions, Filter 4 finds no Systemic Resistance. A T1 task runs in the Execution Layer end-to-end. Exception Architecture handles rare escalations only.

T2 — Bounded Human Judgment Required

Any of the following: Filter 1 is partially deterministic (standard cases deterministic, defined exception classes are not), Filter 2 shows bounded variance with classifiable exceptions, Filter 3 requires human judgment on defined exception classes but not standard executions. Filter 4 finds no Systemic Resistance. A T2 task runs autonomously for standard executions and escalates defined exception classes to the Steward. The boundary between autonomous and escalated execution is governed by Exception Architecture and encoded as the Intervention Threshold.

T3 — Human Ownership Mandatory

Any of the following: Filter 1 is non-deterministic, Filter 2 shows unbounded variance, Filter 3 requires human judgment at the critical path on standard executions, or Filter 4 identifies Systemic Resistance. A T3 task lives in the Judgment Layer. The Steward owns it. Agents may perform supporting T1 sub-tasks — data retrieval, document preparation, output formatting — but cannot own the completion or be accountable for the outcome.

What the tier assignment means

Each tier carries confirmed economic parameters and a prescribed architectural approach. These are not targets — they are the structural consequences of the tier classification, confirmed by Arco simulation data.

T1 Execution Layer — Full autonomous operation

INTERVENTION THRESHOLD

1:100 — one human intervention per 100 executions (1–2% escalation rate). Set this threshold in system design, not discovered through operational failure.

THROUGHPUT

37–50× throughput advantage over human-staffed equivalent. Workforce Arbitrage is maximum at T1.

COST REDUCTION

46× cost reduction vs human junior confirmed by Arco simulation (customer care, IT vertical).

ARCHITECTURE

Full Execution Layer. Deterministic Loop. Exception Architecture governs rare escalations. Eligible for Intelligence Arbitrage: route to smallest effective model at lowest cost.

MTTI CONTRIBUTION

Maximum. T1 tasks running without interruption extend MTTI furthest. If T1 is generating escalations above 2%, the task has been misclassified or Exception Architecture is incomplete.

T2 — Execution Layer with Judgment Layer escalation path

INTERVENTION THRESHOLD

1:10 to 1:5 — one human intervention per 5–10 executions, calibrated to the exception class risk profile. Threshold is set per exception class, not per task. Higher-risk exceptions set at 1:5; lower-risk at 1:10.

THROUGHPUT

18–29× throughput advantage over human-staffed equivalent. Workforce Arbitrage is partial at T2 — autonomous standard executions capture the arbitrage; exception handling by the Steward does not.

COST REDUCTION

11× cost reduction vs human confirmed by Arco simulation (customer care, IT vertical).

ARCHITECTURE

Execution Layer for standard cases. Judgment Layer escalation path for defined exception classes. Exception Architecture specifies: which conditions trigger escalation, what information the Steward receives, what record is written to the Operational Ledger when the exception is resolved.

MTTI CONTRIBUTION

Moderate. T2 tasks are the primary source of MTTI compression over time: as the Steward resolves exception classes and encodes them into the architecture, the Exception Architecture improves and T2 Escalation Rate falls. A T2 task whose escalation rate falls below the 1:100 threshold over time has effectively become T1.

T3 Judgment Layer — Steward ownership

INTERVENTION THRESHOLD

Mandatory. Every execution requires Steward involvement. No threshold parameter is set — the task is not in the Execution Layer. The Steward owns the task; agents may assist with sub-tasks only.

THROUGHPUT

Near-zero Workforce Arbitrage. The throughput ceiling is the Steward’s capacity. T3 tasks are not eligible for agentic throughput scaling.

ARCHITECTURE

Judgment Layer. The Steward owns the completion and is accountable for the outcome. Design the supporting sub-task layer: what T1 data retrieval, formatting, and preparation can agents handle before the Steward takes ownership? The goal is to concentrate the Steward’s involvement on the judgment moment itself, not on the preparation work that precedes it.

MTTI CONTRIBUTION

Limiting factor. T3 tasks are the primary constraint on MTTI. Track T3 volume relative to total task volume. The goal of mature Exception Architecture is to progressively reclassify borderline T3 tasks — where the judgment is habitual rather than definitional — as T2, reducing the MTTI constraint over time.

The Operator’s Verdict

A business whose Revenue Loop is dominated by T1 tasks achieves maximum Operational Arbitrage and Headcount Decoupling. A business with high T3 concentration in the Revenue Loop has a high Systemic Resistance profile and should be re-evaluated against the Market Selection Framework before committing to an autonomous build.

KEY TAKEAWAY

How does Arco classify tasks for agentic deployment, and what does each tier mean?

Arco classifies every task in a revenue loop into one of three tiers using four criteria: Outcome Determinism (can success be evaluated by logic?), Context Variability (are inputs bounded and classifiable?), Judgment Requirement (is human assessment required at the critical path?), and Systemic Resistance (is human involvement legally or contractually mandated?). T1 tasks are fully automatable, run end-to-end in the Execution Layer, and carry an Intervention Threshold of 1:100 — one human intervention per 100 executions. T2 tasks are autonomous for standard cases and escalate defined exception classes to the Steward, with an Intervention Threshold of 1:10 to 1:5. T3 tasks require human ownership on every execution and live in the Judgment Layer — agents may assist with supporting sub-tasks but cannot own the completion. Key metrics: T1 — 46× cost reduction vs human junior, 37–50× throughput, 1:100 Intervention Threshold. T2 — 11× cost reduction, 18–29× throughput, 1:10 to 1:5 Intervention Threshold. T3 — near-zero Workforce Arbitrage, mandatory Steward ownership.