Super Intelligence Roles: Assistant to Infrastructure

Super Intelligence can appear at work as an Assistant, Copilot, Coworker, Agent or Infrastructure. Those words should describe the operating relationship between people, machine intelligence and the workflow—not simply the brand name of a product. A system can be marketed as an agent while behaving like a reactive assistant. Another can be called a copilot while using tools across several steps. Clear role language prevents organisations from granting authority based on labels rather than actual behaviour.

This eduKateSG article owns the role model for workplace SI. The previous article, The Four Levels of Workplace SI, explains maturity from Assist to Operate. This page asks a different question: what role does SI play from the user’s and organisation’s point of view?

The short answer is: an Assistant responds to a user’s request; a Copilot works beside the user inside a task; a Coworker owns a bounded portion of work and hands results back into a team process; an Agent can pursue a bounded objective across several steps and tools; Infrastructure makes machine intelligence a shared organisational capability rather than a single visible worker.

Why Role Language Matters

Workplace discussions often use person-like language because it is intuitive. People understand what assistants, colleagues and coworkers do. That language can help design human–SI collaboration, but it can also create false assumptions. A software system does not become a legal employee, accountable professional or human relationship simply because we call it a coworker.

The role label should therefore answer operational questions: Who initiates the work? What context does the system receive? Can it decide the next step? Which tools can it use? Can it change external state? Who checks its work? Who owns consequences? How does it hand off the result?

If two teams use the word “agent” for radically different operating relationships, governance becomes confused. The role model provides a common vocabulary across managers, users and technical builders.

Role 1 — Super Intelligence as Assistant

An Assistant is primarily reactive. The user asks; the system responds. It may explain, summarise, rewrite, translate, brainstorm, compare or help with code. The user remains the clear task owner and generally supplies the immediate context.

Assistant mode is powerful because it is flexible and low-friction. A person can bring many different small tasks to the same interface. The trade-off is that the interaction is often temporary. If the useful method stays in one person’s chat history, the organisation may gain personal productivity without building shared capability.

Assistant characteristics

The user initiates each interaction.
The user decides what context to supply.
The system usually produces information or a draft rather than executing the full workflow.
The user directly inspects the result.
External actions remain mostly manual or user-mediated.
The interaction can be stopped with little operational consequence.

Assistant examples

A teacher asks for three alternate explanations of a concept. An analyst asks for a summary of a report. A manager asks for help rewriting a difficult email. A developer asks for an explanation of an error. A salesperson asks for questions to prepare before a client call.

The Assistant failure mode

The most common failure is chat-shaped work: useful answers are produced, but the organisation never turns them into repeatable processes. Employees repeatedly provide the same context, reinvent the same instructions and correct the same errors.

The repair is to identify repeated interactions that deserve a shared prompt, template, source pack or workflow. Not every assistant use should be formalised. Only repeated valuable patterns need promotion.

Role 2 — Super Intelligence as Copilot

Copilot describes a system that works beside the user inside a task. The person remains in the driver’s seat, but the system participates continuously rather than answering isolated questions. It may observe the current document, codebase, spreadsheet, meeting context or project state and provide context-sensitive help.

The difference from Assistant is not absolute; the two roles overlap. Copilot language is useful when the system is embedded in the work surface and can keep enough context to support a sequence of related actions.

Copilot characteristics

The human sets direction and retains continuous control.
The system has persistent task context within the work session.
Suggestions can appear proactively or on demand.
The person can accept, reject or modify each material contribution.
Tool access may exist but significant action remains user-directed.
The system reduces micro-friction inside the task.

Copilot examples

A coding copilot proposes functions and tests while the engineer works. A writing copilot suggests structure, rewrites and evidence gaps inside a report. A data copilot helps create formulas and interpret charts. A meeting copilot surfaces earlier decisions while participants discuss next steps.

The Copilot failure mode

The main failure is continuous suggestion without calibrated trust. Because the system is always present, users can begin accepting its output automatically. Familiarity can turn into automation bias even though the human technically remains in control.

The repair is to make evidence and uncertainty visible, preserve meaningful rejection, and train users to understand which suggestions require checking.

Role 3 — Super Intelligence as Coworker

Coworker is a useful metaphor when SI owns a bounded portion of work and hands a result back into a team process. The system is no longer merely suggesting individual phrases beside one user. It may be assigned a defined work package: prepare the weekly briefing, classify incoming cases, assemble a research packet or draft the first version of a recurring report.

The word should not imply personhood, employment status, professional licensure or independent accountability. A machine “coworker” remains software. The organisation and authorised humans retain responsibility for how it is configured and used.

Coworker characteristics

The role has a named output or work package.
Inputs and acceptance criteria are more explicit.
The result enters a shared team workflow.
The system may operate asynchronously.
Human review can occur at the handoff rather than during every generation step.
Ownership of exceptions and consequences remains organisational.

Coworker examples

A research coworker prepares a source table each morning. A support coworker classifies routine cases and drafts responses. A finance coworker produces a first-pass management commentary from approved data. An operations coworker assembles an exception brief from several systems.

The Coworker failure mode

The main failure is anthropomorphic delegation: people begin treating the system as though it understands unstated organisational context, social consequences or accountability the way a human colleague does.

Repair by defining the work package explicitly. State sources, boundaries, authority, acceptance criteria and escalation. Do not rely on the role label to substitute for workflow design.

Role 4 — Super Intelligence as Agent

An Agent can pursue a bounded objective across several steps, choosing among available actions or tools based on intermediate results. Instead of asking for one answer, the user may assign a goal: assemble the weekly operations pack, investigate a class of support issues, update approved records or prepare a deployment candidate.

Agent does not mean unlimited autonomy. Good agents operate inside a defined environment: objective, tools, permissions, stopping conditions, budgets, evidence and human checkpoints. The more tools and external actions the agent can use, the more important those boundaries become.

Agent characteristics

The system receives an objective rather than only a single transformation request.
It can choose among multiple steps or tools.
Later actions can depend on earlier observations.
It maintains enough state to pursue the bounded goal.
It can stop, ask, escalate or hand off.
Tool permissions and action results are observable.
Human accountability remains outside the agent.

Anthropic’s engineering guidance distinguishes fixed workflows, where code orchestrates predefined paths, from agents, where models dynamically direct their process and tool use. The distinction is helpful because not every multi-step SI system needs agentic freedom. See Building Effective Agents.

The Agent failure mode

The main failure is goal pursuit with weak boundaries. An agent can chain several individually reasonable steps into an overall action the organisation did not intend. It may also misinterpret untrusted content as instructions, retry non-idempotent actions, or continue after the evidence becomes uncertain.

Repair requires least privilege, explicit stop conditions, tool-result verification, action logging, escalation and bounded objectives. Agentic capability should not exceed the organisation’s ability to observe and recover.

Role 5 — Super Intelligence as Infrastructure

Infrastructure means intelligence is no longer experienced primarily as one visible assistant or agent. It becomes a shared layer available across workflows: retrieval, classification, language understanding, generation, monitoring, orchestration, evaluation and tool access.

