How Super Intelligence Works | The Complete SI Guide to Models, Reasoning, Tools, Agents and Human Control

How does Super Intelligence work? A useful starting point is to separate the model from the system around it. A model supplies learned computational capability. An application prepares the task, provides context, retrieves information when needed, invokes permitted tools and checks what happened before delivering a result.

The answer on a screen is only the visible part of that arrangement. To understand it properly, we need to follow the data, the training, the inference, the evidence and the permissions—not simply admire the speed or fluency of the response.

This How Super Intelligence Works hub is the entry point to a 100-article curriculum on AI architecture, machine learning, large language models, generative AI, retrieval, memory, tools and AI agents. It also includes the evaluation, security, infrastructure and human decisions that make these technologies usable.

A note on terminology: eduKateSG uses “Super Intelligence”, or SI, as the series name for the field commonly called artificial intelligence. This is an editorial convention. It is not a claim that every present-day system possesses artificial superintelligence. Conventional technical terms—including AI, LLM, AGI and ASI—remain visible so readers can connect the explanations to research.

Start reading: topics 001–056 have published reading routes. Closely related topics may share an existing guide. Topics 057–100 remain planned; their unlinked titles are a curriculum plan, not a claim that those pages already exist.

---

Begin With the Four Foundations

001. The Whole Stack — From Human Intent to Machine Action explains how the pieces fit together. Follow a teaching task through information preparation, model capability, tools, checking and a reviewable result.

002. From Input to Output — What Actually Happens After You Ask follows one request through the machinery. A fictional stock-log calculation separates correct source selection from correct arithmetic and honest completion.

003. Model versus System — Why the Model Is Only One Part of SI compares hypothetical applications using the same model. Learn to identify whether the bottleneck lies in capability, evidence, retrieval, permissions or delivery.

004. Capability versus Autonomy — Being Smart Is Not the Same as Being Allowed to Act explains bounded delegation. A publishing example shows why a good draft, permission to publish and evidence of publication are different things.

Why the Model Alone Is Not the Whole Answer

Imagine asking an assistant to explain a difficult paragraph. Now imagine asking it to find the current approved document, compare two versions, calculate a quantity, create a draft and leave the original record unchanged. The second task needs more than a fluent explanation.

It needs the correct source, the right access, appropriate operations and a way to check their results. Google’s production ML overview places the model inside a wider engineering system. That is the perspective adopted throughout this curriculum.

When a system fails, the distinction helps us investigate. A missing attachment is not the same as an arithmetic error. An outdated source is not the same as a malformed tool request. An unauthorised action is not made acceptable by the quality of the generated text.

Our aim is to make these mechanisms understandable enough to inspect. A student should be able to ask where a claim came from. A teacher should be able to preserve the learning objective. A builder should be able to identify a failed handoff. A user should be able to distinguish a suggestion from an action.

Three Processes to Keep Separate

Training develops model capability

Training adjusts learned parameters using data and a learning objective. The specific method depends on the model and task. Google’s neural-network introduction provides a foundation for understanding how layers and training contribute to learned prediction.

Inference applies a trained model to a current input

Inference is the computation performed when the model is used. For an autoregressive text model, generation involves continuing a token sequence. The application around that model may add retrieval, formatting, tool calls or further model invocations. Not every AI system uses this same generation mechanism.

An agentic workflow connects decisions to observations and actions

An agentic application may let a model choose among permitted steps, inspect results and continue. Anthropic’s workflow-and-agent distinction is useful here. The choice to add flexibility should follow the task, not the assumption that greater autonomy is always better.

These processes can interact without becoming identical. Correcting a response in conversation does not automatically demonstrate a weight update. Saving a preference is not the same as retraining. Calling a tool is not the same as proving that the operation succeeded.

---

How Super Intelligence Works in One Complete Example

A directory of 100 article titles is useful only if the reader already understands the machine those titles belong to. This section supplies the missing teaching core. We will follow one complete task from human request to checked result and identify where the major SI mechanisms enter.

Imagine a teacher asks: “Use the approved chapter on heat transfer to create a one-page revision sheet for Secondary 1 students. Include a short explanation, two practice questions and answers. Use only the supplied chapter for factual claims. Save a private draft for review; do not send it to students.”

The request sounds simple, but it contains several jobs. The application must identify the source, preserve the learner level, distinguish factual material from invented practice scenarios, create a useful document, respect the draft-only boundary and report whether the save actually succeeded.

Layer 1: Human intent becomes a task

The first layer is not a neural network. It is the assignment. The system needs to know the audience, output, source boundary, permitted action and stopping point. If the task is ambiguous, more model capability can produce a more polished version of the wrong job.

A useful task representation is: audience = Secondary 1; output = one-page revision sheet; evidence = approved heat-transfer chapter; creative freedom = original practice scenarios that do not invent new scientific rules; action = create private draft; prohibited = sending, grading and changing learner records.

Layer 2: Source material becomes usable information

