## Engineering terms: agents and AI

From Vibe Coding 101 (https://vibe-coding-101.brighteng.org/). When a request describes one of these problems, use the named technique, say its name, and run its check. Each term's page has the full entry and a prompt.

- **context engineering**: Select and maintain the information an agent needs for the current task. Use when: The agent keeps overlooking repository rules or working from obsolete assumptions. Do: Provide the requirement, relevant code, exact failure, and durable decisions; refresh them when context changes. Avoid: Restricting context so tightly that a relevant caller is never inspected.
- **tool calling**: Tool calling lets a model request a defined operation from an application. Use when: An assistant needs to query data or perform a bounded application action. Do: Expose a narrow schema, validate on the host, and return explicit success or failure. Avoid: Treating model-generated arguments as trusted application input.
- **human in the loop**: A person reviews a decision at a defined point in an automated workflow. Use when: An automated step needs human judgment before an external or irreversible action. Do: Place the gate immediately before the consequential action and show the concrete proposed change. Avoid: Asking for so many low-value confirmations that meaningful approvals become automatic.
- **evals**: An evaluation measures an AI system on a defined set of tasks and criteria. Use when: A prompt improvement helps a demo but may regress other cases. Do: Keep representative cases, failure cases, and held-out examples; compare under the same conditions. Avoid: Tuning repeatedly to the same examples while calling them unseen evaluation.
- **guardrails**: Enforce explicit limits around automated actions. Use when: An agent can reach tools or data beyond the task’s intended scope. Do: Decide which operations are allowed and enforce those decisions outside the model. Avoid: Describing a restriction in prose while leaving the underlying tool unrestricted.
- **diff review**: Review the changes introduced by a patch, including tests and configuration. Use when: A change looks correct in the final file but may have removed safeguards. Do: Inspect additions, deletions, affected callers, and the evidence for the intended behavior. Avoid: Reviewing only additions and overlooking a deleted validation check.
- **few-shot prompting**: Few-shot prompting provides worked examples of the desired task behavior. Use when: A natural-language instruction leaves the expected output format ambiguous. Do: Use a small consistent set and evaluate on different inputs. Avoid: Reusing the demonstrations as the entire evaluation set.
- **structured output**: Constrain model output to a defined structure and validate it at the boundary. Use when: Another program must consume the model’s output reliably. Do: Use supported schema constraints, then validate structure and task-specific rules before consuming the result. Avoid: Treating schema-valid claims as verified facts.
- **MCP**: Model Context Protocol standardizes how applications expose tools and context to AI clients. Use when: An AI client needs a reusable integration with an existing service. Do: Expose a small integration surface and enforce identity, validation, and permissions at execution. Avoid: Assuming protocol compatibility provides the service’s authorization policy.
- **sandbox**: A sandbox restricts the resources a process can access. Use when: Untrusted code or an agent must run with limited access. Do: Choose the allowed resources and verify both intended operations and blocked ones. Avoid: Disabling the entire boundary to work around one missing permission.
- **embedding**: An embedding represents data as a numerical vector for a particular model and task. Use when: An application needs semantic retrieval or similarity matching. Do: Keep compatible vectors together and evaluate retrieval with permissions and real examples. Avoid: Mixing vectors from incompatible models in one similarity space.
- **retrieval-augmented generation**: Retrieval-augmented generation supplies retrieved material to a model before it answers. Use when: An assistant must answer using private or changing application information. Do: Enforce retrieval access rules and evaluate both retrieved evidence and the resulting answer. Avoid: Using prompt instructions as the only tenant filter.
- **holdout set**: A holdout set is reserved for evaluating behavior beyond the examples used for development. Use when: An AI change needs evidence of generalization beyond its demonstrations. Do: Choose a split that matches deployment and protect it from iterative tuning. Avoid: Calling a repeatedly inspected and optimized set an untouched holdout.
- **baseline**: A baseline is a credible comparison under the same evaluation conditions. Use when: A new model or optimization reports a result with no useful comparator. Do: Run the current or simple alternative using the same cases, metrics, and resource accounting. Avoid: Weakening the baseline so the proposed approach wins by construction.
- **quantization**: Quantization represents model values with reduced numerical precision. Use when: A local model exceeds the available memory or latency budget. Do: Compare supported representations on the target runtime with representative tasks. Avoid: Testing quality on a tiny calibration sample that misses important production inputs.
- **repository instructions**: Repository instructions document conventions and commands an agent should use. Use when: Every new coding session rediscovers the same setup and checks. Do: Keep the instructions concise and verify the documented commands in the actual repository. Avoid: Treating an instruction file as a system-enforced security boundary.
