AI / AI Agents & Skills Interview questions

An AI agent is a system where a language model decides, step by step, which actions to take to reach a goal, runs those actions through tools, and uses the results to pick the next step.

Unlike a single prompt-and-response call, the model controls the flow. It can search, read files, call APIs or write code, and it stops only when it judges the task done or a limit is reached.

A minimal agent is just three things: a model, a set of tools, and a loop that feeds tool results back to the model.

The agent loop is the repeated cycle in which the model reasons, calls a tool, observes the result and decides again until the task is finished.

1. Send the goal, tool definitions and history to the model.
2. The model replies with either a final answer or a tool call.
3. The application runs the requested tool.
4. The result is appended to the conversation.
5. Repeat until the model answers without a tool call, or a step limit hits.

flowchart LR
  A["Goal + history"] --> B["Model call"]
  B --> C{Tool call?}
  C -- Yes --> D["Run tool"]
  D --> E["Append result"]
  E --> B
  C -- No --> F["Final answer"]

Always add a maximum iteration count so a confused agent cannot loop forever.

Most agents are built from the same five parts, whatever framework wraps them.

Guardrails and logging usually sit around the loop rather than inside the model.

Tool use (also called function calling) lets a model request an action by emitting a structured call, a tool name plus JSON arguments, instead of plain text.

You describe each tool with a name, a description and a JSON schema for its inputs. The model never runs anything itself. Your code runs the tool and returns the output as a new message.

{
  "type": "tool_use",
  "name": "get_weather",
  "input": { "city": "Charlotte" }
}

This is what lets an agent search the web, query a database or edit files.

An agent skill is a packaged folder of instructions, and optionally scripts and reference files, that an agent loads on demand to do a specialized task well.

Think of it as an onboarding guide for one job, such as building a spreadsheet or reviewing a contract. The agent reads it only when the task calls for it, so it adds no cost to unrelated work.

Each skill has a short name and description that tell the agent when it applies.

SKILL.md is the entry-point file of a skill. It begins with YAML frontmatter holding the skill's name and description, followed by Markdown instructions.

---
name: invoice-review
description: Review supplier invoices for errors. Use when the user uploads an invoice or asks to check billing.
---
# Invoice review
1. Extract line items.
2. Compare totals against the purchase order.
3. Flag mismatches in a short table.

The frontmatter is always visible to the agent. The body is read only after the skill is chosen.

MCP is an open protocol, introduced by Anthropic, that standardizes how AI applications connect to external tools and data sources.

Instead of writing a custom integration for every app and service pair, a service exposes an MCP server and any MCP client can use it. Messages use JSON-RPC 2.0.

A server can offer three kinds of capability: tools (actions), resources (data to read) and prompts (reusable templates).

Two common transports are stdio, for servers running locally as a child process, and streamable HTTP, for remote servers. Many popular tools, such as file systems, databases and issue trackers, already have ready-made MCP servers.

ReAct (Reason + Act) is a prompting pattern where the model alternates between writing a short thought, taking an action, and reading the observation that comes back.

Thought: I need the user's order status.
Action: lookup_order(id=4821)
Observation: shipped, arrives Friday
Thought: I can answer now.
Answer: Your order ships Friday.

Reasoning guides which tool to use, and tool results keep the reasoning grounded in real data rather than guesses.

Modern APIs with native tool calling have largely absorbed this pattern, but the idea still holds: interleaving a brief rationale with tool results makes runs easier to debug, since you can read why each action was taken.

Agent memory is usually split by how long the information lives and where it is stored.

Long-term memory is often further described as episodic (past events), semantic (facts) and procedural (how to do things, which skills resemble).

In practice, most agents combine both. They keep the live task in context and write key facts, such as user preferences or finished steps, to a file or store they can reload in the next session.

A subagent is a separate agent instance, started by a parent agent to handle a focused subtask in its own fresh context window.

It gets its own instructions and sometimes a limited tool set. When it finishes, it returns a short result to the parent, not its whole working history.

That keeps the parent's context clean and lets independent subtasks, like searching three codebases, run in parallel.

Example: a code-review agent might spawn one subagent per changed module. Each reads its module in depth, then sends back a three-line verdict, so the parent never has to hold every file in its own context.

The system prompt is the standing instruction block sent with every model call. It defines the agent's role, rules, tool-use guidance, tone and output format.

