From Generation to Execution: A Practical Guide to 14 LLM Keywords

In 2025, the center of gravity for large language models is moving from generating content to completing tasks. Teams used to judge models mainly by parameter count and single-turn Q&A quality. Developers now care more about whether a model can break down a goal, call tools, keep executing, check results, and stay stable when information is incomplete.

The overview below lists 14 keywords, the core problem each one addresses, and the main risk or boundary of use. Use it to see which topics match your team, then read the matching section.

No.	Keyword	Core problem	Main risk or boundary
1	Reasoning	Reduce omissions and errors	Longer output is not more accurate
2	Model evaluation	Score models with business metrics	Public leaderboards do not replace your own data
3	Agents	Move from answers to execution	Needs saved state and human takeover
4	Coding agents	Change code safely	Depends on test coverage and code review
5	Command-line LLMs	Prevent mistaken commands	Writes need approval and rollback
6	Long-running tasks	Make multi-hour jobs recoverable	Re-runs can cause side effects
7	Inference cost control	Control compute spend	Over-compression lowers quality
8	Model mix	Assign models by task	Routing rules need regular checks
9	Multimodal editing	Edit images and documents in natural language	Copyright and privacy need review
10	Prompt engineering	Make output stable and controllable	Prompts need version control
11	Retrieval augmentation	Ground answers in sources	Bad retrieval becomes a wrong answer
12	Bias control	Find and manage inconsistent behavior	Needs ongoing sample monitoring
13	In-region model selection	Evaluate models against local constraints	Must include data location and compliance
14	Data and permission boundaries	Limit data exposure and overreach	Least privilege by default; open access only when needed

1. Reasoning: Judge quality with structure and checks

Reasoning means the model splits the problem, checks conditions, validates results, and plans a path before it answers. It fits tasks that need intermediate steps, such as math, code debugging, data analysis, and workflow orchestration.

Do not judge reasoning by answer length alone. In engineering, require a JSON object with fixed fields, then have a program check that the fields are complete and the values fall in a reasonable range. For example, require {"risk_level": "low|medium|high", "reason": "...", "steps": []}. If validation fails, request the output once more. If it still fails, hand the case to a person.

Acceptance criterion: on a labeled test set, both field completeness and result accuracy meet the thresholds the team set in advance.

2. Model evaluation: Replace gut feel with business data

Start evaluation by collecting 100 to 200 real business samples. Each sample includes the input, the reference answer, and the scoring rules. Report results by task type—for example, ticket classification accuracy, summary omission rate, and code test pass rate.

After every model or prompt change, rerun the same sample set and keep the history. If a key metric on the new version is worse than the old one, find the samples that regressed before you decide whether to ship.

3. Agents: From demos to something you can run

An agent is made of a model, tools, memory, task state, and an execution policy. Unlike a normal chat app, the user states a goal and the system splits it into steps and keeps moving.

A controllable flow looks like this: receive the goal, confirm constraints and success criteria, split subtasks, choose tools and validate parameters, execute and log, read results and revise the plan, verify the output, then submit the result—or ask a person to confirm high-risk steps.

Four mechanisms need to be in place:

• State saving: after each step, write task state with a step number, an input summary, an output summary, and a timestamp, so a stopped job can resume from the breakpoint.
• Failure retry: retry only retryable errors such as network timeouts and rate limits, at most three times, with backoff of 1 second, 2 seconds, then 4 seconds.
• Approval gates: delete, send, deploy, and permission changes require human confirmation.
• Human takeover: the task can be paused at any time so someone can inspect the current plan and the steps already run.

4. Coding agents: Small changes that can be rolled back

A coding agent covers understanding the requirement, searching the project, editing code, running tests, locating errors, and writing a change description. Developers then focus on defining the goal, reviewing the plan, and controlling quality.

Recommended practice:

1. Run in a separate branch or sandbox. Do not edit the main branch directly.
2. Lock dependency versions before commit—for example, keep package-lock.json or poetry.lock—so the model does not upgrade libraries on its own.
3. Write clear acceptance criteria, such as “API return values stay the same; new unit tests cover empty input.”
4. Keep each change to a small set of files. Run the project’s existing tests, such as pytest or npm test, then run static checks.
5. Have a person review dependency changes, permission code, data handling, and error branches.
6. Save each change as its own commit. If something goes wrong, roll back with git revert. Do not force-reset.

5. Command-line LLMs: Read-only by default

The command line fits server administration, log analysis, and deployment troubleshooting. Commands can be composed and scripted. A model can explain errors, draft query commands, summarize log patterns, and turn a natural-language goal into commands.

Read-only by default is the first line of defense. The model should propose read-only commands first—for example, grep ERROR <log file> or kubectl get pods -n <namespace>—and the user confirms before any write runs. An allowlist can permit only ls, grep, tail, and read-only queries. Deletes, overwrites, permission changes, and network configuration changes always go through approval.

Before a write, rehearse the impact in a non-production environment. For example, run SELECT COUNT(*) FROM <table> WHERE <condition>; to see how many rows would be affected, then decide whether to run a delete. The confirmation template should include:

Goal: <environment>/<database or service>/<object name>
Command: <command to run>
Scope: <objects and count expected to be affected>
Rollback: <backup location and restore command>
Risk: <low/medium/high>
Approver required: <role>

The runtime should use a read-only account or a least-privilege account, and the version should be explicit. A production write must have approval, a backup, and least privilege at the same time. If any one of those is missing, do not run it.

Audit logs should record at least: UTC timestamp, operator and session ID, original instruction and generated command, target environment identifier, approver and approval time, exit code and output summary, and whether a rollback ran. Mask passwords, tokens, and personal data in logs, and set retention according to company policy.

6. Long-running tasks: Make interruption recoverable

A long-running task is batch work that can take hours, such as bulk translation, data cleaning, or document review. The risk is that a failure in the middle, followed by a full rerun, writes or sends the same items twice.

Implementation points: give each subtask a unique idempotency key and check that the key does not already exist before writing a result; record a checkpoint after each batch; set a per-step timeout and put timed-out steps on a retry queue; at the end, produce a summary of succeeded, failed, and skipped items.

Acceptance criterion: after you interrupt the job on purpose and resume from the latest checkpoint, the final result matches an uninterrupted run and contains no duplicate items.

7. Inference cost control: Spend by task

Cost is driven by input tokens, output tokens, and the number of calls. Measure the cost of one run for each task type before you decide what to optimize first.

Four common moves: set a max_tokens cap on each request; cache repeated system prompts; send simple work such as classification and extraction to a smaller model; for long documents, retrieve or split first and send only the relevant segments. After each change, rerun the evaluation samples from section 2 to see whether quality dropped.

8. Model mix: Assign a model to the task

A model mix routes each request to a different model based on difficulty, latency, and cost. Simple classification can use a small model. Hard code changes can use a stronger model. Sensitive data can stay on a model deployed in your own environment.

Write routing rules as configuration and log every routing decision. Each month, sample the routing logs and confirm that hard tasks were not sent to a weaker model.

9. Multimodal editing: Change images and documents in natural language

Multimodal editing means using a text instruction to change an image, table, document, or audio. For example, the instruction “convert amounts in column three to thousands of yuan and keep two decimal places” should return the edited table and a description of what changed.

Example: the input is a spreadsheet file plus an instruction. The output is a new file plus a change list that names each edited cell and the value before and after.

Human review should check whether numbers and dates were changed by mistake, whether text inside images was replaced, and whether the original formatting was kept. For material that includes someone else’s work or personal data, confirm you have permission before upload, and mask faces, national ID numbers, and similar fields.

10. Prompt engineering: Make output stable and controllable

The goal is the same input producing output with a consistent structure. Three practices matter: specify the output format, give one or two positive examples and one negative example, and put prompts under version control.

After a prompt change, compare the old and new versions on the evaluation samples from section 2. If the format error rate rises sharply, roll the prompt back.

11. Retrieval augmentation: Make answers traceable

Retrieval augmentation means finding relevant passages in a knowledge base first, then having the model answer from those passages. Results depend on how you chunk text, how good retrieval is, and whether you require citations.

Requirements: every answer must cite source IDs; if retrieval returns nothing or relevance is below the threshold, the model should say it found no supporting source instead of answering from memory; periodically check that citations match the source text. A retrieval error becomes a wrong answer, so retrieval itself belongs in evaluation.

12. Bias control: Find inconsistent behavior

Bias here means the model’s answer to the same question changes with wording, order, or user identity. If the same résumé gets a clearly different score after only the name changes, that needs investigation.

Build a paired sample set: submit the same question with different wording and different order, and compare whether the conclusion stays the same. Resample in production every week. If the gap exceeds the threshold, notify the owner. First adjust the prompt or add rules. Change the model only if that is not enough.

13. In-region model selection: Judge by task and compliance together

There are many models, and public leaderboards disagree. Compare candidates on accuracy on your own business samples, price per call, response latency, context length, where data is stored, whether industry compliance requirements are met, and the provider’s availability commitment.

Run the same sample set on two or three candidates, build a comparison table, then pick a primary model and a backup using cost and compliance together.

14. Data and permission boundaries: Least privilege by default

The data and tool permissions a model can use should match the scope of the task. Common practice: give each agent its own service account; grant only the tables or APIs it needs; mask fields such as phone numbers and national ID numbers before they reach the model; filter retrieval results by user role.

The main overreach risk is tool calls. Before execution, check that parameters stay inside the allowed range—for example, queries limited to the current department’s data, and writes limited to a specified directory.

Checklist

• Success criteria and acceptance samples are defined.
• Output has a fixed format and is validated by a program.
• Writes have approval, backup, and a rollback path.
• Long-running tasks have checkpoints and idempotency keys.
• Answers cite sources, and the system refuses when there is no basis.
• Sensitive fields are masked before they enter the model.
• Evaluation samples are rerun after a model or prompt change.
• Logs record the operator, command, approval, and result, and sensitive data is masked.