Three Concepts (AI Agent · Tool · Prompt Template ) — One Cohesive System

Calculating read time…

🤖

AGENT

The autonomous decision-maker. Receives a goal, reasons, plans, calls tools, adapts, and delivers results without step-by-step human instruction.

🔧

TOOL

The agent's hands. Any OIC integration, REST call, DB query, or AI service the agent can invoke to take real action in the enterprise world.

📝

PROMPT TEMPLATE

The agent's constitution. The reusable, parameterised document that shapes identity, rules, reasoning style, and output format for every session.

🎯 Section 1: The Hook — Why This Changes Everything

Imagine this: Your CFO sends a message at 8 AM — "Get me all high-risk AP invoices above ₹25 lakhs, check each against our supplier payment history, flag the anomalies, and notify the Finance Manager before the 9 AM risk review."

Before OIC Gen3, this meant: someone logged into Fusion, ran a report, exported to Excel, manually cross-referenced supplier history, composed emails, and hoped nothing fell through the cracks. That person's morning was gone. And tomorrow it would happen again.

✅ With OIC Gen3 Agent + Tool + Prompt Template: That entire workflow runs autonomously in under 90 seconds. The agent reads the goal, calls the Fusion AP tool to fetch invoices, calls the supplier history tool for each anomaly, uses a prompt template to structure its risk analysis, and sends a formatted Teams notification — all without a single human touching a keyboard.

That is not just automation. That is autonomous intelligence — built on three deceptively simple primitives. This article teaches you all three, from first principles to production deployment.

🏢 Section 2: The Business Problem OIC Gen3 Solves

Enterprise Oracle environments — Fusion Finance, HCM, SCM, CX — generate enormous operational workloads that follow intelligent patterns but require judgment at each decision point. Traditional OIC integrations automate data movement. But the judgment — "is this invoice suspicious?", "does this leave request need escalation?", "which supplier is a credit risk?" — still required human eyes on every case.

❌ The Old World

Scheduled batch jobs. Fixed rules. Rigid flows. If the rule didn't cover the case, the integration failed or routed to a human queue. Humans processed the same judgment 200 times a day.

⚠️ The Gap

OCI AI was available (Vision, Language, GenAI) but wiring it into Fusion workflows required deep custom code. No enterprise-grade framework. No reusable patterns. Every team reinvented the wheel separately.

✅ OIC Gen3 Answer

Agent + Tool + Prompt Template is a production-ready framework for autonomous, intelligent integrations — Oracle-native, SOX-compliant, and accessible to any OIC developer without building LLM infrastructure from scratch.

Business Process	Traditional OIC	OIC Gen3 Agent
AP Invoice Review	Batch fetch → fixed threshold → route to queue	Fetch → reason on risk pattern → flag anomalies → notify contextually
Supplier Onboarding	Form submission → manual review → email chain	Read docs → validate completeness → cross-check tax → raise targeted queries
Leave Approval	HCM trigger → manager email → manual decision	Check balance + project coverage + team capacity → recommend approve/defer with reasoning
Contract Expiry	Reminder email at 90/60/30 days	Analyse value + renewal risk + supplier performance → prepare negotiation brief → notify lead

💡 Section 3: Why Agent, Tool, and Prompt Template Matter in OIC Gen3

OIC Gen3 is not "OIC with AI bolted on." It is a fundamentally redesigned platform where AI is a first-class citizen of the integration runtime. Oracle rebuilt the execution model to natively support agentic workflows — where the integration is driven by LLM reasoning rather than a fixed graph of activities you design at build time.

💡 The Paradigm Shift: In classic OIC, you are the brain — you design every step, branch, and transformation at build time. In OIC Gen3 with Agents, the LLM is the brain — you define the goal, register the tools, write the prompt template, and the agent decides its execution plan at runtime based on what it encounters.

🏛️ Oracle-Native Stack

Agent, Tool, and Prompt Template are first-class objects in OIC Gen3's AI Agent Studio. The entire stack — LLM, tools, memory, guardrails — is managed inside OCI tenancy. No external dependencies.