For agents it also tells the model when to use each tool, when to ask the user for clarification, and when to stop. Because it is resent every turn, a bloated system prompt costs tokens each time.

Keep it specific and short, and move rarely used guidance into skills.

Example: "You are a billing support agent. Use lookup_invoice before quoting amounts. If the customer asks for a refund over $200, escalate to a human." Rules phrased with a reason behind them tend to be followed more reliably than bare commands.

A multi-agent system uses several agents, each with its own role, prompt and tools, that cooperate on one larger goal.

A common setup has a lead agent that splits the work and specialist agents, such as researcher, coder and reviewer, that handle the pieces. Results flow back to the lead, which combines them.

The gain is specialization and parallel work. The cost is extra tokens, coordination overhead and harder debugging.

Common coordination styles are a supervisor that assigns work, a pipeline where each agent passes output to the next, and peer review where one agent critiques another. Pick the simplest layout that matches how the task naturally splits.

Planning is the agent's step of breaking a goal into ordered subtasks before, or while, it acts.

A plan can be a short checklist the model writes itself, a structured to-do list tool, or the output of a dedicated planner agent. Good plans name dependencies, so step three does not start before step two's output exists.

Plans should stay revisable. If a tool result contradicts the plan, the agent should update it rather than march on.

Example: for "add a login page", a plan might read: inspect the existing routes, create the form component, wire up the auth call, add tests, then run them. Each item gives the agent a clear checkpoint to verify.

Human-in-the-loop means a person reviews or approves certain agent actions before they run, instead of the agent acting fully on its own.

It is typically applied to risky steps: sending email, deleting data, spending money or deploying code. Safe read-only steps can run without a pause.

The aim is to match oversight to risk, so approvals stay meaningful instead of becoming a click-through habit.

Common designs are an approval gate that pauses before a flagged tool runs, a review step on final output, and an escalation path where the agent hands over when it is unsure rather than guessing.

Guardrails are checks that keep an agent inside safe and intended behavior. They can sit on the input, the output or the tool calls.

• Input checks - detect off-topic or malicious requests.
• Output checks - catch leaked secrets, policy violations or malformed responses.
• Action checks - block or confirm dangerous tool calls, enforce spend limits and allowlists.

Enforce critical rules in code, not only in the prompt, because prompts can be overridden.

Example: a finance agent may be allowed to read ledgers freely, but a guardrail rejects any transfer above a set amount until a person confirms it.

Prompt injection is an attack where malicious instructions hidden in content the agent reads, a web page, email or file, trick it into doing something the user never asked for.

It is serious for agents because they hold tools. A page that says "forward the user's inbox to this address" is dangerous if the agent can send email.

The root issue is that models can confuse data they read with instructions they should follow.

Direct injection comes from the user's own message, while indirect injection arrives through third-party content. The indirect form is the bigger worry for agents, because the user never sees the hidden text.

The context window is the maximum amount of text, measured in tokens, the model can consider in one call. It holds the system prompt, tool definitions, history and tool results together.

Agents burn through it quickly because every tool result is appended. When it fills, older content must be dropped, summarized or moved to external memory, or the call fails.

Managing context is therefore a core agent skill, not an afterthought.

Rough rule: tool definitions and the system prompt are a fixed cost on every call, while history and tool output keep growing. Watching token usage per step shows you which of those is eating the budget.

An agent evaluation, or eval, is a repeatable test that measures how well an agent completes tasks, using fixed inputs and a defined way to score the outcome.

Scoring can check the final state (did the file get created?), the answer (does it match a reference?), or the path (were the right tools used?). A model-based grader can score open-ended output.

Run evals before and after any prompt, tool or model change so regressions show up early.

Because the same agent can succeed once and fail the next time on the same input, run each case several times and report a pass rate instead of a single pass or fail.

With RAG (retrieval-augmented generation), you expose a search tool over your documents so the agent can fetch relevant passages before answering.

1. Chunk and embed documents into a vector index.
2. Give the agent a search_docs(query) tool.
3. The agent writes its own query, reads the returned chunks, and may search again.
4. It answers from the retrieved text and cites the source.

This is "agentic RAG": the agent decides when and what to retrieve, rather than retrieval running blindly on every question.