The chapter may contain paragraphs, diagrams, captions and tables. The system must preserve relationships that matter to the lesson. If a diagram label is detached from the wrong arrow, the model can receive the right words in the wrong structure. This is a representation problem before it is a reasoning problem.

For a text model, the prepared material is eventually converted into tokens and numerical representations. Google’s current Machine Learning Crash Course describes tokens as the units used by language models and introduces the Transformer as an important architecture for modern LLMs. The curriculum later develops these mechanisms separately rather than compressing them into one metaphor.

Layer 3: The model applies learned capability

The model can interpret the instruction, recognise relationships in the supplied material and generate a candidate revision sheet. Its learned parameters provide broad capability. They do not establish which chapter is approved today, which learner is using the sheet or whether the teacher authorised publication.

This is why the hub keeps model mechanics and system architecture separate. The model is essential, but a deployed SI application has other responsibilities. Google’s production ML material makes the same general point: real production systems contain data, serving, testing, monitoring and other components around the model.

Layer 4: Context tells the model what matters now

The teacher’s request, the selected chapter and any relevant system rules become part of the current working context. Context is not a magical second brain. It is the information made available for this inference or sequence of inferences.

A strong context contains what the task needs and keeps unrelated material out. Twenty old worksheets, an abandoned draft and a different student’s notes do not become useful merely because they fit inside a large context window.

Layer 5: Retrieval may bring in missing evidence

If the approved chapter was not attached directly, a retrieval layer may locate it from an authorised collection. The retrieval job is not simply “search for heat transfer”. It is “find the current approved source for this task”. Relevance, authority and freshness are separate properties.

Retrieval-augmented generation combines external retrieved material with a generative model. It can make current or local evidence available without retraining the model. It can also fail by retrieving the wrong version or an incomplete passage, which is why retrieval itself needs evaluation.

Layer 6: Reasoning and decomposition organise harder work

The task can be decomposed into smaller requirements: identify the chapter’s core distinction, draft the explanation, create two applications, produce answer keys, check each factual claim, then format the sheet. Decomposition is useful when the subproblems preserve the dependencies of the original task.

The system may spend additional computation on difficult questions, compare candidate outputs or run checks. That extra work is not valuable merely because it is longer. It is valuable when it improves a task-relevant outcome that can be measured.

Layer 7: Tools perform operations outside text generation

A document tool can create the private draft. A calculator could verify numerical examples if the lesson contains them. A search service could retrieve evidence. These tools extend the system, but a model proposing a tool call is different from the application executing it.

The 2026-07-28 Model Context Protocol specification is one current example of an open protocol for connecting AI applications with tools and resources. A protocol can standardise the connection; it does not replace the need to define which user is authorised to perform which operation.

Layer 8: Autonomy determines how much work continues without intervention

The system might be allowed to draft, check and save privately without asking after every step. It should still stop before sending the sheet because sending was excluded. Capability and autonomy are related but different variables.

An agentic workflow can choose among permitted next steps and continue after observing results. A fixed workflow can follow predetermined steps. Neither architecture automatically deserves more trust. The task, variability, consequences and available controls determine which arrangement is suitable.

Layer 9: Verification decides what the result actually proves

The revision sheet should be checked against the chapter. The answer keys should be attempted. The saved document should be read back. The final status should distinguish a completed draft from a sent assignment or a demonstrated learning outcome.

NIST’s AI Risk Management Framework and Generative AI Profile treat AI risk and trustworthiness as system-lifecycle concerns rather than properties of a single output. That broader perspective matches the structure of this series: design, use, evaluation and operating context all matter.

Layer 10: Human and institutional responsibility closes the loop

The teacher decides whether the revision sheet is suitable for the class. The school decides which source is approved, which records are private and who may distribute material. SI can assist those decisions without silently inheriting their authority.

The final result is therefore precise: a source-grounded private revision-sheet draft exists and is ready for teacher review. It is not “the class has learned heat transfer”, “the lesson has been sent” or “the model knows the school’s curriculum forever”.

The Ten Questions That Let You Inspect Any SI System

When you meet a new SI product, workflow or agent, ask ten questions. What outcome is the human trying to achieve? What evidence is required? How is the information represented? Which model capability is involved? What context is supplied? Does the system retrieve anything external?

Then ask: which tools can it use? How much of the work may continue autonomously? What verifies the result? Who owns the final decision and the consequences? These ten questions are the portable map behind the 100-article series.

A product can be impressive while still leaving several answers unclear. That does not automatically make it unusable. It tells you what to investigate before relying on it for a more consequential task.

Prerequisites: What You Need Before Going Deeper

You do not need advanced mathematics to begin this series. The first requirement is the ability to separate evidence from conclusion. If a system says a file was saved, ask what confirms the file exists. If it cites a document, ask whether that document supports the nearby claim.

The second prerequisite is basic probability intuition: a likely prediction is not automatically a verified fact. Later articles will introduce probability, logits, sampling and calibration more carefully.