🔗 OIC Flows = Tools

Your existing OIC integrations — Fusion REST, File Server, DB Adapter, REST Adapter — all become agent tools. Your investment in OIC flows is not wasted; it is upgraded into AI-callable capabilities.

⚓ Enterprise Guardrails

OCI IAM, OCI Vault, audit logging, human approval gates — all integrated. OIC Gen3 agents are not prototypes; they are enterprise systems that can pass SOX, GDPR, and internal audit requirements.

🎯 Faster Time-to-Value

Because tools are registered OIC flows and prompt templates are reusable objects, an OIC team that masters these three concepts can ship a production AI agent in days — not months of custom AI engineering.

🤖 Section 4: What Is an Agent? — Complete Deep Dive

An Agent in OIC Gen3 is an autonomous AI entity that receives a goal, reasons about how to achieve it, decides which tools to call, observes the results, adapts its plan, and continues until the goal is achieved or an iteration limit is reached — all without a human specifying each individual step.

💡 Beginner Mental Model: Think of an Agent as an extremely capable, autonomous employee you can give complex tasks in plain English — "Prepare the monthly AP exception report and notify the relevant managers" — and who will figure out every step, use every available tool, and return with the completed result. You manage their capabilities and boundaries. They manage their own execution.

🔄 The ReAct Loop — How an Agent Actually Works

Every OIC Gen3 agent operates on the ReAct (Reason + Act) loop. This is the heartbeat of agentic behaviour. Understanding this loop is the foundation of everything else in agent architecture.

🔄 The OIC Gen3 ReAct Loop — AP Invoice Risk Example

📥 GOAL RECEIVED: "Identify all high-risk AP invoices above ₹25L this week. Flag anomalies. Notify Finance Manager with a risk summary."

⬇️

🧠 THINK (Iteration 1): "I need to fetch this week's AP invoices above ₹25L. I have get_ap_invoices. I will call it with amount_threshold=2500000 and date_range=this_week."

⬇️

⚡ ACT: Calls OIC Tool → Fusion Finance AP REST API → Returns: 18 invoices. 3 from GlobalParts Ltd, same submission date, amounts just below split-invoice threshold.

⬇️

👁️ OBSERVE: "18 invoices found. GlobalParts Ltd pattern: same date + amounts just under approval threshold — possible invoice splitting. Need payment history for this supplier."

⬇️

🧠 THINK (Iteration 2): "Call get_supplier_history for GlobalParts Ltd. Run three-way match on all 18 invoices in parallel."

⬇️ Loop continues through iterations 3–6...

✅ GOAL ACHIEVED (Iteration 7): 15 invoices matched. 3 flagged as high-risk. Risk summary generated via Prompt Template. Finance Manager notified via Teams. OCI Audit log written. Session complete.

⚙️ Agent Anatomy — The 5 Core Components

🧠 LLM Reasoning Engine

OCI Generative AI model (Cohere Command R+ or Meta Llama 3) inside OCI tenancy. Reads goal, context, tool catalogue, and past observations. Generates next plan and tool call decisions. The brain of the system.

🔄 ReAct Loop Controller

Manages Think→Act→Observe→Adapt cycle. Tracks iteration count against the max_iterations limit. Detects goal completion or failure. Routes tool calls to the correct OIC integrations.

📋 Session State Manager

Holds all data for the current run: goal, context window content, tool call history, observations, iteration count, variables. Lives in OIC process memory for the agent session duration.

💾 Memory Manager

Short-term: current session context window. Long-term: OCI Object Storage — persists key learnings, user preferences, and past task outcomes across sessions. Loads relevant prior context at session start.

📝 Prompt Template Engine

Loads and renders the agent's prompt template at session start. Injects dynamic context — user goal, retrieved knowledge, prior results — before each LLM call. Defines the agent's personality and rules of engagement.

⚙️ Critical Agent Configuration Parameters