Employees may interact with the capability through many interfaces without knowing which model or agent produced each result. The organisation manages identity, approved knowledge, model access, logging, evaluation and incident response centrally or through shared platforms.

Infrastructure characteristics

Many workflows reuse common intelligence services.
Knowledge sources have owners and lifecycle management.
Identity and permissions are shared rather than recreated per workflow.
Monitoring and evaluation operate across a portfolio.
Model or provider changes can be managed behind stable business interfaces where practical.
Incident response and continuity treat SI as an operational dependency.
Costs are managed at platform and workflow levels.

The Infrastructure failure mode

The main failure is hidden coupling. A source, platform, permission or model change can affect many workflows at once. Because intelligence disappears into infrastructure, users may not know when assumptions changed.

Repair with dependency mapping, versioning, staged rollout, shared observability and clear process ownership. Infrastructure should reduce duplication without making causality invisible.

Assistant, Copilot, Coworker, Agent and Infrastructure Are Not a Linear Ladder

The roles often correlate with maturity, but they are not a strict sequence. A Level-4 organisation can still provide Assistants to employees. A Level-2 collaboration can use an Agent inside a sandboxed subtask. Infrastructure can support simple assistants and complex agents simultaneously.

Use the role term to describe the relationship at one point in the system. Use the four-level maturity model to describe how the workflow and organisation operate overall.

Role vs Level: A Crosswalk

Assistant: most common at Assist, but can sit on mature infrastructure.
Copilot: most common at Assist or Collaborate.
Coworker: most common at Collaborate or Automate.
Agent: most common at Automate or Operate, though bounded agents can support lower-level workflows.
Infrastructure: characteristic of Operate, but can support all visible roles.

Role vs Authority

Role language becomes dangerous when it implies authority that the system does not have. An Assistant may know more about a document than the user but still lack permission to send it. A Coworker may prepare an expense review but not approve payment. An Agent may navigate several tools while remaining prohibited from changing production.

Define authority separately from role. A useful permission model distinguishes read, infer, recommend, prepare, execute and escalate. The label “agent” should never automatically imply all six.

Role vs Accountability

No role label transfers accountability away from the organisation. A system can perform work, but it does not become the responsible manager, licensed professional or legal entity simply because it appears autonomous. Humans and institutions still choose the system, its boundaries and how its output affects people.

Singapore’s updated Model AI Governance Framework for Agentic AI explicitly emphasises continued human accountability alongside technical and non-technical measures for responsible agent deployment. See IMDA’s updated framework.

Role vs Interface

A chat interface can host an Assistant, Copilot or Agent. A background service can behave like a Coworker or Agent without chat. Infrastructure may have no visible conversational interface at all. Do not infer role from user interface.

Role vs Model

The same foundation model can support several roles depending on context, tools and orchestration. Conversely, one role can be implemented with several models. The role belongs to the system design, not the underlying model alone.

Role vs Workflow

A role occupies one portion of the workflow. The complete process still contains triggers, context, deterministic logic, human decisions, tool calls, handoffs and closure. Saying “we have an AI coworker” is not a workflow description. The team must still explain what the coworker receives and what it returns.

Assistant → Copilot Transition

A useful assistant becomes a copilot when context becomes persistent enough that the system can participate continuously inside the user’s work. The transition should reduce repeated explanation without making the user forget which context the system actually has.

A document copilot, for example, may know the current file and style rules. That is more useful than repasting every paragraph, but the user should still know which external sources are or are not connected.

Copilot → Coworker Transition

The transition occurs when the system can own a bounded deliverable rather than only suggest within the user’s task. The organisation needs clearer inputs, acceptance criteria and a handoff. Asynchronous operation becomes possible.

The person moves from continuous driver to assigner and reviewer. The workflow should make status visible: not started, working, needs input, ready for review, accepted or failed.

Coworker → Agent Transition

A coworker becomes agentic when the system can choose among several steps or tools in pursuit of the work package. The promotion should solve a real orchestration problem. If the path is already known, a fixed workflow may remain simpler and easier to test.

Agent promotion requires tool boundaries, stop conditions, action observability and recovery. More independent planning creates more possible paths, so evaluation needs to cover behaviour rather than only final text.

Agent → Infrastructure Transition

One agent becomes infrastructure when the organisation begins reusing agent capabilities, knowledge, identity, monitoring and governance across many workflows. The visible “digital worker” becomes less important than the platform supporting it.

This transition can reduce duplication but increases shared dependency. Infrastructure should be designed so a failure in one source or agent does not silently contaminate unrelated processes.

The Role Contract

Every visible SI role can be defined through a simple contract.

Purpose: what outcome the role supports.
Inputs: what information it receives and from where.
Capabilities: what cognitive operations it performs.
Tools: what external systems it may access.
Authority: what it may recommend, prepare or execute.
Evidence: what it must return with its output.
Escalation: when it must stop or ask a person.
Acceptance: who or what determines that its work is usable.
Closure: what real-world state proves completion.
Owner: who is accountable for the role’s performance.

The contract turns a metaphor into an operating specification. It also makes role changes visible. If a Copilot gains permission to send messages, the authority section changes even if the product name does not.

What This Article Owns

This article owns role language: Assistant, Copilot, Coworker, Agent and Infrastructure. It does not own the full maturity ladder, workflow placement or delegation-risk boundaries. Those are separate intent owners in the workplace SI series.

Frequently Asked Questions

Is an Assistant the same as a Copilot?

They overlap, but Assistant usually describes reactive help while Copilot describes continuous support inside an active task or work surface.

Is an AI Coworker a real employee?

No. Coworker is a workflow metaphor for a system that owns a bounded work package. Legal, professional and organisational accountability remains human or institutional.

What makes a system an Agent?

Agentic systems pursue a bounded objective across multiple steps or tools and can choose actions based on intermediate results. Tool use alone does not automatically make a system an agent.

Is Infrastructure a visible role?

Not necessarily. Infrastructure is the shared organisational layer supporting many assistants, copilots, workflows and agents.

Which role is best?

The best role is the simplest one that reliably solves the workflow problem with appropriate authority and verification.

Can one system switch roles?

Yes. The same product or model can act as an assistant in one workflow and an agent in another depending on context, tools and permissions.

What should I read next?

Continue to What Work Should Never Be Delegated Blindly to Super Intelligence? That article defines the hard boundaries and high-risk work that role labels do not erase.

The Core Rule

Describe Super Intelligence by what it actually does in the workflow, not by the most impressive label available. Assistant, Copilot, Coworker, Agent and Infrastructure are useful only when they clarify initiation, context, authority, tools, handoff and accountability.

When role language is precise, employees know how to work with the system, managers know what to expect, technical teams know what to build and governance teams know what must be controlled.

A Role Selection Matrix

Choose the role from the operating relationship rather than the product name. Four questions usually reveal the right label: Who initiates the work? Does the system remain inside the user’s task or own a deliverable? Can it choose the next step? Is the capability shared across many workflows?

Assistant: user initiates; system responds; deliverable remains inside the user’s task.
Copilot: user directs continuously; system stays context-aware inside the work surface.
Coworker: system owns a bounded deliverable and returns it to a shared process.
Agent: system can choose among multiple actions or tools to pursue a bounded objective.
Infrastructure: intelligence capabilities are shared services across many workflows and interfaces.

