Card 1 of 50
Front. Runtime. What is the agent runtime?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 50 cards in this deck
1.Runtime
What is the agent runtime?
The service that runs the loop: it calls the model, executes tools, enforces limits, stores state, and records traces.
2.Runs-tool
After the model emits a tool call, which component runs the tool?
The runtime. The model only outputs a request with a tool name and arguments.
3.Run-id
What is a run ID for?
A unique key for one agent run that ties together its model calls, tool calls, logs, costs, and final status.
4.Step-counter
Where is a run's step counter kept?
In the runtime's state for that run, not in the model. The model has no memory of how many steps have passed.
5.Run-state
What state does the runtime keep for a run?
The message history, step and token counts, pending tool calls, budgets used, and the run's status.
6.Durable
What is durable execution for agents?
Saving the run's state after each step, so a crash or redeploy can resume the run instead of starting over.
7.Resume-safe
Why must a resumed run not repeat completed writes?
Re-running a payment or email step would duplicate it. The runtime must record which tool calls already finished.
8.Idempotency
What is an idempotency key on a tool call?
A unique key sent with a write, so the receiving system ignores a repeat of the same request.
9.Registry
What is a tool registry?
The runtime's list of available tools with their names, schemas, versions, permissions, and handlers.
10.Namespaces
Why give tools namespaces?
So tools from different sources, such as two MCP servers, cannot clash on the same short name.
11.Ambiguous
The model emits a bare tool name that two namespaces both define. What should the runtime do?
Refuse to guess. Return an error naming the matches so the model can call the fully qualified name.
12.Unknown-tool
What should happen when the model calls a tool that does not exist?
The runtime returns an error observation listing that the tool is unknown. It must not crash the run.
13.Schema-check
Where are tool arguments checked against the schema?
In the runtime, before the handler runs. Invalid calls return a validation error to the model.
14.Schema-version
Why version tool schemas?
A changed schema can break saved prompts, evals, and resumed runs. Versions let old and new callers coexist.
15.Timeout
Why does every tool call need a timeout?
A hung tool would hold the run forever. The timeout turns it into an error the model and runtime can handle.
16.Retry-backoff
How should the runtime retry a transient tool failure?
A few times with exponential backoff and jitter, and only for safe or idempotent calls.
17.Rate-limit
The rate limit stops a call. What should the observation say?
That the call was not made because of a rate limit, and when it can be retried. It must not look like an empty result.
18.Empty-vs-error
Why must an empty result differ from an error?
'No rows found' is a fact the model can use. 'Query failed' means nothing is known. Mixing them leads to wrong conclusions.
19.Truncated-obs
An observation was shortened before the model call. What must the trace record?
That it was truncated, the original size, and what was kept, so a reader knows the model did not see the full result.
20.Budgets
What limits does a runtime enforce per run?
Maximum steps, tokens, wall-clock time, cost, and sometimes the number of calls to each tool.
21.Limit-stop
How should a run stopped by a limit be recorded?
With a distinct status, such as 'step limit reached', separate from success or error, so dashboards count it correctly.
22.Cancellation
What must happen when a user cancels a run?
The runtime stops issuing new calls, cancels in-flight work where possible, and records the run as cancelled.
23.Concurrency
Why limit concurrent runs per user or tenant?
To protect shared model capacity and downstream tools from one heavy user.
24.Parallel-calls
What must the runtime do with parallel tool calls?
Run them, wait for all results or timeouts, and return every result matched to its call ID.
25.Sandbox
Why run code-executing tools in a sandbox?
Model-written code can be wrong or malicious. A sandbox limits its files, network, CPU, and memory.
26.Egress
What is an egress policy for an agent sandbox?
Rules for which network destinations code may reach, blocking data exfiltration and unexpected calls.
27.Secrets
How should a tool get its credentials?
The runtime injects them into the tool handler. They never appear in the model's context or in traces.
28.Least-privilege
What is least privilege for agent tools?
Each tool's credentials allow only what that tool needs, such as read-only access for a search tool.
29.Trace
What is an agent trace?
A structured record of a run: each model call and tool call as a span, with inputs, outputs, timing, tokens, and errors.
30.Span
What is a span in tracing?
One timed operation with a start, end, attributes, and parent, so nested calls form a tree.
31.Otel
What is OpenTelemetry?
An open standard and set of libraries for producing traces, metrics, and logs that many backends can read.
32.No-trace
A finished run left no trace. What can a later reader not establish?
Which steps ran, what tools returned, what the model saw, and why the run ended.
33.Run-versions
What versions should each run record?
The model, prompt, tool schemas, skill files, and runtime config, so a result can be tied to exactly what produced it.
34.Replay
What is trace replay?
Re-running the model steps of a recorded run with the recorded tool results, to debug or test a prompt change.
35.Replay-limit
Why can a replay differ from the original run?
Sampling, a changed model version, or tool results that differ once the replay diverges from the recorded path.
36.Token-accounting
Why count tokens per step, not just per run?
To see which steps drive cost, such as large tool results being resent each turn.
37.Cost-attribution
What is cost attribution for agents?
Tagging each run's model and tool costs with its user, team, or feature, so spend can be tracked and capped.
38.Redaction
Why redact traces?
Prompts and tool results can contain personal data or secrets, which should not be stored or shown in full to everyone.
39.Retention
What is a trace retention policy?
How long traces are kept and who may read them, balancing debugging needs against privacy and storage cost.
40.Audit
What is an audit log for agent actions?
A tamper-resistant record of every write action: who triggered it, which tool, what arguments, and the result.
41.Approval
How does a human approval step work in the runtime?
The run pauses with its state saved, a person approves or rejects the proposed action, and the run resumes with that decision.
42.Fallback
What is a model fallback?
Switching to another model when the primary one errors or times out, with the switch recorded in the trace.
43.Circuit-breaker
What is a circuit breaker for a tool?
After repeated failures, the runtime stops calling the tool for a while and returns an immediate error, protecting both sides.
44.Session-ttl
What is a session TTL?
How long saved run or conversation state is kept before it expires and is deleted.
45.Eval-ci
Why run agent evals in CI?
So prompt, tool, or model changes are scored on a fixed task set before release, catching regressions early.
46.Canary
How should a prompt or model change be rolled out?
To a small share of traffic first, watching success, errors, and cost before widening.
47.Flags
Why put agent changes behind feature flags?
They can be turned off instantly without a redeploy if something goes wrong.
48.Slo
What SLOs make sense for an agent service?
Run success rate, latency percentiles, error rate by cause, and cost per run, each with a target.
49.Status-codes
Why give each run a final status code?
Success, failure, limit reached, cancelled, and awaiting approval need different handling and alerting.
50.Mcp
What does an MCP server provide to an agent runtime?
A standard way to list and call tools and read resources hosted by a separate process or service.