Computer knowledge used to be arranged as a list of courses. In the AI era, the question is no longer how many more terms we should learn, but how the pieces of knowledge connect.

Large models, RAG, agents, harness engineering, loop engineering and graph engineering have arrived in quick succession. Windows, Linux, macOS, iOS and Android still determine where the resulting system can run.

Which knowledge forms the physical foundation? Which part supplies the runtime, the probabilistic capability, the executable system, or the final interface with people? What follows is neither a ranking nor a curriculum climbing from low to high. It is a topology.

Five peer knowledge domainsArrows show dependencies, not rank. Engineering trustworthiness cuts across every domain.
Computer knowledge topology for the AI era Dependencies from computing hardware, operating systems, cloud and backends through large models, RAG, agents, harnesses, loops and graph engineering, and finally to web, desktop and mobile products. 1. Computer FundamentalsAlgorithm / Network / System / Hardware 02 Software platformsRuntime / Distribution / Data 3 Models and KnowledgeProbabilistic Intelligence / External Memory 04 Intelligent engineeringReliable agent execution systems 05 Product touchpointsWeb / Desktop / Mobile PHYSICALComputing HardwareCPU · GPU/NPU · Memory · ISA SYSTEMOperating SystemsKernel · Processes · I/O · Permissions PROTOCOLSNetwork / ProtocolsTCP/IP · HTTP/QUIC · DNS CS FOUNDATIONAlgorithms / Data StructuresComplexity · Graph · Concurrency · Abstraction RUNTIMELanguage / RuntimeCompilation · GC · Async · Dependencies PLATFORMCloud / DistributedContainers · K8s · Queues · SRE DATAData / KnowledgeSQL · Vector · Graph · Stream SERVICEBackend / APIDomains · REST/gRPC · Events MODELModel Architectures / TrainingTransformer · MoE · Alignment INFERENCEInference / ServingSampling · Cache · Quantization · Cloud/Edge EVALUATIONEvaluations / Model SafetyQuality · Risk · Trajectory · Cost GROUNDINGRAG / GraphRAGRetrieval · Reranking · Citations · Relations AGENT RUNTIMEAgentTools · Memory · State · Guardrails AGENT ENVIRONMENTHarness EngineeringContext · Tools · Permissions · Evals EXECUTION LOOPLoop EngineeringGoals · Verification · Memory · Stopping SYSTEM TOPOLOGYGraph EngineeringTasks · Agents · Tools · State Graphs BROWSERWeb FrontendHTML · CSS · JS/TS · A11y DESKTOPWindows · Linux · macOSNative API · Packaging · Updates MOBILEiOS · AndroidLifecycle · On-Device AI · App Stores OUTCOMEProducts / Human-AI CollaborationRequirements · UX · Workflow · Responsibility Across Every LayerEngineering TrustworthinessSecurity · Privacy · Testing · Evals · Observability · Reliability · Cost · Supply Chain · Governance · Human Approval Core Focus:Algorithms and Hardware → Systems and Networks → Software Platforms → Models and Knowledge → Intelligent Engineering → Product Delivery
The five domains have equal standing. Harness, loop and graph engineering appear at the same level of detail as the other nodes.

The five knowledge domains are at the same level

The diagram has five peer domains: computer fundamentals, software platforms, models and knowledge, intelligent engineering, and product touchpoints.

"Peer" does not mean independent. The domains have many upstream and downstream dependencies. Hardware limits throughput, latency, capacity and energy use. Operating systems organise hardware into processes, memory, files, devices and permissions. Languages and runtimes turn code into executable behaviour. Cloud, backend and data platforms extend a program on one machine into a service that can be deployed and recovered. Large models and RAG supply probabilistic capabilities and external evidence. Agents, harnesses, loops and graph engineering organise those capabilities into systems that can act, verify, stop and be held accountable. Web, desktop and mobile interfaces finally deliver them to people.

The arrows show dependencies, not rank. Intelligent engineering is not "higher" than an operating system, and a product is not "more important" than hardware. A missing part in any domain can surface as a problem somewhere else.

1. Computer fundamentals: physical, system and abstraction boundaries

Computer fundamentals include four parts: computing hardware, operating systems, networks and protocols, algorithms and data structures.

Hardware sets the physical limits of compute, bandwidth, memory, storage and energy use. The AI era has made GPUs, NPUs, quantisation and high-bandwidth interconnects more visible. It has not removed CPUs, cache hierarchies, instruction set architectures or I/O.

The operating system still manages processes, threads, virtual memory, file systems, devices, networks, and security boundaries. Windows, Linux, macOS, iOS, and Android are different implementations of this layer. An agent can call tools, but the tools ultimately still go through processes, files, permissions, drivers, and sandboxes.

Networks and protocols determine how machines, services and devices exchange data. Algorithms and data structures supply the foundations for complexity, graphs, concurrency and abstraction. The task graphs, knowledge graphs and agent graphs that appear later still rest on these fundamentals.

2. Software platforms: turning code into systems that run and scale

Software platforms include languages and runtimes, cloud and distributed systems, backends and APIs, data and knowledge storage.