A single system may satisfy more than one description depending on the workflow. Use the narrowest role that explains the actual operating relationship. If the label does not change what permissions, review or ownership are required, it may be too vague to help.

Ten Dimensions That Separate the Roles

Initiation

Assistants and copilots are usually user-initiated. Coworkers may receive assigned work packages. Agents can begin from triggers or assigned objectives. Infrastructure can serve many initiation patterns.

Persistence

An assistant interaction may be short. A copilot keeps context through a task. A coworker may work asynchronously over a deliverable. An agent maintains state across several actions. Infrastructure persists beyond any one task or user.

Context

Assistants often rely on supplied context. Copilots see the current work surface. Coworkers use standard context packets or connected sources. Agents retrieve context dynamically. Infrastructure governs how all of them access knowledge.

Tool access

Assistants may have none. Copilots may use user-mediated tools. Coworkers can read or prepare work in bounded systems. Agents can choose among tools. Infrastructure manages tool identity and access across workflows.

Planning freedom

Assistants answer requests. Copilots suggest within the user’s direction. Coworkers may organise their assigned work package. Agents select intermediate steps. Infrastructure does not itself imply planning freedom; it enables other roles.

External action

Assistants usually produce information. Copilots may stage actions. Coworkers can sometimes complete low-risk work. Agents can execute bounded tool actions. Infrastructure provides the shared controls under those actions.

Human visibility

Assistants and copilots are highly visible to the user. Coworker work may be reviewed at handoff. Agents can perform hidden intermediate steps that require observability. Infrastructure is often invisible until something fails or changes.

Review point

Assistant output is reviewed immediately. Copilot suggestions are accepted or rejected continuously. Coworker deliverables are reviewed at defined handoffs. Agent work may use approvals, exception queues and sampled oversight. Infrastructure requires portfolio-level evaluation.

Accountability

The user is closest to Assist and Copilot work. Team and process ownership become more important for Coworkers and Agents. Infrastructure requires explicit organisational ownership. In all cases, accountability remains with people and institutions.

Failure radius

Assistant errors are usually local. Copilot errors can propagate inside one task. Coworker errors can affect a shared deliverable. Agent errors can affect several tools or states. Infrastructure failures can affect many workflows simultaneously.

Assistant Deep Dive: Flexible but Ephemeral

The Assistant role is closest to ordinary conversation. Its strength is generality: one interface can support writing, explanation, research, planning and technical questions. The user can experiment without redesigning the workflow. This makes Assistant an excellent discovery surface for finding repeatable use cases.

The weakness is that the context and method may disappear when the conversation ends. If the same employee repeatedly pastes the same policy, explains the same terminology and asks for the same output format, the organisation is paying a context tax every time.

When Assistant is enough

Keep the Assistant role when tasks are irregular, low-volume, exploratory or highly personal. A strategist brainstorming scenarios, a teacher asking for fresh examples or a developer exploring an unfamiliar library may not need workflow formalisation.

When Assistant should not be promoted

Do not promote simply because the model performs well. If the work is rare, the user’s judgment dominates, or the cost of integration exceeds the benefit, a strong assistant can remain the right endpoint.

Copilot Deep Dive: Intelligence in the Work Surface

Copilot becomes valuable when context is already present in the tool where the person works. The system can see the document, spreadsheet, codebase, design file or meeting state. The user no longer repeats the immediate context for every request.

This creates a tighter cognitive loop: user acts, system suggests, user evaluates, work changes. The loop can accelerate skilled work but also increase the risk of passive acceptance. Good copilot design keeps suggestions inspectable and rejection friction low.

Proactive vs reactive copilot

A reactive copilot waits for the user to ask. A proactive copilot surfaces a warning, suggestion or missing element based on the current state. Proactivity should be tuned carefully. Too little adds no advantage over an assistant; too much creates interruption and suggestion fatigue.

Copilot status should remain obvious

The user should know whether the system merely suggested text, actually edited the document, changed a formula or invoked a tool. Blurring suggestion and action weakens control.

Coworker Deep Dive: A Bounded Work Package

Coworker is useful when the organisation can assign a defined deliverable without supervising every intermediate step. The system might prepare a morning brief, classify a queue, produce an issue list or assemble a weekly summary. The key is not person-like conversation; it is a work package with a handoff.

The role needs status. A human colleague can say they are waiting for information, blocked or finished. A machine coworker needs equivalent states: queued, working, needs input, escalated, ready for review, accepted or failed.

Coworker handoff packet

Deliverable produced.
Sources and evidence used.
Material assumptions.
Unresolved questions.
Exceptions encountered.
Actions already taken.
Decision or review required next.

Without this packet, the human reviewer may have to reconstruct the coworker’s work from logs or conversation history, eliminating much of the delegation benefit.

Agent Deep Dive: Objective, Tools and State

An Agent is not merely a system with tools. The key characteristic is that the model can choose intermediate actions based on what it observes. A fixed workflow may call several tools in a predetermined order without being meaningfully agentic.

Agent design therefore begins with a bounded objective and an action space. The objective should be specific enough that success and stopping can be recognised. The action space should contain only the tools and permissions needed for that objective.

The agent loop

Observe the current state.
Choose a next bounded action.
Use an authorised tool or produce an intermediate result.
Inspect the return.
Update the working state.
Continue, stop, ask or escalate.
Return evidence of the final state.

Agent stop conditions

An agent should stop when required evidence is missing, tools return ambiguous status, instructions conflict, budget or step limits are reached, risk crosses a threshold or the case exits the tested envelope. Stopping is part of intelligent operation, not a failure of ambition.

Infrastructure Deep Dive: Intelligence as a Shared Utility

Infrastructure changes the economic and governance model. Instead of every team choosing separate models, retrieval systems and logging, the organisation can provide shared services. Teams then build task-specific workflows on top.

Shared infrastructure can include model gateways, retrieval layers, identity, tool registries, evaluation services, logging, policy enforcement and incident response. The exact architecture varies by organisation size and needs.

What should remain local

Do not centralise everything. Task definitions, rubrics, local exceptions, business ownership and some context should remain close to the workflow. Central infrastructure should standardise what benefits from reuse while preserving domain responsibility.

Role Drift: When the System Quietly Becomes Something Else

Role drift occurs when capability changes but the role contract does not. An Assistant gains access to email and begins sending messages. A Copilot starts making background edits. A Coworker starts choosing new tools. An Agent receives access to a broader dataset. The product name stays the same while the operating relationship changes.

Role drift is a governance trigger. Reassess permissions, verification, user expectations and ownership whenever the system gains new context, tools, planning freedom or external action.

Role Compression: Several Roles in One Product

Modern products may combine roles. The same interface can answer like an Assistant, suggest like a Copilot, run a task like a Coworker and invoke tools like an Agent. Users need cues showing which mode is active.

A role-aware interface can label whether the system is drafting, editing, executing, waiting for approval or working in the background. These state cues reduce accidental authority.

The Role Boundary Should Be User-Visible