The third prerequisite is basic computing language. A file, database record, API request, model input and model parameter are different things. The series explains each concept when needed, but keeping these categories separate prevents many early misunderstandings.

The fourth prerequisite is willingness to inspect examples. The curriculum is not designed as a vocabulary list. Each major mechanism should eventually be traceable through a worked problem, an error case and a transfer exercise.

Five Reader Routes Through the 100 Articles

Beginner route

Read 001–004 first, then 011 Tokens, 015 Neural Networks, 016 Transformers, 031 Inference, 041 Context Engineering, 046 Retrieval-Augmented Generation, 051 Tool Use, 054 Agents, 071 Hallucinations and 073 Evaluations. This route builds a complete mental model before adding specialised detail.

Builder route

After 001–004, prioritise 020 Context Windows, 026 Post-Training, 031 Inference, 041 Context Engineering, 044 Retrieval, 046 RAG, 052 Function Calling, 053 Connectors, 054 Agents, 060 Orchestration, 073 Evaluations and 089 Deployment. This route follows a system from model capability into a production application.

Student and educator route

Begin with 001–004, then study 005 Uncertainty, 038 Verification, 047 Memory, 050 Provenance, 071 Hallucinations, 073 Evaluations, 078 Privacy and 091 Education. The focus is not turning every learner into an ML engineer. It is developing judgment about what an SI output shows and what it does not show.

Agent route

Read 004 carefully, then move through 036 Planning, 041 Context Engineering, 047 Memory, 051 Tool Use, 052 APIs, 053 Connectors, 054 Agents, 055 Workflows versus Agents, 056 Agent Loop, 057 Computer Use, 059 Multi-Agent Systems, 060 Orchestration, 073 Evaluations and 077 Permissions.

Infrastructure and leadership route

Begin with the system distinction in 001–004, then read 073–080 and 081–090 before the sector applications in 091–100. This route emphasises operating conditions, evaluation, governance, resources and the institutional responsibilities surrounding deployment.

Comprehension Checkpoint 1: Can You Separate the Layers?

Question: a model gives the correct answer when the right passage is pasted into the chat, but gives the wrong answer when an application retrieves the passage automatically. Is that enough evidence to say the model is the main problem?

Answer: no. The controlled condition shows that the model can handle at least those examples when given the correct evidence. Inspect retrieval and context assembly first. The model could still have limitations, but this failure has not isolated them.

Question: an assistant writes an excellent email but was asked only for a draft. It then sends the email because a mail tool is available. Is this primarily a writing-quality problem?

Answer: no. The content can be excellent while the action exceeds the task authority. This is an autonomy, permission or tool-control problem.

Comprehension Checkpoint 2: Can You Trace a Claim?

Suppose an SI answer says, “The policy changed in September.” A traceable system should let you determine whether September came from the user, a retrieved document, a calculation or the model’s own generation. The method of checking depends on that origin.

If the date comes from a retrieved policy, inspect the document and effective date. If it comes from a calculation, inspect the inputs and arithmetic. If it is generated without evidence, treat it as unsupported until a source is found.

This is one of the most useful SI literacy habits because it works across products. Interface design, model names and tool ecosystems can change; the distinction between supplied, retrieved, calculated, observed and generated claims remains valuable.

Comprehension Checkpoint 3: Can You Recognise Unnecessary Complexity?

Task: rewrite one paragraph for clarity using only the paragraph itself. Do you need an autonomous agent, persistent memory, web retrieval and five external tools? Probably not. A bounded language-model call may be the simpler design.

Task: monitor a changing public dataset, compare new releases, update a report and notify a person when a threshold is crossed. Now retrieval, scheduling, state, tools, verification and a repeated workflow may be justified.

The mature question is not “How much SI can we add?” It is “Which responsibilities does this task actually need, and what evidence will show that each responsibility is working?”

Common Misconceptions This Series Will Correct

Misconception 1: the chatbot is the model. The visible product can include retrieval, tools, memory, orchestration and policy layers around one or more models. Misconception 2: more context is always better. Irrelevant or conflicting information can make a task harder to manage.

Misconception 3: tool use proves the model knew the answer. A model can delegate arithmetic or search to external systems. Misconception 4: a citation automatically proves the claim. The source must actually support the nearby statement and be the appropriate version.

Misconception 5: autonomy and intelligence are the same scale. A highly capable model can be given no authority to act, while simple software can have dangerous permissions. Misconception 6: a longer reasoning trace guarantees a better answer. The relevant test is the quality of the result under the task conditions.

Misconception 7: current information must be inside the model. Retrieval and tools can supply current evidence during use. Misconception 8: one successful demonstration proves reliability. A reliable claim needs representative evaluation and failure testing.

The Core Vocabulary of the Hub

Model: a learned computational component. Inference: running a trained model on input. Context: task-relevant information supplied for the current inference or sequence. Retrieval: obtaining external information needed for the task. Tool: an external capability the application can invoke.