Parameter	What It Controls	Recommended Value	Risk If Wrong
`max_iterations`	Maximum ReAct loop cycles before forced stop	20–30 for complex tasks	Too high → runaway agent floods Fusion APIs
`temperature`	LLM creativity vs determinism	0.1 for finance/legal tasks	Too high → agent "creatively" invents actions
`max_tokens`	LLM response length limit per iteration	1,000–2,000	Too low → plan truncated mid-reasoning
`session_timeout`	Max wall-clock time for agent session	5–15 minutes	Too long → user hangs, OCI resources held
`memory_enabled`	Persist learnings across sessions	true for user-specific agents	Shared memory without isolation = data leakage

🤖 The Agent is the orchestrator — the brain that drives everything. It does not contain business logic. It contains intelligence. Your business logic lives in the Tools it calls and the rules defined in its Prompt Template.

🔧 Section 5: What Is a Tool? — Complete Deep Dive

A Tool is any external capability that an OIC Gen3 agent can invoke to take action or retrieve information from the real world. In OIC Gen3, every tool is backed by an OIC integration — a REST endpoint the agent calls when it decides that particular capability is needed to progress toward its goal.

💡 Beginner Mental Model: Tools are the agent's hands. Without tools, an agent can only produce words. With the right tools, it can query Fusion Finance, send Teams messages, post journal entries, trigger BPM workflows, call OCI Vision, and perform any action your existing OIC integrations support. If you have an OIC flow for it — you already have a tool.

🗂️ The Tool Classification System

Every tool you register with an OIC Gen3 agent must be classified. This classification is what the Guardrail Engine uses to determine whether the agent can execute it autonomously or whether it needs a human approval gate first.

🟢 READ Tools

Safe to call autonomously. No data mutation.

Examples:
• get_pending_invoices()
• get_supplier_history(id)
• check_leave_balance()
• search_knowledge_base(q)

✅ Agent: fully autonomous. No approval needed.

🟡 WRITE-REVERSIBLE Tools

Creates or updates data but can be corrected.

Examples:
• create_draft_invoice()
• flag_invoice_for_review()
• send_teams_alert()
• update_supplier_notes()

⚠️ Execute with audit log. Review within 24h.

🔴 WRITE-IRREVERSIBLE Tools

Permanent, financial, or compliance-critical.

Examples:
• post_gl_journal()
• approve_payment(amount)
• close_fiscal_period()
• terminate_contract()

🛑 HUMAN APPROVAL REQUIRED. Always.

📋 Anatomy of a Well-Registered Tool

The single most important element of any tool registration is the description field. This is the text the LLM reads when deciding whether to call this tool. Vague descriptions cause wrong tool selection. Precise descriptions produce accurate, efficient agent execution every time.

🔧 Complete Tool Registration — Production Standard

    {

      "name": "get_ap_invoices_by_risk",

      "description": "Retrieves Accounts Payable invoices from Oracle Fusion Finance for a specified business unit, minimum amount threshold, date range, and validation status. Returns invoice ID, supplier name, amount in base currency, submission date, current AP status, and 3-way match result. Use this tool when you need to find invoices requiring risk assessment, validation, anomaly detection, or financial review. Do NOT use for GL journal queries — use get_gl_balances for that purpose.",

      "classification": "READ",

      "oicEndpoint": "https://oic.oracle.com/ic/api/integration/v1/flows/rest/GET_AP_INVOICES_RISK/1.0",

      "parameters": {

        "businessUnit": { "type": "string", "required": true, "description": "Oracle BU code e.g. IN_CORP" },

        "minAmount": { "type": "number", "required": false, "description": "Minimum invoice amount in INR base currency" },

        "dateFrom": { "type": "string", "required": false, "description": "ISO 8601 date e.g. 2025-06-01" }

      },

      "returnMode": "SUMMARY", // Condensed payload to save context tokens

      "timeout_seconds": 30,

      "retry_on_failure": true,

      "max_retries": 3

    }