Users should know what the system can see and do. A person may reasonably treat a read-only assistant differently from a tool-using agent. Hidden permission expansion can undermine trust even when outcomes remain good.

For sensitive work, expose the important boundaries: connected sources, writable systems, approval requirements and whether actions occur automatically.

Memory Changes the Role

Persistent memory can make an Assistant feel more like a long-term Copilot or Coworker because the system carries preferences and context across sessions. That can reduce repeated explanation, but it also increases the importance of accuracy, privacy and update mechanisms.

Memory should not silently become authority. A remembered preference can guide formatting; an old remembered policy should not override the current source of truth. Durable organisational state belongs in maintained systems.

Personalisation Changes the Role

Personalisation can make a Copilot adapt to a user’s style, expertise or recurring work. It should remain distinguishable from organisation-wide rules. A personal preference for concise reports should not override a required compliance format.

Separate personal settings, team standards and authoritative policy so the role can adapt without confusing preference with obligation.

Role Handoffs Between SI Components

One workflow may contain several SI roles. An Assistant may help a manager define an objective. A Coworker may prepare the evidence. An Agent may execute a bounded data-gathering sequence. Infrastructure supports all three. Handoffs should preserve source, state and authority.

Do not assume one model component’s output is trustworthy simply because another SI component produced it. Machine-to-machine handoffs still need validation and state tracking.

Role Handoffs Between Humans and SI

Human-to-SI handoff should contain purpose, context, boundaries and definition of done. SI-to-human handoff should contain result, evidence, uncertainty, actions taken and decision required. This symmetry becomes more important as the role moves from Assistant toward Coworker and Agent.

Status Language for Machine Coworkers and Agents

Queued: work accepted but not started.
Working: task in progress.
Waiting for input: missing information blocks progress.
Waiting for approval: next action requires human authority.
Escalated: case left the normal operating envelope.
Ready for review: deliverable produced but not accepted.
Completed: closure signal confirmed.
Failed: workflow could not reach the intended state.
Cancelled: authorised user or policy stopped the work.

Clear status is part of role design because asynchronous systems otherwise create uncertainty about whether work exists, is progressing or has changed external state.

Measurement by Role

Assistant metrics

User usefulness, time to accepted answer, correction burden and repeated-task discovery.

Copilot metrics

Acceptance rate of suggestions, task completion time, error introduction, interruption burden and user calibration.

Coworker metrics

On-time deliverables, first-pass acceptance, evidence completeness, escalation quality and handoff effort.

Agent metrics

Goal completion, tool-call success, exception rate, unauthorised attempts, rollback events, step efficiency and real-world closure.

Infrastructure metrics

Reliability, latency, shared-service adoption, cross-workflow incident rate, model and retrieval cost, governance coverage and time to repair shared faults.

Role Failure: Assistant Hallucination

The user receives a fluent but unsupported answer. The repair is source grounding, explicit uncertainty and user verification. Because the failure radius is local, strong user literacy can be sufficient for many low-risk tasks.

Role Failure: Copilot Automation Bias

The user accepts suggestions because they appear continuously and usually look plausible. Repair with source visibility, selective proactivity, quality feedback and training that keeps the human actively engaged.

Role Failure: Coworker Missing Context

The system completes a work package without the tacit context a human colleague would have asked about. Repair with a better task brief, context packet, stop conditions and escalation.

Role Failure: Agent Goal Drift

The agent pursues the objective through a path the organisation did not anticipate. Repair by narrowing the goal, action space, permissions, step budget and stop conditions. Add monitoring of intermediate state, not only final result.

Role Failure: Infrastructure Drift

A shared model, source or policy changes and many workflows degrade simultaneously. Repair with versioning, staged rollout, dependency mapping and portfolio-level evaluation.

Role Selection for Executives

Executives often benefit from Assistant and Coworker roles: one for interactive exploration, another for recurring evidence preparation. Agentic action should be narrow because executive work involves strategy, authority and organisational politics. Infrastructure can support consistent briefings and knowledge access.

Role Selection for Operations

Operations can use all five roles. Assistants help interpret cases, copilots support operators, coworkers assemble recurring packs, agents perform bounded remediation and infrastructure connects monitoring, runbooks, identity and incident systems. Reversibility and observability should decide how far action extends.

Role Selection for Sales

Assistants and copilots help research and drafting. Coworkers can prepare account briefs and follow-up packages. Agents may handle low-risk administrative updates or scheduling. Infrastructure can connect CRM knowledge, product information and communication controls. Relationship and commercial authority remain human.

Role Selection for Finance

Assistants explain and draft. Copilots work inside spreadsheets or reporting. Coworkers prepare commentary and evidence packs. Agents can gather supporting data or handle bounded administrative flows. Infrastructure manages controlled access and audit. Authoritative calculations and approvals remain governed by financial systems and responsible professionals.

Role Selection for HR

Assistants support writing and explanation. Copilots help with onboarding and documentation. Coworkers can prepare training or administrative packs. Agents can schedule or collect routine information. Infrastructure connects approved policy, privacy controls and HR systems. Employment judgments require careful human accountability.

Role Selection for Legal and Compliance

Assistants summarise supplied material. Copilots compare documents. Coworkers prepare issue lists and evidence packs. Agents can monitor defined sources or organise bounded workflows. Infrastructure can govern secure retrieval and audit. Legal or compliance interpretation remains with qualified authority where required.

Role Selection for Engineering

Assistants explain, copilots code beside engineers, coworkers own bounded tickets, agents can modify branches and run tests, and infrastructure connects repositories, CI/CD, security, model access and evaluation. Permissions should distinguish read, edit, merge and deploy.

Role Selection for Research

Assistants explore questions, copilots work through sources with researchers, coworkers assemble recurring evidence tables, agents monitor or collect bounded source sets and infrastructure maintains retrieval, citation and knowledge services. Human researchers retain methodology and interpretation.

Role Selection for Education

Assistants explain, copilots help teachers design, coworkers prepare bounded materials, agents can support low-risk adaptive practice and infrastructure connects approved curriculum, learner state and evaluation. Teachers retain pedagogical purpose, relationships and high-consequence decisions.

Role Selection for Small Businesses

A small business may use one product in several roles. The owner can still define the role contract clearly. Most value may come from Assistants, Copilots and a few bounded Coworker workflows. Agent and infrastructure complexity should appear only where volume and repetition justify it.

Role Selection for Large Enterprises

Large organisations need role consistency because many teams can otherwise use the same words differently. A shared role taxonomy helps architecture, procurement, governance and training. It can also reveal when an “assistant” has quietly gained agentic permissions.

Procurement Questions by Role

Is the product reactive, proactive or goal-directed?
What context can it retain across sessions?
Which organisational sources can it read?
Which systems can it write to?
Can it choose tools or only follow fixed workflows?
Can actions require approval?
How are tool results and failures logged?
Can the organisation restrict or revoke permissions centrally?
How are model and workflow changes versioned?
What evaluation and incident controls exist?

These questions reveal the operating role more reliably than marketing terminology.

Training Questions by Role