Quality depends heavily on chunk size, embedding choice and how well the agent phrases its query. If answers look wrong, inspect what was retrieved before blaming the model.

Anthropic's guidance on building effective agents highlights a handful of reusable patterns.

• Prompt chaining - a fixed sequence of calls, each feeding the next.
• Routing - classify the input and send it to a specialized path.
• Parallelization - run independent subtasks at once, or vote across runs.
• Orchestrator-workers - a lead model delegates dynamic subtasks.
• Evaluator-optimizer - one model drafts, another critiques, in a loop.

Start with the simplest one that works and add complexity only when measurements justify it.

A chatbot responds to messages. An agent pursues a goal, and takes actions to get there.

The line blurs, since a chatbot with a search tool already behaves a little like an agent.

Example: asked to "book the cheapest flight to Denver", a chatbot lists tips, while an agent searches fares, compares them, asks for confirmation, and completes the booking through a booking tool.

The extra autonomy brings extra risk, so agents need limits, logging and approvals that chatbots rarely require.

In a workflow, your code defines the path: steps run in a predetermined order and the model fills in each step. In an agent, the model decides the path at run time.

Workflows are more predictable, cheaper and easier to test, so they suit tasks with known steps, like extract, validate, then save. Agents suit open-ended tasks where the number of steps cannot be known in advance, like fixing an unfamiliar bug.

A practical rule is to use a workflow whenever the steps are stable, and reach for an agent only when they are not.

Many production systems are hybrids: a workflow handles the stable outer steps, and an agent runs inside one step, such as research, where the path is unknown.

They solve different problems and often work together.

Example: an MCP tool connects to your CRM, and a skill explains your team's process for writing a renewal summary from that data.

The two are complementary rather than competing. A skill can even tell the agent which MCP tools to call and in what order, so one carries the procedure and the other carries the access.

Progressive disclosure means a skill reveals its content in layers, so the agent only pays the token cost for what the task needs.

1. Level 1: only each skill's name and description sit in the system prompt at startup.
2. Level 2: when a task matches, the agent reads the full SKILL.md body.
3. Level 3: extra files and scripts, referenced from SKILL.md, are opened or run only if required.

Because of this, you can install dozens of skills while keeping the base context small.

Example: with 40 skills installed and about 100 tokens of metadata each, startup costs roughly 4,000 tokens, instead of loading every full instruction set up front. Detailed content enters context only for the one or two skills actually used.

The description is the only part of a skill the agent sees before deciding to use it, so it acts as the trigger. If it is vague, the skill is missed. If it is too broad, the skill fires when it should not.

A good description states both what the skill does and when to use it, with the words a user would actually say.

Weak:   Helps with documents.
Strong: Create and edit Word (.docx) files. Use when the user
        asks for a Word document, memo or formatted report.

Test a description by writing five different ways a user might ask for the task and checking that the skill fires for each. Also write one near-miss request that should not trigger it.

The model reads the tool names, descriptions and parameter schemas in its context and picks the one that best fits the current step. There is no hidden router; it is the model's own judgment based on that text.

That is why description quality drives accuracy. Two tools with overlapping descriptions will be confused, and a tool whose description omits its limits will be misused.

You can steer the choice with clear descriptions, instructions in the system prompt, or by forcing a specific tool in the API when a step must happen.

Example: if the tools are search_orders and get_order, a description saying the second needs an exact order ID tells the model to use the first when it only has a customer name.

ReAct decides one step at a time, adapting after every observation. Plan-and-execute writes a full plan first and then carries it out, possibly with a cheaper model for execution.

Many real agents blend both: plan briefly, act in ReAct style, and replan when something breaks.

Choose ReAct for exploratory work where the next step depends on what you find, such as debugging. Choose plan-and-execute when the task is large but predictable, since the upfront plan is reviewable and keeps a long run on track.

Errors and context both accumulate. Each step has a small chance of going wrong, and over dozens of steps those chances compound.

Typical causes:

• Context bloat - old tool output crowds out the goal.
• Goal drift - the agent forgets the original request.
• Compounding mistakes - an early wrong assumption poisons later steps.
• Lost state - nothing records what is already done.

Mitigations include progress files, periodic summaries, checkpoints and verification after each major step.

If each step is 95% reliable, a 20-step task finishes cleanly only about a third of the time. That is why shorter chains, verification points and checkpoints matter more than raw model strength.