💡 Golden Rule for Tool Descriptions: [Action verb] + [Oracle data object] + [Oracle module] + [available filters] + [what it returns] + [when to use it] + [when NOT to use it]. The "when NOT to use" clause prevents the LLM from calling the wrong tool for similar-sounding tasks.

🔧 The Four Tool Design Principles

🎯 Principle 1 — One Tool, One Responsibility

Each tool does exactly one well-defined thing. get_invoice_with_history_and_notify() is a terrible tool design. Split it into get_invoice(), get_supplier_history(), and send_notification(). The agent will call them in the correct sequence.

🗜️ Principle 2 — Return Summaries, Not Full Payloads

A Fusion invoice JSON can be 8,000+ tokens. Set returnMode: SUMMARY. The agent needs the key fields — invoice_id, supplier, amount, status — not every FLEX field and audit trail entry. Token budget is precious and directly drives cost and latency.

🔒 Principle 3 — Never Expose Raw Fusion APIs Directly

The OIC integration behind each tool is the security boundary. It handles: OAuth token management via OCI Vault, response payload trimming, PII masking, rate limiting, retry logic, and audit logging. Raw Fusion APIs exposed directly to agents bypass all these controls.

🧪 Principle 4 — Test Each Tool in Isolation First

Before registering a tool with an agent, test the underlying OIC integration independently with real Fusion sandbox data. A tool that returns errors, empty payloads, or malformed JSON causes the agent to loop or hallucinate. The tool must be reliable before the agent can be reliable.

🔧 Tools are the interface between the agent's intelligence and your enterprise systems. A well-designed tool catalogue is what separates a fragile demo agent from a production-grade enterprise AI system.

📝 Section 6: What Is a Prompt Template? — Complete Deep Dive

A Prompt Template in OIC Gen3 is a reusable, parameterised document that defines the agent's identity, expertise, behavioural rules, output format requirements, and contextual instructions. It is loaded at session start and shapes every LLM call the agent makes throughout the session. Think of it as the agent's permanent job description combined with its rules of engagement.

💡 Beginner Mental Model: Before a new contractor starts work, you give them a briefing document: who they are in this context, what they're authorised to do, what they must never do, what format their deliverables should follow, and any special context they need. That briefing is your Prompt Template. The agent reads it first, every single session.

🏗️ Prompt Template Anatomy — The 7 Sections

① IDENTITY & PERSONA
Who the agent is. Domain expertise. Organisational context. Tone. E.g.: "You are AP-RiskAgent, an Oracle Fusion Finance AP Specialist with deep expertise in Accounts Payable processing, 3-way matching, and supplier risk assessment for InfraGroup India."

② SCOPE & MANDATE
Exactly what the agent is authorised to handle. E.g.: "You only answer questions and perform tasks related to Accounts Payable, invoice processing, and payment validation. You do not handle HCM, GL journals, or any non-Finance data. If asked about other domains, decline politely and redirect."

③ HARD RULES (NON-NEGOTIABLE)
Absolute constraints that must never be violated. E.g.: "NEVER recommend payment approval above ₹50L without explicit CFO confirmation. NEVER reveal invoice data from one business unit to a user authenticated for a different BU. ALWAYS log your reasoning at each step before calling a tool."

④ TOOL USAGE GUIDANCE
Summary of the tool catalogue with guidance on when to use which tool. Prevents wrong tool selection. E.g.: "Use get_ap_invoices for retrieving invoice data. Use get_supplier_history ONLY when a risk anomaly is detected. Use send_notification ONLY as the final step after all analysis is complete."

⑤ REASONING STYLE
How the agent should structure its thinking. E.g.: "Before calling any tool, explicitly state what you expect to find and why you are calling it. After each result, summarise what you learned before deciding the next step. Verify all numeric calculations by restating the formula and result."

⑥ REQUIRED OUTPUT FORMAT
The exact structure the final response must follow. E.g.: "Your final response MUST include: (1) Executive Summary in 3 sentences, (2) Risk Findings Table with columns: Invoice ID | Supplier | Amount | Risk Type | Recommended Action, (3) Next Steps ordered by priority, (4) Confidence: HIGH/MEDIUM/LOW with justification."

