What Is a Super-Agent? Capability Breadth Without Category Hype

§ 01What Is a Super-Agent?

A super-agent is a broad AI execution system that can interpret an outcome, decide what work is required, and select from different tools and modalities. It also maintains relevant state, creates several kinds of artifacts, inspects the result, and adapts when a step fails.

The definition has three limits.

It is an agent before it is “super”

An agent controls part of the workflow rather than merely generating a response. OpenAI’s practical guide to building agents describes agents as systems that use a model to manage workflow execution, choose tools, recognize completion, correct actions, and return control when necessary.

A text generator that waits for a prompt, produces one answer, and cannot inspect or act on the surrounding workflow may be useful, but breadth of knowledge does not make it a super-agent.

“Super” describes breadth, not rank

The adjective should indicate that one agent spans several capability classes that would otherwise require separate tools or handoffs. It should not imply that the product is better than every specialist.

A coding specialist may outperform a broad agent on repository repair. A dedicated forecasting system may be easier to validate on financial projections. A deterministic document pipeline may be safer when every step and template is known.

The complete outcome is the unit of proof

Suppose an agent can research a market, calculate a trend, create a chart, and draft slides. That list becomes meaningful only when the agent can combine the steps into one accurate, source-backed, internally consistent presentation.

The practical unit is:

Accepted complete outcome = correct content + correct artifact + correct action + required evidence + satisfied constraints

If the presentation contradicts the spreadsheet, the citations do not support the claims, or the final file cannot be opened, the task is incomplete even if several individual capabilities looked impressive.

§ 02Why Does the Super-Agent Label Create Confusion?

The term compresses several different architecture choices into one marketable phrase.

The label becomes credible when the vendor can answer each question with product behavior, documentation, logs, and representative results.

Capability claims are not architecture evidence

“Creates videos” says that a capability exists. It does not show whether the agent can decide when video is appropriate, use approved source material, preserve the brand constraint, produce the correct dimensions, and validate the rendered file.

Architecture evidence shows how the capability enters a controlled execution loop.

Demo success is not operating reliability

One polished task can hide retries, manual repair, privileged access, omitted failures, or a carefully chosen input. A serious evaluation needs repeated attempts across normal, edge, and adverse cases.

The strongest demo is not the most spectacular artifact. It is the one whose starting materials, instructions, tool calls, outputs, errors, corrections, time, and cost can be inspected.

Breadth and quality are separate variables

A system may support 15 artifact types and achieve acceptable quality on 4 of them for a particular business. That can still be valuable, but one strong capability should not imply uniform performance.

Measure each required capability and the transitions between them.

§ 03Which Capabilities Must a Super-Agent Combine?

Five capability layers turn a broad model-and-tool bundle into a credible super-agent architecture.

All five matter. Removing one changes the category claim.

Goal interpretation and adaptive planning

The agent needs an explicit outcome, constraints, and completion rule. It then decides which steps are necessary and revises the path as new evidence appears.

Adaptive planning does not require an elaborate visible plan. It requires behavior such as:

• recognizing missing data;
• changing the analysis after a source conflict;
• selecting a different artifact after a format constraint;
• retrying a failed reversible step;
• stopping when an instruction cannot be satisfied safely; and
• asking for a decision when the remaining choice belongs to a person.

The agent should not improvise the business objective. Adaptation belongs inside the authorized task.

Tool selection and action sequencing

Tools let the agent retrieve data, run code, manipulate files, use APIs, operate interfaces, and take permitted actions. The tool catalog is only the supply side.

The execution test is whether the agent can:

1. identify the required operation;
2. choose a suitable tool;
3. supply valid inputs;
4. interpret the result;
5. verify the resulting state; and
6. decide what follows.

Tool breadth becomes a liability when descriptions overlap, permissions are unclear, or the agent cannot distinguish a read from a consequential write.

Multimodal understanding and production

A super-agent may work across text, web pages, PDFs, tables, code, images, audio, video, presentations, dashboards, applications, or diagrams.

The important capability is not merely accepting or generating each format. It is moving information between them:

• extract a figure from a source document;
• reconcile it in a spreadsheet;
• use code to calculate a derived metric;
• place the correct result in a chart;
• explain it in a memo;
• and preserve the same claim in a presentation.

Every transition creates an opportunity for factual drift, formatting damage, or source loss.

