Agent interviews fall apart when the loop never stops

An agent interview can sound comfortable until the hiring manager asks how the loop ends. You have a model, a search tool and a function that can change something in production. The agent has called search 6 times, received nearly identical documents and still claims it needs one more pass. Who stops it, and what evidence do they use?

That question gets close to the job. Agent systems turn ordinary software decisions into a long chain where one weak decision can spread. The AI agents and RAG interview track lets you practice that chain with someone on the other side of it. The useful part is the follow-up, especially after your neat first answer meets a failed tool call.

Planning has to survive contact with a tool

“The agent makes a plan” sounds complete, but it is only a sketch. A plan needs a smallest next action, a condition for success, a condition for failure and a limit on how much work the system may do. I would rather hear a modest 4-step plan with explicit exits than a beautiful graph full of agents that can wander for an hour.

Task decomposition gets harder when a tool returns something plausible but incomplete. Suppose a research agent searches an internal knowledge base and finds an old refund policy. Does it accept the first result, issue a narrower query, compare the date with another source or ask a person? Your answer should connect the next action to the uncertainty in the current result. “Try again” is a retry policy with no brain attached, and the Planning and Task Decomposition session keeps pressing on that gap.

Recovery belongs in the original design. Name the failures you expect, such as a timeout, malformed output, missing permission or conflicting evidence. Then explain which failures deserve a retry and which should stop the run. If an agent can send email or issue a refund, an uncertain answer should get less freedom than a formatting task. That is judgment, and interviewers can hear when it came from building something rather than reading a framework page.

Memory needs an admission policy

Long-term memory gets uncomfortable once the system saves a wrong preference on Tuesday and treats it as fact for the next 6 months. A serious memory answer begins with what earns the right to be stored. User-confirmed facts, task state and temporary working notes have different lifetimes. They also need different deletion and correction rules.

Give the interviewer one example of a memory write you would reject. An agent may infer that a customer prefers a certain pricing plan because they clicked it once. Saving that inference as a durable preference would be reckless. Keep it as temporary context, attach provenance or wait for confirmation. This small example says more than naming 4 vector databases, which is why it belongs in the Agent Memory session.

Context windows create another tradeoff. A longer transcript can preserve useful detail while burying the current instruction under old tool output. Summarization may help, though it can also sand away the reason a decision was made. Sometimes the right fix is a smaller task with a clean handoff. Adding a summarizer agent by reflex often gives you another component to debug at 4:30am.

Retrieval may need a second attempt

Basic RAG usually has a fixed shape. The system retrieves documents and uses them to answer. Agentic RAG changes that shape by letting the model inspect the evidence, revise the query and retrieve again. That pattern is useful when the first search can be incomplete, but it needs a budget and a reason to continue.

An interviewer may ask what happens when the top chunks disagree. Talk about dates, source authority, document scope and whether the answer can wait for human review. Embeddings help find related text. They don’t decide which policy is current, whether a source is allowed or when evidence is strong enough to act.

Evaluation should match that shape. Check retrieval separately from the final answer. Record the query, returned document IDs, tool arguments, latency, cost and the decision that caused another retrieval. End-to-end accuracy alone leaves you guessing whether a bad answer came from search, context assembly or the model’s reasoning. The Agentic RAG session lives in this mess, where a 12-step run fails between steps 9 and 10.

Tool access changes the risk

Tool calling is an API design problem with an unpredictable caller. Schemas need tight fields, authentication should use the smallest useful permission and side effects need idempotency. If a payment tool times out after submitting a refund, the next call must determine whether the refund happened before trying again. Otherwise a routine retry becomes a finance incident.

Prompt injection belongs in the same discussion. Retrieved text is data, even when it contains sentences that look like instructions. A web page telling the agent to ignore prior rules should have no authority over the send-email function. Explain how you separate trusted instructions, untrusted content and tool permissions. “The system prompt says don’t” won’t carry much weight in a senior interview.

Multi-agent designs add coordination problems before they add intelligence. Say who assigns work, who owns shared state and what happens when 2 agents edit the same ticket. If they disagree, the system needs a resolution rule that does more than ask both of them again. MCP and A2A matter when the role involves tools or agents crossing product boundaries. For a small internal script, knowing when to skip that machinery is a perfectly good answer.

What the track asks you to practice

The track starts with what an agent is, then moves through tool calling, planning, memory, context engineering and RAG for agents. Later sessions deal with frameworks, multi-agent coordination, MCP and A2A, metacognition, self-correction, security and trust. Choose the sessions that match the posting and leave the rest of the catalog alone.

Before any practice session, write down one agent you could ship. List its tools, the state it keeps, the evidence it needs, the side effects it may cause and the point where it gives up. Put a cost or step bound on the run. Then let someone interrupt your design with a stale document, a timeout and an unauthorized request.

The best agent interview answers make restraint visible. They show where the system acts, where it checks and where it hands control back to a person. You can pressure-test those choices in the AI agents and RAG interview track, then return to your design and ask why the loop is still running.