Agent: in this series, a system in which model-guided decisions can select among permitted steps over a task loop. Workflow: an orchestrated sequence whose control may be more predefined. Evaluation: a defined method for testing behaviour or outcomes. Autonomy: the amount of work that proceeds without additional human intervention.

Provenance: where information came from. Grounding: connecting an answer to relevant external evidence or observation. Verification: checking a claim, calculation or resulting state. Permission: the authority to perform a particular operation on a particular resource.

What the Hub Will Not Pretend

The series will not present every AI system as a language model. It will not equate token prediction with the whole of intelligence. It will not treat human learning and model training as identical. It will not call a proposed future capability an established present fact.

It will also avoid using article length as evidence of authority. The purpose of the Clementi floor is completeness: hidden transitions, worked examples, diagnostic distinctions, practical methods, observable progress and independent transfer. Repetition does not satisfy that standard.

The hub therefore serves two jobs at once. It is a directory for the 100 supporting articles, and it is a first-principles lesson that lets a reader understand why those articles belong together before opening any of them.

Your First Independent SI Mapping Exercise

Take a harmless task you know well. Example: “Summarise this two-page note and create three questions I can use to check whether I understood it.” Write down the outcome, source, model capability, optional tools, verification and authority boundary.

A reasonable answer is: outcome = concise summary plus three questions; source = the supplied note; model capability = reading, synthesis and question generation; retrieval = unnecessary unless external facts are requested; tools = unnecessary unless saving a file is requested; verification = compare summary claims with the note and attempt the questions; authority = no external action required.

Now change one condition: “Save the final questions to my study folder.” A file tool and target identity become relevant. Change another: “Use the latest school notice too.” Retrieval or an approved document source becomes relevant. The architecture changes because the task changed.

If you can perform that mapping, you already understand the central logic of How Super Intelligence Works. The remaining articles deepen each component until the reader can move from a simple mental map to technical and operational detail.

A Reading Map for the Complete Curriculum

The ten parts follow a practical sequence: understand the whole system; understand its representations; study learning and inference; add knowledge and tools; examine other media and physical action; then study reliability, infrastructure and applications.

Jump to system foundations, representations and model mechanics, training, inference and reasoning, context and memory, tools and agents, multimodal systems, reliability and control, infrastructure or applications and the frontier.

Every supporting title belongs to the “How Super Intelligence Works” series. The numbering identifies its place in the curriculum, not a ranking of importance. Several ideas will be revisited from different angles, but each article has one principal explanatory job.

---

Part 1: The Complete SI System — Articles 001–010

Begin with the boundaries. What is the system meant to do? Which component supplies the capability? What information is available? What can change outside the conversation? These questions create the framework for the technical material that follows.

001. The Whole Stack — From Human Intent to Machine Action. Published above. The complete architecture, explained through a task whose inputs, output, checks and human responsibilities can be inspected.

002. From Input to Output — What Actually Happens After You Ask. Published above. The lifecycle of one request, from input preparation and representation to generation, tool results and a usable response.

003. Model versus System — Why the Model Is Only One Part of SI. Published above. How application design changes the usefulness and reliability of a model without necessarily changing its learned parameters.

004. Capability versus Autonomy — Being Smart Is Not the Same as Being Allowed to Act. Published above. Separate task performance, access, authorisation and the scope of delegated work.

005. Prediction, Probability and Uncertainty. Published. Explain logits, token probability, thresholds, calibration, sampling, uncertainty and why likely output is not the same as verified truth.

006. Why Language Models Can Do More Than Language. Published. Examine how token sequences can represent code, tables, labels, instructions and structured tasks, and how tools extend the wider system.

007. SI versus Traditional Software. Published. Compare learned behaviour with explicit rules, authoritative state, deterministic validation and hybrid system design.

008. SI versus Search Engines. Published. Distinguish crawling, indexing, ranking, retrieval, RAG, generation, freshness and evidence.

009. SI versus Databases. Published. Separate learned representations from stored records, exact queries, transactions, vector retrieval and authoritative state.

010. The SI Failure Map — Where the Full Pipeline Can Break. Published. Trace failures across task definition, sources, representation, retrieval, models, tools, permissions, execution, verification and reporting to their first unstable point.

Part 2: Representation and Model Mechanics — Articles 011–020

This part moves inside the computational representation. Its purpose is to make numerical processing understandable without pretending that a token is a thought or that a neural-network layer is a literal map of a human mind.

011. Tokens — The Units a Language Model Processes. Published. Explain vocabulary items, token IDs, subwords, special tokens, context budgets and why tokens do not correspond neatly to words.

012. Tokenisation — How Text Becomes Model Input. Published. Follow normalization, pre-tokenization, BPE, WordPiece, Unigram, special-token processing, padding, truncation and decoding.

013. Embeddings — Turning Information Into Numerical Representations. Published. Explain token, sentence and document embeddings, learned vector geometry, cosine similarity, semantic search, retrieval evaluation and representation-version discipline.