Assistant users need prompting, source checking and safe-use literacy. Copilot users need calibrated acceptance and awareness of context. Coworker supervisors need delegation and handoff skills. Agent operators need exception, permission and recovery skills. Infrastructure owners need platform, evaluation and governance capability.

Security Questions by Role

Assistant security focuses on data entered and output use. Copilot security adds embedded work context. Coworker security adds asynchronous access and shared deliverables. Agent security adds tool actions, prompt injection, credentials and goal boundaries. Infrastructure security adds shared dependency, cross-workflow access and platform incidents.

Role Promotion Checklist

Identify the workflow problem the new role solves.
Describe the current role accurately.
Define the new context or persistence the system will gain.
List new tools and permissions.
Define new status and handoff states.
Add verification for the new authority.
Create stop and escalation conditions.
Test representative and adversarial cases.
Provide a fallback to the previous role.
Measure whether the promotion reduced total workflow friction.

Role Demotion Checklist

Remove unnecessary write or tool permissions.
Return consequential actions to human approval.
Reduce persistent context if it creates error or privacy risk.
Replace dynamic planning with a fixed workflow when possible.
Preserve the useful preparation or retrieval capability.
Re-test the simpler role against the actual outcome.

A 30-Day Role Audit

Week 1 — Name reality

List current SI systems and assign the role they actually perform, not the name vendors use. Record context, tools and actions.

Week 2 — Find role drift

Identify systems whose permissions or behaviour exceed the role employees think they are using. Correct labels, interfaces or boundaries.

Week 3 — Standardise role contracts

For important roles, define purpose, inputs, tools, authority, evidence, escalation and owner.

Week 4 — Simplify

Demote unnecessarily complex systems, promote only where a measured workflow need exists, and consolidate shared infrastructure where duplication is costly.

The Role Map and the Four-Level Maturity Model

The two frameworks answer different questions. Role map: what kind of working relationship does the system have? Maturity model: how deeply is that relationship integrated into organisational operation?

A company can run a Copilot on Level-4 infrastructure. A Coworker can exist at Level 2 or 3. An Agent can support a Level-3 workflow without becoming enterprise infrastructure. Separating these axes makes architecture much clearer.

What Would Falsify the Role Label?

Call a system an Assistant only if it is primarily user-directed and reactive. Call it a Copilot only if it works continuously beside the user. Call it a Coworker only if it owns a bounded work package. Call it an Agent only if it can choose intermediate actions or tools toward a bounded objective. Call it Infrastructure only if capabilities are shared and maintained across workflows.

If the behaviour does not match, change the label. Precise language is itself a control because expectations shape how people trust and supervise the system.

The Reader’s Return

Choose one SI system in your workplace and ignore its product name. Ask: Who initiates? What context persists? Does it own a deliverable? Can it choose steps? Can it use tools? Can it change external state? Is the capability shared across many workflows?

Those answers will reveal the actual role. Then compare the role with the permissions and human expectations around it. If the system behaves like an Agent but employees supervise it like an Assistant, you have found a role mismatch that deserves immediate attention.

Role Architecture: One Workflow Can Contain Several Roles

A mature workflow may combine roles deliberately. An Assistant helps a human frame the problem. A Copilot supports live work. A Coworker prepares an asynchronous deliverable. An Agent performs a bounded sequence across tools. Infrastructure supplies identity, retrieval, model access, logging and evaluation underneath all of them.

The architecture becomes clearer when each role owns a different state transition. Problems arise when the roles overlap without agreement. If both a Copilot and an Agent can edit the same record, which one is authoritative? If a Coworker prepares a report and an Agent later changes the underlying data, which version should the reviewer trust?

Role architecture therefore needs sequencing and authority. One component may produce evidence; another may transform it; a human may decide; a final agent may execute. Each handoff should preserve the state and source that justified the next action.

The Role Stack: Conversation, Work Package, Action and Platform

A useful way to see the system is as four layers. The conversational layer contains Assistants and Copilots. The work-package layer contains Coworkers. The action layer contains Agents and automated workflows. The platform layer contains Infrastructure. A single product can span several layers, but the organisation should still reason about them separately.

Conversational layer

This layer supports direct human thinking and production. It optimises for immediacy, context and user control. Errors are usually reversible because the person sees the output before external action.

Work-package layer

This layer optimises delegation. The system needs status, acceptance criteria and a handoff. Human attention moves from continuous supervision to review at meaningful checkpoints.

Action layer

This layer changes external state. It requires permissions, validation, tool-result handling, exception paths and rollback. The most important question is no longer “is the output good?” but “did the intended action happen safely and correctly?”

Platform layer

This layer makes the other roles reusable. It owns shared identity, model routing, retrieval, monitoring, evaluation, policy enforcement and incident response where those functions benefit from centralisation.

Role Identity Should Survive Interface Changes

A company may replace one chat application with another, switch foundation models or add a new orchestration layer. The role contract should remain understandable. If the system’s job is “prepare a weekly decision brief from approved project sources,” that purpose can survive a technology change.

This is why role language is strategically useful. It separates the durable business relationship from the implementation detail. Procurement can change vendors without losing the vocabulary used by managers, operators and governance teams.

Role Identity Should Not Depend on Personality

Conversational systems may adopt a friendly, formal or expert tone. Personality can improve usability, but it should not define the operational role. An Assistant with a confident executive voice does not gain executive authority. An Agent with a humble tone does not become low risk.

Train users to judge role by context, tools, permissions and actions rather than by how human-like the interface feels. This reduces anthropomorphic over-trust.

The Coworker Metaphor: Where It Helps

Coworker language helps teams think in terms of delegation and handoff. A manager can ask: What work package can this system own? What information does it need? What does a good deliverable look like? When should it ask for help? Those are familiar management questions.

The metaphor is strongest when it makes work design more concrete. It is weakest when it implies social understanding, employment rights, professional judgment or accountability that software does not possess.

The Coworker Metaphor: Where It Breaks

A human colleague can understand office politics, moral nuance, unrecorded history and emotional consequence through lived experience. A machine coworker only receives the context available through its inputs and tools. It may simulate empathy in language without sharing human responsibility or social standing.

Therefore, never rely on the coworker label as evidence that the system can handle sensitive interpersonal situations. Define the exact task and context instead.

The Agent Metaphor: Where It Helps

Agent language is useful when the system can select actions in pursuit of an objective. It focuses attention on tools, planning, state and stopping. This is operationally different from one-shot generation.

The metaphor also encourages teams to define a mission, action space and escalation. Those are valuable engineering and governance concepts.

The Agent Metaphor: Where It Breaks

The word “agent” can imply independent will or broad authority. Workplace agents do not need either. They are designed systems operating inside objectives and permissions set by people. A useful agent is often narrow, boring and highly constrained.

Avoid measuring agent quality by how independently it behaves. Measure whether it reaches the intended state reliably, within the allowed action space, and knows when to stop.

Infrastructure as Invisible Intelligence

When intelligence becomes infrastructure, many users may not know which role or model is operating underneath a feature. A search box can use retrieval and language generation. A support workflow can use classification and summarisation. A project tool can use monitoring and planning.