⑦ DYNAMIC CONTEXT PARAMETERS
Parameterised placeholders filled at runtime: {{user_name}}, {{business_unit}}, {{retrieved_policy_docs}}, {{current_date}}. These are what make one template serve all users, business units, and contexts without rewriting the entire document each time.

📝 Real Production Prompt Template — AP Risk Agent

  ## IDENTITY

  You are AP-RiskAgent, Oracle Fusion Finance AP Risk Specialist

  for {{business_unit}} at InfraGroup India.

  Authenticated user: {{user_name}} | Today: {{current_date}} | Session: {{session_id}}

  ## MANDATE

  You ONLY process Accounts Payable risk assessment requests. You do not handle

  GL, HCM, SCM, or any non-Finance domain. Decline other requests politely.

  ## HARD RULES — NEVER VIOLATE

  RULE 1: NEVER recommend payment approval above ₹50,00,000 without CFO confirmation.

  RULE 2: NEVER reveal data from BUs other than {{business_unit}}.

  RULE 3: ALWAYS state reasoning before calling any tool.

  RULE 4: If a tool returns an error, log it and try an alternative. Do not guess data.

  RULE 5: Numeric values from Fusion are authoritative. Never calculate amounts independently.

  ## POLICY CONTEXT (from Knowledge Base)

  {{retrieved_policy_docs}}

  ## REASONING PROTOCOL

  For every step: THINK (state intent) → ACT (call tool) → OBSERVE (summarise result)

  → ADAPT (update plan). Log each step. Verify invoice amounts numerically.

  ## YOUR TASK IS COMPLETE WHEN:

  All invoices have been assessed, anomalies flagged in Fusion, and Finance Manager

  notified with a structured risk summary following the output format below.

  ## REQUIRED OUTPUT FORMAT

  EXECUTIVE SUMMARY: [3 sentences max]

  RISK FINDINGS: Invoice ID | Supplier | Amount | Risk Type | Recommended Action

  NEXT STEPS: [Ordered by priority, most urgent first]

  CONFIDENCE: [HIGH/MEDIUM/LOW] — [Justification in 1 sentence]

📋 Prompt Template Design Rules

📌 Store in OCI Object Storage

Never hardcode prompt templates in OIC flows. Store in OCI Object Storage and load at session start. This enables version control, A/B testing, and policy updates without flow redeployment.

🧩 Parameterise Everything

Business unit, user name, date, role, retrieved docs — every contextual element should be a parameter. One well-parameterised template serves all users. A hardcoded template serves only one scenario.

📐 Specify Output Schema

Always define the exact output format. A structured output schema makes downstream OIC processing — parsing, routing, Teams notification formatting — reliable and fully deterministic.

🚧 Always Define Completion Signal

Without a clear "YOUR TASK IS COMPLETE WHEN..." clause, agents loop indefinitely trying to determine if they're done. This is one of the top causes of max_iterations being hit on simple tasks.

📝 The Prompt Template is the agent's constitution. It defines what it is, what it can do, what it must never do, and how it must communicate. A bad prompt template produces an unpredictable agent. A great one produces a trustworthy specialist.

🔗 Section 7: How Agent, Tool, and Prompt Template Work Together

Individually, each concept is powerful. Together, they form a complete, self-contained enterprise AI execution system. Here is exactly how the three interact during a live OIC Gen3 agent session.

🔗 Unified Execution Flow — All Three Working Together

── SESSION INITIATION ──

👤 Human / OIC Scheduled Trigger sends Goal + Context Parameters
"Review AP invoices for BU=IN_CORP, threshold=₹25L, week=this"

⬇️

📝 PROMPT TEMPLATE
Loaded from OCI Object Storage. Parameters injected: user_name, business_unit, current_date, retrieved_policy_docs. Agent identity and rules activated.

→