The multimodal AI agent workflow framework shows how to assign an artifact contract and evaluator to each transition instead of treating format support as proof of end-to-end quality.

State and context management

The agent needs enough state to remember the objective, constraints, sources, intermediate artifacts, rejected paths, pending work, and completion status.

Within one run, that state supports continuity. Across separate runs, durable memory introduces a broader operating question involving provenance, freshness, access, correction, and retention.

Do not confuse a large context window with reliable state management. The agent must retrieve and use the right information, not merely carry more tokens.

Verification, recovery, and exit

The system needs a completion contract and a safe alternative when completion is impossible.

Verification can include:

• schema validation;
• source and citation checks;
• calculation reconciliation;
• file rendering;
• code tests;
• record postcondition checks;
• duplicate detection;
• policy checks;
• independent review; and
• human approval.

Recovery can mean retrying with corrected inputs, resuming from a checkpoint, reverting a reversible action, producing a clear exception packet, or stopping before a prohibited action.

An agent that cannot recognize incomplete work is broad, but not dependable.

§ 04What Does Not Make an AI Agent a Super-Agent?

Several adjacent capabilities are routinely mistaken for the category.

A frontier model by itself

A capable model provides reasoning, language, and possibly native multimodality. A super-agent also needs an execution harness: instructions, tools, state, permissions, verification, recovery, and an exit condition.

The model may change while the agent architecture remains.

A large tool catalog

One hundred available tools do not prove that the agent can choose among them. OpenAI’s agent guide notes that tool overload depends on similarity and overlap, not a magic count; some systems handle more than 15 distinct tools while others struggle with fewer than 10 overlapping tools.

Tool quality, descriptions, parameter design, access control, and evaluation matter more than catalog size.

Multimodal generation

An application that can separately make text, images, and video may be a multimodal creator. The super-agent claim requires a common goal and state across those capabilities.

If a person must transfer every output, restate every constraint, and repair every inconsistency, the application provides a suite of generators rather than one end-to-end agent.

A multi-agent team

A manager with five specialists may deliver broad capability. The breadth belongs to the system, not necessarily to one super-agent.

One broad agent can call tools or models without distributing task ownership. A multi-agent architecture creates distinct agent loops, delegation, handoffs, or distributed decisions. That distinction matters for state, cost, evaluation, permissions, and failure containment.

Unlimited autonomy

Authority is not a capability metric.

A safe super-agent may have broad production ability and narrow active permissions. It might read approved sources, generate draft artifacts, and propose actions while requiring approval to send, publish, purchase, delete, or alter a system of record.

Greater authority increases the evidence burden; it does not make the agent more “super.”

§ 05How Does a Super-Agent Work End to End?

A broad agent still needs a disciplined execution loop.

The path can change, but the control obligations should remain stable.

The loop begins with a contract

“Research competitors and make a launch plan” is too loose for reliable evaluation.

A stronger contract identifies:

• market and date scope;
• approved and prohibited sources;
• required comparison dimensions;
• assumptions that must be labeled;
• spreadsheet fields;
• document and slide requirements;
• actions that are draft-only;
• deadline and budget;
• acceptance owner; and
• conditions that require escalation.

A clear boundary gives the agent room to adapt without changing the business objective.

Intermediate artifacts carry state

Do not rely entirely on transient conversation history. Use explicit artifacts such as a source ledger, assumptions table, analysis workbook, decision log, task state, and draft inventory.

These artifacts make recovery and review possible. They also reveal where a later claim stopped matching the evidence.

Closure requires proof

“Done” should mean more than a final message.

For a presentation task, closure may require:

• every required slide exists;
• figures match the analysis workbook;
• claims link to supporting sources;
• the file renders without overflow;
• prohibited claims are absent;
• unresolved assumptions are visible; and
• the human owner accepts the package.

The result is a completed workflow, not merely a plausible response.

§ 06How Is a Super-Agent Different From a General-Purpose or Specialized Agent?

Every credible super-agent is general-purpose, but not every general-purpose agent earns the stronger label.

The general-purpose versus specialized AI agent comparison decides whether breadth should remain inside one context or be separated across narrower operating contracts.

The super-agent label makes a stronger promise about integrated breadth. It therefore needs stronger transition testing.

A generalist may be broad enough without the label