Return the error to the model as a clear, readable tool result instead of crashing the loop. A message like "File not found: report.csv. Available files: sales.csv" lets the model correct itself.

1. Catch exceptions in the tool wrapper.
2. Return a short message saying what failed and what to try.
3. Retry automatically only for transient errors such as timeouts.
4. Cap total retries so the agent cannot spin.

Avoid dumping raw stack traces. They waste tokens and rarely help the model.

Also distinguish error types. A transient error, such as a timeout, deserves a retry. A fixable error, such as a wrong argument, needs feedback. A fatal error, such as missing permission, should stop and report to the user.

Context compaction shrinks a long history so the agent can keep working. When usage nears a threshold, the older part of the conversation is summarized and replaced with that summary.

A good summary keeps the goal, decisions made, files changed, open problems and next steps. It drops raw tool output that is no longer needed.

Related techniques include clearing stale tool results, and writing notes to an external file so facts survive even after the context is trimmed.

Compaction trades detail for room, so tune it. Summarizing too early loses useful facts, while summarizing too late risks hitting the limit mid-step. Many setups trigger it at a fixed share of the window, such as when usage passes roughly 80%.

Use multiple agents when the work is parallelizable, needs separate contexts, or benefits from specialized instructions. Otherwise a single agent with good tools is simpler and cheaper.

• Breadth tasks - researching many independent sources at once.
• Context isolation - a noisy subtask would flood the main context.
• Distinct roles - a reviewer that should not share the author's assumptions.

Avoid it for tightly coupled work where every step depends on shared state. Coordination costs and extra tokens will outweigh the gain.

Before splitting, measure a single-agent baseline. If one agent with better tools already hits your quality target, the multi-agent version only adds cost, latency and more places for things to go wrong.

In the orchestrator-worker pattern, a lead model analyzes the request, decides at run time which subtasks are needed, hands each to a worker, and then synthesizes the results.

flowchart TD
  U["User request"] --> O[Orchestrator]
  O --> W1["Worker: subtask A"]
  O --> W2["Worker: subtask B"]
  O --> W3["Worker: subtask C"]
  W1 --> S["Orchestrator synthesizes"]
  W2 --> S
  W3 --> S
  S --> R["Final answer"]

It differs from plain parallelization because the subtasks are not fixed in advance. The orchestrator chooses them based on the input, which suits things like multi-file code changes or broad research.

Give each worker a clear objective, an output format and the tools it needs. Vague delegation leads to duplicated or missed work.

Design tools the way you would design an API for a new teammate who cannot ask questions: clear, narrow and forgiving.

1. Give it a precise name and a description covering when to use it and its limits.
2. Keep parameters few, typed and documented, with examples for tricky formats.
3. Return concise, relevant output. Trim noise, and use readable names instead of opaque IDs.
4. Make errors instructive, saying how to fix the call.
5. Combine chatty low-level calls into one task-level tool when they are always used together.

Test by watching real agent runs. Wherever the model misuses a tool, the fix is usually in the description or the output.

No single fix exists, so layer several defenses and assume some injections will get through.

• Least privilege - give the agent only the tools and data the task needs.
• Separate trust levels - treat fetched content as data, and label it clearly as untrusted.
• Confirm risky actions - require human approval for sends, deletes and payments.
• Break the "lethal trifecta" - avoid combining private data, untrusted content and an outbound channel in one session.
• Monitor and filter - scan inputs and outputs, and log all tool calls.

The strongest protection is architectural: limit what a hijacked agent could possibly do.

Start with a set of realistic tasks, each with a clear success condition, and run the agent on them repeatedly. Agents are non-deterministic, so one pass proves little.

Grade the outcome rather than a required path, or you will punish valid alternative solutions.

Include hard cases: ambiguous requests, missing data, tools that fail, and attempts to push the agent off task. Easy tasks alone will make almost any agent look good.

Make the tool idempotent: calling it twice with the same input should leave the system in the same state as calling it once.

• Pass an idempotency key with writes such as payments or order creation, so the server ignores duplicates.
• Prefer "set status to shipped" over "increment shipped count".
• Check existence first, for example create-if-not-exists.
• Return the existing result when a duplicate is detected.

This matters because agents retry after timeouts and may not know whether the first attempt succeeded.

