Why can a large language model do more than ordinary language tasks? The answer begins with a misunderstanding hidden inside the name. A language model is trained to operate on sequences of tokens, but those token sequences can represent much more than conversational prose. They can encode instructions, code, tables, structured records, equations, labels, markup, plans and other symbolic patterns.
That does not mean a language model automatically becomes a perfect calculator, database, search engine or software system. It means that many tasks can be represented in forms the model can process. The broader SI application can then add retrieval, tools, memory, execution and verification where the model alone is insufficient.
This article explains the transition from language modeling to a broader task interface. We will examine translation, summarisation, classification, extraction, code, structured data, mathematics, planning and tool use. We will also keep the boundaries clear: some apparent “general intelligence” comes from the model, some comes from the representation of the task, and some comes from the system around the model.
Google’s current Introduction to Large Language Models describes language models as estimating the probability of tokens or token sequences and notes uses such as text generation, translation and summarisation. It also notes that tokens are now used in areas such as vision and audio generation. The important lesson is that token-based sequence modeling is a computational interface, not merely a dictionary of English words.
For the preceding mechanism, read Prediction, Probability and Uncertainty. Here we ask a new question: how can a model trained around sequence prediction become useful for tasks that look like coding, classification, analysis or planning?
The Hidden Transition: Many Problems Can Be Written as Sequences
Consider a simple classification problem. A support message says, “The projector turns on but the image keeps flickering.” The desired category is one of DISPLAY, NETWORK, AUDIO or POWER. That task can be represented as a sequence: instruction, input text, then output label. A language model can learn or infer the mapping from the sequence pattern.
Now consider data extraction. The input is “Order 4317, three blue folders, delivery Friday.” The desired output might be a structured record: order_id = 4317, item = blue folders, quantity = 3, delivery_day = Friday. Again, the task can be represented as a sequence transformation.
Now consider code. The input describes a function and perhaps shows examples. The output is source code, which is also a symbolic sequence with syntax, repeated patterns and long-range dependencies. The model does not need code to be ordinary prose in order to process it as tokens.
The common structure is not “everything is language” in a philosophical sense. The practical structure is that many digital tasks can be expressed as sequences of symbols. Sequence models can therefore learn reusable statistical structure across several kinds of symbolic work.
Tokens Are Not Limited to Whole English Words
A token can correspond to a whole word, part of a word, punctuation mark, symbol or other vocabulary unit. Modern tokenizers often split text into subword pieces. This lets the model represent rare words, identifiers and unfamiliar combinations using a finite vocabulary.
Programming languages benefit from this flexibility because code contains punctuation, brackets, operators, keywords and identifiers. Structured data contains quotes, commas, braces and field names. Mathematics contains numerals and symbols. These can all be represented as token sequences, although their usefulness depends on the model’s training and the task.
The representation still matters. A table flattened carelessly into disconnected text can lose row-column relationships. A code file truncated before the function definition can become impossible to interpret. Tokenisation makes data processable; it does not guarantee that the right structure survived preprocessing.
Language Is Also an Interface for Describing Tasks
Human instructions are a powerful coordination layer because people can describe new tasks in ordinary language. “Summarise this”, “classify these messages”, “extract the dates”, “compare these policies”, “write a function that sorts these records” and “explain why this answer is wrong” all describe different operations without requiring a custom graphical interface for each one.
This is one reason instruction-following language models appear general-purpose. The same input channel can specify the task, constraints, examples and desired output format. The model can then condition its generation on that context.
The interface is flexible, but flexibility creates ambiguity. “Make this better” is less precise than “rewrite this paragraph for a Primary 6 reader without changing any factual claim”. A general language interface reduces the need for dedicated UI controls, but it does not remove the need for a well-defined job.
Task 1: Summarisation Is a Compression Problem
Summarisation asks the model to preserve important information while reducing length. The task involves selection, compression and rewriting. The model must decide which details matter under the requested summary objective.
A meeting summary for executives may prioritise decisions, owners and deadlines. A study summary for a student may preserve definitions and causal relationships. The source can be the same while the summary changes because the task specification changes.
The model’s language capability helps convert the selected information into coherent text. Verification still matters: a concise summary that invents one decision is worse than a slightly longer summary that accurately reflects the meeting.
Task 2: Translation Is a Structured Transformation
Translation transforms one sequence into another while preserving meaning across languages. The task depends on grammar, vocabulary, idiom, register and context. A language model can learn statistical relationships across multilingual examples and use context to choose among possible translations.
Translation also reveals the limits of “one word equals one word”. Meaning can be distributed across phrases and grammatical constructions. A good translation may change word order, split a sentence or choose a different idiom while preserving the intended meaning.
For high-stakes documents, human review and domain terminology may still be necessary. A model can be capable of fluent translation without having authority to certify legal, medical or official equivalence.
Task 3: Classification Can Be Framed as Generation
Return to the support-message example. Instead of building a separate classifier head, an instruction-following model can receive the message and generate one permitted label. This turns classification into constrained text generation.
Example: “Classify the message into DISPLAY, NETWORK, AUDIO or POWER. Message: The projector turns on but the image flickers.” A suitable output is DISPLAY. The model uses learned associations between the symptoms and the category definitions supplied or learned.
For reliability, the application should validate that the output is one of the allowed labels. If the model writes “probably display issue”, a parser can map or reject it according to the contract. Flexible generation can be combined with deterministic validation.
Task 4: Information Extraction Can Produce Structured Data
Suppose a teacher writes: “Secondary 2 revision class, Wednesday 4:30 PM, Room 3, bring geometry set.” The system needs a record with level, activity, day, time, room and materials.
A model can transform the sentence into a structured format such as JSON. The surrounding application can validate required fields and types. A time field should parse as a time. A room identifier should match the allowed set. If a required field is absent, the system should not fabricate it simply to satisfy the schema.
This is where SI and traditional software work well together. The language model handles flexible input; deterministic code enforces structural requirements. The model does not need to replace the schema validator.
Task 5: Code Is a Language With Executable Consequences
Source code is symbolic text governed by formal syntax and semantics. Models trained on code can learn patterns of functions, APIs, control flow, tests and documentation. The paper Evaluating Large Language Models Trained on Code helped demonstrate that language-model architectures can generate functional code under benchmark conditions.
But code generation differs from ordinary prose because the output can be executed. A plausible-looking function can contain a bug, security problem or wrong assumption. Execution, tests, static analysis and review become part of the system.
A useful workflow is therefore: describe the function, generate candidate code, run tests in a bounded environment, inspect failures, revise and review the final change. The model contributes code synthesis; the toolchain provides executable evidence.
Worked Code Example: From Requirement to Tested Function
Requirement: write a function that receives a list of scores and returns the arithmetic mean, ignoring missing values represented by null. If every value is missing, return null. This requirement can be expressed in natural language, but the desired output is code.
A candidate implementation in Python might filter out None values, check whether the remaining list is empty, then return sum(values) / len(values). The structure is simple enough to reason about, but we still need tests.
Test 1: [10, 20, 30] should return 20. Test 2: [10, None, 30] should return 20. Test 3: [None, None] should return None. Test 4: [] should also return None if the specification treats an empty input the same way.
If the generated function divides by the original list length instead of the filtered length, Test 2 exposes the defect. The model can generate code; the tests tell us whether this implementation satisfies the stated contract for these cases.
Task 6: Tables Become Sequences, but Structure Must Survive
A table is two-dimensional, while a text model ultimately receives a sequence. The application therefore needs a representation that preserves rows, columns, headers and values well enough for the task.
Consider a three-row table: Class A, 18 students, 6 absent; Class B, 20 students, 2 absent; Class C, 16 students, 0 absent. A model can answer “Which class has the highest absence rate?” only if it correctly pairs each numerator and denominator.
Class A has 6/18 = 33.3%; Class B has 2/20 = 10%; Class C has 0/16 = 0%. The answer is Class A. If the table extraction swaps the 18 and 20, the model can perform flawless arithmetic on corrupted structure.
This is another reason the model is not the whole system. Data ingestion, representation and validation can determine whether the model receives a solvable problem.
Task 7: Mathematics Can Be Represented, but Exactness Needs Care
Mathematics contains symbolic structure that can be serialized into text. Language models can recognise many mathematical patterns, explain procedures and generate candidate solutions. They can also make arithmetic or logical mistakes.
For exact numerical work, a calculator or code execution environment can verify computations. The model can decide which quantities belong in the expression; deterministic tools can evaluate the expression. This division of labour is often stronger than forcing the model to do every calculation internally.
The article From Input to Output demonstrated this with a stock-log example: selecting the right records and calculating the total are separate responsibilities.
Task 8: Planning Can Be Written as a Sequence of States and Actions
A planning task describes a goal, starting state, constraints and possible actions. Those elements can be expressed in text or structured representations. The model can propose a sequence of steps and revise it when new information arrives.
Example: “Prepare a school open-house checklist. The hall is booked, invitations are not sent, catering requires final headcount, and the event is in ten days.” A model can propose dependencies: confirm invitation list, send invitations, collect RSVPs, finalise headcount, confirm catering.
The plan is useful only if it respects reality. The model does not know whether the invitations were actually sent unless a connected system reports that state. Planning text and operational execution remain distinct.
Task 9: Question Answering Can Combine Retrieval and Generation
A language model can answer from its learned parameters or supplied context. For current, local or source-sensitive questions, retrieval can locate evidence and place it into the model’s context.
The model’s language capability then becomes a synthesis layer. It can compare passages, explain differences and answer in a form suited to the user. Retrieval contributes information; generation contributes interpretation and presentation.
This is why a model can appear more knowledgeable when connected to tools without its weights changing. The system has expanded the information available at runtime.
In-Context Learning: Examples Can Specify a New Task
One striking capability of large language models is that examples in the prompt can define a task without updating the model’s weights. The paper Language Models are Few-Shot Learners popularised this capability in large autoregressive models.
Suppose the prompt shows three examples mapping customer messages to labels, then provides a fourth message. The model can continue the pattern and output a label. The examples act as context, not as permanent training updates.
This helps explain why one model can handle many tasks through prompting. The task definition itself is represented as a sequence. The model uses the context to infer what continuation pattern is expected.
Why Scale Can Produce Broader Transfer
Larger models, more diverse data and greater compute can improve the ability to learn patterns that transfer across tasks. But “scale” is not a universal explanation for every capability. Architecture, data mixture, post-training, context and evaluation all matter.
The foundation-model framing from Stanford describes models trained broadly enough to be adapted to many downstream tasks. That broad base creates economic and technical leverage: one model can support many applications rather than one handcrafted model per task.
At the same time, broad capability can create broad failure modes. A single underlying model can propagate biases, security issues or factual weaknesses into many downstream systems. Generality increases the importance of system-level evaluation.
Why “Emergence” Must Be Used Carefully
Some abilities appear weak or absent in smaller models and become much stronger at larger scales. These patterns are sometimes described as emergent capabilities. The term can be useful, but measurement choices can make gradual improvements look sudden when a benchmark uses a hard pass/fail threshold.
For this series, the safer habit is to describe the observed task performance and scale conditions rather than treating “emergence” as a mysterious force. Ask what improved, on which benchmark, under which prompting and evaluation procedure.
The general lesson remains important: a model trained for next-token prediction can exhibit useful behaviour on tasks that were not encoded as separate handcrafted modules. The explanation lies in learned representations and transfer, not magic.
Why Code, Tables and Instructions Benefit From Shared Representations
Many digital artefacts contain overlapping concepts. A software function has a name, arguments, documentation and behaviour. A table has fields and values. An instruction has goals and constraints. A model trained across diverse symbolic material can learn patterns that connect these structures.
For example, documentation says “timeout_seconds controls how long the request waits before failing”. Code calls request(timeout_seconds=30). An error log says “request timed out”. The model can connect the shared concept across prose, code and logs because all three appear as related token patterns.
This does not mean the model has a perfect symbolic database. The representation is distributed and approximate. The benefit is flexible cross-format reasoning; the cost is that exactness and provenance may need external support.
The Role of Post-Training
A raw pretrained language model predicts continuations. Post-training can shape it into a more useful assistant by teaching instruction following, preference patterns, safety behaviour or tool-use conventions.
This is another reason the phrase “the language model learned to do X” can be too broad. A capability may come from pretraining, instruction tuning, preference training, tool demonstrations or the application around the model.
Later articles in the series separate these stages. For now, the key idea is that general task behaviour is assembled through several learning and system layers.
Tools Turn Symbolic Plans Into External Operations
A model can write “calculate 19 × 27”, “search the handbook”, “save this draft” or “run the test suite”. Without tools, those may remain text. With connected tools, the application can execute the operation and return the result.
This greatly expands apparent capability. A model connected to a calculator can produce exact arithmetic more reliably. A model connected to search can use current sources. A model connected to a code runner can test generated programs.
The expansion belongs to the system, not only the model. Permission, tool validation and result checking become essential because generated intentions can now change external state.
Multimodal Systems Extend Beyond Text Tokens
Modern SI systems can include images, audio and video as inputs or outputs. Some architectures convert these modalities into token-like or embedding representations that can be processed with related transformer techniques.
Google’s current LLM introduction notes that tokenization ideas are used in computer vision and audio generation. The exact architecture varies across systems, so this series will not pretend that every multimodal model simply turns pixels into English-like tokens.
The important idea is representation alignment. A system can connect visual, auditory and textual information in a shared task. For example, it can receive a photograph of a graph and a text question, then generate an explanation. That is broader than pure text, even if a language-like interface coordinates the task.
Worked Multiformat Example: From Photo to Structured Record
Imagine a photo of a classroom whiteboard showing “Sec 2 Science — Tue 3:30 — Lab 2 — bring goggles”. A multimodal system first needs to perceive the text and layout. The task is then to create a structured event record.
Expected record: level = Secondary 2; subject = Science; day = Tuesday; time = 3:30 PM; location = Lab 2; material = goggles. The output can then be validated against a schema.
If the visual model misreads Lab 2 as Lab Z, the language model may generate a perfectly formatted record containing the wrong location. The failure belongs to perception or extraction. Again, broad SI capability does not eliminate the need to diagnose which representation broke.
Why Language Models Are Not Databases
A model can reproduce many facts from learned parameters, but those parameters are not a conventional database with one authoritative row per fact. The system may produce plausible outdated or incorrect information.
If the task requires exact current state—today’s room booking, a customer balance, a published policy version—the appropriate source is often a database, file, API or live search system. The model can interpret and explain the result.
This is why “can answer questions about data” does not imply “should replace the data store”. Flexible reasoning and authoritative state are different system roles.
Why Language Models Are Not Calculators
A language model can learn arithmetic patterns and sometimes solve calculations directly. A calculator implements numerical operations with explicit rules and is usually preferable when exact arithmetic is the goal.
The useful hybrid is model plus calculator. The model reads the problem, identifies the relevant numbers and constructs an expression. The calculator evaluates it. The system then checks that the expression itself matches the intended problem.
This preserves the strength of each component: flexible interpretation from the model and exact execution from the calculator.
Why Language Models Are Not Search Engines
A language model generates a continuation from its model and context. A search engine discovers, indexes and ranks documents. Modern products can combine these functions, but the mechanisms remain distinct.
When the answer needs current public evidence, search can find candidate sources. The language model can summarise or compare them. The next article in this batch will examine this distinction in depth.
A Capability Map: What Comes From Where?
Drafting prose: primarily model generation. Finding a current policy: retrieval or search. Calculating an exact total: calculator or code tool. Remembering a user preference across sessions: persistent application memory. Saving a document: file tool. Proving the document exists: tool result or read-back.
This map is more useful than saying “the AI did it”. One user-visible task can combine several sources of capability. Improvements and failures should be attributed to the component that actually owns the responsibility.
Three Common Failure Patterns
Pattern 1: The model is asked to be a database
A user asks for a current value that changes daily, but no live source is provided. The model produces a plausible number. Repair: connect the authoritative source or require the user to provide it.
Pattern 2: The model is asked to be a calculator
The reasoning is correct but a long arithmetic expression contains one mistake. Repair: use deterministic calculation and verify the constructed expression.
Pattern 3: The model is asked to be an executor
The system generates “file saved” without any file tool. Repair: separate intended action from executed action and tie completion language to tool evidence.
How to Evaluate “General” Capability Without Being Fooled
A strong evaluation uses different task families: summarisation, extraction, classification, transformation, code, reasoning and tool use. Each family needs task-specific acceptance criteria. One average score can hide serious weakness in a critical area.
Control the context. If one system receives a perfectly selected source and another receives nothing, the test measures more than model capability. If one system can use tools, state that clearly.
Include transfer cases. A model that memorises the exact examples may perform well on familiar prompts but fail when surface details change. Good evaluation changes names, order, wording and irrelevant detail while preserving the underlying structure.
Include failure cases. Missing information, conflicting sources, malformed data and unavailable tools reveal whether the system can preserve boundaries instead of improvising success.
Repair, Stabilise and Extend the Capability Stack
Repair
When a task fails, identify whether the first unstable point is representation, model interpretation, retrieval, tool execution or verification. Do not add more agents before understanding the failure.
Stabilise
Build a small regression set covering ordinary variations. If the system classifies support tickets, include clear cases, mixed cases and missing-information cases. Preserve those tests through model and prompt changes.
Extend
Add new modalities, tools or longer-horizon workflows only after the existing task is dependable. Expansion introduces new interfaces and failure modes. The old tests remain necessary.
Independent Exercise 1: Classification or Generation?
Task: assign each student question to Mathematics, Science, English or Humanities. Can a language model perform this without a custom classification model? What system control should still be added?
Answer
Yes. The task can be framed as constrained generation: provide the allowed labels and ask for one. The application should validate that the output belongs to the allowed set and evaluate classification performance on representative questions.
Independent Exercise 2: Extraction
Input: “Primary 6 Science revision, Friday 5 PM, Room 4, bring calculator and ruler.” List the structured fields a model could extract, and name one thing it should not invent.
Answer
Fields can include level = Primary 6, subject = Science, activity = revision, day = Friday, time = 5 PM, room = 4, materials = calculator and ruler. It should not invent a date, duration or teacher name because none was provided.
Independent Exercise 3: Tool Boundary
A model writes a correct Python function and says “all tests passed”, but no code-execution tool is available. What is wrong?
Answer
The code may be a valid candidate, but the claim about tests is unsupported. The system should say the code has not been executed or provide actual test results from a tool.
Independent Exercise 4: Generality
A model can summarise prose and generate code. Does that prove the same internal mechanism is used in exactly the same way for both tasks?
Answer
No. The same model architecture and parameters can support both tasks, but the internal representations and attention patterns may differ. Observed multi-task capability does not justify an unsupported story about identical internal reasoning.
A Deeper Mechanism: Prediction Forces the Model to Learn Useful Structure
Why should predicting the next token teach anything beyond local word associations? Because good prediction in complex data often requires representing information that extends far beyond the immediately adjacent token. To continue a story, the model may need to track who did what. To continue code, it may need to track variable names, brackets and function structure. To translate, it may need relationships between meanings across languages.
The model is not explicitly told, “Build a reusable concept of function arguments” every time. During training, parameter updates reward representations that improve prediction across many examples. Useful internal structure can therefore emerge because it compresses recurring regularities in the data.
This is one reason self-supervised learning is powerful. The training data supplies enormous numbers of prediction targets. Every sequence provides opportunities to learn syntax, terminology, patterns of explanation, code structure and relationships between concepts.
The next-token objective remains important, but it should not be confused with the complexity of the representations required to perform it well. A chess move can be encoded as a short symbol while depending on the state of an entire board. Likewise, a token can be locally small while the computation behind its probability uses broad context.
Formal Languages Make the Boundary Especially Clear
Programming languages and markup are called languages because they have syntax, but their rules are more formal than ordinary conversation. A missing bracket can make a program invalid. A misplaced field can break a configuration. This creates tasks where the model’s sequence knowledge can be tested against hard constraints.
Consider JSON. The object {“name”:”Aisha”,”score”:18} must obey a specific structure. A language model can generate such structures because braces, quotes, keys and values occur in recurring patterns. The application can then validate the result with a JSON parser.
If the parser rejects the output, the failure is objectively observable. The model can be asked to repair the structure. This creates a useful loop: flexible generation followed by deterministic validation.
The same pattern applies to SQL, regular expressions, configuration files and many other formal artefacts. SI becomes more dependable when generated symbolic output is checked by the system that defines the formal rules.
Worked Example: Natural Language to SQL Without Trusting the First Draft
Imagine a small database table with fields student_id, class_name and attendance_status. The user asks, “Count how many students in Class A are marked absent.” A language model can translate the request into a candidate SQL query.
A candidate might be: SELECT COUNT(*) FROM attendance WHERE class_name = ‘A’ AND attendance_status = ‘absent’; The database can execute this query in a read-only environment. The model’s job is to map the user’s wording to the schema and intended filter. The database’s job is to perform the exact query against the stored rows.
Now change the request to “Count students who are not present.” If the database only uses statuses absent, late and present, the meaning of “not present” becomes ambiguous. Should late students be counted? The model should not silently choose unless the organisation has defined the rule or the context makes it clear.
This example shows why natural-language interfaces are powerful and risky at the same time. They let non-programmers express database intent. They also make semantic ambiguity visible at the point where a rigid query must eventually be produced.
Worked Example: Debugging Code Is Different From Writing Code
Suppose the program is intended to return the largest value in a list but fails on all-negative inputs because it initializes max_value to zero. The user asks the model to diagnose the bug.
The model can inspect the code and recognise the pattern: zero is not a safe initial maximum if every actual value may be below zero. A repair is to initialize from the first list element or from an appropriate negative infinity value, while handling the empty-list case explicitly.
The model has moved beyond code completion into explanation and debugging. Yet testing remains essential. Test [3, 8, 2] → 8, [-5, -2, -9] → -2, [4] → 4, and [] according to the chosen specification.
This is a recurring SI pattern. The same model can generate, inspect and explain code because all three tasks are represented through related sequences. The surrounding execution environment supplies evidence that the proposed repair actually works on the defined cases.
Worked Example: Comparing Two Policies
Document comparison looks different from code but uses a similar representational principle. Suppose Policy A says “Students may borrow one device for three school days.” Policy B says “Students may borrow up to two devices for three school days.” The task is to identify the change.
A language model can align the two passages and produce: the duration is unchanged; the maximum number of devices increased from one to two. This is a transformation from two input sequences into a structured difference statement.
Now suppose Policy B also removes a sentence about teacher approval. The model needs enough context to notice absence, not only changed wording. Long-document comparison therefore depends heavily on source completeness and chunking.
The model can help surface changes, while a document-governance system tells us which version is current and whether both documents were fully compared. Again, capability is distributed across model and system.
Worked Example: One Model, Four Output Shapes
Use one source paragraph about photosynthesis. Task A: summarise it in 50 words. Task B: produce three multiple-choice questions. Task C: extract the named scientific processes into a list. Task D: rewrite it for a younger learner without changing the science.
The source remains the same while the output contract changes. The model conditions on the task description and produces different transformations. This demonstrates general-purpose interface behaviour without requiring four separate handcrafted programs.
However, the evaluation also changes. A summary is judged for coverage and accuracy. Multiple-choice questions need answerability and plausible distractors. Extraction needs completeness and exactness. Simplification needs age-appropriate language without factual distortion.
“One model, many tasks” therefore does not mean “one metric, many tasks”. Generality on the input side increases the importance of task-specific evaluation on the output side.
The Role of Templates, Schemas and Constrained Decoding
Applications can reduce output ambiguity by providing templates or schemas. A job application parser can require fields such as name, date, qualification and source_line. A tutoring workflow can require question, expected_answer and concept fields.
Some generation systems support constrained decoding or grammar-based output, limiting the model to structurally valid sequences. This can make integration more reliable, but it cannot guarantee semantic correctness. A valid JSON object can still contain the wrong date.
Structural constraints and factual verification therefore complement each other. One checks that the output has the right shape; the other checks that the values are supported.
Cross-Domain Transfer Is Often About Shared Structure
A model trained on many domains can reuse patterns such as comparison, sequence, cause, category, exception and dependency. These abstract relationships appear in science, law, software, education and everyday planning.
For example, “X happens only if condition Y is met” appears in policy rules, program logic and scientific explanations. A model can learn to recognise conditional structure across surface forms.
This helps explain transfer without claiming that the model contains a human-like universal theory of reasoning. Shared statistical and structural patterns can support useful generalisation across tasks.
When Transfer Breaks
Transfer is weakest when the new task requires concepts or precision not supported by the model’s training, context or tools. A model that writes excellent prose may still fail at a specialised symbolic proof. A model that understands ordinary code may struggle with a rare language or proprietary API.
Transfer can also break when the surface form is misleading. A word problem can require mathematical structure that differs from its familiar vocabulary. A policy can use an ordinary word such as “approved” with a precise institutional meaning.
The repair is task-specific: better examples, domain context, retrieval, specialised models, tools or human expertise. The existence of broad capability should not make us ignore domain boundaries.
General Capability Does Not Remove the Need for Domain Expertise
A model can generate a medical-sounding explanation, legal-sounding clause or engineering calculation. The fluency of the language does not certify professional validity. Domains have standards, tacit knowledge, measurement requirements and accountability structures that exceed generic text generation.
The appropriate system can still use SI productively: retrieve authoritative material, draft documentation, surface alternatives, run calculations and prepare questions for review. The domain professional retains responsibility for judgments that require qualified expertise.
This is a key difference between assistance and authority. The model’s broad interface can make specialised work easier to navigate without making every user or model a certified specialist.
Why Tools Can Make a Language Model Look Like a Different Kind of Machine
Connect a calculator and the system becomes better at arithmetic. Connect a browser and it gains current information access. Connect a database and it can answer organisation-specific queries. Connect a code runner and it can test programs. Connect image generation and it can produce visual assets.
The visible user experience may make all of these look like one intelligence. Architecturally, they are a coordinated system. The model selects or interprets operations; the tools perform specialised work.
This distinction protects evaluation. If a system answers a current question because search found the relevant page, we should test retrieval quality. If it solves an equation by running code, we should inspect the constructed equation and execution result.
A Full SI Task Decomposition Exercise
Task: “Read this school event notice, create a parent-friendly summary, extract the date and location, check whether the date is a public holiday, and save a draft message.” Which capabilities belong to the model and which belong elsewhere?
The model can summarise the notice and extract candidate date and location fields. A date parser can validate the date format. A current holiday lookup is an external information tool because holiday calendars change by jurisdiction and year. A file or messaging tool creates the draft object.
Verification checks that the summary matches the notice, the parsed date is correct, the holiday result came from the relevant jurisdiction and the saved draft exists. The model coordinates much of the task, but the complete capability emerges from several components.
A Measurement Framework for General-Purpose Models
To evaluate a broadly capable model, begin with task families rather than a single grand score. Family 1: transformation—rewrite, translate, summarise. Family 2: extraction—identify fields and entities. Family 3: classification—select labels. Family 4: generation—draft new material under constraints.
Family 5: reasoning—combine information to reach a conclusion. Family 6: code—generate, explain and repair programs. Family 7: tool use—select valid operations and interpret results. Family 8: long-context work—compare or synthesise across many sources.
For each family, define representative tasks and failure conditions. A system can be strong in one family and weak in another. The goal is to map capability, not to force every dimension into a single intelligence number.
Independent Exercise 5: Schema Versus Meaning
A model returns valid JSON for an event but places the venue inside the date field. Did structural validation solve the task?
Answer
No. The structure is syntactically valid, but the semantic mapping is wrong. Structural validation and factual or semantic validation are separate checks.
Independent Exercise 6: Broad Capability or Tool Help?
An assistant answers a difficult multiplication problem exactly after calling a calculator. What can you conclude about the complete system, and what can you not conclude about the model alone?
Answer
You can conclude that the system successfully used an arithmetic tool for that case if the call and result are verified. You cannot conclude that the model itself performed the exact multiplication internally.
Independent Exercise 7: Current Information
A model accurately explains a policy that was updated yesterday because the application retrieved today’s policy page. Did the model weights need to change?
Answer
No. Retrieval can provide current information at inference time. The model can interpret the newly supplied evidence without being retrained on that policy update.
Independent Exercise 8: Transfer Failure
A general model can explain ordinary algebra but repeatedly fails a specialised symbolic manipulation task even with clear examples. What are reasonable next steps?
Answer
Evaluate a specialised model or tool, add deterministic symbolic computation, improve task representation and keep human review where necessary. Broad language ability does not guarantee expert performance in every formal domain.
Frequently Asked Questions About Why LLMs Can Do More Than Language
Are LLMs only next-token predictors?
Autoregressive LLMs generate by predicting next-token distributions, but that mechanism can support complex task behaviour when the context represents instructions, examples, code and structured data. The model is also embedded in an application that may add tools and retrieval.
Why can an LLM write code?
Code is a tokenizable symbolic sequence with recurring syntax and semantics. Models trained on code can learn patterns that support code generation. Execution and testing remain separate responsibilities.
Why can an LLM classify text?
Classification can be represented as a sequence transformation from input text to one of a small set of labels. Instruction-following models can perform this through constrained generation.
Can an LLM replace databases?
No. A model can help query, transform or explain data, but authoritative current state is better maintained in databases or other explicit records.
Can an LLM replace calculators?
It can solve many arithmetic problems, but exact calculations are often better delegated to deterministic tools. The model remains useful for interpreting the problem and constructing the calculation.
Does multimodal AI still count as a language model?
Products and research systems use different architectures and names. Some multimodal systems combine language-model components with visual or audio encoders. The article’s point is that SI can coordinate several representations; it does not require calling every component a language model.
Is generality the same as AGI?
No. Broad competence across many digital tasks does not by itself establish artificial general intelligence under any particular definition. The later AGI article will separate demonstrated task breadth from stronger theoretical claims.
Does tool use make the model smarter?
Tool use makes the overall system more capable by giving it access to operations or information outside the model. Whether we call that “smarter” informally, the engineering distinction remains: model capability and system capability are not identical.
What is the biggest limitation of treating everything as text?
Important structure can be lost. Tables, images, physical state and software permissions have relationships that may not survive naive text serialization. Good systems preserve the representation needed for the task.
Language Is the Interface; the System Is the Machine
The reason language models can do more than ordinary conversation is not that language magically contains every capability. It is that many digital tasks can be represented as structured sequences, and broad training allows one model to learn patterns that transfer across those representations.
The model can summarise, translate, classify, extract, draft code and propose plans. The surrounding system can retrieve current knowledge, execute calculations, run code, save files and verify results. Together they create a much broader capability than the phrase “text predictor” suggests.
The next step is to compare this learned, probabilistic style of computation with explicit programmed rules. Continue through the How Super Intelligence Works hub. Previous: 005 — Prediction, Probability and Uncertainty. Next: 007 — SI versus Traditional Software.