Languages, compilers and runtimes manage types, memory, asynchronous work, concurrency, dependencies and external interfaces. Cloud and distributed systems turn programs into services that can be deployed, scaled, observed and rolled back. Backends connect products, data and agents through APIs, events and task systems. The data layer stores facts, state, events, vectors and relations. It also holds the external state used by RAG, long-term memory and evaluations.

The essential skill in this domain is not knowing one framework. It is defining stable contracts, understanding failure modes, and handling consistency, idempotency, permissions, capacity, releases and rollback.

3. Models and knowledge: probabilistic ability is not a fact system

The models and knowledge domain includes model architecture and training, inference and serving, evaluations and model safety, RAG and GraphRAG.

Large models provide prediction, generation, reasoning and multimodal conversion. They do not come with fresh facts, tool permissions, reliable stopping conditions or accountability for the system around them. The inference layer determines batching, caching, quantisation, routing, throughput, latency and unit cost. Evals turn subjective demonstrations into repeatable evidence by measuring quality, faithfulness, safety, trajectories, cost and regression.

RAG is not a way to dump a pile of documents into a model. Its purpose is to supply traceable external evidence during generation. Classic RAG retrieves context before generation. GraphRAG strengthens entities and relations. Agentic RAG lets the system decide when and what to retrieve, whether to call a tool, how to verify the result and when to stop.

4. Intelligent engineering: organising models into reliable execution systems

Intelligent engineering includes Agent Runtime, Harness Engineering, Loop Engineering, and Graph Engineering. They maintain the same granularity as the other four knowledge domains and do not occupy a "higher" position on their own.

Agent Runtime Turn a model into an executor with instructions, tools, state, memory, handoffs and guardrails.

Harness Engineering Design an environment in which an agent can work reliably: repository knowledge, assembled context, a tool catalogue, sandboxes, permissions, architectural constraints, tests, evals, tracing and continuous integration. The point is not to write one beautiful prompt. It is to make the right way of working discoverable, executable and verifiable.

Loop Engineering Build long-running closed loops on top of the harness: discover work, set a goal, act, observe, verify independently, write back the state, then choose whether to retry, stop or escalate to a person. A loop without budgets, stopping conditions and human gates usually does little more than accumulate errors automatically.

Graph Engineering Model tasks, agents, tools, data and system state explicitly as a graph that evolves over time. Dependencies organise parallel execution, specialists with different capabilities, independent verification and persistent state. This new paradigm emerged in 2026. It is still at the frontier and needs further testing.

5. Product touchpoints: where the system meets people

Product touchpoints include web frontends, Windows, Linux and macOS desktops, iOS and Android devices, and the design of collaboration between people and machines.

The web is the most common distribution surface for AI products. Desktop systems host local models, development tools, files and computer-use agents. Mobile devices connect cloud and on-device AI to touch, cameras, speech, location, notifications and offline situations.

The product layer must decide how probabilistic results are explained, undone and approved. A model can suggest and an agent can act, but product and accountability design still decide what deserves automation, what a person must decide and who bears the cost of failure.

Engineering trustworthiness is not an afterthought

Security, privacy, testing, evals, observability, reliability, performance, cost, supply chains and governance do not belong at the end of the process. Together they form a set of constraints that crosses hardware, systems, platforms, data, models, agents and products.

A usable system must rehearse failure, detect deviations, limit the blast radius, preserve evidence for audit, and roll back, stop or return control to a person when necessary.

Capability Pyramid: From Uninformed Users to Result Accountability

The knowledge topology answers "What is the system made of?" The capability pyramid answers "How much must a person be able to take on?"

The scope narrows towards the top as judgement and responsibility increase

At the bottom is the uninformed user. "Uninformed" is not an insult here. It means that a person brings intent, a problem and ordinary judgement without needing to understand how the system is built. Above that come: know, meaning an understanding of concepts, protocols and system boundaries; make, the ability to implement, test and deploy; control, the ability to define specifications, permissions, evals and stopping conditions; orchestrate, the ability to organise task graphs, tools and multiple agents; and own, the ability to take responsibility for value, risk and the final result.

AI can greatly lower the threshold for making things. It can also give an uninformed user results that once required a specialist. Higher up the pyramid, however, human judgement and responsibility become harder to outsource. AI can generate code, but it cannot decide whether a system deserves to exist. It can execute a process, but it cannot assume responsibility for the consequences.

The intellectual structure we actually need

Behind the diagram are seven durable capabilities: abstraction and decomposition, causal reasoning about systems, mathematics and statistics, experimental verification, adversarial risk, product human factors, and operational reliability.

Different jobs need different proportions. Model training demands more mathematics and statistics. Platform engineering depends more on causal systems thinking and operational reliability. Product work needs stronger human factors and judgement about responsibility. Harness, loop and graph engineering require a simultaneous grasp of task decomposition, permissions, evals, state and recovery from failure.

The AI era does not require everyone to master the entire diagram. A more realistic aim is to locate yourself in the topology and understand your upstream and downstream dependencies. Build genuine depth in one or two domains, while keeping enough cross-layer judgement to know when a tool can take over, when you must verify the work yourself and when the system must stop.

Knowledge is valuable not because it gives us more names to remember, but because it lets us see a system’s boundaries, dependencies and responsibilities.