014. Vector Space — How Similarity Becomes Geometry. Published. Introduce dimensions, norms, dot products, cosine similarity, distance, projections, high-dimensional neighbourhoods and the limits of interpreting geometric closeness.

015. Neural Networks — How Layers Learn Patterns. Published. Build from weighted sums and nonlinear activations through loss, backpropagation, gradient descent, optimisation, regularisation and generalisation.

016. Transformers — An Important Architecture for Language Models. Published. Assemble embeddings, positional information, QKV attention, multi-head attention, feed-forward networks, residuals, causal masks and KV caching into a complete sequence model.

017. Attention — Combining Information Across Positions. Published. Introduce queries, keys, values, masks, softmax, multi-head attention, cross-attention and KV cache while keeping attention separate from conscious human attention.

018. Parameters and Weights — What Training Changes. Published. Explain learned numerical tensors, checkpoints, trainable versus frozen state, fine-tuning, LoRA, quantisation and why parameter count alone does not specify system usefulness.

019. Layers — How Representations Transform. Published. Follow information through successive layers, residual blocks, probes, ablations and causal interventions while avoiding one-concept-per-layer interpretations.

020. Context Windows — The Information Available for an Inference. Published. Explain token budgets, history, retrieval, truncation, long-context evaluation, KV-cache constraints and why fitting information into a window does not guarantee reliable use.

Part 3: Training and Machine Learning — Articles 021–030

Training is where model parameters are developed or adapted. This part asks what signal the model is trained against, where the examples come from and how improvements should be tested beyond the training material.

021. Pretraining — Learning Before the User Arrives. Published. Explain prediction objectives, loss, batches, checkpoints, validation, transfer, scaling and how broad capability is learned before a user’s task begins.

022. Training Data — What the Model Learns From. Published. Examine collection, filtering, coverage, deduplication, provenance, contamination, synthetic data, privacy, bias and dataset governance.

023. Self-Supervised Learning — Learning Signals From Data. Published. Explain next-token prediction, masked modeling, contrastive learning, denoising, representation learning and downstream transfer.

024. Backpropagation and Gradient Descent. Published. Connect forward passes, loss, chain rule, gradients, learning rates, optimisers, numerical stability and parameter updates through worked examples.

025. Scaling — Models, Data and Compute. Published. Study scaling laws, model-data-compute balance, Chinchilla-style compute allocation, diminishing returns, inference cost and deployment-optimal scale.

026. Post-Training — Adapting a Model for Useful Behaviour. Published. Explain supervised fine-tuning, instruction tuning, RLHF, DPO, RLAIF, tool-use training, safety shaping and regression testing.

027. Instruction Following — Learning to Respond to Requests. Published. Separate instruction tuning from runtime prompting and examine constraints, hierarchy, ambiguity, tool schemas, prompt injection and stop conditions.

028. Preference Learning — Comparing Candidate Outputs. Published. Explore pairwise preferences, reward models, RLHF, DPO, AI feedback, rater bias, reward hacking and the difference between preference and truth.

029. Synthetic Data — Machine-Generated Training Material. Published. Examine generation, filtering, verification and diversity, including why producing more examples does not by itself establish better learning.

030. Distillation and Specialisation. Published. Explain transferring behaviour into smaller or focused models, and the evaluations needed to determine which capabilities survive the change.

Part 4: Inference, Reasoning and Planning — Articles 031–040

This part studies the work performed during use. It distinguishes producing a candidate, exploring alternatives, checking constraints and verifying an answer. Describing a process as reasoning does not remove the need to inspect its results.

031. Inference — Running a Trained Model. Published. Explain runtime inputs, computation and outputs, including the difference between model execution and the full application request lifecycle.

032. Next-Token Prediction — A Mechanism, Not the Whole System. Published. Connect autoregressive generation to complex outputs while avoiding the claim that every AI architecture works this way.

033. Machine Reasoning — Working Through a Problem. Published. Examine decomposition, search, verification and structured problem solving without treating generated explanations as complete access to internal computation.

034. Test-Time Compute — Additional Work at Inference. Published. Study sequential reasoning, candidate sampling, verifier-guided selection, search, adaptive budgets and stopping rules.

035. Problem Decomposition — Dividing a Difficult Task. Published. Explain task graphs, dependencies, subproblem boundaries, parallel work, recombination and global verification.

036. Planning — Choosing and Revising Steps. Published. Connect goals, state, actions, preconditions, resources, constraints, replanning, execution monitoring and approval.

037. Search — Exploring Possible Solutions. Published. Explain BFS, DFS, A*, beam search, MCTS, heuristics, pruning, Tree of Thoughts and verifier-guided solution search.

038. Verification — Checking Rather Than Merely Generating. Published. Verify sources, calculations, code, schemas, tool outcomes and resulting state with claim-matched evidence and regression tests.