🤖 AGENT
Receives goal + rendered prompt template. LLM reads both. Begins ReAct loop. Generates first Think-Act plan based on available tools.

→

🔧 TOOLS
Agent selects and calls registered OIC tools. Results returned as SUMMARY payloads. Agent observes and adapts plan. Loop continues until goal achieved or iteration limit hit.

⬇️ Multiple ReAct iterations

✅ GOAL ACHIEVED: Agent generates final output using the Prompt Template's output format specification. OIC delivers formatted result to user/downstream system. Session ends. OCI Audit log written.

🛡️ SECURITY ENFORCED AT EVERY LAYER: OCI IAM (identity) · OCI Vault (secrets) · VCN Private Subnets (network isolation) · OCI Audit (immutable log) · OIC BPM Gates (on WRITE-IRREVERSIBLE tools)

Component	Role	Who Designs It	Changes When
🤖 Agent	Orchestrator — decides WHEN to call what and manages the loop	AI Architect (configures runtime params)	Scope changes, model upgrade, new capability type
🔧 Tool	Executor — does the actual work and interfaces with real systems	OIC Developer (builds the integration)	New Fusion module, external system, schema change
📝 Prompt Template	Rulebook — defines identity, constraints, reasoning, output format	Functional Analyst + OIC Architect	Policy change, compliance requirement, quality tuning

🏭 Section 8: Real Corporate Example — InfraGroup India AP Risk Agent

Company: InfraGroup India — a large infrastructure conglomerate with ₹8,000 Cr annual AP spend across 6 business units, running Oracle Fusion Finance on OIC Gen3.

Problem: The AP team spent 4 hours every Monday morning manually reviewing high-value invoices for risk: duplicate submissions, split invoicing, GRN mismatches, and suspicious supplier patterns. Manual, error-prone, and unscalable with 300% invoice volume growth projected.

Solution: OIC Gen3 AP Risk Agent with 7 registered tools, 1 parameterised prompt template, and a Monday morning OIC scheduled trigger.

🏭 InfraGroup AP Risk Agent — Complete Tool Catalogue

#	Tool Name	OIC Integration Behind It	Classification	When Agent Calls It
1	`get_weekly_invoices`	Fusion Finance AP REST (GET invoices)	🟢 READ	Always first — fetches the week's invoice list
2	`run_three_way_match`	OIC flow → Fusion PO + GRN match logic	🟢 READ	For each invoice above threshold
3	`get_supplier_history`	OIC flow → Fusion Supplier 360 REST	🟢 READ	When anomaly pattern detected
4	`detect_split_invoices`	OIC flow → custom DB query + OCI Analytics	🟢 READ	When same supplier has multiple invoices near threshold
5	`flag_invoice_for_review`	OIC flow → Fusion AP status update REST	🟡 WRITE-REV	After risk confirmed — before notification
6	`send_risk_notification`	OIC flow → MS Teams Webhook adapter	🟡 WRITE-REV	Always last — after all analysis complete
7	`search_ap_policy_kb`	OIC flow → OCI OpenSearch vector query	🟢 READ	When policy interpretation is needed

4 hrs

→ 90 seconds per weekly run

3×

More invoices reviewed per week than before

₹2.3Cr

Potential fraud caught in first 60 days

Manual errors in risk flagging post-automation

🛠️ Section 9: Step-by-Step Implementation in OIC Gen3

Provision OCI Infrastructure First

Create OCI Vault and store Fusion OAuth credentials, OpenSearch API key, Teams Webhook URL as secrets. Create OCI Object Storage bucket for prompt templates and agent memory. Create OCI IAM Policies granting OIC the minimum required permissions scoped to the Finance domain. Configure VCN private subnets so agent-to-Fusion traffic never crosses the public internet. Do this before writing a single OIC flow — security is the foundation, not an afterthought.

Build and Test Each OIC Integration (Tool Backend)