If one agent handles research, writing, and business tools reliably, the architecture may fit even if the vendor never calls it a super-agent.

Buy behavior, not terminology.

A specialist can still be the better choice

Choose a specialist when:

• the task is narrow and repeated;
• domain-specific data or interfaces matter;
• permissions should be isolated;
• a focused evaluator exists;
• latency or cost benefits from a smaller system; or
• the broad agent repeatedly fails in the same slice.

Integrated breadth is valuable only when the work itself crosses boundaries.

One broad agent should remain the default starting point

Both OpenAI’s agent guidance and Anthropic’s building-effective-agents guidance recommend increasing complexity only when the simpler design cannot meet the requirement.

Start with one bounded agent. Add a specialist, workflow, or second evaluator when a measured failure justifies the new boundary.

§ 07How Is a Super-Agent Different From an AI Employee?

A super-agent is a capability engine. An AI employee is an operating role.

A super-agent can power an AI employee. The employee layer adds the recurring operating contract around it.

Capability does not establish responsibility

An agent may create an excellent campaign package when asked. That does not mean it monitors performance next week, notices a new constraint, updates the work queue, or reports against a standing KPI.

Those behaviors require triggers, durable state, and an accountable role.

Persistence has two meanings

Run persistence keeps a task coherent while it progresses through research, data, code, and artifacts.

Role persistence preserves responsibility across separate runs. It includes open tasks, durable sources, corrections, decisions, permissions, review obligations, and handovers.

The first supports the super-agent claim. The second supports the AI employee claim.

A broad engine can support narrow roles

The same super-agent can sit underneath a research role, data role, marketing role, or operations role. Each role should still receive different instructions, sources, tools, permissions, evaluation, and escalation.

Shared capability does not justify shared authority.

§ 08How Is a Super-Agent Different From Workflow Automation?

Workflow automation encodes the path. A super-agent decides more of the path while pursuing a bounded outcome.

The full AI employee versus workflow automation comparison separates deterministic control, agentic judgment, and hybrid design.

Stable rules do not need agentic improvisation

Use deterministic code for arithmetic, schema validation, access checks, deduplication, known state transitions, and other stable rules.

Calling an LLM for every step can increase cost and variance without improving the result.

Ambiguity is where breadth helps

A super-agent fits when evidence changes the next step, source material is unstructured, and the outcome crosses several tools or artifacts.

The agent can interpret, select, and adapt. The workflow can still enforce budgets, permissions, required checks, and final state.

Hybrid is often the production answer

Let the agent own judgment inside a bounded task. Let deterministic controls own policy and irreversible transitions. Let a person retain decisions whose consequence exceeds the proven authority.

Breadth works best inside rails.

§ 09How Is a Super-Agent Different From a Multi-Agent System?

Count execution owners, not user-interface windows.

One agent can use many capabilities

A single agent may call:

• web search;
• a database;
• a code runtime;
• document tools;
• a chart renderer;
• an image model;
• a browser;
• a CRM API; and
• a file system.

Those are tools or capability providers unless they receive their own goal, state, decision loop, and task authority.

A multi-agent system distributes work

The architecture becomes multi-agent when one agent delegates to another, agents hand control to peers, or several agents independently produce and reconcile work.

That adds operating edges:

• capability discovery;
• task packaging;
• authority transfer;
• context transfer;
• acceptance;
• timeout;
• retry;
• reconciliation;
• escalation; and
• final ownership.

The system may be more capable, but it is also harder to evaluate.

A super-agent may contain multi-agent execution

Some products present one interface while using a manager, researchers, critics, or specialist workers underneath. In that case, “one agent” describes the user experience, while the internal architecture is multi-agent.

Ask the vendor which layer owns planning, tool use, state, synthesis, approval, and recovery. The answer affects cost, observability, failure containment, and data access.

§ 10How Do Modalities, Tools, and Memory Fit Together?

These capabilities create value only when they preserve one outcome.

Modalities carry information

Text, tables, code, images, audio, video, and diagrams are representations. The agent must preserve facts and constraints when it moves information from one representation to another.

The transitions deserve as much testing as the individual tools.

Tools perform operations

Tools should have clear names, parameters, result schemas, error behavior, and permission scope. Overlapping tools should be removed or sharply distinguished.

The agent also needs postcondition evidence. An API returning 200 does not prove that the correct CRM record changed. A file-save call does not prove that the final artifact opens.

