Tool Calling & Agents · 2 to 3 hours
Implement a validated, tenant-scoped tool adapter
Implement a get_ticket adapter that validates model-proposed arguments, takes tenant scope from trusted context, and passes a fixture table, then explain how a bounded orchestrator handles timeouts, invalid calls, and parallel lookups.
3 h
1
Step 1: The question
Implement get_ticket with strict arguments and tenant-scoped access, and pass the fixture table. Then describe how an asynchronous orchestrator would handle a lookup timeout, a model that keeps sending invalid arguments, and two parallel lookups where one fails.
Define the teaching contract
The tool is get_ticket. It accepts exactly one field, ticket_id, in the form TKT- followed by three digits. The authenticated context supplies tenant and canReadTickets. Records are keyed by tenant and ticket ID.
The result contains only ID, title, and status. An unregistered tool name returns unknown_tool, and arguments that break the contract return invalid_arguments. A caller without read permission receives forbidden, and a missing record returns not_found. The model cannot override tenant or grants through arguments.
The in-memory fixtures model two tenants with the same ticket ID to demonstrate why resource identity alone is insufficient.
| Store key | Stored ticket |
|---|---|
| alpha:TKT-104 | TKT-104, "Settings crash", open |
| beta:TKT-104 | TKT-104, "Private billing issue", closed |
Constraints
- Accept exactly one argument, ticket_id, in the form TKT- followed by three digits
- Tenant and read permission come only from the trusted context
- Return a copy with only id, title, and status, never the stored object
- Model turns and tool calls have separate budgets
Deliverables
- An executeTool implementation that passes the fixture table and the edge cases
- Orchestrator behavior for a lookup timeout, repeated invalid arguments, and two parallel lookups where one fails
- What a timeout does and does not prove
2
Step 2: Hints
Optional. Each hint gives a little more away.
3
Step 3: Work through it
Predict the outcome
Predict the fixture outcomes
Using the teaching contract, predict what executeTool returns for each call before you reveal the answers.
| Tool and arguments | Trusted context | Expected outcome |
|---|---|---|
| get_ticket, TKT-104 | alpha, read allowed | ? |
| get_ticket, TKT-104 | beta, read allowed | ? |
| get_ticket, TKT-999 | alpha, read allowed | ? |
| get_ticket, TKT-104 | alpha, read denied | ? |
| delete_ticket, TKT-104 | alpha, read allowed | ? |
| get_ticket, numeric ID 104 | alpha, read allowed | ? |
| get_ticket, TKT-104 plus tenant beta | alpha, read allowed | ? |
| get_ticket, null arguments | alpha, read allowed | ? |
Code exercise
Validated ticket adapter
Implement executeTool so every fixture row returns its expected outcome. Also handle an array, an empty object, an extra field, a four-digit ID, an unknown tenant, a permission denial, and a caller that mutates the returned ticket.
Expected
Every fixture row and edge case returns its expected result, and changing a returned ticket never changes the store.
Limitations
The context is assumed to come from verified application authentication. The string composite key is suitable only for these constrained fixtures; a production database should use an unambiguous tenant-qualified key or query predicate. The adapter has no network calls, writes, persistence, or concurrent permission changes, and those capabilities require additional behavior.
Kept in this browser. Saving your score below keeps a copy with it.
0 / 5000
4
Step 4: Reference answer
5
Step 5: Score yourself
Score each dimension 0, 1, or 2, then save the score to your history. Readiness thresholds are editorial estimates.
Grades your written answer against this rubric with your own AI provider key from Settings. It is a second opinion: the score you save is still yours.
0 of 10 · Scored 0 of 5 dimensions
Ready at 8 of 10, with no 0 in Tenant authorization
Kept in this browser until you sign up, then it moves to your account.
Complete this level when the adapter passes its fixtures and you can trace every execution to a validated call, trusted scope, result, and stopping rule.
Your saved scores
Practice saves and mock interview answers on this question, newest first.
No saved scores yet. Score every dimension, then save.
6
Step 6: Follow-up questions
An interviewer may ask these next.
Why reject a model-supplied tenant?
Is schema validation sufficient?
Why separate turn and call budgets?
Does a timeout cancel execution?
How do you handle out-of-order results?
Can all read calls run in parallel?
7