These four concepts are the nervous system of any multi-agent OIC solution. Without them, you have a single chatbot. With them, you have an enterprise-grade autonomous system that can handle complex, multi-step Oracle Fusion workflows — across Finance, HCM, SCM, and Procurement — simultaneously, reliably, and safely.
This guide is entirely technical. Every concept is explained through a real OIC implementation you can follow step by step.
🏢 Master Scenario — ABC Corp Enterprise AI Platform:
ABC Corp has deployed OIC Gen3 with four specialist AI agents running inside a single OIC Project:
① Finance Agent — Handles AP invoices, GL queries, payment status (Fusion Finance)
② HR Agent — Handles leave, onboarding, policy questions (Fusion HCM)
③ Procurement Agent — Handles PO creation, supplier queries, 3-way match (Fusion SCM)
④ Compliance Agent — Cross-checks all actions against regulatory and internal policy
A user sends ONE message: "I need to onboard a new vendor GlobalParts Ltd, raise a PO for ₹80L, get it approved, and post the accrual to GL — all before month-end in 3 days."
How does OIC know which agent handles which part? How does each agent remember what happened in previous steps? How do they share results? How is the whole thing coordinated? That is exactly what this guide answers.
ABC Corp has deployed OIC Gen3 with four specialist AI agents running inside a single OIC Project:
① Finance Agent — Handles AP invoices, GL queries, payment status (Fusion Finance)
② HR Agent — Handles leave, onboarding, policy questions (Fusion HCM)
③ Procurement Agent — Handles PO creation, supplier queries, 3-way match (Fusion SCM)
④ Compliance Agent — Cross-checks all actions against regulatory and internal policy
A user sends ONE message: "I need to onboard a new vendor GlobalParts Ltd, raise a PO for ₹80L, get it approved, and post the accrual to GL — all before month-end in 3 days."
How does OIC know which agent handles which part? How does each agent remember what happened in previous steps? How do they share results? How is the whole thing coordinated? That is exactly what this guide answers.
⚙️ Four Technical Pillars of Multi-Agent OIC Gen3
🔀
Agent Routing
Who handles this request?
🧩
Context
What does the agent see?
🧠
Memory
What does it remember?
🎭
Orchestration
Who coordinates all agents?
🔀 Pillar 1: Agent Routing — How OIC Decides Which Agent Handles What
1.1 What Is Agent Routing and Why Does It Exist?
When a user sends a message to your OIC AI platform, the system needs to make a decision: which agent is responsible for this request? This decision — made in milliseconds, before any tool is called — is Agent Routing.
In a single-agent system, routing is trivial. In an enterprise system with 4+ specialist agents, routing is a critical architectural component. Get it wrong and a Finance question goes to the HR agent, which has no Fusion Finance tools, and the user gets a useless response.
💡 Technical Reality: In OIC Gen3, routing is implemented at two levels:
Level 1 — Orchestrator Agent routing: A master "Orchestrator Agent" reads the user message, classifies intent, and delegates to the correct specialist agent (sub-agent call).
Level 2 — Tool-level routing: Within a single agent, the LLM's ReAct loop routes each step to the correct tool (Fusion Finance API vs Fusion HCM API vs Knowledge Base).
Level 1 — Orchestrator Agent routing: A master "Orchestrator Agent" reads the user message, classifies intent, and delegates to the correct specialist agent (sub-agent call).
Level 2 — Tool-level routing: Within a single agent, the LLM's ReAct loop routes each step to the correct tool (Fusion Finance API vs Fusion HCM API vs Knowledge Base).
1.2 Three Routing Patterns in OIC Gen3 — With Real Examples
Pattern A — LLM Intent Classification Routing
How it works: The Orchestrator Agent's LLM reads the user message and classifies intent into a predefined taxonomy. Based on the classified intent, it calls the matching specialist agent as a sub-agent tool.
OIC Implementation: Orchestrator Agent has 4 tools, each a sub-agent invocation:
Best for: Clear domain boundaries. Finance ≠ HR ≠ SCM.
OIC Implementation: Orchestrator Agent has 4 tools, each a sub-agent invocation:
invoke_finance_agent() invoke_hr_agent()invoke_procurement_agent() invoke_compliance_agent()Best for: Clear domain boundaries. Finance ≠ HR ≠ SCM.
Pattern B — Keyword/Rule-Based Routing
How it works: Before the LLM sees the message, an OIC REST Trigger integration applies deterministic rules using XSLT/Assign Activities. Faster, cheaper, 100% predictable.
OIC Implementation: In a pre-agent OIC Orchestration flow:
Best for: High-volume, simple classification. Zero LLM cost for routing.
OIC Implementation: In a pre-agent OIC Orchestration flow:
if message contains "invoice" OR "AP" OR "payment" → Finance Agentif message contains "leave" OR "onboard" → HR AgentBest for: High-volume, simple classification. Zero LLM cost for routing.
Pattern C — Hybrid Routing (Rule + LLM Fallback)
How it works: OIC Router applies keyword rules first. High confidence → route directly. Ambiguous or multi-domain → hand off to Orchestrator Agent LLM for classification.
OIC Implementation:
Best for: Production systems. Minimises LLM cost while handling edge cases correctly.
OIC Implementation:
if keyword_match_score > 0.85 → direct routeelse → invoke Orchestrator Agent LLMBest for: Production systems. Minimises LLM cost while handling edge cases correctly.
1.3 Step-by-Step: Building Pattern C Hybrid Routing in OIC Gen3
🔧 Implementation — Hybrid Router Integration
1
Create the Router Integration:
Design → Integrations → + Create → Orchestration → Name:
Trigger: REST | Method: POST | Path:
Request body:
Design → Integrations → + Create → Orchestration → Name:
ABC_Agent_Router_v1Trigger: REST | Method: POST | Path:
/route-requestRequest body:
{ "user_message": "string", "session_id": "string", "user_id": "string" }
2
Add Assign Activity — Keyword Scoring:
After the REST trigger, add an Assign Activity named
After the REST trigger, add an Assign Activity named
Compute_Keyword_Scores. Use XPath/XSLT to compute a score for each domain:
finance_score = count of matches: ["invoice","AP","payment","GL",
"journal","payable","ledger","accrual"] in lower-case(user_message)
hr_score = count of matches: ["leave","onboard","employee","grade",
"salary","payroll","hcm","hire"]
procurement_score = count of matches: ["PO","vendor","supplier",
"purchase order","3-way match","GRN","contract"]
compliance_score = count of matches: ["policy","regulation","audit",
"sox","gdpr","approval limit","delegation"]
3
Add Switch Activity — Routing Decision:
Branch 1: max_score >= 3 AND single domain winner (Finance) → Condition: finance_score = max AND finance_score >= 3 → Action: Call Finance Agent OIC endpoint directly → Skip: Orchestrator LLM entirely (zero LLM cost) Branch 2: max_score >= 3 AND single domain winner (HR) → Call HR Agent OIC endpoint directly Branch 3: max_score >= 3 AND single domain winner (Procurement) → Call Procurement Agent OIC endpoint directly Branch 4 (Default — ambiguous or multi-domain): → Call Orchestrator Agent → Pass: full user_message + all domain scores as context → Orchestrator LLM makes the final routing decision
4
Live Routing Example — The ABC Corp Master Scenario:
User message: "I need to onboard a new vendor GlobalParts Ltd, raise a PO for ₹80L, get it approved, and post the accrual to GL"
Keyword scoring result:
→ Multi-domain detected (Finance + Procurement both score >= 2) → Branch 4 fires
→ Orchestrator Agent receives message + domain scores
→ Orchestrator LLM decides: "This is a multi-step cross-domain task. I will call Procurement Agent first, then Finance Agent sequentially."
User message: "I need to onboard a new vendor GlobalParts Ltd, raise a PO for ₹80L, get it approved, and post the accrual to GL"
Keyword scoring result:
finance_score: 2 (GL, accrual) procurement_score: 4 (vendor, PO, approved, purchase) compliance_score: 1 (approved)→ Multi-domain detected (Finance + Procurement both score >= 2) → Branch 4 fires
→ Orchestrator Agent receives message + domain scores
→ Orchestrator LLM decides: "This is a multi-step cross-domain task. I will call Procurement Agent first, then Finance Agent sequentially."
1.4 Routing Architecture
USER MESSAGE → OIC REST Entry Point
│
▼
┌────────────────────────────┐
│ ABC_Agent_Router_v1 │
│ (OIC Orchestration) │
│ │
│ ASSIGN: Keyword Scoring │
│ finance=2, proc=4, │
│ hr=0, compliance=1 │
│ │
│ SWITCH: Routing Decision │
└──────────┬─────────────────┘
│
┌─────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Single Single AMBIGUOUS /
Finance Procurement MULTI-DOMAIN
(score≥3) (score≥3) (any other)
│ │ │
▼ ▼ ▼
Finance Procurement ┌────────────┐
Agent Agent │Orchestrator│
endpoint endpoint │Agent (LLM) │
direct direct │ │
call call │ Decides: │
(no LLM (no LLM │ Sequential │
routing) routing) │ or Parallel│
└─────┬──────┘
│
┌────────────┼──────────────┐
▼ ▼ ▼
Finance Procurement Compliance
Agent Agent Agent
(accrual) (PO+vendor) (limits check)
1.5 How the Orchestrator Agent System Prompt Controls Routing
## ORCHESTRATOR AGENT — ROUTING INSTRUCTIONS You are the ABC Corp Master Orchestrator. Your ONLY job is to coordinate specialist agents. You do NOT answer business questions yourself. ## ROUTING RULES (follow exactly in this priority order) RULE 1 — SINGLE DOMAIN: If request is purely about AP invoices, GL, payments, accruals → Call invoke_finance_agent() with full user request → Do not split or modify the request RULE 2 — SINGLE DOMAIN: If request is purely about PO, vendor, sourcing, 3-way match → Call invoke_procurement_agent() RULE 3 — MULTI-DOMAIN (SEQUENTIAL): If request requires Procurement THEN Finance → Step 1: Call invoke_procurement_agent() — wait for result → Step 2: Pass procurement result as context to invoke_finance_agent() → This is SEQUENTIAL — never call both at same time for dependent tasks RULE 4 — MULTI-DOMAIN (PARALLEL): If request requires independent sub-tasks from multiple domains → Call both agents simultaneously (parallel tool calls) → Merge results before responding RULE 5 — COMPLIANCE GATE: For ANY action involving amounts above ₹50L → ALWAYS call invoke_compliance_agent() FIRST → Only proceed with other agents after compliance_agent returns CLEARED ## NEVER DO THESE ❌ Never answer Finance or HR questions yourself ❌ Never call Finance Agent for HR questions ❌ Never skip compliance check for high-value transactions
🧩 Pillar 2: Context in OIC Gen3 — What the Agent Sees at Runtime
2.1 What Is Context? The Technical Definition
Every time the LLM inside an OIC AI Agent processes a request, it can only work with information that is physically inside its context window at that moment. The context window is a token-limited buffer — everything that matters must be packed into it before the LLM runs. Outside the window: invisible. Inside the window: everything the agent knows and can act on.
In OIC Gen3, Context Engineering is the discipline of deciding exactly what goes into the context window for each agent invocation — and in what order. This is not automatic. You, the architect, control it through the Agent configuration, System Prompt, Tool responses, and Memory retrieval.
2.2 The 6 Layers of Context in OIC Gen3
🧩 Context Window Anatomy — Finance Agent Processing a ₹80L PO Accrual
LAYER 1 — System Prompt (~12% of context)
Your Finance Agent's persona, rules, tool descriptions, output format, domain restrictions.
Content: "You are the ABC Corp Finance Agent. You have access to Fusion Finance APIs. You NEVER post a GL journal above ₹50L without CFO approval..."
Token budget: ~2,400 tokens. Write once. Reused every invocation.
Your Finance Agent's persona, rules, tool descriptions, output format, domain restrictions.
Content: "You are the ABC Corp Finance Agent. You have access to Fusion Finance APIs. You NEVER post a GL journal above ₹50L without CFO approval..."
Token budget: ~2,400 tokens. Write once. Reused every invocation.
LAYER 2 — Tool Schemas (~10% of context)
JSON schema of every tool the agent has available. The LLM reads these to decide which tool to call.
Content:
Token budget: ~2,000 tokens. Minimise schema verbosity — long parameter descriptions eat budget fast.
JSON schema of every tool the agent has available. The LLM reads these to decide which tool to call.
Content:
get_gl_balance(), post_journal_entry(), check_supplier_status(), run_accrual()...Token budget: ~2,000 tokens. Minimise schema verbosity — long parameter descriptions eat budget fast.
LAYER 3 — Long-Term Memory Retrieval (~8% of context)
Relevant facts retrieved from OCI Object Storage memory store — learned from previous sessions.
Auto-retrieved for this session: "Previous session note: GlobalParts Ltd PAN verified. This user is Finance Controller Ravi Kumar — approved for journals up to ₹1Cr. Last month's accrual posting for this supplier was INV-2025-03-441."
Token budget: ~1,600 tokens.
Relevant facts retrieved from OCI Object Storage memory store — learned from previous sessions.
Auto-retrieved for this session: "Previous session note: GlobalParts Ltd PAN verified. This user is Finance Controller Ravi Kumar — approved for journals up to ₹1Cr. Last month's accrual posting for this supplier was INV-2025-03-441."
Token budget: ~1,600 tokens.
LAYER 4 — Knowledge Base Retrieval (~15% of context)
Top-K most relevant policy chunks retrieved from OCI OpenSearch based on current query.
Retrieved for "₹80L PO accrual": "Finance Policy Section 7.3: Accruals above ₹50L require period-end approval by Finance Controller. GL code mapping: Debit 5001-ACCRUALS, Credit 2001-VENDOR-PAYABLE..."
Token budget: ~3,000 tokens (Top 5 chunks × 600 tokens each, after summarisation).
Top-K most relevant policy chunks retrieved from OCI OpenSearch based on current query.
Retrieved for "₹80L PO accrual": "Finance Policy Section 7.3: Accruals above ₹50L require period-end approval by Finance Controller. GL code mapping: Debit 5001-ACCRUALS, Credit 2001-VENDOR-PAYABLE..."
Token budget: ~3,000 tokens (Top 5 chunks × 600 tokens each, after summarisation).
LAYER 5 — Conversation History (trimmed) (~25% of context)
Prior turns in this session, summarised and trimmed to stay within budget.
Content: "[Turn 1] User: Onboard GlobalParts Ltd. Agent: Initiated vendor onboarding... [Turn 3] Procurement Agent: PO-2025-0441 raised for ₹80L. Status: PENDING_FINANCE_POSTING."
Token budget: ~5,000 tokens. OIC auto-trims oldest turns first.
Prior turns in this session, summarised and trimmed to stay within budget.
Content: "[Turn 1] User: Onboard GlobalParts Ltd. Agent: Initiated vendor onboarding... [Turn 3] Procurement Agent: PO-2025-0441 raised for ₹80L. Status: PENDING_FINANCE_POSTING."
Token budget: ~5,000 tokens. OIC auto-trims oldest turns first.
LAYER 6 — Current User Message + Tool Results (runtime variable)
The live request plus any tool call responses from this iteration.
Content: Current user instruction + Procurement Agent's handoff:
Token budget: Remaining after layers 1–5. Usually ~5,000–8,000 tokens available.
The live request plus any tool call responses from this iteration.
Content: Current user instruction + Procurement Agent's handoff:
{po_id:"PO-2025-0441", amount:8000000, supplier_id:"SUP_0441", gl_period:"JUL-25", status:"APPROVED_BY_MANAGER"}Token budget: Remaining after layers 1–5. Usually ~5,000–8,000 tokens available.
⚠️ Total budget check: 2,400+2,000+1,600+3,000+5,000+6,000 = ~20,000 tokens consumed. OCI Cohere Command R+ context limit = 128K tokens — you have headroom. But without response summarisation in your OIC tools, a single Fusion HCM Worker JSON can consume 8,000+ tokens in one tool call, rapidly exhausting Layer 6 budget.
2.3 The Most Critical Context Engineering Decision: Tool Response Summarisation
This is the single biggest context mistake in enterprise OIC implementations. Here is a concrete before/after example.
❌ WITHOUT Summarisation — Raw Fusion Response
Agent calls
Fusion REST API returns full Supplier JSON with 50+ fields — SupplierNumber, SupplierName, TaxOrganizationType, TaxpayerIdentificationNumber, LifecycleStatus, SiteCount, Sites array, Contacts array, BankAccounts array...
~4,200 tokens consumed for one tool call. 3 such calls = 12,600 tokens gone. Context budget crisis.
get_supplier_details("SUP_0441")Fusion REST API returns full Supplier JSON with 50+ fields — SupplierNumber, SupplierName, TaxOrganizationType, TaxpayerIdentificationNumber, LifecycleStatus, SiteCount, Sites array, Contacts array, BankAccounts array...
~4,200 tokens consumed for one tool call. 3 such calls = 12,600 tokens gone. Context budget crisis.
✅ WITH Summarisation — OIC XSLT Transform
Add XSLT Assign Activity INSIDE the OIC tool integration before returning to agent. Agent receives only:
~120 tokens. 97% reduction. Same 3 calls = 360 tokens. Context budget preserved.
{
"supplier_id": "SUP_0441",
"name": "GlobalParts Ltd",
"status": "ACTIVE",
"gstin_verified": true,
"approved_for_po":true,
"payment_terms": "Net 30"
}
🔧 HOW TO IMPLEMENT: Add XSLT Summariser to OIC Tool Integration
In your OIC tool integration (e.g.
1. After the Fusion REST Invoke Activity, add an Assign Activity named
2. Build a new minimal JSON using XPath expressions:
Get_Supplier_Details):1. After the Fusion REST Invoke Activity, add an Assign Activity named
Summarise_For_Agent.2. Build a new minimal JSON using XPath expressions:
$summarisedResponse/supplier_id = $fusionResponse/SupplierNumber
$summarisedResponse/name = $fusionResponse/SupplierName
$summarisedResponse/status = $fusionResponse/LifecycleStatus
$summarisedResponse/gstin_verified = fn:string-length($fusionResponse/TaxpayerIdentificationNumber) > 10
$summarisedResponse/approved_for_po= ($fusionResponse/LifecycleStatus = 'ACTIVE') and
($fusionResponse/OneTimeFlag = 'N')
$summarisedResponse/payment_terms = $fusionResponse/Sites[1]/PaymentTermsName
3. Map
4. The Agent receives only the 6 fields it actually needs. Fusion complexity stays hidden inside OIC.
$summarisedResponse (not $fusionResponse) as the tool's return value.4. The Agent receives only the 6 fields it actually needs. Fusion complexity stays hidden inside OIC.
2.4 Context Passing Between Agents — The Handoff Contract
When the Orchestrator routes to the Procurement Agent, and the Procurement Agent completes its work and hands off to the Finance Agent, context must flow between agents. This is a structured handoff, not a free-form message.
📋 Agent Handoff Contract — Procurement Agent to Finance Agent
What Procurement Agent must include in its response to Orchestrator:
{
"agent": "PROCUREMENT_AGENT",
"status": "COMPLETED",
"task_completed": "PO creation and approval",
/* Everything Finance Agent needs — pre-extracted, pre-validated */
"handoff_to_next": {
"po_id": "PO-2025-0441",
"po_amount_inr": 8000000,
"po_currency": "INR",
"supplier_id": "SUP_0441",
"supplier_name": "GlobalParts Ltd",
"gl_cost_center": "CC_TECH_001",
"gl_period": "JUL-25",
"purchase_category": "HARDWARE",
"approved_by": "rahul.sharma@abc.com",
"approval_timestamp": "2025-07-01T11:42:00+05:30",
"requires_accrual": true,
"debit_gl_account": "5001-ACCRUALS",
"credit_gl_account": "2001-VENDOR-PAYABLE"
},
/* For audit trail */
"session_id": "SESSION_20250701_001",
"oic_tracking_id": "OIC_TRK_20250701_PO_001"
}
Orchestrator receives this and passes
handoff_to_next as the context parameter when calling invoke_finance_agent(). Finance Agent starts with all the procurement context pre-loaded — no re-asking, no re-fetching, no wasted tokens.
🧠 Pillar 3: Memory in OIC Gen3 — What the Agent Remembers
3.1 The Memory Problem — Why Stateless AI Is Useless in Enterprise
By default, every LLM is stateless. Each API call is completely independent. The model has zero memory of what happened 5 minutes ago, yesterday, or last month. For enterprise Oracle Fusion workflows, this is a dealbreaker.
😰 Without Memory — Real Enterprise Failure Scenarios
Scenario A: Finance Controller Ravi Kumar tells the agent: "My approval limit is ₹1Cr — always check with me before escalating to CFO." Next session: agent escalates a ₹60L journal to the CFO. Ravi is furious. Agent forgot.
Scenario B: Last month, Procurement Agent discovered that GlobalParts Ltd has a recurring GRN mismatch issue. This month a new PO is raised. Agent has no memory of last month's issue. Passes validation without the extra check. Invoice dispute arises again.
Scenario C: HR Agent helped onboard 12 employees last quarter. Every new hire: agent re-learns from scratch, asks the same qualification questions, applies the same grade checks, re-reads the same policies. Zero efficiency gain from prior experience.
3.2 The 3 Types of Memory in OIC Gen3 — Technical Architecture
⚡ Type 1 — In-Session (Short-Term) Memory
The conversation history inside the current agent session. Stored in OIC process memory (RAM). Lives only for the duration of one agent execution.
Technical storage: OIC Agent Session State object. Automatically managed by OIC Agent Runtime.
Token impact: Grows with each turn. OIC auto-trims oldest messages when approaching context limit.
Example: Within one session: Agent asks "What is the PO amount?" → User replies "₹80L" → Agent remembers this for all subsequent steps in the same session.
Technical storage: OIC Agent Session State object. Automatically managed by OIC Agent Runtime.
Token impact: Grows with each turn. OIC auto-trims oldest messages when approaching context limit.
Example: Within one session: Agent asks "What is the PO amount?" → User replies "₹80L" → Agent remembers this for all subsequent steps in the same session.
💾 Type 2 — Cross-Session (Long-Term) Memory
Facts and learnings persisted across multiple sessions. Agent can remember things from last week, last month, last year.
Technical storage: OCI Object Storage — encrypted JSON files, one per user/entity. Optional: OCI Autonomous Database for structured memory.
How OIC accesses it: At session start, Memory Manager OIC integration reads the user's memory file → extracts relevant facts → injects into Layer 3 of context window.
Example: "Ravi Kumar: approval_limit_inr=10000000, preferred_escalation=CFO_direct, last_gl_period=JUN-25, GlobalParts_flag=GRN_mismatch_risk"
Technical storage: OCI Object Storage — encrypted JSON files, one per user/entity. Optional: OCI Autonomous Database for structured memory.
How OIC accesses it: At session start, Memory Manager OIC integration reads the user's memory file → extracts relevant facts → injects into Layer 3 of context window.
Example: "Ravi Kumar: approval_limit_inr=10000000, preferred_escalation=CFO_direct, last_gl_period=JUN-25, GlobalParts_flag=GRN_mismatch_risk"
🏢 Type 3 — Shared/Entity Memory
Memory about entities (suppliers, GL accounts, cost centres) shared across ALL users and ALL agents. Not user-specific. Entity-specific.
Technical storage: OCI Object Storage with entity-keyed JSON. OR: OCI Autonomous Database with entity_type, entity_id, memory_key, memory_value columns.
Lifespan: Permanent. Updated by any agent that learns a new fact about the entity.
Example: Entity memory for GlobalParts Ltd:
Any agent (Finance, Procurement, Compliance) reads this → applies extra validation automatically.
Technical storage: OCI Object Storage with entity-keyed JSON. OR: OCI Autonomous Database with entity_type, entity_id, memory_key, memory_value columns.
Lifespan: Permanent. Updated by any agent that learns a new fact about the entity.
Example: Entity memory for GlobalParts Ltd:
{supplier:"GlobalParts", grn_mismatch_flag:true, grn_mismatch_count:3, last_audit_date:"2025-06"}Any agent (Finance, Procurement, Compliance) reads this → applies extra validation automatically.
3.3 Step-by-Step: Implementing Long-Term Memory in OIC Gen3
🔧 Implementation — Memory Read Integration (Session Start)
1
Create Memory Read Integration:
Name:
Input:
Called by every specialist agent at the very START of each session.
Name:
Agent_Memory_Read_v1 | Type: Orchestration | Trigger: RESTInput:
{ user_id, agent_type, session_context_keywords[] }Called by every specialist agent at the very START of each session.
2
OCI Object Storage Read — User Memory File:
Add Invoke → OCI Object Storage SDK Adapter → GetObject
Object path:
If object doesn't exist (first session): return empty memory template. Do not fail.
Parse JSON → extract relevant memory entries based on
Add Invoke → OCI Object Storage SDK Adapter → GetObject
Object path:
agent-memory/users/{user_id}/memory.jsonIf object doesn't exist (first session): return empty memory template. Do not fail.
Parse JSON → extract relevant memory entries based on
session_context_keywords.
3
Entity Memory Read:
For each entity_id in session_context (e.g. supplier_id="SUP_0441"):
→ Read:
→ Merge entity facts with user facts → Return combined memory context as formatted text block.
For each entity_id in session_context (e.g. supplier_id="SUP_0441"):
→ Read:
agent-memory/entities/suppliers/{supplier_id}/memory.json→ Merge entity facts with user facts → Return combined memory context as formatted text block.
4
Format memory for LLM context injection (injected into Layer 3):
--- MEMORY CONTEXT (from prior sessions) --- USER: Ravi Kumar (ravi.kumar@abc.com) - Role: Finance Controller, BU: Technology - Approval limit: ₹1Cr (do not escalate below this) - Prefers: Direct CFO escalation for exceptions - Last session: JUN-25 accruals completed successfully ENTITY: GlobalParts Ltd (SUP_0441) ⚠️ GRN mismatch flag: TRUE (3 occurrences last 6 months) - Always run 3-way match before invoice approval - Last issue: INV-2025-03-441, resolved 2025-04-12 - Bank account verified: ICICI Bank, IFSC ICIC0001234 --- END MEMORY CONTEXT ---
🔧 Implementation — Memory Write Integration (Session End)
1
Agent System Prompt — Memory Extraction Instructions:
At the end of every successful session, the agent must output a structured memory block:
At the end of every successful session, the agent must output a structured memory block:
"At session end, generate a MEMORY_UPDATE block:
MEMORY_UPDATE:{
user_memory: [key-value facts to remember about this user],
entity_memory: [key-value facts about any entity processed],
session_outcome: COMPLETED|FAILED|PARTIAL,
next_session_hints: [any facts useful for next session]
}"
2
OIC Agent Completion Hook — Call Memory Write Integration:
In your Agent's post-execution OIC flow, add an Invoke to:
Parse the MEMORY_UPDATE block from the agent's final response.
Merge with existing memory (not overwrite — always append/update).
Write back to OCI Object Storage:
In your Agent's post-execution OIC flow, add an Invoke to:
Agent_Memory_Write_v1Parse the MEMORY_UPDATE block from the agent's final response.
Merge with existing memory (not overwrite — always append/update).
Write back to OCI Object Storage:
agent-memory/users/{user_id}/memory.json
3
Example — What Finance Agent writes to memory after our ₹80L session:
User memory updates: last_gl_period_processed: JUL-25 last_po_amount_processed: 8000000 ravi_preference_confirmed: direct_cfo_escalation Entity memory updates (GlobalParts SUP_0441): grn_mismatch_count: 3 (unchanged — no new issue this session) last_po_id: PO-2025-0441 last_accrual_journal: JNL-2025-0441 relationship_status: ACTIVE_GOOD_STANDING
3.4 Memory Architecture — OCI Storage Structure
OCI Object Storage Bucket: abc-corp-agent-memory │ ├── users/ │ ├── ravi.kumar@abc.com/ │ │ └── memory.json ← Finance Controller preferences + history │ ├── priya.sharma@abc.com/ │ │ └── memory.json ← Procurement Manager memory │ └── hr.admin@abc.com/ │ └── memory.json ← HR Admin session history │ ├── entities/ │ ├── suppliers/ │ │ ├── SUP_0441/ │ │ │ └── memory.json ← GRN flags, audit history, bank details │ │ └── SUP_0882/ │ │ └── memory.json │ ├── gl-accounts/ │ │ └── 5001-ACCRUALS/ │ │ └── memory.json ← Posting history, period balances │ └── cost-centres/ │ └── CC_TECH_001/ │ └── memory.json │ └── shared/ ├── approval-limits.json ← Current DoA table (all roles) ├── gl-period-status.json ← Open/closed periods └── active-flags.json ← Any system-wide flags Each memory.json structure: { "entity_id": "SUP_0441", "version": 14, "last_updated": "2025-07-01T14:32:00+05:30", "updated_by_agent": "PROCUREMENT_AGENT", "updated_by_session":"SESSION_20250701_001", "facts": { "grn_mismatch_flag": true, "grn_mismatch_count": 3, "last_issue_session": "SESSION_20250401_003", "bank_verified": true, "last_po_id": "PO-2025-0441" }, "history": [ {"date":"2025-07-01","event":"PO-2025-0441 processed"}, {"date":"2025-04-01","event":"GRN mismatch on INV-2025-03-441"} ] }
🎭 Pillar 4: Agent Orchestration — Coordinating Multiple Specialist Agents
4.1 What Is Orchestration? The Technical Reality
Orchestration is the pattern where one Orchestrator Agent acts as a coordinator — decomposing a complex user goal into sub-tasks, delegating each to the correct specialist agent, collecting results, handling failures, and synthesising a final coherent response.
In OIC Gen3, orchestration is built using the Agent-as-Tool pattern: each specialist agent is registered as a tool inside the Orchestrator Agent. The Orchestrator's LLM treats each specialist agent call exactly like any other tool call — it decides when to call it, with what parameters, and how to use the result.
4.2 Orchestration Patterns — 4 Real OIC Implementations
🔀 Pattern 1 — Sequential Orchestration (Dependent Pipeline)
When to use: Sub-tasks must complete in order. Output of Task A is input to Task B.
ABC Corp Example: Vendor onboarding → PO creation → 3-way match → GL accrual posting. Each step requires the previous step's output (supplier_id → PO_id → GRN_id → journal_id).
OIC Implementation: Orchestrator System Prompt: "For vendor-to-payment workflows, ALWAYS call in this order: (1) invoke_compliance_agent for limit check, (2) invoke_procurement_agent for PO, (3) invoke_finance_agent for accrual. Never skip steps. Always pass output of each step as context to next."
⚡ Pattern 2 — Parallel Orchestration (Independent Sub-Tasks)
When to use: Sub-tasks are completely independent. No dependency. Run simultaneously for speed.
ABC Corp Example: "Give me Q2 status on: (1) all pending AP invoices, (2) all open POs, (3) headcount vs budget." These three requests go to Finance, Procurement, and HR Agent simultaneously.
OIC Implementation: In OIC Gen3, parallel tool calls are supported. Orchestrator calls all three specialist agents in the same ReAct iteration. Waits for all three to complete. Merges results into a single Q2 status report.
🛡️ Pattern 3 — Gated Orchestration (Compliance as Checkpoint)
When to use: All high-value actions must pass a compliance gate before execution.
ABC Corp Example: Any action involving amounts above ₹50L is automatically intercepted by the Orchestrator, sent to Compliance Agent first. Only if Compliance Agent returns CLEARED does the Orchestrator proceed.
OIC Implementation: In Orchestrator System Prompt: "Before calling any agent for a transaction above ₹50L: FIRST call invoke_compliance_agent(transaction_details). Only if compliance_status=CLEARED, proceed. If BLOCKED, stop and notify user with compliance reason."
🔄 Pattern 4 — Retry Orchestration (Failure Recovery)
When to use: A specialist agent fails or returns incomplete result. Orchestrator must retry or reroute.
ABC Corp Example: Finance Agent fails to post journal because GL period is closed. Orchestrator does not give up — it calls a recovery sub-task: "Call Finance Agent to reopen period (if authorised), then retry the accrual posting."
OIC Implementation: Orchestrator System Prompt: "If an agent returns status=FAILED with reason=PERIOD_CLOSED: (1) Check if period can be reopened. (2) If authority exists, reopen and retry. (3) If retry fails twice, escalate to human with full failure context."
4.3 Full Orchestration Implementation — The ABC Corp ₹80L Scenario End to End
ORCHESTRATOR AGENT — FULL EXECUTION TRACE User: "Onboard GlobalParts Ltd, raise PO ₹80L, approve, post accrual — 3 days" ═══════════════════════════════════════════════════════════════════════════════ ITERATION 1 — THINK: "This is a multi-domain, sequential, high-value task. Amount ₹80L > ₹50L threshold → compliance gate required first. Sequence: compliance → procurement (vendor onboard + PO) → finance (accrual). Need to check memory for GlobalParts Ltd before anything." ITERATION 1 — ACT (Parallel initial calls): [CALL 1] read_agent_memory(entity_id="GlobalParts_SUP_0441") [CALL 2] invoke_compliance_agent( amount=8000000, action="vendor_onboard_and_po", entity="GlobalParts Ltd", requested_by="ravi.kumar") ITERATION 1 — OBSERVE: Memory: {grn_mismatch_flag: true, count: 3} ← Risk flag found! Compliance: {status: "CONDITIONALLY_CLEARED", condition: "Mandatory 3-way match before payment release"} ITERATION 2 — THINK: "Compliance cleared with condition. Memory shows GRN risk. I will include GRN mismatch warning in Procurement Agent context." ITERATION 2 — ACT: [CALL] invoke_procurement_agent( request: "Onboard GlobalParts Ltd and raise PO for ₹80L hardware", context: { compliance_status: "CONDITIONALLY_CLEARED", compliance_condition: "3-way match mandatory", memory_warning: "GRN mismatch flag: TRUE (3 occurrences)", requested_by: "ravi.kumar@abc.com", deadline: "2025-07-04" } ) ITERATION 2 — OBSERVE (Procurement Agent completes): { vendor_onboarding: "COMPLETED", supplier_id: "SUP_0441", po_id: "PO-2025-0441", po_amount: 8000000, po_status: "APPROVED", three_way_match_scheduled: true, approved_by: "rahul.sharma@abc.com", gl_period: "JUL-25", debit_account: "5001-ACCRUALS", credit_account: "2001-VENDOR-PAYABLE" } ITERATION 3 — THINK: "Procurement complete. PO approved. Now Finance Agent for accrual posting. Pass full procurement result as context so Finance doesn't re-fetch anything." ITERATION 3 — ACT: [CALL] invoke_finance_agent( request: "Post month-end accrual for PO-2025-0441", context: { po_id: "PO-2025-0441", amount_inr: 8000000, supplier_id: "SUP_0441", gl_period: "JUL-25", debit_gl: "5001-ACCRUALS", credit_gl: "2001-VENDOR-PAYABLE", approved_by: "rahul.sharma@abc.com", compliance_condition: "3-way match before payment", memory_user_preference: "No CFO escalation below ₹1Cr" } ) ITERATION 3 — OBSERVE (Finance Agent completes): { journal_id: "JNL-2025-0441", status: "POSTED", gl_period: "JUL-25", posted_by: "FINANCE_AGENT (on behalf of ravi.kumar)", requires_cfo_approval: false ← ₹80L < ₹1Cr Ravi limit (from memory) } ITERATION 4 — ACT: [CALL] write_agent_memory(session_outcomes) FINAL RESPONSE TO USER: "✅ All tasks completed within your 3-day deadline: 1. GlobalParts Ltd onboarded as approved vendor (SUP_0441) 2. PO-2025-0441 raised for ₹80,00,000 — approved by Rahul Sharma 3. GL accrual posted: Journal JNL-2025-0441 to period JUL-25 Debit: 5001-ACCRUALS | Credit: 2001-VENDOR-PAYABLE ⚠️ Note: Mandatory 3-way match required before invoice payment. 3-way match has been scheduled by Procurement team. Audit trail: Session SESSION_20250701_001 | OCI Audit logged." Total iterations: 4 | Total tool calls: 6 | Wall time: ~47 seconds
4.4 Orchestrator System Prompt — Complete Technical Version
## IDENTITY You are the ABC Corp Master Orchestrator Agent. You coordinate Finance, HR, Procurement, and Compliance specialist agents. You do NOT answer business questions yourself — you delegate to specialists. ## SPECIALIST AGENTS (your tools) - invoke_finance_agent(request, context) → For: GL, AP, AR, payments, accruals, journals, period-end → Always pass: full context from prior agent results - invoke_hr_agent(request, context) → For: leave, onboarding, grade, policy, HCM employee records - invoke_procurement_agent(request, context) → For: PO, vendor, sourcing, 3-way match, GRN, contracts → Always pass: compliance clearance reference if amount > ₹50L - invoke_compliance_agent(request, context) → ALWAYS call this FIRST for any amount > ₹50L - read_agent_memory(entity_id, user_id) → Call at START of every session involving a known entity or user - write_agent_memory(session_summary) → Call at END of every successfully completed session ## ORCHESTRATION DECISION RULES IF request involves one domain only: → Route directly to that specialist. No multi-step needed. IF request involves multiple domains with dependencies: → Plan the full sequence BEFORE calling any agent → Share your plan in a PLAN: block before executing → Execute in dependency order (never skip a step) → Always pass previous agent output as context to next IF amount > ₹50L: → compliance_agent ALWAYS runs first (non-negotiable) → Only proceed if compliance_status = CLEARED or CONDITIONALLY_CLEARED IF any agent returns status = FAILED: → Analyse failure reason before retrying → Retry maximum 2 times with modified parameters → If still failing, stop and report to user with full context ## MEMORY RULES ALWAYS call read_agent_memory at start if a supplier, vendor, or employee is mentioned OR the user has history in the system. ALWAYS call write_agent_memory at end of every successful session. ## OUTPUT FORMAT For multi-step completions: - Number each completed task - Include IDs for every created record (PO, Journal, Employee) - Include any conditions or warnings from compliance - Include audit session reference
🚨 Common Mistakes — All Four Pillars
MISTAKE 1
Routing Keywords From User-Visible Language Only
Problem: Keyword router looks for "invoice" to route to Finance Agent. A Procurement user asks: "Is the invoice for PO-2025-001 matched to the GRN?" — contains "invoice" → wrongly sent to Finance Agent, which has no GRN tools.
Fix: Add contextual keyword pairs. "invoice" alone is ambiguous. "invoice + GRN" → Procurement. "invoice + GL" → Finance. Test routing with 50+ real user message samples from each domain before go-live.
MISTAKE 2
Passing Full Agent Response as Next Agent's Input
Problem: Orchestrator passes the Procurement Agent's complete verbose response — including all reasoning, intermediate thoughts, all tool outputs — as context to Finance Agent. Finance Agent's context window is 40% consumed before it starts its own work.
Fix: Orchestrator must extract ONLY the structured handoff data from each agent response. Never pass agent reasoning text to the next agent — only the structured output fields. Define a handoff contract schema and enforce it in Orchestrator System Prompt.
MISTAKE 3
Storing PII in Entity/User Memory
Problem: Memory write includes employee salary, personal bank account numbers, health data, ID numbers. OCI Object Storage memory files are not encrypted at the field level. A memory file read by the wrong agent now exposes PII in the LLM context.
Fix: Memory files must NEVER contain raw PII. Store only reference tokens (e.g. "salary_band_ref: BAND_5_HIGH" not "salary: ₹18,00,000"). Store "bank_verified: true" not the actual account number. Apply OCI Vault encryption for all memory bucket objects.
MISTAKE 4
No Failure Propagation Contract
Problem: Procurement Agent fails on step 3 of 5. Returns partial result. Orchestrator doesn't detect the failure. Passes partial result to Finance Agent. Finance Agent processes incomplete data. Corrupt GL journal created. No one knows where it broke.
Fix: Every agent response MUST include: status (COMPLETED/FAILED/PARTIAL), completed_steps, failed_at_step, rollback_required (boolean), rollback_instructions. Orchestrator MUST check status before passing to next agent. If status ≠ COMPLETED: stop pipeline, trigger rollback, notify user.
MISTAKE 5
Growing Memory Files Without Pruning
Problem: Every session appends to memory files. After 12 months, Ravi Kumar's user memory file is 50,000 tokens. Reading it at session start consumes 40% of context budget before the first user message. Agent becomes effectively useless.
Fix: Implement Memory Pruning Integration — run weekly via OIC Scheduled Integration. Keep last 30 session entries, keep all permanent flags, delete outdated preferences (older than 90 days). Set max memory file size: 1,500 tokens. Summarise historical facts into single entries.
🏗️ Complete Architecture — All Four Pillars Together
ABC CORP — OIC Gen3 MULTI-AGENT PLATFORM Complete Architecture: Routing + Context + Memory + Orchestration ═══════════════════════════════════════════════════════════════════════════════ USER REQUEST │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ ABC_Agent_Router_v1 (OIC Orchestration) │ │ ROUTING: Keyword score → Single domain: direct route │ │ Multi-domain: → Orchestrator Agent │ └─────────────────────────────┬───────────────────────────────┘ │ (multi-domain detected) ▼ ┌────────────────────────────────────────────────────────────────────────────┐ │ ORCHESTRATOR AGENT (OIC Agent Studio) │ │ │ │ CONTEXT WINDOW BUILT AT SESSION START: │ │ ┌──────────┐ ┌─────────┐ ┌─────────────┐ ┌────────────┐ ┌─────────────┐ │ │ │ System │ │ Tool │ │ Memory │ │ KB │ │ Conv. │ │ │ │ Prompt │ │ Schemas │ │ (OCS read) │ │ Retrieval │ │ History │ │ │ │ ~2,400T │ │ ~2,000T │ │ ~1,600T │ │ ~2,000T │ │ ~4,000T │ │ │ └──────────┘ └─────────┘ └─────────────┘ └────────────┘ └─────────────┘ │ │ │ │ ReAct Loop: THINK → ACT (route to specialist) → OBSERVE → THINK │ │ │ │ ROUTING TOOLS (specialist agent invocations): │ │ invoke_compliance_agent │ invoke_procurement_agent │ │ invoke_finance_agent │ invoke_hr_agent │ │ read_agent_memory │ write_agent_memory │ └───────────────────────────────┬────────────────────────────────────────────┘ ┌─────────────────┬────┴──────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────────┐ │ COMPLIANCE │ │ PROCUREMENT │ │ FINANCE │ │ AGENT │ │ AGENT │ │ AGENT │ │ │ │ │ │ │ │ + Policy KB │ │ + Vendor KB │ │ + Finance KB │ │ + DoA Memory │ │ + Entity Memory │ │ + User Memory │ │ + Orch Context │ │ + Orch Context │ │ + Handoff Data │ │ │ │ │ │ │ │ check_doa() │ │ onboard_vendor()│ │ check_period() │ │ validate_reg() │ │ create_po() │ │ post_journal() │ │ flag_audit() │ │ run_3way() │ │ get_gl_bal() │ └────────┬────────┘ └────────┬────────┘ └────────┬─────────┘ │ │ │ ▼ ▼ ▼ OCI GenAI LLM OCI GenAI LLM OCI GenAI LLM (Cohere Cmd R+) (Cohere Cmd R+) (Cohere Cmd R+) │ │ │ ▼ ▼ ▼ Fusion Finance Fusion SCM/PO Fusion Finance REST APIs REST APIs GL/Journal APIs ──────────────── SHARED INFRASTRUCTURE ───────────────── │ │ │ ▼ ▼ ▼ ┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ OCI Object │ │ OCI │ │ OCI Logging │ │ Storage │ │ OpenSearch │ │ Analytics │ │ │ │ │ │ │ │ User Memory │ │ Knowledge │ │ Every tool call │ │ Entity Mem │ │ Base Vectors │ │ Every routing decision│ │ Shared KV │ │ Policy Docs │ │ Token usage/session │ └─────────────┘ └──────────────┘ └──────────────────────┘ │ OCI Vault (all secrets) OCI IAM (all access control) OCI Audit (immutable trail)
🚀 Production Checklist + Architect Interview Questions
✅ Production Readiness — All 4 Pillars
✅ Routing: 50+ real user messages tested across all routing branches. Zero misclassifications in UAT on high-value transactions.
✅ Context: All OIC tool integrations have XSLT summariser. Max tool response = 200 tokens. Context budget verified ≤ 40K tokens per session avg.
✅ Memory: OCI Object Storage bucket encrypted. IAM scoped per agent type. Memory pruning job runs weekly. Max memory file size ≤ 1,500 tokens. PII field confirmed absent.
✅ Orchestration: Failure contract implemented in all agents. Sequential dependency tested with deliberate step-2 failure. Rollback triggered correctly. Orchestrator retried max 2× before escalating.
✅ Observability: OCI Logging dashboard live. Routing decision logs visible. Context budget per session tracked. Orchestration step trace queryable by session_id.
✅ Security: Compliance gate tested — ₹51L transaction blocked until compliance_agent explicitly cleared. Prompt injection tested on agent handoff context fields.
🎤 Architect Interview Questions
Q1: A user message is "Check the leave balance and raise a PO for office supplies for ₹2L." How does your OIC routing system handle this?
Keyword scoring: leave_score=2, procurement_score=3. Both >= 2 but tasks are independent. Multi-domain parallel case. Router sends to Orchestrator. Orchestrator identifies tasks have no dependency — calls invoke_hr_agent and invoke_procurement_agent in parallel in same ReAct iteration. Merges both results into single response. No compliance gate since ₹2L < ₹50L threshold.
Keyword scoring: leave_score=2, procurement_score=3. Both >= 2 but tasks are independent. Multi-domain parallel case. Router sends to Orchestrator. Orchestrator identifies tasks have no dependency — calls invoke_hr_agent and invoke_procurement_agent in parallel in same ReAct iteration. Merges both results into single response. No compliance gate since ₹2L < ₹50L threshold.
Q2: The Finance Agent's context window is 128K tokens. Why would you still implement tool response summarisation?
(1) Cost — OCI GenAI charges per input token. 4,000-token tool responses across 10 tool calls = 40,000 extra tokens per session = significant cost at scale. (2) Attention dilution — LLMs give proportional attention to all context. 48-field Fusion JSON dilutes attention on the 6 fields that actually matter. Summarised context = better reasoning. (3) Latency — larger context = slower TTFT. (4) Hallucination — LLMs can confuse fields in very dense JSON. Clean, minimal context = fewer errors.
(1) Cost — OCI GenAI charges per input token. 4,000-token tool responses across 10 tool calls = 40,000 extra tokens per session = significant cost at scale. (2) Attention dilution — LLMs give proportional attention to all context. 48-field Fusion JSON dilutes attention on the 6 fields that actually matter. Summarised context = better reasoning. (3) Latency — larger context = slower TTFT. (4) Hallucination — LLMs can confuse fields in very dense JSON. Clean, minimal context = fewer errors.
Q3: How do you prevent memory poisoning — where a malicious or incorrect fact is written to entity memory and affects all future sessions?
(1) Memory writes go through a validation OIC Integration — never direct storage write from agent. (2) Only COMPLETED sessions trigger memory writes. (3) Confidence gating: agent must mark a memory item confidence=HIGH or confidence=VERIFIED — VERIFIED requires cross-verification with a Fusion data source. (4) Weekly audit: OIC Scheduled Integration scans entity memory for flags that contradict current Fusion master data. (5) Memory file versioning in OCI Object Storage — any memory write can be rolled back to prior version.
(1) Memory writes go through a validation OIC Integration — never direct storage write from agent. (2) Only COMPLETED sessions trigger memory writes. (3) Confidence gating: agent must mark a memory item confidence=HIGH or confidence=VERIFIED — VERIFIED requires cross-verification with a Fusion data source. (4) Weekly audit: OIC Scheduled Integration scans entity memory for flags that contradict current Fusion master data. (5) Memory file versioning in OCI Object Storage — any memory write can be rolled back to prior version.
Q4 (Architect): Design the Orchestrator failure recovery pattern: Procurement Agent succeeded (PO created), Finance Agent failed (GL period closed). You cannot undo the PO. What does the Orchestrator do?
Orchestrator receives Finance Agent response: {status:FAILED, reason:PERIOD_CLOSED, po_id:PO-2025-0441, rollback_required:false (PO is valid)}. Recovery path: (1) Call Finance Agent: check if period can be reopened and who has authority. (2) If authority exists and within policy: reopen JUL-25, retry accrual. (3) If period cannot be reopened: Human Approval Gate — Finance Controller decides: post to AUG-25 period or wait for reopen. (4) PO-2025-0441 status updated in memory as "PENDING_ACCRUAL_POSTING" so next session Finance Agent immediately knows context. Orchestrator response to user includes complete step status with pending action clearly identified.
Orchestrator receives Finance Agent response: {status:FAILED, reason:PERIOD_CLOSED, po_id:PO-2025-0441, rollback_required:false (PO is valid)}. Recovery path: (1) Call Finance Agent: check if period can be reopened and who has authority. (2) If authority exists and within policy: reopen JUL-25, retry accrual. (3) If period cannot be reopened: Human Approval Gate — Finance Controller decides: post to AUG-25 period or wait for reopen. (4) PO-2025-0441 status updated in memory as "PENDING_ACCRUAL_POSTING" so next session Finance Agent immediately knows context. Orchestrator response to user includes complete step status with pending action clearly identified.
📌 Quick Reference Card
🔀 Routing — Key Rules
- Keyword score single domain ≥3 → direct route (no LLM cost)
- Multi-domain → Orchestrator LLM
- Test routing with 50+ real messages
- Use contextual keyword pairs not single words
- Log every routing decision for observability
🧩 Context — Key Rules
- 6 layers: SysPrompt → Tools → Memory → KB → History → Current
- ALL tool responses must have XSLT summariser
- Target: <200 tokens per tool response
- Define handoff contract schema for agent-to-agent
- Never pass agent reasoning text to next agent
🧠 Memory — Key Rules
- 3 types: in-session, cross-session, entity/shared
- OCI Object Storage: user + entity + shared buckets
- Max memory file size: 1,500 tokens
- Weekly pruning job mandatory
- Never store raw PII — use reference tokens
- Write only on COMPLETED sessions
🎭 Orchestration — Key Rules
- 4 patterns: Sequential, Parallel, Gated, Retry
- Compliance gate mandatory for amounts >₹50L
- Every agent must implement failure contract
- Orchestrator checks status before passing to next
- Max 2 retries, then escalate to human
- Plan full sequence before first tool call
🌱 The Architect's Closing Thought:
Routing decides who handles a request. Context decides what they know right now. Memory decides what they remember from before. Orchestration decides how multiple specialists work together toward a single goal. Get any one of these wrong and your multi-agent platform is not enterprise-grade — it is an elaborate demo.
The organisations winning with Oracle AI Agents in production are the ones who invested in the plumbing: clean handoff contracts, aggressive response summarisation, structured memory with pruning, and orchestration failure recovery. The LLM is the smallest part of the solution. The architecture around it is everything.
Build the plumbing. Trust the architecture. The intelligence will follow. ⚙️ 🧠 🎭
Routing decides who handles a request. Context decides what they know right now. Memory decides what they remember from before. Orchestration decides how multiple specialists work together toward a single goal. Get any one of these wrong and your multi-agent platform is not enterprise-grade — it is an elaborate demo.
The organisations winning with Oracle AI Agents in production are the ones who invested in the plumbing: clean handoff contracts, aggressive response summarisation, structured memory with pruning, and orchestration failure recovery. The LLM is the smallest part of the solution. The architecture around it is everything.
Build the plumbing. Trust the architecture. The intelligence will follow. ⚙️ 🧠 🎭
Comments
Post a Comment