Free CCAR-F Exam Flashcards

Start with the simplest design that meets the requirement, then add agentic complexity only when the simpler approach fails measurable tests.

A strong baseline for many applications: retrieve relevant context, provide clear instructions and examples, and evaluate before adding loops or agents.

A model repeatedly plans, calls tools, observes results, and decides whether to continue. Use it when the path cannot be fully scripted.

Break a task into ordered steps where each model call feeds the next. It improves control when the workflow sequence is predictable.

Classify the input, then send it to the best specialized prompt, tool, model, or workflow. Use when inputs fall into known categories.

Run independent subtasks at the same time and combine results. It helps with speed or diverse checks when subtasks do not depend on each other.

One model decomposes work and delegates to worker calls or agents. Use when subtasks are dynamic and cannot be enumerated ahead of time.

One call produces an output and another evaluates it against criteria, creating feedback for revision. Useful when quality can be judged clearly.

Give each subagent a narrow role, clear tool access, and a bounded output contract. Broad overlapping roles create coordination failures.

Choose model capability based on task risk, ambiguity, latency, and cost. Use stronger models for complex reasoning and smaller models for routine steps.

A tool schema should name the action, define required inputs, constrain types, and make invalid calls hard for the model to produce.

The model relies on the tool name and description to decide when to call it. Ambiguous descriptions lead to wrong tool selection.

Return concise, structured errors that explain what failed and whether retry, correction, or escalation is appropriate.

Expose only the operations and data a workflow needs. Tool access should be scoped by role, environment, and user authorization.

Model Context Protocol standardizes how Claude connects to external tools, resources, and prompts through MCP servers.

Tools are callable actions exposed by an MCP server, such as querying a system, creating an object, or running a bounded operation.

Resources expose contextual data that a model can read, such as files, records, schemas, or documentation snippets.

Prompts are reusable prompt templates or workflows provided by an MCP server to guide common tasks.

stdio is commonly used for local MCP servers launched as subprocesses. It is simple for local developer workflows.

HTTP-based transport is better suited for remote services, hosted integrations, and network-accessible MCP servers.

CLAUDE.md captures durable project instructions, conventions, and constraints that Claude Code should follow across tasks.

settings.json controls local configuration such as permissions, tool behavior, and workflow defaults depending on the project setup.

Permissions determine which operations can run automatically and which require confirmation. Use stricter permissions for risky write or shell actions.

Slash commands package repeatable workflows so developers can trigger common project tasks with consistent instructions.

Hooks run configured actions at workflow points, such as validation, formatting, logging, or policy checks.

Headless or CI usage requires explicit prompts, predictable outputs, scoped permissions, and validation because no human is steering interactively.

The system prompt sets durable role, constraints, output expectations, and safety boundaries for the model.

State the goal, inputs, constraints, and success criteria. Missing criteria force the model to infer requirements.

Good examples show the model the desired style, format, level of detail, and edge-case handling.

Structured output asks the model to produce a predictable shape, often enforced by a schema or tool call for reliable parsing.

A schema should define required fields, types, enums, and nesting. This reduces parser failures and ambiguous responses.

Stop sequences end generation at predictable boundaries. They help prevent trailing text when exact parsing matters.

Use deeper reasoning for complex planning or trade-off decisions, not for simple extraction or deterministic formatting.

Long contexts can bury important instructions or exceed limits. Prioritize, summarize, and retrieve only the context needed for the task.

Prompt caching can reduce cost and latency when stable, repeated context is reused across requests.

Retrieval-augmented generation supplies relevant external context at request time instead of relying only on the model's stored knowledge.

Chunks should be large enough to preserve meaning but small enough to retrieve precisely. Poor chunking causes missing or noisy context.

A grounded workflow should cite or use retrieved context and refuse to invent details when the context is insufficient.

Retries help transient failures but should use limits, backoff, and idempotency safeguards to avoid repeated harmful actions.

Timeouts prevent workflows from hanging indefinitely. Set them based on expected tool latency and user experience requirements.

Evals measure whether the system performs the intended task reliably. They should cover realistic success cases and known failure modes.

Guardrails constrain unsafe, invalid, or out-of-scope behavior through prompts, tools, policies, validation, or human review.

Use human approval for high-impact actions, irreversible changes, sensitive data access, or uncertain model judgments.

Reduce latency by using smaller models where appropriate, caching, parallel independent calls, and limiting unnecessary context.

Control cost by routing simple tasks to cheaper models, trimming context, caching stable prompts, and avoiding needless agent loops.

Log inputs, tool calls, outputs, latency, cost, and errors at the right level so failures can be diagnosed without leaking sensitive data.

Treat retrieved or user-provided content as data, not instructions. Keep trusted system instructions separate and validate tool actions.

Limit what data enters prompts, redact where possible, and scope tools so the model cannot access data unrelated to the task.

Document why a model, tool, prompt pattern, or agent design was chosen so future teams can evaluate trade-offs and changes.

Prefer answers that are simple, testable, least-privilege, observable, and reliable under failure conditions.