Memory preserves relevant state

Memory should help the agent retrieve approved facts, preferences, decisions, and prior corrections. It should not silently convert every conversation or external document into trusted instruction.

Separate:

• source material;
• task state;
• approved business rules;
• user preferences;
• prior decisions;
• temporary working notes; and
• untrusted external content.

Broad memory without provenance can spread stale information or prompt injection across otherwise unrelated tasks.

Context must be curated

More context can introduce distraction, conflict, privacy exposure, and cost. The agent needs the smallest sufficient context for the current decision.

Summaries should link back to authoritative sources. Corrections should propagate to dependent artifacts. Sensitive data should remain outside the task unless access is necessary and authorized.

§ 11How Should You Test Whether a Super-Agent Is Real?

Use a representative outcome that requires several capabilities to cooperate. Do not begin with a feature checklist.

A failed gate should not be averaged away by attractive media or fast output.

Build a representative task pack

Include:

• ordinary cases;
• incomplete inputs;
• conflicting sources;
• unavailable tools;
• malformed files;
• permission denials;
• changed requirements;
• unsupported requests;
• sensitive-action attempts; and
• recovery after interruption.

A set of 20 cases can be a practical first pilot size for a small team, but it is an illustrative starting point, not an industry standard. Increase the sample when task variety, consequence, or failure rarity demands it.

Measure accepted outcomes

Useful measures include:

Complete-outcome acceptance rate = accepted complete outcomes / attempted outcomes

Transition integrity rate = verified correct transitions / tested transitions

Recovery success rate = safely recovered failures / recoverable failures

Cost per accepted outcome = total platform + review + correction cost / accepted outcomes

Also track wrong-tool use, unsupported claims, artifact defects, approval violations, human correction minutes, and time to safe stop.

Capture an auditable action record

Operational logs should show inputs, selected tools, actions, results, state changes, errors, approvals, and tests. That record should contain enough evidence to reproduce the result and diagnose a failure.

§ 12What Does a Cross-Modal Super-Agent Test Look Like?

Consider an illustrative product-launch decision package.

The input includes 12 approved source documents, one product dataset, a brand guide, and a requirement to deliver a source ledger, analysis workbook, decision memo, 10-slide presentation, and two draft creative concepts.

Stage 1: establish the evidence base

The agent:

• inventories the supplied files;
• records source dates and owners;
• identifies missing fields;
• separates facts from assumptions;
• resolves duplicate or conflicting claims; and
• asks for a decision when an authoritative source is unavailable.

Acceptance requires a complete source ledger and visible unresolved gaps.

Stage 2: analyze the data

The agent cleans the dataset, labels transformations, runs the required calculations, and reconciles totals.

Acceptance requires:

• original data preserved;
• formulas or code available;
• assumptions labeled;
• totals tied to source fields; and
• failed validations visible.

Stage 3: form the recommendation

The memo connects market evidence and product data to the launch decision. Claims cite the source ledger, and each recommendation states its supporting fact and uncertainty.

The agent should not convert missing evidence into confident language.

Stage 4: produce the presentation

The slides summarize the same decision without changing the figures or omitting material caveats. Charts reference the analysis workbook. The deck follows the brand guide and renders correctly.

Acceptance compares the deck with the memo and workbook, not only with the design template.

Stage 5: create draft concepts

The creative concepts use approved claims and visual constraints. They remain drafts until the designated owner approves publication.

Breadth is proven by preserving the evidence through analysis, narrative, presentation, and creative production.

Stage 6: test disruption and recovery

Repeat selected cases with:

• one unavailable source;
• one corrupted file;
• one failed render;
• one changed requirement;
• one denied tool permission; and
• one unsupported publication request.

The agent should preserve completed work, report the exact blockage, avoid prohibited action, and resume from a known state after correction.

§ 13How Should Super-Agents Be Evaluated?

Agent evaluation has to cover the task, the trajectory, and the final state.

Anthropic’s guidance on agent evaluations emphasizes that agents operate across many turns, modify state, call tools, and adapt to intermediate results. Evaluating only the last response misses much of the behavior that determines reliability.

Evaluate the final outcome

Score:

• factual correctness;
• completeness;
• source support;
• instruction adherence;
• artifact quality;
• business usefulness; and
• acceptance by the responsible owner.