039. Mathematics and Code — Working in Checkable Domains. Published. Connect model reasoning to calculators, symbolic algebra, tests, compilers, solvers and proof assistants while preserving the original specification.

040. Confidence and Calibration. Published. Separate token probability, model scores and calibrated reliability through reliability diagrams, proper scoring rules, drift monitoring and selective prediction.

Part 5: Context, Retrieval, Knowledge and Memory — Articles 041–050

This part follows information into the current task and across tasks. The central questions are what is available, where it came from, whether it is still valid and who is permitted to use it.

041. Context Engineering — Preparing the Working Information. Published. Engineer the task environment across instructions, evidence, memory, retrieval, tool schemas, current state, compression and trust boundaries.

042. Instructions — Goals, Rules and Task Boundaries. Published. Study instruction roles and conflicts, including why text inside an external source should not acquire the user’s authority.

043. Long Context — Reading More Without Losing the Task. Published. Examine document length, relevance, evidence placement and the checks needed when large inputs contain competing versions or distractions.

044. Retrieval — Finding Missing Information. Published. Follow query formation, source selection and returned evidence, including the difference between finding something relevant and finding something authoritative.

045. Semantic Search — Retrieving Beyond Exact Words. Published. Explain embedding-based retrieval and its relationship to keyword search, metadata filtering and the particular information need.

046. Retrieval-Augmented Generation — Evidence Before an Answer. Published. Assemble a RAG pipeline and diagnose failures in retrieval, context preparation, interpretation and citation support.

047. Memory — Carrying Selected Information Forward. Published. Separate application storage, retrieved history and model parameters. Examine correction, purpose and the risks of preserving obsolete conclusions.

048. Working, Episodic and Semantic Machine Memory. Published. Use these functional categories to compare designs while explaining where analogies with human memory become misleading.

049. Knowledge Freshness — Keeping Evidence Current. Published. Explain dates, versions, live queries and update paths, including how an unchanged model can receive newly available information.

050. Provenance and Citations — Tracing a Claim. Follow a statement to its supporting source, distinguish quotation from inference and identify when a citation does not support the claim.

Part 6: Tools, Agents and Machine Action — Articles 051–060

The moment an application can act through software, the analysis must include permissions, target identity and resulting state. A generated instruction is not an executed operation, and an executed request is not always a confirmed success.

051. Tool Use — Extending Capability Beyond the Model. This topic shares the practical SI tools guide. Explain calculators, search, file operations and other external functions through the evidence they return and the boundaries they require.

052. Function Calling and APIs — Structured Software Interaction. This topic shares the practical API guide. Follow a proposed call through argument validation, execution and result handling, keeping generated text separate from trusted authority.

053. Connectors and Context Protocols. Start with the complete connection-to-result exercise in the shared connector guide. Explain interoperable access to data and tools, including why connecting a service does not authorise every available operation.

054. Agents — Models Inside Repeating Work Loops. This topic shares the practical agent guide and its complete action-and-observation case. Define an operational agent through its environment, choices, observations, state and stopping conditions rather than through a marketing label.

055. Workflows versus Agents. This topic shares the practical agent guide. Compare fixed orchestration with model-directed steps and identify when each arrangement fits the variation and consequences of the task. For the companion workflow comparison, read choosing fixed boundaries and adaptive steps.

056. The Agent Loop — Observe, Decide, Act and Check. Follow the complete action-and-observation traces, repairs and stopping tests in the shared agent guide. Trace progress across steps, including how to recognise repeated activity that is not reducing uncertainty or completing work.

057. Computer Use — Working Through an Interface. Planned. Examine screenshots, interface state, action selection and verification, with attention to ambiguity and changing layouts.

058. Research Agents — Finding and Comparing Evidence. Planned. Separate source discovery, reading, synthesis and fact checking, and explain why an extensive search can still produce an unsupported conclusion.

059. Multi-Agent Systems — Several Processes Working Together. Planned. Study delegation, shared state, disagreement and coordination costs without assuming that additional agents necessarily improve the result.

060. Orchestration — Coordinating Models, Tools and Tasks. Planned. Explain routing, dependencies, state ownership, error handling and the control layer that keeps a larger workflow coherent.

Part 7: Multimodal and Embodied SI — Articles 061–070

Text is only one kind of input and output. This part examines images, sound, documents, video, spatial information and physical systems. Each introduces its own representation problems and its own ways to check whether the result matches reality.

061. Vision — Interpreting Images. Planned. Explain visual inputs, representations and task-dependent interpretation, including why seeing a page is not the same as correctly reading every detail.

062. Image Generation — Producing Pictures From Representations. Planned. Introduce relevant generative mechanisms, controls and limitations, keeping generated illustration separate from photographic evidence.

063. Speech and Audio. Planned. Distinguish recognition, synthesis, speaker-related information and sound interpretation. Follow how uncertainty can enter before a spoken request becomes text.

064. Video — Information Across Space and Time. Planned. Examine motion, sequence, sampling and temporal relationships, including what can be lost when a system sees only selected frames.