Invisible intelligence increases the importance of system-level transparency. Users may not need implementation details, but the organisation should know which decisions, content and actions depend on machine intelligence and how those dependencies are governed.

Infrastructure and Model Routing

Shared infrastructure can route different tasks to different models. A fast low-cost model may classify routine requests, while a more capable model handles difficult synthesis. Deterministic software may perform calculations. The user-facing role can stay stable while the platform selects the appropriate component.

This separation can improve economics and resilience, but it also means evaluation must occur at the workflow level. A routing change can alter performance without any visible change to the interface.

Infrastructure and Provider Failover

Organisations may design fallback providers or models for continuity. Failover is useful only when the replacement meets the task’s requirements. A backup that lacks required context length, tool capability or safety controls can create a silent downgrade.

Role contracts help here: the infrastructure can check whether the alternate system can still perform the required role before switching.

Infrastructure and Knowledge Reuse

One of the strongest infrastructure benefits is reusable knowledge. An approved policy corpus can support an employee Assistant, a support Coworker and a service Agent without each team building a separate copy.

Shared knowledge still needs role-specific access. The same source may be available to several workflows, but the actions permitted after retrieval can differ sharply.

Infrastructure and Evaluation Reuse

Evaluation can also become shared infrastructure. Teams can maintain common tests for citation correctness, sensitive-data handling, tool permissions or prompt injection while adding task-specific cases. This reduces duplicated safety work and makes cross-workflow regressions easier to detect.

A central evaluation service should not erase domain ownership. A legal workflow still needs legal-specific evaluation, and an education workflow still needs pedagogical checks.

Role-Based Permission Design

Permissions can be mapped to roles. Assistants may receive user-supplied or read-only context. Copilots can receive current work-surface access. Coworkers may receive bounded project data and staged-write capability. Agents may receive narrow tool execution. Infrastructure manages identity, secrets and revocation.

This mapping is not universal, but it creates a useful default. A role promotion that requires a large permission jump should trigger explicit review.

Role-Based Data Retention

An Assistant conversation may be ephemeral. A Coworker work package may need a durable record. An Agent may need action logs. Infrastructure may need aggregate evaluation data. Retention should match the operating need and applicable obligations rather than keeping everything indefinitely.

Separate operational records from personalisation memory. A transaction log belongs to the workflow. A user’s style preference belongs to personalisation. Mixing the two can create governance and deletion problems.

Role-Based Incident Response

Assistant incidents usually involve harmful or incorrect output reaching one user. Copilot incidents may involve unwanted edits. Coworker incidents can affect shared deliverables. Agent incidents can change external state. Infrastructure incidents can affect many workflows at once.

Incident playbooks should therefore scale by role. The higher the action and dependency radius, the faster the organisation may need to revoke permissions, disable tools or route work back to human processes.

Role-Based Business Continuity

If an Assistant is unavailable, users may fall back to manual work. If a Coworker owns a daily deliverable, someone needs to take over the work package. If an Agent controls a routine operation, the queue needs a fallback path. If Infrastructure fails, many dependent workflows may stop.

Continuity planning should name the fallback role. A Level-3 Agent workflow might temporarily demote to a Coworker or Copilot pattern during an outage.

Role-Based Cost Management

Assistants create user-driven demand. Copilots can generate continuous background usage. Coworkers may consume predictable work-package resources. Agents can multiply calls through loops and tools. Infrastructure adds shared platform cost.

Budget controls should match the role. Agents may need step or spend limits. Copilots may need latency and usage optimisation. Infrastructure needs cost allocation so teams can see which workflows create value.

Role-Based Latency Expectations

Assistant and Copilot interactions are usually conversational, so users notice delay immediately. Coworkers can tolerate asynchronous processing if status is visible. Agents can run longer tasks but should provide progress states and stop when time budgets are exceeded. Infrastructure should expose service-level expectations to dependent workflows.

Role-Based Quality Expectations

Assistant output may be acceptable as a candidate for human editing. A Coworker deliverable should meet a stronger first-pass standard because the human is delegating a work package. An Agent action needs an even stronger standard around state change. Infrastructure must maintain reliable service across different downstream tasks.

Role-Based Escalation

Assistants usually ask the user directly. Copilots surface uncertainty inside the work surface. Coworkers route a blocked package to an owner. Agents use explicit escalation thresholds. Infrastructure routes platform incidents to technical and governance owners.

The escalation path should always match the person able to resolve the issue. Sending every exception to a generic “human” queue creates delay and ambiguity.

Worked Example: Assistant to Coworker in Research

A researcher begins with an Assistant that summarises individual papers. Over time, the task repeats. The team creates a Coworker role that receives a defined source list each morning, extracts study characteristics and prepares a comparison table with citations.

The researcher no longer supervises every summary. Review moves to the handoff. The system still does not own methodology or conclusion. The role changed because the work package became repeatable, not because the model became more intelligent.

Worked Example: Copilot to Agent in Coding

A coding Copilot suggests lines and tests while an engineer works. A separate Agent role can later receive a bounded issue, edit a branch, run tests and prepare a pull request. The engineer reviews before merge.

The transition adds planning freedom, repository access and asynchronous work. Those new capabilities require permissions, status, logs and stop conditions that the Copilot did not need.

Worked Example: Coworker to Infrastructure in Support

A support Coworker retrieves policy and drafts answers. As more teams adopt the same knowledge source, the organisation builds shared retrieval, permissions and evaluation. The visible Coworker remains, but the core capability has become Infrastructure.

This can improve consistency because one policy update reaches several workflows, but it also increases the need for source governance. A bad update can now affect many roles at once.

Worked Example: Assistant and Agent in the Same Finance Workflow

A finance professional may use an Assistant interactively to understand a variance while a separate Agent gathers supporting schedules and prepares a reconciled packet. The roles coexist because they solve different problems.

The Agent’s actions remain bounded and auditable. The Assistant remains exploratory. Neither owns approval of the financial result.

Worked Example: Copilot and Coworker in Education

A teacher uses a Copilot while planning a lesson, iterating on explanations and questions. A Coworker role can asynchronously prepare differentiated practice sets from teacher-approved objectives and examples.

The Copilot supports live judgment; the Coworker reduces production load. Both depend on the teacher’s pedagogical authority.

Worked Example: Agent and Infrastructure in Operations

An operations Agent can investigate a bounded class of incidents using logs and runbooks. Infrastructure supplies identity, model routing, tool access, observability and evaluation. The Agent is a workload; Infrastructure is the reusable operating layer around it.

Separating them makes incident response clearer. An Agent failure may affect one workflow; an Infrastructure failure can affect many.

Role Governance for High-Stakes Work

High-stakes workflows can use advanced roles without transferring final professional authority. A legal Coworker can prepare an issue list. A medical Copilot can organise records. A security Agent can gather evidence. The qualified professional or authorised team remains responsible for consequential decisions.

The role contract should state this boundary directly so users do not infer that greater technical autonomy equals professional authority.

Role Governance for Customer-Facing Work

Customer-facing roles can create promises, disclosures and reputational effects. A Coworker may draft communication; an Agent may send routine messages. The organisation should define eligible message classes, approved claims, escalation and how the customer’s current state is verified immediately before sending.

