Capabilities in context

LLMs are especially useful where the input and output can be expressed as language or code. Common capabilities include:

• drafting, rewriting, and summarizing;
• classifying text into described categories;
• extracting fields into a requested structure;
• translating or changing tone;
• answering questions from supplied material;
• explaining concepts at different levels;
• generating, reviewing, or transforming code;
• proposing options and comparing tradeoffs.

These tasks share statistical structure. A summary resembles shorter texts paired with longer ones. Classification can be expressed as continuing with a category label. Translation is a sequence transformation conditioned by an instruction. Code has syntax and recurring relationships that can also be learned through prediction.

The model’s broad pretraining supplies patterns; post-training makes following instructions more likely; the current context selects the task.

In zero-shot use, you describe the task without giving examples:

Classify this review as positive, neutral, or negative. Return one label.

In few-shot use, you include examples:

“It arrived early and works well.” → positive
“The package came yesterday.” → neutral
“The hinge broke immediately.” → negative
“It is fine, but shipping took a month.” →

Examples teach the desired mapping inside the current context. They can clarify ambiguous labels, formatting, edge cases, and tone. This is called in-context learning: behavior adapts from material in the prompt without updating model weights.

The phrase “learning” can mislead. The examples influence this request and perhaps later messages that still include them. They do not normally become permanent training. Starting a fresh request without those examples removes their direct influence unless the application stores and reinserts them.

Good instructions define more than a topic. They specify:

1. Goal: what transformation or decision is required?
2. Inputs: which text or data should be used?
3. Constraints: what must be included, excluded, or left unchanged?
4. Output: what structure, length, or audience is expected?
5. Evidence policy: should the model use only supplied sources, cite passages, or state uncertainty?

Compare “Tell me about this contract” with “Using only the contract below, list each renewal date and quote the sentence that supports it. If no date is stated, return not specified.” The second request narrows the likely output and makes checking easier.

Prompt quality cannot create unavailable information. If the contract is missing, no clever wording gives the model dependable access to it. If the question requires today’s inventory, the application needs a current source or tool.

LLMs can often handle multi-step problems better when the task is decomposed. Asking for assumptions, intermediate calculations, a checklist, or a draft followed by verification can make relevant structure explicit in context.

For example, instead of:

Plan our event.

use:

Given the budget and attendance below, first list constraints, then propose two venue plans, calculate each total, and flag any missing inputs.

This does not prove the model reasons exactly as a human does. It describes a useful behavior: the generated sequence can represent intermediate steps that condition later tokens. Some models also perform hidden internal computation that products do not expose.

Do not require a model to reveal private “chain-of-thought” as proof. A concise rationale, cited evidence, executable calculation, or independently checked output is more useful than a persuasive internal-sounding narrative.

An LLM by itself generates tokens. Applications can connect it to tools that search documents, query databases, run code, use calculators, or call external services. The model may produce a structured tool request; the application executes it; the result returns to the context; then the model continues.

This division of labor is important:

• The model interprets language and proposes what to do.
• A retrieval system supplies selected source passages.
• A calculator or code runner performs exact operations.
• An application enforces permissions and validates actions.

Tool access can improve freshness and precision, but it adds failure modes. The model may choose the wrong tool, create bad arguments, or misunderstand the result. High-impact actions need validation, permission boundaries, and sometimes human approval.

“This model can summarize” is incomplete. Performance depends on document length, language, domain, requested format, model version, and what counts as a good summary. A model may excel on news articles yet omit obligations from contracts.

Evaluate the exact task with representative examples. Include ordinary cases, difficult cases, and cases where the right behavior is to abstain. Measure the properties that matter: factual coverage, label accuracy, valid structure, latency, cost, or user acceptance.

Capabilities also interact. A model that writes elegant prose may be weak at exact extraction. A model strong at coding may be unnecessary for email classification. Use public benchmarks to narrow candidates, then use your own evaluation to decide.