For each of the 7 tools: create an OIC REST-triggered integration. Connect to Fusion via the Oracle Applications adapter (OAuth managed by OCI Vault). Build the request transformation and response transformation. Add a XSLT/JavaScript transform step that produces a SUMMARY response with only 6–8 essential fields. Test each integration independently with real Fusion sandbox data using OIC Test Console. Verify empty results, error handling, and timeout behaviour. 100% pass rate before proceeding to tool registration.

Write and Upload the Prompt Template

Write the prompt template following the 7-section structure (Identity, Mandate, Hard Rules, Tool Guidance, Reasoning Style, Completion Signal, Output Format). Use {{double_curly_braces}} for all runtime parameters. Review it with both the technical architect (for rule completeness) and the functional analyst (for business accuracy). Upload to OCI Object Storage. Record the object URL — OIC will fetch it at session start.

Register Tools in OIC AI Agent Studio

Navigate to AI Agent Studio → Tools → Register Tool. For each tool: enter the name using the Golden Rule description format, set classification (READ/WRITE-REVERSIBLE/WRITE-IRREVERSIBLE), point to the OIC integration REST endpoint, define parameter schema with types and descriptions, set returnMode=SUMMARY, configure timeout=30s and retry settings. Test each registered tool from the Studio test panel using real parameters before building the agent.

Create and Configure the Agent

In AI Agent Studio → New Agent → Name: AP-RiskAgent. Select LLM: OCI Generative AI (Cohere Command R+). Set runtime parameters: max_iterations=25, temperature=0.1, max_tokens=1500, session_timeout=600. Point to Prompt Template OCI Object Storage URL. Assign all 7 registered tools. Set OCI IAM role with Finance-scope only policies. Enable OCI Logging for all agent sessions. Set memory_enabled=true with user-partitioned, encrypted storage in a dedicated OCI Object Storage bucket.

Configure Guardrails (Non-Negotiable)

In OIC BPM: create a Human Approval Step wired as a pre-execution gate on all WRITE-IRREVERSIBLE tools. The agent cannot call the underlying Fusion API without this gate's approval. In OCI API Gateway: set per-agent rate limits (max 100 tool calls/session, max 20/minute to any single tool). In OCI IAM: enforce Finance-scope policies so this agent cannot call HCM or SCM endpoints. Add OCI Content Filter for out-of-scope topic categories.

Set Up Trigger and Observability

Create an OIC Scheduled Integration that fires every Monday 7:30 AM IST. It builds the goal JSON (business_unit=IN_CORP, threshold=2500000, date_range=last_7_days) and invokes the agent. Configure OCI CloudGuard rules: sessions exceeding 40 tool calls trigger a PagerDuty alert immediately. Build an OCI Monitoring dashboard showing weekly token usage, average session duration, completion rate, and cost per session. Review this dashboard in the first team standup each week.

🧪 Section 10: Testing and Validation

🔧 Phase 1 — Tool Unit Tests

Test each OIC integration independently. Verify it connects to Fusion, returns SUMMARY format data, handles empty results gracefully, and logs correctly to OCI. Use OIC Test Console with live Fusion sandbox data. Do not proceed until 100% pass rate.

📝 Phase 2 — Prompt Template Tests

Test template rendering with all parameter combinations. Inject edge-case inputs: empty business unit, missing date, null retrieved docs. Verify all dynamic slots are correctly filled and the output format specification is clear and unambiguous to the LLM.

🤖 Phase 3 — Agent Integration Tests

Run 5 end-to-end scenarios in AI Agent Studio test panel: (1) Clean week — no anomalies, (2) One anomaly detected, (3) Multiple anomalies from same supplier, (4) No invoices above threshold, (5) Fusion API returns 503 error. Verify correct agent behaviour in each case.

🛡️ Phase 4 — Adversarial Tests

Test prompt injection: place instruction override text in an invoice description. Test scope bypass: ask the agent to retrieve HCM data. Test hallucination: ask about a non-existent PO. Verify all guardrails trigger correctly and return safe, graceful responses without exposing internal errors.

📊 Minimum Passing Criteria Before Production Go-Live