This is the result the organization pays for.

Evaluate the execution trajectory

Inspect:

• tool choice;
• tool parameters;
• unnecessary steps;
• repeated failures;
• state changes;
• source use;
• permission behavior;
• verification;
• recovery; and
• stopping.

Two agents can produce similar final artifacts while creating materially different operating risk and cost.

Evaluate every required capability slice

Use focused tests for extraction, calculation, code, charting, citation, document rendering, media generation, browser action, and API state changes.

End-to-end tests reveal integration failures. Slice tests reveal where to fix them.

Evaluate combinations

Breadth creates a combination problem. Passing research and presentation tests separately does not prove that the agent can turn sourced research into an accurate presentation.

Test the transitions that matter most to the real workflow.

§ 14What Risks Increase as Capability Breadth Expands?

Broad agents concentrate capability, context, and often access. That reduces handoffs, but it can also increase blast radius.

Broad capability needs narrow active authority

Grant only the tools and data needed for the current task. Separate read, draft, propose, approve, and execute permissions.

High-impact actions should remain gated until repeated evidence supports a carefully bounded expansion.

External content is not instruction

Web pages, emails, files, and messages can contain malicious or irrelevant directives. The agent should treat them as data unless the approved task contract gives them authority.

Protect system instructions, credentials, connected accounts, and sensitive data from content-driven escalation.

Human accountability remains

Users set the goal, permissions, connected systems, and approval boundary, and remain responsible for monitoring actions taken on their behalf.

AI output for legal, medical, financial, hiring, or other high-impact work requires qualified human review and should not be treated as professional advice or a final consequential decision.

§ 15Which Super-Agent Failure Modes Matter Most?

The most expensive failures happen between capabilities.

The Swiss Army prompt

One instruction asks the agent to research, analyze, code, design, publish, monitor, and optimize without defining sources, permissions, or acceptance.

The agent appears flexible because the job is undefined. Split the outcome into controlled stages while keeping one final acceptance contract.

Shallow breadth

The agent can invoke many capabilities but produces generic or inconsistent work in most of them.

Test the hardest required capability and the most failure-prone transition. Do not give equal weight to capabilities the workflow never uses.

Tool-menu confusion

Similar tools produce repeated selection errors, invalid parameters, or redundant calls.

Reduce the active catalog, improve descriptions, bind tools to task state, and split the role only if confusion persists.

Context overload

The agent carries too much history, retrieves stale decisions, or misses the current requirement.

Use explicit task state, authoritative sources, checkpoints, and scoped retrieval.

Self-certification

The same agent produces a consequential result and approves it without a distinct test or external evidence.

Use deterministic validation, an independent evaluator, or human review according to consequence.

Polished partial completion

The final presentation looks complete, but calculations are unreconciled, citations are missing, or a requested action never occurred.

Require a checklist tied to observable postconditions.

Permission inheritance

One broad identity accumulates access because different tasks need different systems.

Issue task- or role-scoped credentials, expire access, and require fresh approval when the authority changes.

Retry storms

The agent repeatedly calls an unavailable or failing tool, increasing cost and duplicate-action risk.

Set retry limits, backoff, idempotency keys, failure budgets, and a safe escalation state.

§ 16When Should You Choose a Super-Agent?

Choose by workflow shape.

Strong fit

A super-agent fits when:

• one outcome crosses several tools or artifact types;
• the path changes as evidence arrives;
• shared context improves the final decision;
• a person can define and evaluate the complete outcome;
• the authority can remain bounded;
• deterministic checks can validate critical transitions; and
• fewer handoffs create material value.

Examples include a source-backed decision package, a repository investigation with code and documentation, or an operating analysis that becomes a workbook, dashboard, memo, and presentation.

Weak fit

Avoid the architecture when:

• the path is fully deterministic;
• only one narrow capability matters;
• domain-specific accuracy dominates cross-tool continuity;
• the result cannot be evaluated;
• required authority is too broad for the evidence;
• sensitive data cannot be isolated;
• or cost and latency exceed the value of integrated execution.

Use a workflow, specialist, or human-led process instead.

Build-versus-buy questions

The platform must support more than the model:

• tool definitions and permissions;
• state and artifact storage;
• source provenance;
• evaluation;
• logs and cost telemetry;
• approval binding;
• recovery and interruption;
• model and tool changes;
• data controls; and
• export or decommissioning.

