5 Agent Engineering Questions That Separate Builders from Buzzword Users

01 Tool Timeout: Dare You Retry?

The interviewer poses a concrete scenario: an API times out but may have already written data. A naive "add retry" answer is just the start. The candidate must explain how to determine whether the operation succeeded, then decide to query status, continue, or escalate to a human.

Parameter errors (wrong fields, types, ranges) should be validated in code first; retrying the same bad parameters ten times changes nothing. The real difficulty is not knowing what happened after a timeout . For read-only idempotent APIs, limited retries on transient faults are acceptable. For write operations (create ticket, submit order), the system must first query status by business ID. If the interface supports idempotency keys, reuse the same key on retry. When status cannot be confirmed, suspend the task or hand off to a human.

Follow-up question: "How does your system prevent a single user click from creating two orders?"

02 RAG Has the Answer, Why Can't It Find It?

Using the author's AI intelligent bidding system as an example: the tender says "bid validity period is 60 days" but the system reports "validity period not found." The author walks the retrieval chain with the manually confirmed original text.

Parsing and ingestion. Was the raw text extracted? Were scanned pages OCR'd? Do table values still align with headers?

Chunking and recall. Were "bid validity period" and "60 days" split into separate chunks? Did the correct chunk appear in the candidate results?

Reranking and assembly. Was the correct chunk pushed out during reranking? Is it still present in the final context sent to the model?

If the correct evidence already reached the model, the next step is to observe how the model uses that evidence. Separating these stages tells you whether to fix parsing, adjust retrieval, or rewrite the prompt.

03 At Turn 20, Why Did the Key Condition Disappear?

First inspect what was actually sent to the model in this turn . The earliest messages may have been truncated, the summary may have dropped constraints, or the memory may have been stored but not recalled in the current turn.

Example: the user first says "review only the technical bid," later mentions the pricing file. This review scope fits as task state, attached each turn as needed. Chit-chat can be compressed into summaries; cross-session preferences stored and retrieved per scenario.

Verification method: place the key condition in turn 1, insert a dozen irrelevant turns, then ask the Agent to execute the task. Check what it actually did and whether it had access to that condition at execution time.

04 Same Tool Called 10 Times, How to Stop?

Suppose the Agent repeatedly searches attachments with identical parameters, each returning empty results. Can the logs show at a glance that it's repeating the same action?

The author implements two guards in the executor: (1) detect consecutive calls with the same tool, same parameters, and no new results; (2) set step, time, and token budgets for the task. When a budget is hit, exit with the evidence gathered so far, optionally escalating to a human.

For debugging, stitch a single task's call chain linking tool, parameters, latency, result, and exit reason . If tokens are wasted re-injecting entire attachments each turn, only pass the currently needed fragments. For write, delete, or external send operations, permissions and human confirmation are enforced at the application layer.

05 Workflow Fails Mid-Way: Start Over?

Assume 20 attachments were already parsed, then the final report generation times out. On recovery, the system should reuse parsed results and re-run only the failed step.

Linear tasks can use a simple chain. When branches, human reviews, or interrupt/resume are needed, nodes and state must be explicit. Whether using LangGraph or a custom state machine, you must clearly explain where state is persisted, which step to resume from, and which operations have side effects if re-executed .

LangGraph state persistence reference:

https://docs.langchain.com/oss/python/langgraph/persistence

Agent Learning Path & Hands-On Projects

With basic Python and HTTP API knowledge, you can start building. Each milestone should have a runnable demo.

Model calling & structured output. Connect local Qwen3.6, convert a tender requirement into structured fields. Validate output with a schema; deliberately pass a result missing fields and observe handling.

Qwen3.6 model: https://huggingface.co/Qwen/Qwen3.6-35B-A3B

Tool calling & exception handling. Build a page-by-page document reader tool. Let the model choose tool and page number; the application validates and executes, then returns results to the model. Simulate parameter errors, interface timeouts, and empty results.

Document parsing & RAG. Use a set of de-identified tenders for page-traceable retrieval. Manually label a few correct evidence items; verify they enter top recall results and appear in the final context. Parsing flow:

State management & workflow recovery. Run "clause-by-clause review → evidence verification → summary." Interrupt mid-way and verify checkpoint recovery.

Evaluation & production. Build a test set with expected results covering missing evidence, scanned pages, duplicate clauses, and API exceptions. After every prompt or retrieval change, regress on the same set; record false positives, false negatives, duplicates, and latency.

To measure whether adding an Agent adds value: run the same failure samples twice, compare fixed retrieval vs. Agent-assisted re-query. Count how many evidence pieces the re-query actually recovered, how many false negatives it eliminated, and how much extra time it cost.