Example: a create-invoice tool takes idempotency_key = order-4821. If the first call times out and the agent retries, the server recognizes the key and returns the invoice already created instead of billing twice.

Skills change behavior through readable instructions, so they are faster, cheaper and easier to maintain than retraining a model.

Fine-tuning still makes sense for deep style changes or high-volume narrow tasks, but for team procedures and domain know-how, skills are usually the better first choice.

The two also combine well. A skill can capture the team's evolving procedures, while a fine-tuned model, if you have one, supplies baseline domain fluency or tone.

Most of an agent's cost comes from repeatedly resending a growing context, so attack that first.

1. Prompt caching - cache the stable prefix (system prompt, tools) so repeat calls are cheaper and faster.
2. Trim tool output - return only the fields the model needs.
3. Parallel tool calls - run independent calls together to cut wall time.
4. Right-size models - use a smaller model for simple subagents or routing.
5. Skills over bloated prompts - load instructions only when relevant.
6. Step limits - stop runaway loops early.

Measure before tuning. Log tokens per step and per tool, find the top cost driver, and fix that first. Caching and output trimming are usually the cheapest wins, and model downsizing needs an eval to confirm quality holds.

Read the trace first. Looping nearly always shows up as the same tool call repeated with the same or slightly changed arguments.

1. Find the repeat. Which call, and what result came back each time?
2. Check the result. Often the tool returns an unhelpful or empty response, so the model keeps trying.
3. Improve feedback. Make the error say what to change, or say clearly that nothing exists.
4. Clarify the stop condition in the instructions.
5. Add guards: a max step count and detection of repeated identical calls that forces a replan or escalation to a human.

A frequent real cause is a search tool that returns zero results with no explanation, so the model keeps rephrasing. A message such as "0 matches in 1,200 files; try a broader term" often breaks the cycle on its own.

A skill invocation is a short chain of decisions, and the agent only reads what it needs at each stage.

flowchart TD
  A["Startup: load skill names + descriptions"] --> B["User request arrives"]
  B --> C{Description matches task?}
  C -- No --> G["Answer without skill"]
  C -- Yes --> D["Read SKILL.md body"]
  D --> E{Needs extra files or scripts?}
  E -- Yes --> F["Open file or run script, only output enters context"]
  E -- No --> H["Follow instructions"]
  F --> H
  H --> I["Final result"]

The match in step three is the model's judgment against the descriptions. Script source is not loaded into context; only its output is, which keeps long procedures cheap.

If a skill misfires, check step three first. Most selection problems trace back to a weak or overlapping description, not to the instructions in the body.

A task moves through setup, a repeating work cycle, and a wrap-up.

sequenceDiagram
  participant U as User
  participant R as Runtime
  participant M as Model
  participant T as Tool
  U->>R: Request
  R->>M: Prompt + tools + history
  M-->>R: Tool call
  R->>T: Execute
  T-->>R: Result
  R->>M: Append result
  M-->>R: Final answer
  R-->>U: Response

Between the first and last calls the loop may repeat many times. The runtime also enforces limits, logs each step, and may pause for human approval before risky tools. If context fills, it compacts history before the next model call.

Failure points sit at each hop: a model may pick the wrong tool, a tool may error or time out, or context may fill. Good runtimes handle each explicitly, with retries, feedback to the model, or compaction, and stop with a clear message when the step limit is reached.

Give the agent the minimum access that lets it finish the task, and nothing standing beyond it.

• Scope tools - expose only what the task needs, with read-only versions where possible.
• Scope credentials - use short-lived, narrowly scoped tokens, not a personal admin key.
• Scope the environment - run in a sandbox with limited file paths and an allowlist of network domains.
• Gate escalation - require approval to widen permissions mid-task.

Assume the agent can be manipulated. Permissions then bound the worst case.

Example: an agent that summarizes support tickets needs read access to the ticket system only. Giving it write or delete access for convenience turns a hijacked session into a data-loss incident. Review permissions on a schedule, since tools added later tend to widen access quietly.

Since the context window disappears when a session ends, anything worth keeping must be written outside it.

• Progress files - a plain text or JSON file listing done, pending and blocked items.
• Memory stores - key-value or vector stores for user facts and past decisions.
• Version control - commits and notes that document what changed and why.

At the start of a new session, the agent reads these first to rebuild its bearings. Keep them short and structured, and update them as work is done, not only at the end.