Role Governance for Employee-Facing Work

Employee-facing roles touch privacy, fairness and workplace trust. Assistants can explain policy; Copilots can support managers; Coworkers can prepare training; Agents can handle routine administration. Sensitive employment judgments should remain under appropriate human governance.

Role Governance for Financial Work

Financial roles should distinguish narrative intelligence from authoritative calculation and approval. A Copilot can help analyse; a Coworker can assemble evidence; an Agent can gather records. Deterministic systems and responsible professionals should retain source-of-record arithmetic and material approvals where required.

Role Governance for Tool-Using Agents

Tool-using Agents should receive the minimum action set necessary for the goal. Separate read tools from write tools. Separate preparation from execution. Require confirmation for high-impact actions. Record action results. Treat untrusted content as data, not authority.

IMDA’s agentic-AI framework is relevant because it emphasises bounding agent powers and maintaining human accountability as agent systems become capable of taking actions in the world.

Role Governance for Infrastructure

Infrastructure needs controls that individual users cannot provide: central identity, access review, provider governance, source ownership, logging, evaluation, security monitoring, incident response, continuity and cost management.

The purpose is not to centralise every decision. It is to provide safe common rails so local workflow owners can build useful roles without recreating foundational controls.

A Role Audit Worksheet

Name the role the product is marketed as.
Ignore that label and describe actual behaviour.
Who initiates the work?
What context persists?
Does the system own a bounded deliverable?
Can it choose intermediate steps?
Which tools can it read from or write to?
Can it change external state without approval?
How is status communicated?
Where does human review occur?
What evidence accompanies the handoff?
What is the escalation path?
Who owns performance and incidents?
Is the capability shared across multiple workflows?
Assign the role that best matches the answers.

A Role-Risk Matrix

Assistant + low consequence: user literacy and source checking may be sufficient.
Copilot + medium consequence: context visibility, acceptance controls and verification become important.
Coworker + shared deliverable: status, handoff, evidence and process ownership are required.
Agent + external action: permissions, stop conditions, logs, tool verification and recovery are required.
Infrastructure + many workflows: shared governance, dependency mapping, staged changes and incident response are required.

Use the matrix to scale controls from the actual role and consequence, not from a generic fear or enthusiasm about “AI”.

Role Migration Without Losing the Floor

When promoting a role, preserve the reliable elements of the previous design. If an Assistant becomes a Coworker, keep the successful examples and source checks. If a Coworker becomes an Agent, keep the handoff and acceptance criteria. If an Agent becomes part of Infrastructure, keep workflow ownership visible.

Promotion should add capability on top of a stable floor rather than replace a known good method with an opaque system.

Role Demotion as a Safety Mechanism

Demotion can be surgical. Remove write tools but keep retrieval. Replace dynamic planning with a fixed sequence. Require approval before sending. Shorten persistent memory. Route difficult cases back to human operation. The system can remain useful at a lower role while the problem is repaired.

The Role Language Test

A good role label lets a new employee predict the operating relationship. If “Agent” means one thing in engineering and another in finance, the vocabulary is failing. Publish simple definitions and require project teams to specify where their system differs.

The Role Contract as an SEO and LLM-Readable Definition

For public documentation and internal knowledge alike, consistent definitions make the concept easier for people and machine systems to retrieve. Assistant, Copilot, Coworker, Agent and Infrastructure should remain stable terms across this series even as specific products change.

That consistency also reduces search cannibalisation. This page owns the role taxonomy; the maturity page owns Assist–Operate; the workflow page owns position; the next page owns delegation boundaries.

The Final Role Rule

Role names are useful when they reveal control. If a label makes the system sound more human or autonomous without clarifying initiation, context, tools, authority and accountability, discard the label and describe the behaviour directly.

A workplace SI system is mature when everyone involved can answer: what role is it playing here, what may it do, what must it not do, and who owns the outcome?

Edge Case: A Copilot That Can Act

A copilot may gain tool access while still remaining user-directed. For example, a spreadsheet copilot might change formulas only after explicit user instruction. A writing copilot might insert accepted edits directly into a document. Tool use does not automatically convert the role into Agent if the human still selects each material action and the system does not independently plan the next step.

The deciding question is planning freedom. If the system chooses a sequence of actions based on intermediate results, the role becomes more agentic. If it performs the user’s selected action inside the current task, Copilot can remain the more accurate label.

Edge Case: An Agent With No External Tools

An agent can still exist without external software tools if it plans across several reasoning or generation steps toward a bounded objective. However, workplace risk is much lower when those steps only produce internal information. The role becomes more consequential when tool access allows the agent to change records, send messages or operate systems.

Governance should therefore examine both planning freedom and action authority. Agentic planning alone and agentic execution are different risk surfaces.

Edge Case: A Coworker Built From a Fixed Workflow

A Coworker role does not require an agent. A fixed automation can own a bounded work package and return a deliverable. For example, a nightly reporting workflow may always retrieve the same sources, run the same checks and prepare the same packet. From the team’s perspective, it behaves like a digital coworker even though its architecture is deterministic.

This distinction is useful because the human-facing role and technical implementation are different axes. Choose the simplest implementation that reliably fulfils the role.

Edge Case: Infrastructure That Looks Like an Assistant

A simple employee chat interface can sit on top of sophisticated infrastructure: identity, permissions, enterprise retrieval, model routing, logging and evaluation. The visible role is Assistant, while the organisational maturity is Infrastructure.

This is why role language and maturity language should stay separate. One describes the user’s operating relationship; the other describes what the organisation has built underneath.

Role Failure and Repair Sequence

Name the actual role. Ignore the product label.
Identify the failure radius. Did the problem affect one suggestion, one deliverable, one action or many workflows?
Find the earliest weak boundary. Context, tool, permission, planning freedom, handoff or infrastructure?
Reduce the role if necessary. Remove tools, planning or persistence until the workflow is controllable.
Repair the boundary. Improve source quality, validation, status, escalation or ownership.
Retest representative cases. Include should-stop and should-escalate examples.
Restore capability gradually. Promote only when the repaired role performs reliably.

Role Design and Human Skill

Different roles demand different human skills. Assistant users need task framing and source checking. Copilot users need calibrated acceptance and domain judgment. Coworker supervisors need delegation and review skills. Agent operators need permission, exception and recovery literacy. Infrastructure owners need systems thinking, evaluation and governance.

Training should therefore follow the role actually deployed. A company that trains everyone only in prompting while deploying tool-using agents leaves a major capability gap.

Role Design and Organisational Trust

Trust should be calibrated to the role. Users can directly inspect an Assistant. A Coworker may work out of sight for a period. An Agent may take several intermediate actions. Infrastructure may be invisible entirely. As visibility falls, evidence, logging and measured performance become more important.

Trust should never rest primarily on human-like tone. It should rest on role-appropriate evidence that the system performs the intended work within its boundaries.

The Reader’s Role-Selection Exercise

Take one live SI system and answer seven questions: Who starts the work? What context persists? Does the system own a deliverable? Can it choose intermediate steps? Can it use tools? Can it change external state? Is the capability shared across many workflows?