065. Documents — Pages, Tables and Mixed Layouts. Planned. Study extraction and visual interpretation while preserving headings, units, labels and source locations needed for a trustworthy answer.

066. Code Execution — Running and Checking Generated Work. Planned. Separate writing code from executing it, inspect results and explain why the execution environment needs its own controls.

067. Spatial Reasoning — Position, Objects and Environments. Planned. Examine spatial representations and tasks, including the difference between describing a scene and reliably acting within it.

068. Robotics — Connecting Computation to a Body. Planned. Follow perception, planning and control into physical action, where timing, sensing and environmental consequences cannot be reduced to text quality.

069. Sensors and Edge Intelligence. Planned. Explain local sensing and computation, intermittent connections and the information limits of systems operating away from a central service.

070. World Models and Simulation. Planned. Explore representations used to predict environments and test actions, including the gap between a simulated outcome and an observed one.

Part 8: Reliability, Evaluation, Safety and Security — Articles 071–080

A useful system needs more than a successful demonstration. It needs appropriate tests, visible limits and a repair route. NIST’s AI Risk Management Framework provides a voluntary reference for considering trustworthiness across an AI system’s lifecycle.

071. Hallucinations — Plausible Output That Is Wrong. Planned. Separate unsupported generation, source errors and mistaken synthesis, then examine checks matched to the kind of claim being made.

072. Grounding — Connecting Answers to Evidence. Planned. Study documents, tools and observations as grounding routes, while preserving the limits of what each source can establish.

073. Evaluations — Testing the Actual Task. Planned. Define inputs, acceptance criteria and representative cases, distinguishing component evaluation from assessment of the complete application.

074. Benchmarks — What Scores Measure and Miss. Planned. Examine task selection, conditions and reporting, including why a benchmark result is not a universal certificate of real-world capability.

075. Red Teaming — Finding Failure Before Wider Use. Planned. Explain authorised adversarial testing and how discovered failures become concrete repairs and regression tests.

076. Prompt Injection and Tool Manipulation. Planned. Study trust boundaries around external information and connected tools, with defensive examples rather than treating prompt wording as sufficient security.

077. Permissions, Sandboxes and Containment. Planned. Explain how to limit reachable resources and operations so that capable assistance does not require unrestricted system access.

078. Privacy and Data Security. Planned. Follow information through inputs, storage, tools and logs, and identify where access, retention and disclosure decisions belong.

079. Bias, Fairness and Representation. Planned. Examine datasets, objectives and evaluation populations, making the relevant context explicit rather than relying on a single abstract fairness label.

080. Alignment, Oversight and Human Control. Planned. Separate model behaviour, application safeguards and legitimate human decisions, including the limits of any single control mechanism.

Part 9: Compute, Infrastructure and Operating Costs — Articles 081–090

Digital intelligence still depends on physical and operational resources. This part asks what keeps a service available, how work is distributed and how performance should be assessed against the result the user actually needs.

081. GPUs and Accelerators. Planned. Explain the kinds of computation involved and why hardware suitability depends on workload, memory and communication rather than a single headline specification.

082. Data Centres — The Physical Environment of SI. Planned. Connect computing to power, cooling, storage and networking, while separating measured infrastructure facts from broad resource claims.

083. Distributed Training — Learning Across Machines. Planned. Introduce parallel work, communication and coordination, and explain why scaling involves more than adding identical computers.

084. Inference Infrastructure — Serving Model Requests. Planned. Follow request handling, model execution, resource allocation and service failure into the user’s experience of a deployed application.

085. Latency and Throughput. Planned. Distinguish the time one task takes from the amount of work a service handles, and explain why their trade-offs depend on the application.

086. The Cost of Intelligence. Planned. Examine resources, review and rework alongside generation costs, using clearly labelled scenarios rather than unsupported promises of productivity or savings.

087. Energy, Water and Environmental Load. Planned. Study measurement boundaries, location, workload and uncertainty so that environmental comparisons refer to comparable systems and conditions.

088. Quantisation, Caching and Compression. Planned. Explain distinct efficiency techniques and the evaluations needed to understand their effects on quality, memory and runtime behaviour.

089. Deployment, Monitoring and Versioning. Planned. Follow a system beyond launch, including changing sources, new model versions, regressions, incident investigation and recoverable releases.

090. Open, Open-Weight and Proprietary Models. Planned. Compare access to weights, code, data, documentation and usage rights without collapsing different kinds of openness into one binary label.

Part 10: Applications and the Intelligence Frontier — Articles 091–100

The final part applies the mechanism map to real kinds of work. These articles will explain how systems function in their domains; they are not promises that every proposed use is reliable, appropriate or ready for unsupervised deployment.

091. Education — From Answers to Learning Support. Planned. Examine explanation, practice and feedback while preserving the distinction between a tool’s output and a learner’s independent understanding.

092. Science — Literature, Hypotheses and Experiments. Planned. Follow SI through research tasks, separating generated ideas, experimental evidence and validated conclusions.