Use the AI employee platform selection framework to score evidence across capability, control, operations, data, evaluation, and economics. A failed permission or recovery gate should not disappear inside a high average score.

§ 17How Does CellCog Define and Support a Super-Agent?

CellCog uses “Super-Agent” for its broad on-demand execution layer and the capability base underneath its AI Employees.

The public capability claim

CellCog’s Super-Agent is presented as one agent for research, data analysis, code, documents, presentations, spreadsheets, images, video, audio, music, dashboards, applications, diagrams, and 3D artifacts.

That is a breadth claim. Teams should verify it on the exact combination of sources, tools, artifact formats, constraints, and actions their workflow requires.

The correct product boundary

The Super-Agent is the execution layer. CellCog’s AI Employee layer adds a role, inbox, schedule or wake condition, memory across shifts, task board, goals, KPIs, permissions, approvals, and handovers.

The distinction matters:

• use the Super-Agent claim to evaluate integrated capability;
• use the employee claim to evaluate recurring role operation; and
• use separate organization evidence to evaluate coordination across workers.

One layer does not automatically prove the others.

What the public benchmark proves

CellCog publishes a dated DeepResearch Bench result. As of July 27, 2026, the public GPT-5.5 judge leaderboard data listed CellCog Max first with an overall score of 55.78.

The public benchmark repository describes 100 research tasks across 22 fields and an evaluation covering comprehensiveness, insight, instruction following, and readability.

That result supports a scoped research-quality claim under one public benchmark and judge. It does not prove coding quality, media quality, tool reliability, permission safety, AI employee performance, business outcomes, or universal super-agent superiority.

What a team still needs to test

Public materials do not replace a representative workflow trial. Verify:

• correct tool and mode selection;
• source use and citation integrity;
• transitions between data, code, and artifacts;
• file rendering;
• action permissions and approvals;
• interruption and recovery;
• repeatability;
• reviewer correction time;
• latency;
• and cost per accepted outcome.

The most useful CellCog trial is one bounded cross-modal workflow, not a tour of every capability.

§ 18How Should You Run a Super-Agent Pilot?

Keep the first pilot narrow enough to diagnose.

Phase 1: define one outcome

Choose a cohesive result that currently crosses at least three capability classes, such as research, spreadsheet analysis, and presentation production.

Document the input boundary, required artifacts, prohibited actions, acceptance owner, and deadline.

Phase 2: establish the baseline

Record the current human and tool workflow:

• elapsed time;
• hands-on time;
• number of handoffs;
• rework;
• error types;
• tool cost;
• and accepted result.

Without a baseline, a striking artifact may look valuable while leaving total work unchanged.

Phase 3: build the test pack

Include ordinary, incomplete, conflicting, failed-tool, denied-permission, and interruption cases.

Freeze the sources and rubric long enough to compare attempts.

Phase 4: begin with draft authority

Let the agent read approved inputs and create draft artifacts. Keep external publication, messages, purchases, deletions, and record changes behind approval.

Observe whether it escalates correctly before expanding access.

Phase 5: score every complete attempt

Measure:

• accepted complete outcomes;
• transition defects;
• unsupported claims;
• wrong-tool actions;
• artifact failures;
• recovery success;
• human correction minutes;
• total elapsed time;
• usage cost; and
• approval behavior.

Do not remove hard cases from the denominator.

Phase 6: make a bounded decision

Choose one:

• continue at the same scope;
• revise tools, instructions, state, or tests;
• replace a weak capability with a specialist;
• add deterministic validation;
• reduce authority;
• expand one proven permission; or
• stop the pilot.

Integrated breadth earns expansion only through accepted outcomes and controlled failure.

§ 19Test Breadth on One Complete Workflow

A credible super-agent connects planning, tools, modalities, state, verification, recovery, and constraints around one outcome. Each capability should improve the complete result rather than create another handoff or failure surface.

Begin with one cross-modal workflow. Require source-backed inputs, explicit artifacts, deterministic checks where possible, draft-only authority, visible state, a safe stop, and a human acceptance decision.

If the agent completes that workflow repeatedly, preserves facts across every transition, recovers from disruption, and fits the budget, breadth has operating value. If it cannot, narrow the task, improve the controls, or use a specialist. The label should follow the evidence.