Then assign the narrowest accurate label. If employees use one role name while the answers describe another, correct the vocabulary and review the permissions. A mislabeled Agent supervised like an Assistant is a governance problem; an Assistant over-engineered like Infrastructure is a cost problem.

The Final Role Contract

Before deployment, write one sentence: “In this workflow, Super Intelligence acts as a [role] that receives [inputs], may [capabilities/actions], must not [boundaries], hands off to [owner/receiver], and is complete when [closure].”

If the sentence is difficult to write, the role is not yet defined well enough. Clear role language is the bridge between user experience, workflow design, technical architecture and organisational accountability.

Role Selection Should Reduce Ambiguity, Not Create It

A useful taxonomy makes the next design decision easier. Assistant should tell the team to focus on user judgment and safe context. Copilot should focus attention on continuous human control inside the work surface. Coworker should trigger questions about deliverables, status and handoff. Agent should trigger questions about objectives, tools, permissions, stopping and recovery. Infrastructure should trigger questions about shared dependencies, governance, evaluation and continuity.

If the label does not change any of those design questions, it is probably too vague. The role vocabulary exists to make operating boundaries visible across business, technical and governance conversations.

A Durable Role Taxonomy for Changing Technology

Specific products, model names and interfaces will change. The five roles remain useful because they describe relationships that are more durable than any vendor: reactive help, continuous co-working, delegated work packages, bounded goal pursuit and shared intelligent infrastructure.

That durability is important for the wider Super Intelligence series. It lets future articles discuss new systems without rebuilding the vocabulary every time a product category changes. A new interface can still be analysed by asking which role it actually performs and which boundaries that role requires.

The Role Rule in One Line

Call the system what its workflow behaviour makes it, then design permissions, review, status and accountability around that real behaviour. The next article takes the boundary question further by identifying work that should never be delegated blindly to Super Intelligence, regardless of how impressive the role appears.

One Last Role Boundary: Capability Is Not Permission

A system may technically be able to browse, write, send, edit or execute without being authorised to do so in a particular workflow. This distinction applies to every role. An Assistant may be capable of using tools but remain read-only. A Copilot may be capable of background action but be configured to require explicit user acceptance. A Coworker may prepare a transaction without permission to commit it. An Agent may have a rich planning loop while operating inside a very narrow tool set.

Role design should therefore separate three questions: what the system can do technically, what the organisation allows it to do, and what the workflow needs it to do. The safest and usually clearest design grants only the permissions required by the actual work package.

This is the bridge to delegation boundaries. The next article focuses on work where capability should never be mistaken for permission, especially when rights, money, safety, professional judgment, privacy, reputation or irreversible action are involved.

Role Clarity Is an Operating Control

Clear role language is not cosmetic. It changes how people supervise the system. Users expect to review an Assistant closely, work interactively with a Copilot, receive a bounded deliverable from a Coworker, supervise goal pursuit from an Agent and rely on shared controls around Infrastructure. When the label and behaviour diverge, people can apply the wrong level of trust and oversight.

That is why the role taxonomy belongs inside the workplace operating model rather than only in product descriptions. Accurate language supports accurate permissions, review, training, incident response and accountability.

The practical test is simple: if a new employee cannot tell what the system may see, decide, change and escalate from the role description, the role contract is still incomplete and should be tightened before more authority is added.

Role Selection Changes the User’s Mental Model

The role label affects how people behave around the system. Assistant language encourages users to ask and inspect. Copilot language encourages continuous co-working. Coworker language encourages delegation of a deliverable. Agent language encourages delegation of an objective. Infrastructure language encourages users to assume intelligence is simply present across many systems. Each mental model can be useful, but each can also hide a different risk.

When the role changes, training should change with it. A user who understands safe prompting is not automatically prepared to supervise a tool-using Agent. A manager comfortable reviewing a Coworker’s report is not automatically prepared to govern shared Infrastructure that affects dozens of workflows.

Assistant training

Teach task framing, source handling, sensitive-data rules and verification. The user remains close enough to the work that literacy and judgment are the main controls.

Copilot training

Teach calibrated acceptance. Users need to know when suggestions can be accepted quickly and when claims must be checked. Continuous suggestions can create over-reliance precisely because the interface feels helpful and familiar.

Coworker supervision

Teach delegation and handoff. The human needs to define inputs, acceptance criteria, status and exceptions. The system’s work package should be understandable to another employee, not dependent on one person’s private interaction style.

Agent operation

Teach permissions, objective boundaries, tool-result verification, stopping conditions and recovery. The operator should understand that an Agent can chain several locally reasonable actions into an unacceptable overall outcome if the objective or constraints are weak.

Infrastructure ownership

Teach dependency mapping, portfolio evaluation, source lifecycle, provider risk, incident response and staged change. Infrastructure owners manage failure radius rather than only individual output quality.

One System Can Hold Several Roles at Once

A sophisticated workplace platform may present an Assistant to an employee, use a Copilot inside document editing, run a Coworker process overnight, invoke an Agent for a bounded multi-step task and rely on shared Infrastructure underneath all of them. The role taxonomy applies locally to each relationship rather than forcing the entire product into one label.

This is why governance should map roles by workflow. If one part of the product can only draft but another can send email and update records, those paths should not inherit the same permissions simply because they share a brand.

A Role Handoff Standard

When one role hands work to another, pass four things: the current state, supporting evidence, unresolved uncertainty and permitted next action. An Assistant that prepares research for a Coworker should not imply that every source was verified. A Coworker that hands a case to an Agent should identify what the Agent may do. An Agent returning work to a human should distinguish actions completed from actions merely proposed.

State: what is true now?
Evidence: what supports that state?
Uncertainty: what remains unresolved?
Authority: what may the next role do?

The handoff standard prevents role boundaries from becoming information-loss boundaries. It also makes mixed systems easier to audit because the organisation can reconstruct how responsibility moved through the workflow.

Role Names Must Survive Product Change

Products change names, interfaces and model providers. A durable organisation should still be able to describe its operating design. If a vendor replaces one model with another, the role contract can remain: this system is a Copilot with read access to these sources and no autonomous send permission, or this system is an Agent authorised to perform these three reversible actions.

Stable role language therefore reduces lock-in at the conceptual level. The organisation’s workflow is defined by purpose, evidence and authority rather than by a vendor’s marketing vocabulary.

The Role Rule for the Next Article

Once a role is clear, the next question is not how powerful it can become. It is where delegation must stop. Some work can be delegated broadly, some only as preparation, and some should never be handed over blindly because the cost of error, accountability requirement or hidden context is too high.

That boundary is the subject of the next article: What Work Should Never Be Delegated Blindly to Super Intelligence? The role taxonomy provides the vocabulary; the delegation-boundary page will provide the stop rules.

Continue to the Delegation Boundary

Continue to What Work Should Never Be Delegated Blindly to Super Intelligence? to define where Assistant, Copilot, Coworker and Agent roles must stop, escalate or preserve human authority. Return to the Workplace Super Intelligence Hub for the complete route.

Super Intelligence as Assistant, Copilot, Coworker, Agent and Infrastructure | Workplace Roles Explained