Example progress file: done: [schema, API routes]; pending: [auth tests]; blocked: [staging credentials]. A fresh session reads that line and resumes at the right place without re-deriving everything. Avoid storing secrets in these files, because they are read back into context and may be logged.

Run them in parallel when they are independent, meaning no call needs another call's output, and when they are safe to run at the same time.

Parallel calls cut latency. Avoid them for writes that could conflict, or when rate limits would make bursts fail.

Most agent APIs let the model emit several tool calls in one turn. Your runtime then executes them concurrently and returns all results together, which makes the next model call one round trip instead of several. If one call in a parallel batch fails, return that error alongside the successes so the model can retry only the failed one.

Work from the cheapest check to the most involved.

1. Confirm it is installed and the folder structure and SKILL.md frontmatter are valid.
2. Read the description as if you were the model. Does it name the task and the words users say?
3. Test with an explicit request that clearly matches. If it still fails, the problem is likely loading, not wording.
4. Check for overlap with another skill whose description is broader and wins.
5. Rewrite and retest with several phrasings of the same request.

Remember that over-triggering is the opposite failure. If the skill fires on unrelated requests, narrow the description by naming the file types or situations where it applies. Keep a small test prompt set so every description edit can be checked quickly.

Record every step so you can replay a failed run exactly as the agent saw it.

• Trace each run with a run ID: prompts, model responses, tool calls, arguments, results and timing.
• Track metrics - success rate, steps per task, tokens, cost and error rate per tool.
• Sample and review real transcripts regularly, including successful ones.
• Turn failures into evals so the same bug cannot return unnoticed.

Redact secrets and personal data from logs, since traces contain everything the agent read.

Add alerts on signals such as unusual step counts, repeated identical calls, spikes in cost, and tool error rates. These often reveal a regression before users complain. Keep trace retention short and access-controlled, because transcripts can hold sensitive user data.

An MCP session starts with a handshake, then moves into discovery and calls, all as JSON-RPC messages over a transport such as stdio or streamable HTTP.

sequenceDiagram
  participant C as MCP Client
  participant S as MCP Server
  C->>S: initialize (capabilities)
  S-->>C: server capabilities
  C->>S: tools/list
  S-->>C: tool definitions
  C->>S: tools/call (name, arguments)
  S-->>C: result

The client's host application shows the discovered tool definitions to the model. When the model requests a tool, the client forwards it as tools/call, and the server's result goes back into the conversation.

Servers can also send notifications, for instance when their tool list changes, so a client can refresh what it shows the model. Capability negotiation in the first step means each side only uses features the other supports.

Every tool definition sits in the context, so a long tool list costs tokens on every call and gives the model more near-duplicates to confuse.

With dozens of tools, similar names and overlapping descriptions lead to wrong picks. Selection accuracy drops, and the model may skip the best tool for a mediocre one nearby.

Fixes include trimming to what the task needs, merging overlapping tools, grouping tools behind a router or subagent, and loading tool definitions on demand rather than all at once.

A useful target is to expose only the handful of tools a given task needs. If you truly need many, group them by domain and let a router or subagent pick the group first. Re-measure tool-selection accuracy in your evals each time you add a tool, so you notice the drop early.

The result is appended to the context in full, so a huge output can eat most of the window, push out the goal and instructions, raise cost, and in the worst case cause the call to fail for exceeding the limit.

It also hurts quality. Important details get buried and the model may miss them.

Design tools to prevent it: paginate, accept filters and limits, return summaries with a pointer to details, or save the bulk to a file and return only the path and a preview.

Example: instead of returning 10,000 log lines, a search_logs tool returns the 20 best matches, a total count, and a cursor for the next page. The model gets what it needs and can ask for more.

Scripts give a skill deterministic behavior for steps where the model should not improvise, such as parsing a file, validating a form or converting a format.

They also save tokens. The agent runs the script and only the output enters the context, rather than the model generating, or re-reading, the same code each time.

Bundle a script when the task is repetitive, error-prone to write from scratch, or needs exact output. Keep the SKILL.md focused on when to run it and how to interpret what it prints.

Example: a spreadsheet skill can include a script that recalculates formulas and reports any error cells. The agent runs it after every edit, so correctness checking never depends on the model remembering to do it.