Oracle Agentic AI Foundations common mistakes
Oracle Agentic AI Foundations · Understand the traps and how to avoid them.
Treating an agent as a single LLM call with a longer prompt, so the candidate describes planning, tool use, and memory as one undifferentiated step and cannot distinguish where reasoning ends and execution begins.
Most candidates arrive from prompt-engineering or chatbot backgrounds where the model call is the whole system; the exam's architecture questions hinge on separating the reasoning loop (plan, act, observe, reflect) from deterministic orchestration and from external tool execution.
What to do instead
Practice drawing the loop explicitly: goal intake, plan decomposition, tool selection, action invocation, observation ingestion, reflection/replan, termination or handoff. For each stage, state what is LLM-driven versus code-driven, and where state is persisted. Be able to say which failure (hallucinated tool, infinite loop, premature stop) originates at which stage.
Confusing multi-agent patterns (supervisor/orchestrator, sequential pipeline, hierarchical delegation) with simple tool calling, and choosing a multi-agent topology when a single agent with tools would satisfy the requirement.
Vendor marketing and demos overrepresent multi-agent orchestration, so candidates pattern-match 'complex task' to 'many agents' without weighing added latency, cost, and coordination failure modes.
What to do instead
Learn a decision rule: use one agent with tools when the task is bounded and needs no role separation; add agents only when you need distinct tool scopes, separate context windows, independent review, or parallelizable subtasks. For each topology, memorize its characteristic failure (supervisor bottleneck, delegation loops, loss of shared context) and its observability implication.
Answering platform questions generically ('the platform provides agents and tools') instead of mapping requirements to specific Oracle service roles such as the agent runtime, model access, tool/function registration, knowledge/vector retrieval, and identity integration.
Candidates study agentic concepts abstractly and skim the Oracle service surface, so they cannot attribute a capability to the right component or explain how the pieces compose in a reference architecture.
What to do instead
Build a one-page component map: for each capability (agent definition, model inference, tool invocation, RAG retrieval, memory/state store, guardrails, logging, identity) name the Oracle component that owns it and one adjacent component it integrates with. Rehearse explaining an end-to-end request path through that map, including where authentication and policy checks occur.
Writing tool descriptions and parameter schemas that are vague or permissive (free-text 'query' strings, optional everything, no examples), then blaming the model when it selects the wrong tool or passes malformed arguments.
Candidates focus on the prompt and treat the tool spec as boilerplate; in practice tool name, description, parameter typing, enums, and required fields are the primary signal the model uses for selection and argument construction.
What to do instead
Rewrite tool specs as contracts: imperative name, one-sentence purpose, explicit when-to-use and when-not-to-use guidance, typed parameters with enums and required flags, and one worked example call. Design for disambiguation between similar tools by making descriptions mutually exclusive, and specify the error-return shape so the agent can recover rather than retry blindly.
Designing retrieval as 'embed everything and set top-k high', ignoring chunking strategy, metadata filters, hybrid search, reranking, and the difference between semantic similarity and answer relevance.
Vector search is easy to demo and hard to tune; candidates skip the retrieval-quality tradeoffs and then cannot explain why an agent answers confidently from irrelevant context or misses a document that exists in the corpus.
What to do instead
Learn the levers and their effects: chunk size and overlap versus context precision, metadata filtering for scoping and access control, hybrid keyword-plus-vector for exact identifiers, reranking to fix ordering, and citation/grounding checks to detect unsupported answers. Be able to diagnose a bad answer as a retrieval miss, a ranking problem, or a generation problem, and name the metric you would inspect for each.
Assuming the agent inherits the end user's permissions automatically, and designing retrieval or tool access without propagating user identity and enforcing row/document-level authorization at query time.
Prototypes run with a single service account, so authorization gaps stay invisible until production; the exam tests whether the candidate knows that the model must never be the enforcement point for access control.
What to do instead
State the principle explicitly: identity is propagated from the caller, policy is enforced in the data and tool layer, and the LLM only sees what the caller is entitled to see. For each tool and retrieval path, identify where the check happens and what happens on denial. Also cover prompt-injection defense as a separate control, since retrieved content is untrusted input, not instructions.
Treating guardrails as a single content filter at the input, omitting output validation, tool-call authorization, human-in-the-loop gates for irreversible actions, and audit logging of agent decisions.
Candidates equate responsible AI with moderation endpoints; agentic systems add action risk, so the control surface spans inputs, reasoning, tool execution, and outputs, and each needs its own check.
What to do instead
Enumerate controls by layer: input validation and injection screening, policy checks on planned tool calls, least-privilege tool credentials, confirmation gates for high-impact or irreversible operations, output grounding and PII checks, and immutable audit trails capturing the plan, tool arguments, and results. Be ready to justify which actions require human approval and why.
Describing observability as 'enable logging' without specifying what must be traced per agent run, and without distinguishing evaluation of the final answer from evaluation of intermediate steps.
Traditional APM captures requests and errors but not reasoning traces; candidates underestimate how much of agent debugging depends on reconstructing the plan, tool calls, retrieved context, and token/cost attribution for each step.
What to do instead
Define a trace schema: run ID, user identity, goal, each step's model input/output, tool name and arguments, latency, token and cost, retrieval document IDs, and final outcome. Pair it with an evaluation approach that scores trajectories as well as answers, plus regression suites of representative tasks and online monitors for loop detection, tool error rate, and escalation rate.
Ignoring lifecycle concerns such as prompt/agent versioning, model version pinning, canary rollout, and rollback, then being unable to answer how a behavior change is detected or reverted in production.
Agent definitions behave like code but are often edited in place by non-engineers; without versioned artifacts and evaluation gates, a prompt tweak silently degrades tool selection or safety behavior.
What to do instead
Treat agent configuration, prompts, tool schemas, and retrieval indexes as versioned artifacts promoted through environments with an evaluation gate before release. Know the rollout mechanics: shadow or canary traffic, metric thresholds for promotion, and a tested rollback path. Be able to explain how model deprecation or an index rebuild is handled without breaking live agents.
Hand-waving cost, latency, and reliability by assuming the agent will 'figure it out', instead of reasoning about token budgets, context growth across steps, retry and timeout policy, and idempotency of tool calls.
Demos run short happy-path tasks; production agents accumulate context per step, retry flaky tools, and can duplicate side effects, which candidates rarely model explicitly.
What to do instead
Estimate cost and latency per run as steps times per-step tokens and tool latency, and know the mitigations: context compaction or summarization, caching, parallel tool calls, step and token caps, bounded retries with backoff, circuit breakers, and idempotency keys for side-effecting tools. Practice identifying which of these a given scenario requires and what symptom appears if it is missing.