Test Category	Minimum Pass Rate	Measured By
Tool unit tests	100% — no exceptions	OIC Test Console reports
End-to-end agent scenarios	≥ 90% goal completion rate	OCI Logging session traces
Adversarial / injection tests	100% guardrail trigger rate	Manual review + OCI Audit
Average session duration	< 3 minutes for weekly run	OCI Monitoring dashboard
Average tokens per session	< 30,000 input + output combined	OCI GenAI Usage Logs

🚨 Section 11: Common Mistakes — and How to Avoid Them

💥 Mistake 1 — Vague Tool Descriptions

Description: "Gets invoices from Fusion." This is useless to the LLM when it has five other tools that also "get things from Fusion." It guesses. It calls the wrong tool. The agent loops. Fix: Follow the Golden Rule — Action + Object + Module + Filters + Returns + When to Use + When NOT to Use. The "when NOT to use" clause alone prevents 80% of tool confusion in multi-tool agents.

💥 Mistake 2 — Returning Full Fusion Payloads

Returning full Fusion invoice JSON (8,000+ tokens each) burns the context window after 2–3 tool calls. The agent loses earlier observations. Analysis quality degrades severely. Fix: Add an OIC XSLT or JavaScript transform step in every tool's OIC integration that produces a SUMMARY payload with only the 6–8 fields the agent actually needs.

💥 Mistake 3 — Hardcoding Prompt Templates in OIC Flows

Putting the prompt template text directly in OIC flow source code means every policy update requires a code change, retest, and full redeployment cycle. Prompt templates change 10× more often than flow logic. Fix: Store in OCI Object Storage. Load at session start via OIC REST invoke. Version the template files (v1.0, v1.1, v2.0). Roll back is simply changing the object reference.

💥 Mistake 4 — Setting max_iterations Too High

max_iterations=100 on a Finance Agent means a stuck agent can make 100 Fusion API calls before stopping, creating partial data states, orphaned BPM workflows, and a very expensive OCI GenAI bill. Fix: Start at max_iterations=20. Review average iterations in OCI Logging after the first 10 production runs. Increase incrementally with documented justification for each increment.

💥 Mistake 5 — No Completion Signal in Prompt Template

Without a clear "YOUR TASK IS COMPLETE WHEN..." clause, the LLM does not know when to stop. It continues generating steps, calling tools unnecessarily, and often hits max_iterations on tasks that should complete in 5. Fix: Always include an explicit completion condition in Section 7 of the prompt template, written in unambiguous language the LLM can evaluate against its current state.

💥 Mistake 6 — Relying Solely on Prompt-Level Guardrails

"I put the ₹50L approval limit in the prompt" is not a guardrail — it is a suggestion that a sophisticated input or edge-case LLM behaviour can override. Fix: Every financial constraint must be enforced at the architecture level — OIC BPM Human Approval Gate, OCI IAM Policy, and API Gateway rate limit — AND at the prompt level. Prompt text is the first defence. Architecture is the guarantee.

🏆 Section 12: Best Practices

✅ Agent Best Practices

One agent per business domain — never build a "do everything" agent
Set temperature=0.1 for transactional finance and HR tasks
Always define a clear goal completion signal in the prompt template
Start with max_iterations=20; tune upward only with evidence
Test with real Fusion sandbox data — never mock data only
Review OCI Logging after every production run for the first 4 weeks

✅ Tool Best Practices

One tool = one responsibility — never combine operations
Always return SUMMARY payloads — never full Fusion JSON
Classify every tool before registering with an agent
Include "when NOT to use" in every tool description
All secrets via OCI Vault — never in tool configuration text
Set timeout=30s and retry=3 on all tools that call Fusion REST

✅ Prompt Template Best Practices

Store in OCI Object Storage — never hardcode in flows
Version control every template file (v1.0, v1.1...)
Parameterise all contextual elements — no hardcoded values
Always define the exact output format schema
Include explicit completion signal — "task is complete when..."
Test template changes in a non-prod agent before promoting

Search This Blog