093. Healthcare and Medicine. Planned. Explain information and workflow mechanisms alongside domain-specific validation and qualified oversight, without treating general-purpose output as clinical authority.

094. Software Engineering. Planned. Connect repository understanding, code generation, execution and testing, including why a passing test suite does not establish every property of software.

095. Creativity and Media. Planned. Examine text, image, sound and design workflows, keeping creative generation distinct from factual evidence, attribution and the human creator’s decisions.

096. Business and Institutions. Planned. Follow information, task handoffs and approvals through an organisation, and identify the maintenance responsibilities surrounding a useful SI application.

097. Cybersecurity — Defensive Capability and New Attack Surfaces. Planned. Explain authorised analysis, detection and system protection, including the risks introduced by connected tools and sensitive data access.

098. Government and Public Systems. Planned. Examine technical workflows, documentation, accountability and human decision boundaries in public-service applications, distinguishing evidence from claims about policy outcomes.

099. AGI, ASI and Recursive Improvement. Planned. Separate definitions, demonstrated capabilities and hypotheses about further development. Machine-assisted improvement will not be treated as proof of unlimited self-improvement.

100. The Civilisation-Scale SI Stack. Planned. Use a systems lens to examine connected people, institutions, models, agents and infrastructure. This is an analytical perspective, not a claim that civilisation is one conscious machine.

---

How to Use the Hub Without Reading Everything in Order

A beginner should start with the four published foundations. They explain what the system contains, what happens during a request, why the model is not the whole application and why capability does not automatically grant authority.

A builder can then follow the curriculum through context, retrieval, tools and evaluation. The important exercise is to map a real task to specific components and tests. A fashionable architecture is not a substitute for knowing which problem the application must solve.

An educator can follow the distinction between generated output and learning. Ask what the student must still retrieve, explain, apply and check independently. SI can be part of a learning activity without becoming the evidence that learning has occurred.

A manager or researcher can follow responsibility across the system: who owns the data, who authorises action, who evaluates the result and who repairs failures? These questions remain useful as individual models and products change.

A Reality Check Before Trusting an Answer

Choose one important claim in a response and follow it backwards. Was it supplied by the user? Retrieved from a source? Calculated by a tool? Inferred by the model? Each route calls for a different kind of check.

Then inspect the claimed action. Was a document only drafted, or was it saved? Was a page merely prepared, or was it published? Does the returned link identify a real result? A completion statement should not exceed the evidence available.

Finally, identify what remains uncertain. A missing source, unresolved ambiguity or untested assumption should remain visible. The goal is not to demand impossible certainty from every interaction. It is to make the confidence and the action appropriate to the task.

Frequently Asked Questions About How Super Intelligence Works

Is SI a different technology from AI?

In this series, SI is the editorial name used for AI technologies. It is not a new scientific category or a claim of achieved artificial superintelligence. Standard technical vocabulary remains alongside it so that readers can find and understand the underlying research.

Does every SI system use a transformer?

No. The curriculum includes transformer-based language models because they are important to the systems being discussed, but it does not reduce all machine learning or all AI applications to one architecture. Each mechanism article will state its scope.

Does an SI system automatically know current information?

Do not assume so. Current information needs an appropriate source and an actual update or retrieval route. A model’s learned knowledge, the current conversation and an external database are different sources of information with different limitations.

Do I need advanced mathematics to begin?

No. Begin with the system-level examples. Later technical articles will introduce the mathematics needed for particular mechanisms rather than assuming that every reader already understands vectors, gradients or probability.

Are all 100 supporting articles already published?

No. Topics 001–056 are covered by published guides linked from this hub; some related topics share a guide. The remaining 44 entries are planned topics. Unpublished entries are intentionally unlinked so that the curriculum does not send readers to nonexistent pages.

How is this different from the general intelligence series?

This hub owns the engineered machine-intelligence explanation: representations, models, applications, tools and controls. The wider How Intelligence Works series considers intelligence more broadly. Related ideas can connect without treating human learning and model training as identical processes.

From an Impressive Answer to an Understandable System

Understanding how Super Intelligence works begins when we stop treating the final answer as the whole event. There was a task, an information route, a computation and sometimes an external action. Each stage has conditions under which it can succeed or fail.

The purpose of this curriculum is to make those conditions legible. When readers can distinguish capability from authority, retrieval from knowledge, generation from verification and a model from its application, they can ask better questions and build more dependable uses.

Begin with The Whole Stack, then follow one request from input to output. For the educational habits behind responsible use, continue to The Importance of AI Literacy.

For the wider framework that connects this topic to learning, work, agents, verification, human judgment and the future, continue through the Super Intelligence master guide.

For the wider framework connecting this topic to learning, work, agents, verification, human judgment and the future, continue through the Super Intelligence master guide.

Continue through the SI knowledge web with Super Intelligence master guide. For the complete map, return to the Super Intelligence master guide.