The four levels of workplace Super Intelligence are Assist, Collaborate, Automate and Operate. The levels describe how deeply machine intelligence is integrated into work and how much operating responsibility the system receives. They are not a ranking of whether a company is “advanced” or “behind”. A low-risk writing task may remain at Assist permanently while a stable internal routing process moves to Automate. The correct level depends on the workflow.
This eduKateSG article owns the workplace SI maturity and autonomy ladder. The preceding guide, Where Does Super Intelligence Fit Inside a Workflow?, identifies where SI enters the process. This article asks the next question: once SI has a position, how much responsibility should that position receive?
The short answer is: Assist keeps the human as primary operator; Collaborate gives SI a substantial but supervised share of the cognitive work; Automate lets a repeatable workflow run from a trigger with bounded human checkpoints; Operate makes SI part of organisational infrastructure across connected systems, with humans governing outcomes, policy, exceptions and risk.
The Four Levels in One View
- Level 1 — Assist: the human performs the work and calls SI for local help.
- Level 2 — Collaborate: the human and SI divide meaningful portions of the work and iterate.
- Level 3 — Automate: a repeatable sequence can run from a trigger with defined controls and exceptions.
- Level 4 — Operate: SI becomes a maintained operating layer across knowledge, tools, workflows and organisational governance.
The ladder is about integration and authority, not raw model intelligence. The same model can appear at all four levels. What changes is the workflow surrounding it: context, triggers, tool access, permissions, human checkpoints, observability, measurement and ownership.
Why the Levels Matter
Without a maturity model, organisations often jump from isolated experimentation to ambitious automation because a demonstration looks impressive. The missing question is whether the process itself has earned more autonomy. A system can be capable of taking an action before the organisation is capable of governing that action.
The levels create a staged path. They let a team learn the task at Assist, standardise the human–SI handoff at Collaborate, prove repeatability at Automate and build shared infrastructure at Operate. A workflow can also move backward if evidence changes, risk increases or quality declines.
Level 1 — Assist
At the Assist level, the human remains the primary operator. The person chooses when to use SI, supplies most of the context, reads the output and decides what to do next. The system may draft, summarise, explain, compare, brainstorm, translate or help with code, but it does not own the workflow.
Assist is often the fastest way to start because it requires little integration. A professional can use SI beside existing tools without changing the official process. This is appropriate when the task is irregular, the user is learning what the system can do, context is difficult to formalise or the consequences of error make close human control valuable.
What the human does at Assist
- Defines the objective.
- Chooses the relevant context.
- Initiates every interaction.
- Checks the result directly.
- Transfers accepted work into the real system.
- Owns all consequential decisions and external actions.
What SI does at Assist
- Produces candidate drafts or explanations.
- Summarises supplied material.
- Generates alternatives.
- Helps organise thinking.
- Suggests questions, plans or checks.
- Supports local analysis without independently changing external systems.
The main Assist failure
The main failure is private productivity without organisational learning. One employee becomes excellent at using SI, but the method stays inside personal prompts or chat history. The organisation gains local speed but cannot reproduce, evaluate or maintain the capability.
The repair is not immediate automation. Capture useful instructions, examples, source requirements and checking habits. When a pattern repeats across cases or users, it may be ready for Collaborate.
Level 2 — Collaborate
At the Collaborate level, SI performs a substantial part of the task while the human directs, critiques, supplies additional context and makes consequential judgments. The interaction becomes an iterative working method rather than occasional assistance.
A manager may provide several project reports and ask SI to produce a structured risk brief, then challenge its assumptions and revise the result. A researcher may use SI to organise sources and compare evidence while personally judging methodology. A teacher may ask for candidate explanations and practice sequences while deciding what fits the learner.
What changes from Assist to Collaborate
The most important change is that the SI role becomes explicit. The team can say what the system owns inside the task. Context becomes more structured. Output standards become clearer. Human review becomes a defined operation rather than a general instruction to “check the AI”.
The Collaboration handoff
A strong collaboration has two handoffs. The human-to-SI handoff contains outcome, context, constraints and acceptance criteria. The SI-to-human handoff contains the result, evidence, assumptions, uncertainty and the decision or review required next.
The main Collaborate failure
The main failure is double work. The system produces an output, but the reviewer must redo the whole task to verify it. The organisation has added another production layer instead of reducing work.
Repair by narrowing the system’s role, improving source visibility, structuring output or adding deterministic checks. Collaboration is successful when human effort shifts toward high-value judgment rather than complete reconstruction.
Level 3 — Automate
At the Automate level, the workflow can begin from a trigger and progress through a predefined sequence without a person manually initiating each step. SI interprets or transforms information inside the sequence, while rules, software and human checkpoints control progression.
Automation is not the same as autonomy. A workflow can be highly automated while following a fixed path. For example, an incoming support request can be classified, matched to approved knowledge, drafted and routed for review automatically. The model may never choose an unconstrained goal or invent its own process.
What changes from Collaborate to Automate
- A trigger starts the workflow.
- Inputs are standardised enough for the system to process repeatedly.
- Eligibility rules define which cases enter the automated path.
- Exceptions leave the routine path deliberately.
- Verification is built into the process.
- Tool permissions are defined.
- Logs show important actions and outcomes.
- The system has a closure signal rather than merely an output.
The main Automate failure
The main failure is scaling an unstable process. Automation can make mistakes faster, bury ambiguous cases inside routine throughput or create review queues that exceed human capacity.
Repair by tightening eligibility, improving validation, reducing tool authority, adding better escalation and measuring the end-to-end workflow. A workflow should move back toward Collaborate if operators cannot explain or recover failures reliably.
Level 4 — Operate
At the Operate level, SI becomes part of organisational infrastructure. Multiple workflows may share approved knowledge, identity, permissions, evaluation, monitoring and governance. Humans supervise performance, policy, incidents and exceptions rather than manually initiating every case.
Operate does not mean a company runs itself. It means machine intelligence is treated like an operating layer: maintained, measured and integrated across systems. The organisation knows which workflows exist, who owns them, what they can access, how they are evaluated, and what happens when something goes wrong.
What changes from Automate to Operate
- Several workflows share infrastructure rather than existing as isolated automations.
- Knowledge sources have explicit owners and lifecycle management.
- Identity and permissions are centrally governed.
- Evaluation continues after deployment.
- Incidents and rollback have formal routes.
- Costs and performance are measured across a portfolio.
- Human roles are redesigned around supervision, exceptions, judgment and improvement.
- Architecture can include agents when conditional multi-step behaviour genuinely adds value.
The main Operate failure
The main failure is distributed opacity. Many automated or agentic components interact, but nobody can see how responsibility, data, tools and decisions connect. A problem can cross several systems before an owner notices it.
Repair requires observability, clear workflow ownership, permission boundaries, versioning and portfolio-level governance. Operate should make the organisation more understandable, not less.
The Levels Are Not a Race
A mature organisation can intentionally keep some work at Assist or Collaborate. High-consequence, relationship-sensitive or rapidly changing tasks may benefit from machine preparation without benefiting from autonomous action. A fixed deterministic process may remain simpler and safer than an agent.
The goal is not “get everything to Level 4”. The goal is to put each workflow at the level where the combination of human judgment, machine capability, controls and economics produces the best reliable outcome.
Six Dimensions That Change Across the Levels
Initiation
At Assist, the person starts every interaction. At Collaborate, initiation remains human but the task division is standardised. At Automate, a trigger can start the sequence. At Operate, many triggers feed maintained workflow infrastructure.
Context
At Assist, context is often supplied manually. At Collaborate, context packets and approved sources become repeatable. At Automate, retrieval is connected to the process. At Operate, organisational knowledge has owners, permissions and lifecycle management.
Tool access
Assist may have none. Collaborate can use user-mediated tools. Automate requires bounded system access. Operate requires organisation-wide identity, least privilege, monitoring and recovery.
Human role
Assist keeps the human as operator. Collaborate makes the human director and reviewer. Automate concentrates human attention on approval and exceptions. Operate shifts more attention toward governance, policy, system improvement and high-consequence judgment.
Verification
Assist relies mostly on direct user checking. Collaborate standardises review. Automate embeds validation and sampling. Operate manages evaluation across workflows and versions.
Measurement
Assist often begins with personal usefulness. Collaborate measures task quality and human effort. Automate measures throughput, errors, exceptions and closure. Operate adds portfolio cost, incident, capability and organisational outcome measures.
Promotion Gates Between Levels
A workflow should move upward only when the next level solves a real problem and the current level has produced enough evidence. Promotion is a design decision, not a reward for enthusiasm.
Assist → Collaborate gate
- The task repeats often enough to standardise.
- More than one user can describe the same desired outcome.
- Useful context can be identified explicitly.
- Quality can be evaluated against examples or a rubric.
- The SI role can be bounded inside the task.
Collaborate → Automate gate
- The sequence is stable enough to trigger predictably.
- Inputs and outputs can be structured.
- Common exceptions are recognisable.
- Verification can occur without redoing the whole task.
- Permissions can be bounded.
- Failure and closure states are observable.
Automate → Operate gate
- The automation has demonstrated stable value across real cases.
- Several workflows need shared knowledge, tools or governance.
- Owners exist for process, knowledge and technical infrastructure.
- Monitoring and incident response can scale.
- The organisation can maintain versions, permissions and evaluation over time.
Demotion Gates Matter Too
A workflow should move down a level when error patterns rise, context becomes unreliable, regulation changes, the consequence of action increases, review capacity collapses, tool permissions expand faster than governance, or the system becomes too opaque to supervise.
Demotion is not failure. It is control. Returning an automation to human approval can be the correct response to changed conditions.
Same Workflow, Four Levels: Customer Support
Assist
The agent pastes the customer’s message and asks SI for a draft. The employee retrieves account context manually, reviews the response and sends it.
Collaborate
SI receives a standard context packet, summarises history, retrieves approved knowledge and drafts a reply. The human checks policy and relationship-sensitive details, then edits or approves.
Automate
An incoming request triggers classification, retrieval and draft generation automatically. Routine low-risk cases may be sent after defined checks; uncertain or high-value cases enter a human queue.
Operate
Support SI shares knowledge infrastructure with onboarding and internal search, uses centrally managed permissions, is continuously evaluated, feeds recurring knowledge gaps back to owners and participates in portfolio-level incident and cost management.
Same Workflow, Four Levels: Weekly Reporting
Assist
The manager asks SI to rewrite notes into a clearer report.
Collaborate
The manager supplies project updates in a standard format; SI compares them with milestones, flags inconsistencies and prepares a decision-oriented brief.
Automate
The reporting deadline triggers collection from approved systems. Missing updates are requested, the report is assembled and a draft reaches the manager for review.
Operate
Several reporting workflows share project data, taxonomy, access controls and evaluation. Leadership receives consistent cross-functional views while process owners maintain the underlying definitions.
Same Workflow, Four Levels: Software Development
Assist
An engineer asks SI to explain code or generate a function.
Collaborate
The system reads a bounded code context, proposes changes and tests, and the engineer iterates with it.
Automate
A defined issue can trigger an automated branch change, test suite and review packet. Merge or deployment remains behind explicit gates.
Operate
Coding agents, test systems, repositories and deployment controls are integrated into a governed engineering platform with role-based permissions, observability, evaluation and incident handling.
Same Workflow, Four Levels: Research
Assist
The researcher asks for search terms or a summary of supplied material.
Collaborate
SI helps organise a corpus, extract study characteristics and compare evidence while the researcher judges methodology and source quality.
Automate
A recurring research monitor collects defined sources, deduplicates material, prepares summaries and routes relevant items according to explicit criteria.
Operate
Research retrieval, knowledge management, citation checks and monitoring share maintained infrastructure, permissions and evaluation across teams.
Same Workflow, Four Levels: Education and Training
Assist
A teacher asks SI for alternate examples or a worksheet draft.
Collaborate
The teacher provides learner context and a misconception; SI proposes a sequence, and the teacher checks correctness and pedagogical fit.
Automate
Routine practice generation can respond to validated learner signals, while the teacher reviews exceptions and higher-consequence instructional decisions.
Operate
Learning content, progress signals, knowledge resources and teacher workflows share governed infrastructure, while educators remain accountable for learning design and student relationships.
Permissions Across the Four Levels
Permissions should expand more slowly than capability. At Assist, the user can mediate most data and actions manually. Collaborate may justify read access to approved sources. Automate may need narrowly scoped write permissions. Operate requires identity, least privilege, logs, review and recovery across a portfolio.
The principle is to separate see, infer, recommend, prepare and act. A workflow can advance in sophistication without granting all five at once.
Knowledge Across the Four Levels
Assist can tolerate manual context selection because the user is present. Collaborate benefits from standard source packs. Automate requires machine-retrievable current knowledge. Operate requires the organisation to manage canonical sources, ownership, versioning, retention and permissions as infrastructure.
This is why weak knowledge management becomes more expensive at higher levels. The more automatically the system moves, the less opportunity a human has to notice that a source is stale or contradictory.
Human Review Across the Four Levels
At Assist, review is continuous because the user is operating the task. At Collaborate, review becomes a structured handoff. At Automate, humans may review selected cases, approvals or exceptions. At Operate, review includes system-level oversight: sampled quality, incident patterns, drift, cost and policy.
Higher levels do not eliminate human involvement; they change where human attention sits.
NIST and the Maturity Ladder
NIST’s AI Risk Management Framework and Generative AI Profile organise risk management around governance, mapping, measurement and management across the AI lifecycle. That lifecycle view supports a staged maturity model because risk management must evolve as use moves from local assistance toward connected deployment and sustained operation. See NIST AI 600-1.
IMDA and Agentic Progression
Singapore’s updated Model AI Governance Framework for Agentic AI emphasises bounding agents’ powers, using technical and non-technical controls and maintaining human accountability. These concerns become increasingly important as a workplace moves from Collaborate into Automate and Operate, where systems can invoke tools and take actions. See IMDA’s updated framework.
The Level-Mismatch Problem
Many failures are level mismatches. A Level-1 process is given Level-3 authority before inputs and review are stable. A Level-3 automation is managed with Level-1 habits, so nobody owns monitoring or exceptions. A Level-4 architecture is built for a task whose value could have been achieved with a simple Level-2 collaboration.
The cure is to define the minimum sufficient level. More autonomy should solve a specific operating problem: latency, volume, coordination or repetitive orchestration. If it does not, keep the simpler design.
What This Article Owns
This article owns the Assist → Collaborate → Automate → Operate maturity ladder. The workflow-position article owns where SI sits. The next article will own role identity—Assistant, Copilot, Coworker, Agent and Infrastructure—and explain why those labels should describe operating relationships rather than marketing categories.
A Level-Selection Audit
- Name the workflow and its accepted outcome.
- Identify the current SI position.
- Describe how the work is initiated today.
- List the context that must be available.
- State what the human currently reviews or decides.
- List any external tools or actions.
- Describe common exceptions.
- Identify the current closure signal.
- Measure the current workflow.
- Ask what problem a higher level would solve.
- Define what new control the higher level would require.
- Decide whether the value justifies the additional complexity.
Frequently Asked Questions
Is Assist a beginner level?
It is often an entry point, but it can also be the permanent correct design for irregular, high-judgment or sensitive tasks.
Does Collaborate mean a human must edit every output?
No. The human must perform the meaningful judgment or verification required by the workflow. Editing for its own sake is not the objective.
Does Automate mean no humans?
No. Automation can include human approvals, exception queues and monitoring. It means the routine sequence can progress from a trigger without manual initiation at every step.
Does Operate mean autonomous company?
No. Operate means SI is maintained as organisational infrastructure across workflows, knowledge, permissions, evaluation and governance.
Should every workflow progress through all four levels?
No. Many should stop at Assist or Collaborate. The correct level depends on value, stability, risk, verification and economics.
Can a workflow move backwards?
Yes. It should move down when conditions change or evidence no longer supports the current autonomy level.
What should I read next?
Continue to SI as Assistant, Copilot, Coworker, Agent and Infrastructure. That article maps the human-facing and system-facing roles that appear across these four levels.
The Core Rule
Use the lowest level that reliably achieves the outcome, and increase autonomy only when a higher level solves a real workflow problem and the organisation can support the additional context, permissions, verification, monitoring and recovery.
Assist, Collaborate, Automate and Operate are therefore not four badges of sophistication. They are four operating relationships between people, Super Intelligence and the workflow. The right level is the one that creates useful capacity while keeping responsibility and evidence visible.
The Four Levels Change the Human Job
The maturity ladder is not only a technology ladder. Each level changes what the person does. At Assist, the worker spends most of the time performing the task and occasionally calls SI. At Collaborate, the worker spends more time directing, supplying context and judging. At Automate, the worker increasingly manages exceptions and approvals. At Operate, some people shift toward policy, monitoring, knowledge stewardship, evaluation and system improvement.
If management introduces a higher SI level without redesigning the human role, employees can end up with the old workload plus new review responsibilities. That is not transformation; it is layering. The organisation should explicitly decide which human activities disappear, which remain critical and which new capabilities become possible.
Level 1 Assist in Greater Detail
Assist is the broadest level because it can appear almost anywhere a person already works. The employee may use SI for idea generation before a task, explanation during a task or editing after a task. The user decides whether the output is useful and transfers accepted work manually into the next system.
The strength of Assist is reversibility. The user can discard a poor answer with little external consequence. It also supports learning because the employee sees failure directly. The weakness is inconsistency: different users provide different context, apply different checking standards and discover useful patterns that may never become shared organisational assets.
Good Assist use cases
- Summarising a document the user already has authority to read.
- Generating alternative explanations, outlines or draft structures.
- Comparing two supplied documents.
- Helping an employee formulate questions before a meeting.
- Explaining code, formulas or unfamiliar terminology.
- Creating a first draft that the user fully reviews before release.
Assist does not require workflow redesign
A team can benefit from Assist while leaving the official workflow unchanged. That can be desirable during exploration. However, if a task repeats frequently and the same successful pattern appears across users, the organisation should consider whether the method deserves standardisation at Collaborate.
Level 2 Collaborate in Greater Detail
Collaborate begins when the task division becomes intentional. The team knows what SI should do, what the person should do and how the two parts connect. Instead of each employee inventing a prompt, the organisation can maintain reusable instructions, context packets, examples and review criteria.
Collaboration is often the sweet spot for complex knowledge work. The system absorbs high-volume information processing while the human retains judgment, accountability and domain interpretation. The workflow gains consistency without forcing every case into automation.
Collaboration is iterative
The human can challenge the output, add context, ask the system to compare alternatives and request revisions. Iteration is not failure. Many professional tasks are naturally iterative. The important question is whether each cycle moves the work toward an accepted state without excessive rework.
Collaboration needs a shared language
Teams should agree on what words such as “draft”, “approved”, “current”, “priority”, “risk” and “complete” mean inside the workflow. Hidden differences in terminology can make the same instruction produce inconsistent results across departments.
Level 3 Automate in Greater Detail
Automation requires the organisation to convert part of the workflow into machine-readable structure. The trigger must be observable. Inputs must be accessible. Eligibility must be defined. The next state must be known. Exceptions must have destinations. Closure must return from the real system.
This does not mean every step is intelligent. Strong automated workflows combine deterministic logic and SI. Rules handle exact conditions, schemas validate structure, software executes known operations and SI handles interpretation or generation where language and ambiguity matter.
Automation should shrink uncertainty
The automated path should contain the cases the organisation understands best. Unusual or high-consequence cases can leave the routine path. This produces a safer progression than trying to make the system solve every edge case before deployment.
Automation changes the economics of error
When a person manually processes ten cases, an occasional mistake may remain local. An automated workflow can process thousands. Even a low error rate can create material volume. Monitoring, sampling and rollback therefore become more important as throughput rises.
Level 4 Operate in Greater Detail
Operate is a system-of-systems level. The organisation no longer thinks of each SI workflow as a separate experiment. Shared knowledge, access controls, evaluation, incident response and cost management support many processes. Some components may be agentic; others remain fixed workflows or assistive interfaces.
The value of Operate is reuse. One approved knowledge layer can serve support, onboarding and internal search. One identity and permission system can constrain many agents. One evaluation practice can detect regressions across a portfolio. The risk is coupling: a bad source, permission change or platform failure can affect several workflows at once.
Operate requires platform thinking
Platform thinking asks what should be central and what should remain local. Identity, logging, security policy, model access, knowledge governance and incident handling may benefit from shared infrastructure. Task-specific prompts, rubrics and exceptions may remain close to the process owner.
Maturity Is Not the Same as Capability
A powerful model does not automatically create a Level-4 workplace. An organisation can use a state-of-the-art system at Assist. Conversely, a modest model can operate inside a mature Level-3 automation if the task is narrow, sources are reliable and controls are strong.
This distinction protects planning from vendor-driven thinking. The maturity question is organisational: how repeatable, connected, observable and governed is the use of intelligence?
Maturity Is Not the Same as Autonomy
A workflow can be highly mature and intentionally low-autonomy. A legal research system may be deeply integrated, carefully evaluated and widely used while remaining read-only and human-led because the organisation wants professional interpretation to stay explicit.
Likewise, a small low-risk automation may have high autonomy inside a narrow task without representing broad organisational maturity. The ladder describes the relationship among autonomy, integration and operating infrastructure, but those dimensions do not always increase at exactly the same speed.
A Second Axis: Consequence
The same level should be designed differently depending on consequence. Level-3 automation for internal document tagging can tolerate different controls from Level-3 automation for financial transactions. The maturity model should therefore be read alongside consequence, reversibility and verifiability.
A practical portfolio map can place workflows on two axes: operating level on one axis and consequence on the other. High-level, high-consequence workflows deserve the strongest monitoring, approval and incident readiness.
A Third Axis: Variability
Stable repetitive work is easier to automate than work whose rules change constantly. Variability can come from customers, regulation, product complexity, data quality or human negotiation. High variability pushes the workflow toward Assist or Collaborate unless strong exception mechanisms exist.
When variability decreases because the organisation standardises intake or documentation, a task may become a better automation candidate without any model improvement.
A Fourth Axis: Verification Cost
If checking output costs almost as much as doing the task manually, the business case for a higher level weakens. Collaboration may still be useful for idea generation or breadth, but automation should wait until verification becomes more efficient.
Verification cost can fall through better source links, structured output, deterministic validation, test suites or a narrower task. Improving the review system can therefore promote a workflow even when the model stays the same.
A Fifth Axis: Recovery Capacity
A workflow should not receive more autonomy than the organisation can recover from. If errors are easy to detect and reverse, promotion can be less risky. If a mistake affects safety, reputation, rights or irreversible external state, recovery is weaker and the autonomy threshold should be higher.
Promotion Case Study: Internal Knowledge Search
Assist stage
Employees paste snippets of internal documents into SI and ask questions. This proves that natural-language access is useful, but source selection is manual and inconsistent.
Collaborate stage
The team creates approved source packs and standard instructions requiring answers to cite evidence. Employees use a shared method and report recurring gaps.
Automate stage
A retrieval layer connects to authorised repositories, applies role permissions and automatically returns grounded answers with sources. Unsupported questions escalate to knowledge owners.
Operate stage
The knowledge layer serves several workflows, has canonical source ownership, monitors stale content and feeds unanswered questions into documentation improvement. Search becomes maintained infrastructure rather than a single chatbot.
Promotion Case Study: Sales Follow-Up
Assist stage
The salesperson asks SI to rewrite follow-up messages from personal notes.
Collaborate stage
A standard context packet includes customer objective, agreed commitments, open questions and next meeting. SI drafts; the salesperson checks and sends.
Automate stage
After an approved meeting transcript or note is available, the system prepares a follow-up draft and creates a reminder automatically. Sending remains human-approved.
Operate stage
Account research, meeting preparation, follow-up and CRM hygiene share governed knowledge and permissions across the sales organisation, with monitoring for unsupported claims and missed commitments.
Promotion Case Study: Finance Commentary
Assist stage
An accountant asks SI to improve wording around a variance explanation.
Collaborate stage
The system receives approved figures and supporting schedules, then drafts a narrative with source references. The accountant validates the interpretation.
Automate stage
The reporting cycle triggers retrieval of authorised figures and production of draft commentary, with deterministic reconciliation and exception flags before review.
Operate stage
Reporting workflows share data definitions, source controls, versioning, review policies and audit records across finance, while authoritative numbers remain in financial systems.
Promotion Case Study: Marketing
Assist stage
A marketer asks for headline or copy variants.
Collaborate stage
SI works from approved product claims, audience research and brand guidance while humans direct strategy and select outputs.
Automate stage
Low-risk repurposing and formatting can run automatically after a source asset is approved. External publishing remains behind editorial checks where appropriate.
Operate stage
Content operations, asset management, analytics and knowledge share governed infrastructure while brand, factual accountability and campaign strategy remain human-led.
Promotion Case Study: IT Service Desk
Assist stage
An analyst asks SI for troubleshooting suggestions.
Collaborate stage
SI retrieves approved runbooks, summarises the case and proposes steps while the analyst executes them.
Automate stage
Routine known issues trigger classification, information gathering and bounded fixes; security-sensitive or privileged actions escalate.
Operate stage
Service workflows share identity, logs, monitoring and incident management. Automation performance and exception patterns are managed as operational infrastructure.
Promotion Case Study: Procurement
Assist stage
A buyer asks SI to summarise proposals.
Collaborate stage
SI extracts comparable fields with source references while the buyer defines evaluation criteria.
Automate stage
New proposals trigger extraction, validation and a draft comparison packet. Missing terms automatically generate clarification requests for review.
Operate stage
Supplier knowledge, contract repositories, evaluation standards and procurement workflows share controlled access and auditability while award authority remains within governance.
Promotion Case Study: Education
Assist stage
A teacher asks for examples or practice questions.
Collaborate stage
SI uses a learner profile and curriculum objective to propose a practice sequence; the teacher validates it.
Automate stage
Validated low-risk practice can respond to observed performance signals while unusual misconceptions and higher-stakes decisions return to the teacher.
Operate stage
Learning resources, progress signals and teacher workflows share governed infrastructure, but educational purpose and learner relationships remain human responsibilities.
Promotion Case Study: Legal Research
Assist stage
A lawyer uses SI to summarise supplied material.
Collaborate stage
The system retrieves approved sources and creates an issue map with citations; the professional interprets law and strategy.
Automate stage
Recurring monitoring or document comparison can run automatically, with new developments routed for professional review.
Operate stage
Research, document comparison, knowledge management and matter workflows share secure infrastructure while legal judgment remains explicitly professional.
Promotion Case Study: Software Engineering
Assist stage
Developers ask for explanations or code snippets.
Collaborate stage
SI reads bounded repository context, proposes changes and tests, and iterates with engineers.
Automate stage
Defined issues can trigger branch creation, code changes, tests and review packets. Merge and deployment use explicit gates.
Operate stage
Coding agents, repositories, CI/CD, security controls and observability form a governed engineering platform with portfolio-level monitoring.
Promotion Case Study: Executive Briefing
Assist stage
An executive asks SI to summarise one report.
Collaborate stage
SI assembles several reports, distinguishes facts from interpretations and prepares a structured decision brief.
Automate stage
Recurring briefings can collect approved data automatically, flag missing submissions and deliver a reviewable pack on schedule.
Operate stage
Leadership reporting shares definitions, data sources, access controls and portfolio monitoring while executives retain strategic judgment.
The Architecture at Each Level
Assist architecture
User interface + model + manually supplied context. External tools may be absent or mediated by the user. Logs and evaluation are limited.
Collaborate architecture
Model + reusable instructions + approved context + examples + structured review. Some retrieval or tools may be available, but the human remains closely involved.
Automate architecture
Trigger + orchestration + SI component + deterministic validation + bounded tools + exception queue + closure signal + logs.
Operate architecture
Shared identity + knowledge + model access + orchestration + agent/workflow components + observability + evaluation + incident response + governance + cost management.
The Permission Ladder
- Read supplied data: the user manually provides context.
- Retrieve approved data: the system can read bounded sources.
- Prepare external change: SI creates a draft or staged action.
- Execute low-risk action: the system can change state inside narrow conditions.
- Orchestrate multiple actions: the workflow can use several tools toward a bounded objective.
- Portfolio operation: shared identity and policy govern many workflows.
The permission ladder should normally advance more slowly than the capability ladder. The fact that a model can use a tool does not establish that it should.
The Monitoring Ladder
Assist is monitored mostly by the user noticing problems. Collaborate adds review data and shared correction patterns. Automate requires runtime logs, exception rates and outcome metrics. Operate requires portfolio monitoring, incident analysis, version tracking and cross-workflow dependencies.
The Evaluation Ladder
At Assist, evaluation may begin with task usefulness. At Collaborate, compare accepted output and human effort. At Automate, use representative test sets, live sampling, exception analysis and closure metrics. At Operate, evaluation must survive model and workflow updates across many processes.
The Cost Ladder
Assist has low integration cost but can create duplicated individual effort. Collaborate invests in standardisation. Automate adds engineering, monitoring and exception-handling cost. Operate adds platform and governance cost but can spread those investments across many workflows.
The correct business case considers total cost of ownership, not only model usage. A higher level is justified when shared infrastructure and reduced repetitive work outweigh the extra complexity.
Failure Mode: Level Inflation
Teams sometimes call a simple assistant an “agent” or a fixed automation “autonomous” because the label sounds advanced. This creates confusion about permissions and risk. Name the operating relationship accurately. A clear Level-2 collaboration is more useful than a mislabeled Level-4 claim.
Failure Mode: Autonomy Before Observability
A workflow receives tool access before the team can reconstruct actions. When something fails, nobody knows what state changed. Reduce autonomy, add logs and require world-return evidence before promotion.
Failure Mode: Automation Before Standardisation
Different employees still perform the task in incompatible ways, yet the organisation tries to encode one automated path. Stabilise inputs, definitions and acceptance criteria first.
Failure Mode: Operating Without Owners
Several SI workflows exist, but nobody owns knowledge freshness, evaluation or exceptions. Assign process, knowledge and technical ownership. Shared infrastructure without shared responsibility creates drift.
Failure Mode: Review Theatre
The workflow technically includes human approval, but reviewers see too many cases or lack evidence. Redesign review around high-risk fields, source visibility and manageable queues. A checkbox is not meaningful oversight.
Failure Mode: No Demotion Path
The organisation can promote automation but has no simple way to reduce authority after an incident. Build configuration and operational procedures that can return cases to human review quickly.
A 90-Day Level Progression Plan
Days 1–30 — Assist and observe
Choose one recurring workflow. Use SI in a bounded assistive role. Record context requirements, corrections and actual time saved. Do not automate external action.
Days 31–60 — Collaborate and standardise
Create shared instructions, approved sources, output formats and review criteria. Test across users and representative cases. Decide which exceptions remain human-led.
Days 61–90 — Automate selectively
Automate only the stable path. Add triggers, validation, permissions, logs, exception routing and closure signals. Measure the complete workflow against the improved human baseline.
Do not force Level 4 into a 90-day schedule. Operate is justified when several dependable workflows create a real need for shared infrastructure and governance.
Portfolio Management at Operate
When many workflows exist, treat them as a portfolio. Each should have an owner, level, consequence rating, data classification, tool permissions, model dependency, evaluation method and review trigger. This makes the organisational surface visible.
- Which workflows can change external state?
- Which use sensitive or regulated information?
- Which share the same knowledge source?
- Which depend on the same external platform?
- Which have the highest exception or incident rate?
- Which no longer create enough value to justify maintenance?
- Which could move down a level and become simpler?
- Which repeated infrastructure needs should become shared services?
Small Business: The Four Levels
A small business does not need enterprise architecture to benefit from the model. Assist can create immediate capacity. Collaborate can standardise recurring customer, marketing or administrative work. Automate can handle narrow routine follow-up. Operate may simply mean a small set of maintained connected workflows with clear owners rather than a large platform team.
The principle scales down: use the lowest sufficient level, keep permissions narrow and make sure the owner can understand the process.
Large Organisation: The Four Levels
Large organisations face the opposite problem: hundreds of independent experiments can emerge before governance or knowledge architecture catches up. The maturity ladder helps classify the portfolio and prevent every team from building its own identity, retrieval and monitoring stack.
Shared infrastructure should enable safe local innovation rather than centralise every prompt. Process owners need room to tune task-specific instructions while common access, logging and risk standards remain coherent.
When to Stop at Collaborate
Stop at Collaborate when the task is highly judgment-heavy, context changes rapidly, verification remains expensive, external actions are high-consequence or the volume does not justify automation engineering. A well-designed collaboration can be a mature endpoint.
When to Stop at Automate
Stop at Automate when the workflow path is stable and fixed orchestration is enough. Do not add agentic freedom merely because agents are available. Anthropic’s engineering guidance explicitly distinguishes fixed workflows from agents and recommends matching complexity to need. See Building Effective Agents.
When Operate Becomes Necessary
Operate becomes necessary when the organisation can no longer manage SI as separate local tools. Shared knowledge, permissions, model access, monitoring, evaluation, incident response and cost management become more efficient and safer when treated as common infrastructure.
The Maturity Review Meeting
A quarterly or otherwise appropriate maturity review can ask each workflow owner to justify its current level. Has the workflow improved the intended outcome? Are exceptions manageable? Has the risk profile changed? Are users bypassing controls? Would a lower level be simpler? Would a higher level solve a measured bottleneck?
This keeps autonomy linked to evidence rather than organisational fashion.
The Promotion Record
Before increasing a workflow’s level, record the reason, evidence, new permissions, new failure modes, required monitoring and rollback plan. This lightweight record helps future operators understand why autonomy expanded and what would cause it to shrink again.
The Core Maturity Principle
The four levels are best understood as a control system. Assist maximises direct human control. Collaborate creates repeatable human–machine division of labour. Automate creates repeatable machine-executed sequence with bounded human checkpoints. Operate creates maintained organisational infrastructure around those workflows.
The movement upward should always add enough value to justify the additional coupling, permissions and maintenance. Maturity is not how little humans do. Maturity is how deliberately the organisation allocates work, authority and evidence.
Level Selection by Work Type
High-volume administrative work
These tasks often have clear triggers, repeated patterns and observable end states. They may progress from Assist to Automate relatively quickly if data quality and exception handling are good. Examples include routine classification, document routing, meeting follow-up and standard status reporting. The main gate is whether automation actually removes work rather than creating a larger review queue.
Expert analytical work
Analysis can benefit greatly from Collaborate because SI can increase breadth while the expert retains interpretation. Full automation is less attractive when the evidence is disputed, methodology matters or conclusions affect consequential decisions. The system can still automate preparation, retrieval and formatting around a human-led core.
Relationship-intensive work
Sales negotiation, coaching, management conversations and sensitive customer interactions often remain Assist or Collaborate. SI can prepare context and draft options, but trust and interpersonal judgment remain central. Automation can still handle administrative tail work before or after the human interaction.
Deterministic operations
If a task follows exact rules and software already performs it reliably, SI may not be needed at the core. It can help interpret natural-language inputs or explain exceptions, while deterministic systems retain calculation and execution. A mature workflow can therefore be Level 3 without asking the model to do every step.
Creative production
Creative work often sits well at Collaborate: SI expands options and reduces blank-page cost while humans direct intent, taste and selection. Automation may suit low-risk repurposing after a source asset is approved. Operate becomes relevant when content workflows share brand knowledge, assets and governance.
High-consequence professional work
Legal, medical, financial, security and employment contexts can use SI extensively in preparation and analysis while keeping consequential judgment with qualified humans. Higher levels require stronger evidence, accountability and domain-specific governance.
The Four Levels and Organisational Memory
At Assist, learning is often trapped inside individual use. At Collaborate, the organisation begins converting successful interactions into reusable prompts, examples and source packs. At Automate, the process itself becomes organisational memory because the sequence, checks and exceptions are encoded. At Operate, knowledge about both the business and the SI systems is maintained as infrastructure.
This progression can be valuable even before productivity gains are large. The effort required to automate a workflow often forces the organisation to clarify terminology, source ownership and exception handling. Those improvements can benefit human work as well.
The Four Levels and Capability Atrophy
As SI assumes more routine work, humans practise some skills less often. At Assist, the employee usually remains close to the underlying task. At Collaborate, the human may still exercise the core judgment while delegating production. At Automate and Operate, some workers may see only exceptions.
The organisation should identify which capabilities must remain strong for verification, recovery and future development. Training, simulation, explanation requirements and periodic manual practice may be justified for critical skills. Higher automation does not automatically mean human expertise is no longer needed.
The Four Levels and New Employee Training
Assist can act as an on-demand tutor for new employees, but beginners may not know when the answer is wrong. Collaborate can pair SI with approved sources and explicit examples. Automate can remove routine tasks from the beginner’s workload, which may be helpful for productivity but can also remove learning opportunities.
At Operate, organisations should deliberately design how people learn the system they are expected to supervise. A reviewer who has never performed the underlying task may struggle to detect subtle failures. Training should develop domain understanding, not only interface familiarity.
The Four Levels and Management Span
Automation can change how many cases, projects or customers one manager can oversee, but it can also increase the number of machine-generated signals demanding attention. The organisation should measure whether higher levels actually reduce managerial cognitive load.
A good Level-3 workflow routes only meaningful exceptions. A poor one creates alerts for every uncertainty. Operate should improve signal quality and prioritisation across systems rather than simply give managers more dashboards.
The Four Levels and Data Quality
Assist can sometimes tolerate messy data because the human notices and compensates. Collaborate starts to expose repeated data problems. Automate is much less forgiving because bad data can move through the process without being challenged. Operate magnifies shared data weaknesses across several workflows.
This means data quality often becomes the real promotion gate. If the organisation cannot identify which field, document or record is authoritative, more autonomy should wait.
The Four Levels and Change Management
At Assist, change management is mostly about safe use and skill. Collaborate requires team norms and shared methods. Automate changes jobs, queues and handoffs, so process communication becomes important. Operate changes organisational infrastructure and may require governance roles, platform ownership and portfolio review.
The communication should explain what employees should stop doing as well as what they should start doing. Otherwise, the new system becomes additional work layered on top of legacy habits.
The Four Levels and Incentives
Metrics can accidentally drive the wrong maturity. If teams are rewarded for the number of automated workflows, they may automate unsuitable work. If employees are judged on prompt volume, they may generate unnecessary content. Incentives should focus on accepted outcomes, quality, service and reliable capacity.
The maturity ladder should be a decision framework rather than a target count. A team that intentionally keeps a sensitive workflow at Collaborate may be making a more mature choice than one that forces it to Operate.
The Four Levels and Vendor Lock-In
Assist can usually switch models or tools relatively easily. Collaborate begins to accumulate reusable instructions and context structures. Automate can depend on APIs, tool schemas and orchestration. Operate may create significant platform dependencies.
The higher the level, the more the organisation should separate durable business logic from vendor-specific details where practical. Workflow objectives, acceptance criteria, source ownership and permissions should remain understandable even if the underlying model changes.
The Four Levels and Business Continuity
At Assist, a tool outage may inconvenience individual work. At Automate or Operate, an outage can stop a business process. Higher levels therefore need continuity planning: fallbacks, manual procedures, queue handling and clear communication.
A workflow should know what happens when the model, retrieval service or external tool is unavailable. If nobody can operate the process without the SI layer, that dependency should be deliberate and protected.
The Four Levels and Security
Security exposure grows as the system gains data and tools. Assist may involve only user-supplied information. Collaborate may retrieve internal knowledge. Automate may connect to operational systems. Operate may coordinate across many permissions and workflows.
Least privilege, input validation, prompt-injection resistance, secret handling, logging and incident response become progressively more important. Security is therefore not one final governance layer; it expands alongside maturity.
The Four Levels and Prompt Injection
A read-only assistant that summarises trusted internal text has a different injection risk from an agent that reads untrusted web content and can use email or code tools. As workflows move toward Automate and Operate, the organisation should treat retrieved content as data that may contain malicious or conflicting instructions rather than automatically as trustworthy commands.
Later articles in this series own prompt injection and tool security in depth, but the maturity implication is immediate: higher autonomy requires stronger separation between content and authority.
The Four Levels and Evaluation Sets
At Assist, users can report poor outputs informally. Collaborate should retain examples of accepted and rejected work. Automate benefits from a representative evaluation set containing normal, difficult and should-escalate cases. Operate needs versioned evaluation that can be rerun after changes across a portfolio.
The test set should include abstention and exception behaviour, not only successful answers. A mature workflow must demonstrate that it knows when not to proceed.
The Four Levels and Return on Investment
ROI changes by level. Assist may save minutes for one employee. Collaborate may improve quality and reduce rework across a team. Automate can change throughput and staffing capacity. Operate can create platform-level reuse but also carries significant engineering and governance cost.
Compare like with like. Time released is not automatically cash saved. A platform investment should be justified by several durable workflows, not one demonstration. Higher maturity needs a larger benefit base because maintenance obligations grow.
The Four Levels and Organisational Learning Rate
A useful way to judge maturity is how quickly the organisation converts observed failure into system improvement. At Assist, one user may simply correct an answer. At Collaborate, the team updates a shared instruction. At Automate, the workflow changes its validation or routing. At Operate, the organisation can detect a cross-cutting source or platform issue affecting many workflows.
The speed and quality of this repair loop may matter more than the initial error rate because every real deployment encounters edge cases. Mature organisations learn without losing accountability.
Worked Example: One Employee’s Inbox
At Assist, the employee asks SI to summarise long threads and draft replies. At Collaborate, the team defines categories, priority signals and response standards. At Automate, incoming messages can be triaged and routine drafts prepared. At Operate, email workflows share identity, CRM context, monitoring and organisational knowledge across roles.
The appropriate stopping point depends on consequence. A general administrative inbox may automate heavily. An executive or legal inbox may remain more human-led even with sophisticated context and retrieval.
Worked Example: Meeting Follow-Up
At Assist, a participant asks SI to turn notes into actions. At Collaborate, the meeting has a standard decision/action format. At Automate, approved transcripts trigger action extraction, task creation and draft follow-up. At Operate, meeting outputs connect consistently to project, CRM and knowledge systems.
The key risk is false commitment: a speculative discussion becomes a recorded decision. Higher levels require explicit confirmation logic.
Worked Example: Policy Questions
At Assist, an employee pastes a policy and asks for an explanation. At Collaborate, SI works from approved sources and cites passages. At Automate, employees query a role-aware knowledge system directly. At Operate, policy retrieval, source ownership, stale-content monitoring and unanswered-question analysis become shared infrastructure.
The human policy owner remains authoritative when the source is ambiguous or incomplete.
Worked Example: Expense Processing
At Assist, SI helps explain an expense policy. At Collaborate, it can compare a claim with policy and prepare missing-information questions. At Automate, routine claims can be classified and validated while exceptions go to finance. At Operate, expense workflows share financial controls, identity, audit and monitoring.
Approval authority should be separated from interpretation. A model identifying that a receipt appears eligible does not automatically have permission to approve payment.
Worked Example: Product Feedback
At Assist, a product manager asks SI to summarise a small set of comments. At Collaborate, the system clusters feedback, cites examples and supports human theme analysis. At Automate, incoming feedback can be continuously classified and monitored for threshold changes. At Operate, feedback analysis shares taxonomies, customer context and product knowledge across teams.
The system should preserve representative evidence so aggregate categories do not erase important minority signals.
Worked Example: Operations Monitoring
At Assist, an operator asks SI to interpret logs. At Collaborate, SI prepares incident context while the operator investigates. At Automate, monitored thresholds trigger summaries and runbook suggestions. At Operate, monitoring, incident response, change management and knowledge maintenance share governed infrastructure.
Automatic remediation should remain bounded by reversibility, confidence and production risk.
A Maturity Scorecard Without Artificial Precision
- Repeatability: Is the SI role consistent across users and cases?
- Context: Are sources current, approved and available automatically where needed?
- Verification: Can quality be checked efficiently?
- Exceptions: Are unusual cases recognised and routed?
- Permissions: Does authority match the task?
- Observability: Can important actions and outcomes be reconstructed?
- Measurement: Is end-to-end value demonstrated?
- Recovery: Can the workflow stop, revert or fall back?
- Ownership: Are process, knowledge and technical responsibilities clear?
- Learning: Do repeated corrections improve the system?
Use the scorecard to identify the weakest dimension rather than produce a decorative total score. Promotion is constrained by the first weak link.
A Demotion Playbook
- Freeze new autonomy expansion.
- Identify the failing dimension: data, model, permission, review, tool, ownership or external condition.
- Route affected cases to the last known reliable human-controlled path.
- Preserve logs and evidence from the incident.
- Repair the earliest weak link.
- Rerun representative evaluation cases.
- Restore autonomy gradually only when evidence supports it.
This playbook makes maturity reversible. A workplace should never be trapped at a higher autonomy level because returning to human control is operationally difficult.
The Final Decision: What Level Should This Workflow Use?
Ask three closing questions. First, what specific problem would a higher level solve? Second, what new failure mode or governance burden would the higher level introduce? Third, can the organisation measure the benefit and manage the burden? If the answer to the first is vague or the answer to the third is no, stay at the current level.
The best maturity level is therefore not the highest one. It is the lowest level that reliably delivers the required outcome and the highest level that the organisation can responsibly support at the same time.
A Readiness Gate for Each Level
A team can use a simple readiness question before every promotion. For Assist, can the user personally verify the output? For Collaborate, can the team standardise the handoff? For Automate, can the workflow recognise normal and exceptional cases? For Operate, can the organisation maintain the shared infrastructure and governance over time?
If the answer is no, promotion should wait. This does not mean the technology is incapable. It means the operating environment has not yet created the conditions required for that level.
Assist readiness
- The user understands the task well enough to judge the output.
- The data supplied to the tool is appropriate for the approved environment.
- The output remains reversible until the user accepts it.
- The organisation has basic safe-use guidance.
Collaborate readiness
- The task repeats enough to justify a shared method.
- Current sources and context can be identified.
- Examples of acceptable work exist.
- Review criteria can be written down.
- The human role remains explicit.
Automate readiness
- The trigger and closure states are observable.
- Normal cases can be distinguished from exceptions.
- Tool permissions can be constrained.
- Validation and escalation are built into the path.
- Monitoring can reveal failure before it compounds.
Operate readiness
- Several workflows create a real need for shared infrastructure.
- Identity, knowledge, evaluation and incident handling have owners.
- Portfolio-level dependencies are visible.
- Business continuity and fallback exist.
- Governance can evolve as models, tools and policies change.
The Maturity Ladder and Organisational Design
As more work moves toward Automate and Operate, the organisation may need roles that did not exist in the same form before: workflow owner, knowledge steward, evaluation lead, platform owner, agent-security owner or automation operations lead. In a small business these may be responsibilities rather than full-time jobs, but the functions still need owners.
This is one reason maturity cannot be reduced to software settings. A Level-4 workflow exists inside an institution that can maintain it. If nobody owns source freshness, permission changes or incident response, the technology may look advanced while the operating system remains fragile.
The Maturity Ladder and Human Agency
Higher levels should not make employees passive. People need enough understanding to challenge the system, correct it, recognise exceptions and know when a lower level is appropriate. An operator who cannot explain what the workflow is doing cannot provide meaningful oversight.
The design goal is therefore supported agency: use machine intelligence to reduce avoidable cognitive load while preserving the human capability required for judgment, accountability and recovery.
The Maturity Ladder and Trust
Trust should become more evidence-based as the level rises. At Assist, the user can inspect each output directly. At Automate, direct inspection of every case may be impossible, so trust must shift toward measured performance, validation, sampling, logs and exception handling. At Operate, trust also depends on the quality of the governance and infrastructure around the workflows.
A system should not receive more authority because users have become familiar with its tone. Familiarity is not the same as demonstrated reliability.
The Maturity Ladder and Documentation
Documentation should grow with consequence and coupling. Assist may need a short usage note. Collaborate benefits from a reusable task brief and review checklist. Automate needs trigger, input, exception, permission, verification and rollback documentation. Operate needs portfolio records and shared governance.
The purpose is operational continuity. Another authorised person should be able to understand the workflow without reconstructing it from private messages or one employee’s memory.
A Four-Level Example: Customer Complaint Escalation
At Assist, a service agent asks SI to help phrase a response. At Collaborate, SI receives the customer’s history and approved policy and prepares an evidence-backed draft. At Automate, routine complaints are classified and drafted automatically while defined severity or compensation thresholds route cases to specialists. At Operate, complaint handling shares customer knowledge, policy retrieval, monitoring and escalation infrastructure across service channels.
The workflow can stop at any level. A company with highly bespoke customers may choose Collaborate permanently because relationship judgment dominates. A high-volume standard service operation may justify more automation.
A Four-Level Example: Compliance Monitoring
At Assist, an analyst asks SI to summarise a new rule. At Collaborate, SI compares the rule with internal policy and prepares an issue map. At Automate, defined sources can be monitored for changes and relevant updates routed to the compliance team. At Operate, regulatory knowledge, versioning, evidence and workflow ownership become part of shared governance infrastructure.
Interpretation remains with qualified professionals where required. Higher maturity can automate surveillance and preparation without pretending the system owns legal or compliance authority.
A Four-Level Example: Hiring Administration
At Assist, recruiters use SI to draft job descriptions or candidate communication. At Collaborate, SI organises interview notes and prepares structured summaries against approved criteria. At Automate, scheduling, document collection and low-risk administrative routing can progress automatically. At Operate, recruitment workflows share identity, privacy controls, audit, knowledge and HR systems.
Employment decisions involving people should remain carefully governed. The maturity model can increase administrative efficiency without treating candidate selection as an automatic endpoint.
A Four-Level Example: Knowledge Creation
At Assist, an expert asks SI to turn notes into documentation. At Collaborate, the system uses a template and approved terminology, while the expert validates the content. At Automate, resolved cases or approved project retrospectives can trigger draft knowledge articles for review. At Operate, knowledge creation, retrieval, stale-content detection and gap analysis share a maintained lifecycle.
This progression can increase the organisation’s repair rate because experience is converted into reusable knowledge more consistently.
A Maturity Migration Checklist
- Confirm the higher level solves a measured problem.
- Document the current level’s performance and failure modes.
- Define the new trigger, context, permissions and tools.
- Add the new verification and exception controls before expanding authority.
- Run shadow or limited-scope tests where consequence justifies them.
- Train the people whose roles change.
- Create a fallback to the previous level.
- Measure the complete workflow after migration.
- Review whether the expected value actually appeared.
- Keep, revise or demote based on evidence.
What Would Falsify the Claim That a Workflow Is Ready for a Higher Level?
The claim should be reconsidered if humans cannot agree on what good output looks like, sources are not current, exceptions dominate the workload, review queues grow faster than they clear, the system cannot show what external action occurred, or the organisation cannot return to a known safe process after failure.
These are stronger tests than enthusiasm or a successful demo because they attack the operating assumptions required for the next level.
The Four Levels as a Durable Vocabulary
Assist, Collaborate, Automate and Operate are intentionally simple words. They allow business leaders, operators, educators and technical builders to discuss the same workflow without requiring product-specific jargon. A model may change, but the relationship remains understandable.
This vocabulary also helps procurement and governance. A request for “AI” is too broad. A request for “a Collaborate-level research workflow with read-only retrieval and human approval” is much clearer about the intended operating relationship.
The Reader’s Return
Take one real workflow and name its current level. Do not name the level you hope to reach. Name the level that accurately describes who initiates the work, who supplies context, what the system may access, what humans review, whether a trigger can run the process and whether the workflow is maintained as shared infrastructure.
Then identify the one missing condition that blocks the next level. If no higher level solves an important problem, keep the current one. A mature workplace is not one that automates everything. It is one that knows why each workflow has the level it has.
One More Rule: Mature Workflows Can Stay Human-Led
A workflow can have excellent knowledge sources, strong evaluation, careful permissions, clear ownership and disciplined measurement while remaining at Assist or Collaborate. Maturity does not require removing the person from the centre. In many professional, educational, strategic and relationship-heavy tasks, the human-led design is the feature rather than an incomplete stage.
This distinction is important because it prevents autonomy from becoming a vanity metric. The organisation should ask whether a higher level improves the actual outcome, not whether it looks more technologically sophisticated. If human judgment remains the scarce resource and machine assistance already removes the avoidable preparation burden, Collaborate may be the optimal endpoint.
The four-level model is therefore a control language. It helps a workplace describe where human attention sits, how much responsibility the system receives and what infrastructure is required to support that choice.
A Final Maturity Test
Before approving a higher SI level, ask whether the organisation can still answer five questions clearly: What outcome is this workflow trying to achieve? Which information is authoritative? What may the system do without asking? Which cases require human judgment? What evidence proves the workflow reached the intended real-world state? If any answer becomes less clear after promotion, the workflow has gained capability faster than control.
A mature migration should make those answers easier, not harder. Better infrastructure should clarify ownership, expose state, reduce avoidable work and improve the quality of exceptions. The progression from Assist to Operate is therefore successful only when the organisation gains useful capacity without losing its ability to understand, verify and repair the process.
Level Progression Is a Control Decision, Not a Status Symbol
A workplace should not treat Assist, Collaborate, Automate and Operate as trophies. Moving upward increases the amount of work that can proceed without direct human initiation, but it also increases the need for reliable context, permissions, exception handling, observability and recovery. The correct level is the one that produces the required outcome with an acceptable burden of control.
A mature organisation can deliberately keep a workflow at Assist when the task is rare, sensitive or difficult to verify. Another workflow may be safe to automate because its inputs are structured, its action is reversible and its failure modes are well understood. Maturity therefore means choosing autonomy intentionally rather than maximising it.
Promotion evidence
Before a workflow moves up one level, look for repeated evidence that the current level is stable. Inputs are available. The output standard is understood. Material errors are detected. Exceptions are recognisable. Review capacity is sufficient. The owner can explain what happens when the workflow fails. Promotion should add capability on top of that floor.
Demotion evidence
A workflow should move down when the environment changes faster than the controls. A new data source may introduce ambiguity. A model update may alter behaviour. Error rates may rise. Reviewers may begin rubber-stamping. An external action may become harder to reverse. Demotion can be surgical: remove write access, require approval, return to a fixed path or make the workflow human-initiated again.
Maturity by Evidence, Not by Interface
A polished chat interface can still be Level 1 if the employee initiates every interaction and manually checks every result. A background workflow with no conversational interface can be Level 3 if it responds to triggers and performs a stable sequence. A shared platform can support Level-4 operations while giving employees simple Level-1 assistants. The interface does not determine maturity.
This distinction matters for procurement and governance. A vendor may describe an advanced agent, but the organisation should classify the actual deployment by its initiation, tool access, decision freedom, human checkpoints and ability to change external state.
A Level-Change Review
- Outcome: Is the business result still the same?
- Context: Can the system obtain the required current information without ad hoc human repair?
- Verification: Are meaningful errors detected efficiently?
- Exceptions: Can the system recognise when the normal path no longer fits?
- Authority: Does the proposed level grant any new read, recommend or act permission?
- Recovery: Can the organisation stop, reverse or contain a bad action?
- Capacity: Can humans handle the remaining review and exception workload?
- Evidence: Has the current level performed reliably on representative cases?
The review should produce an explicit decision: remain, promote, demote or retire. Retiring a workflow is valid when ordinary software, process simplification or human work performs better.
Why the Four-Level Model Is Useful Across Departments
The same maturity language lets different departments compare systems without pretending their risks are identical. A marketing drafting workflow and a finance reporting workflow can both be Level 2 even though their evidence and approval rules differ. An IT remediation agent and a customer-support automation can both be Level 3 while having different permissions.
The common language belongs to operating structure; the controls remain domain-specific. That separation makes the model useful as an organisational map rather than a one-size-fits-all policy.
The Level Rule in One Sentence
Advance only when the next level removes meaningful friction and the organisation can still understand, verify and recover the work. The purpose of the maturity model is not to prove that a workplace has sophisticated technology. It is to make the amount of delegated intelligence visible and governable.
Continue to the Next Workplace SI Build
Continue to Super Intelligence as Assistant, Copilot, Coworker, Agent and Infrastructure to translate maturity levels into the actual role SI plays around people and tools. Return to the Workplace Super Intelligence Hub for the full sequence.