Core to Deep Dive
Practice production architecture decisions across orchestration, storage, sandboxes, budgets, multi-agent coordination, and recovery.
Depth
Showing 5 of 5 questions
Short answer
A production architecture needs an API and identity boundary, orchestrator, model gateway, tool registry, state and memory stores, retrieval, policy and approval controls, sandboxing where needed, observability, evaluation, and reliable job execution.
Interview-ready answer
I draw clear boundaries: the orchestrator owns state transitions and budgets; the model gateway handles providers, versions, retries, and usage; tools expose typed capabilities behind authorization; storage separates durable records from working state; and policy gates sensitive actions. Tracing and evaluation wrap every component. Queues, idempotency, cancellation, and dead-letter handling matter for long-running work, while fallbacks define how the system degrades when a model or dependency fails.
Common mistakes
Short answer
Use an agent when the path cannot be enumerated reliably and decisions benefit from language understanding or adaptive tool choice. Use a deterministic workflow when steps, rules, and failure handling are known and repeatability is more valuable.
Interview-ready answer
I prefer deterministic software for payments, authorization, compliance, and stable business processes. An agent is useful at uncertain boundaries such as interpreting a request, selecting among many information sources, or adapting a research plan. Hybrid systems are common: the agent proposes or routes, while a workflow executes validated states. The decision should consider error cost, observability, latency, evaluation coverage, and how often the process changes.
Common mistakes
Short answer
Use authenticated session state for active turns, a consent-aware durable memory service for verified facts and preferences, retrieval scoped to the user, summarization for context budgets, and user controls for inspection and deletion.
Interview-ready answer
The request loads recent session state and retrieves a small set of relevant durable memories using user, task, freshness, and sensitivity filters. The orchestrator builds context, runs the agent, and records trace events. After the response, a memory pipeline proposes candidate facts, deduplicates and classifies them, and writes only those allowed by policy or confirmed by the user. Every record has provenance, timestamps, version, and deletion semantics, and evaluation includes stale and cross-user memory attacks.
Common mistakes
Short answer
Run generated code in ephemeral isolated sandboxes with strict CPU, memory, time, filesystem, process, and network limits. Use allow-listed dependencies, no production credentials, sanitized inputs and outputs, and complete execution auditing.
Interview-ready answer
The orchestrator submits code and test fixtures to a sandbox service through a typed job API. Each job receives a fresh image, non-root user, read-only base filesystem, temporary workspace, seccomp or equivalent process restrictions, and no network unless an explicit allow list is required. Secrets never enter the sandbox. A supervisor enforces wall-clock and resource limits, captures bounded output, destroys the environment, and returns a signed result. Abuse detection and queue isolation protect the platform itself.
Common mistakes
Short answer
Use a deterministic orchestrator that assigns bounded roles, validates messages, tracks shared state, enforces per-agent and global budgets, and owns retries and termination. Agents should not recursively create uncontrolled work.
Interview-ready answer
I would model the workflow as a state machine or durable job graph rather than free-form agent conversation. Each worker receives a typed task and scoped tools, returns a structured result, and emits trace events. The orchestrator applies idempotency, deadlines, retry policies by failure class, concurrency limits, and a global cost budget. Shared artifacts live in versioned storage rather than prompts. A verifier can assess outputs before progression, and terminal states include success, partial completion, blocked, timeout, and policy failure.
Common mistakes