Agent Patterns

An OIC Gen3 Agent Pattern is the reasoning discipline you assign to an AI Agent — it decides whether the agent figures things out step-by-step as it goes, or plans every step up front before touching a single tool. There are four pattern recipes: ReAct, ReAct for OCI GenAI, Plan, and Plan for OCI GenAI. 🤖

Why does this even matter? An LLM with no pattern either rambles (calling tools in a random order, looping forever, guessing at missing values) or is inconsistent (the same request run twice produces two different outcomes) — neither is acceptable when the decision is "approve this $4,000 expense claim" or "escalate this to Finance." A pattern is the guardrail that makes the agent's reasoning predictable, auditable, and repeatable. 🛡️

📑 In This Post

• Quick Comparison
• 1. ReAct
• 2. ReAct for OCI GenAI
• 3. Plan (Plan & Execute)
• 4. Plan for OCI GenAI
• FAQ
• Summary

🔀 Quick Comparison

Pattern	How It Thinks	Model Runs On
ReAct	Think → Act → Observe → Repeat	Third-party LLM (OpenAI, Anthropic, etc.)
ReAct for OCI GenAI	Same loop	OCI Generative AI (your tenancy)
Plan (Plan & Execute)	Planner builds full plan → Executor runs it	Third-party LLM
Plan for OCI GenAI	Same split	OCI Generative AI (your tenancy)

🔄 1. ReAct

ReAct means Reason + Act. The agent doesn't know the full path up front — it thinks, calls one tool, reads the result, and decides its next move based on what it just learned. It's the "figure it out as I go" style of reasoning: sharp and adaptive, but it needs a clear rulebook (your guidelines) or it will wander and call tools it doesn't need. 🧭

How the loop actually runs, step by step (matching the diagram below):

1. Think — the agent looks at the claim details it was given and asks itself "what do I still need to know to decide?"
2. Act — it picks exactly one Tool that answers that question and calls it (never guessing the tool's input — if a required value is missing, it should ask a human instead of inventing one)
3. Observe — it reads the tool's response (e.g. "WithinPolicy = true")
4. Repeat — it thinks again, now armed with that new fact, and either calls another tool or, once it has enough information, gives its final decision

✅ Practical Example:

An employee submits a $45 parking expense with no linked travel request. The agent thinks: "small amount, let me check policy first." It acts by calling CheckExpensePolicy, observes that $45 is well within the $100 daily limit, and — because it's low value — decides it doesn't even need to check for a travel request. It approves instantly, after just one tool call. ⚡

💡 Now Watch The Same Agent Handle A Harder Case:

The same employee submits a $1,800 hotel expense. This time, observing that $1,800 is close to the policy limit changes the agent's next move: it now decides it needs to check GetEmployeeCostCenter (is the cost center even active?), then GetMatchingTravelRequest (is there proof this trip was pre-approved?). Only after both come back clean does it approve — and if the travel request is missing, it escalates to a human instead of guessing. Three tool calls this time, not one — the path length and the tools chosen both depend entirely on what the agent learned along the way. That adaptability, for better or worse, is the defining trait of ReAct. 🏨

🎯 Use ReAct when: the right next step genuinely depends on what a previous tool call returns — investigative, exploratory, or "it depends" tasks where you can't fully predict the path in advance.

🌐 2. ReAct for OCI GenAI

Exactly the same Think → Act → Observe loop as ReAct — the only difference is where the model lives. Instead of calling a third-party LLM, the reasoning happens on a model hosted inside your own OCI tenancy and region. Nothing about how the agent reasons changes; only the address the pattern sends its "thinking" requests to. 🔒

Three enterprise reasons architects reach for this variant instead of plain ReAct:

• 🌍 Data residency — HR and Finance data used in the reasoning never leaves the OCI region
• 💳 Unified billing — OIC and GenAI usage draw from the same Universal Credits pool, instead of managing a separate vendor invoice
• 🔐 Governance parity — the same IAM policies and dynamic groups you already use for other OCI services now also cover your AI Agent, instead of a standalone third-party API key floating around

✅ Practical Example:

Same expense agent as above, but Acme Corp's compliance team requires that employee HR data never leaves the OCI region. You keep every Tool, Prompt Template, and guideline identical — including the exact $1,800 hotel-expense walkthrough from the previous example, which behaves exactly the same way. The only change: in the Agent Pattern's configuration, you swap the LLM Connection from a third-party provider to an OCI GenAI Connection, and pick a model available in your region (e.g. cohere.command-r-plus or a hosted Llama model). One important gotcha to know as a learner: cross-region calls aren't supported — the model must live in the same OCI region as your OIC instance, so always check regional model availability before designing around a specific one. Same reasoning, same behavior, different address for the "brain." ☁️

🗂️ 3. Plan (Plan & Execute)

Instead of one agent improvising, OIC splits the work between two agents: a Planner that thinks once and writes out the full ordered list of steps (never touching a tool), and an Executor that runs that exact list without re-thinking the strategy. Like an architect's blueprint followed by the construction crew — the blueprint is drawn once, and the crew doesn't redesign the building mid-build. 🏗️

How it runs, step by step (matching the diagram below):

1. The Planner reads the claim details and, without calling anything, writes out the complete numbered plan up front
2. That plan is handed to the Executor as a fixed to-do list
3. The Executor calls Tool 1, then Tool 2, then Tool 3 — always in that order, never skipping or reordering
4. If any step fails or a tool errors, the Executor stops and escalates to a human rather than improvising a workaround
5. Once all steps are done, it applies the guidelines (e.g. amount thresholds) to reach APPROVE, REJECT, or ESCALATE

Notice what's missing compared to ReAct: there's no "thinking again" between tool calls. The Executor isn't smarter mid-flight — it's disciplined. All the judgment happens once, upfront, in the Planner.

✅ Practical Example:

Finance mandates that every expense claim, big or small, must always go through the same 3-way check for audit reasons — no shortcuts, not even for the $45 parking receipt from our ReAct example. The Planner writes the fixed plan once: cost center → policy → travel match → decide. The Executor then runs all three tool calls in that exact order every single time, regardless of the claim amount. Compare this to ReAct's $45 example, where the agent skipped the travel-match check entirely for a small claim — under Plan & Execute, that shortcut simply isn't possible, because the plan is fixed before the agent even sees how small the amount is. That's the trade-off: you lose ReAct's efficiency-on-easy-cases, but you gain a guarantee that every claim gets the identical, auditable sequence of checks — exactly what a regulated, always-the-same-sequence process needs. 🧾

🎯 Use Plan & Execute when: you can already name the exact tools and order before the agent starts — think fixed 3-way matches in Procurement, or any process where "always do it the same way" matters more than adapting per case.

🌐🗂️ 4. Plan for OCI GenAI

The same Planner + Executor split as above, but running on OCI Generative AI. This is the pattern architects reach for when a process is both fixed/structured and subject to data-residency or governance rules at the same time — for example, a Payroll or Finance-close process where "always do it the same way" and "the data must never leave OCI" are both hard requirements simultaneously. 🔐

This is also where architects get a genuinely useful cost-optimization lever that the other three patterns don't offer as cleanly: because the Planner and Executor are two separate agents, you can assign them different sized models. Put a bigger, smarter model on the Planner — getting the plan right, once, matters most — and a smaller, cheaper model on the Executor, since it's only following instructions rather than making fresh judgment calls. At high transaction volumes, that difference in cost per run adds up fast. 💰

✅ Practical Example:

Acme Corp processes 50,000 expense claims a month and needs the data to stay inside OCI for compliance — the same residency requirement as our ReAct-for-OCI-GenAI example, but now combined with the fixed, audit-ready sequence from Plan & Execute. In practice, the Planner (a larger, more capable OCI-hosted model) writes the same fixed 4-step plan for every claim of a given category. The Executor (a small, cheap OCI-hosted model) then just runs those steps thousands of times a day, faithfully, without needing to "reason" about strategy at each hop. Since the Executor is doing the bulk of the high-volume work, running it on a smaller model cuts LLM cost significantly compared to running a large model for every single one of those 150,000+ monthly tool calls (50,000 claims × 3 tool calls each) — while the Planner's slightly higher per-call cost barely matters, since it only runs once per claim category, not once per claim. 📉

🎯 Use Plan for OCI GenAI when: you need the determinism of Plan & Execute and the residency/governance of OCI GenAI at the same time — and want the flexibility to size each agent's model independently for cost control.

❓ Frequently Asked Questions

What is an Agent Pattern in OIC Gen3?

It's the reasoning discipline assigned to an AI Agent — whether it figures out its next step adaptively as it goes (ReAct) or plans every step up front before acting (Plan & Execute) — and whether the underlying model runs on a third-party LLM or on OCI Generative AI inside your own tenancy.

When should I use ReAct instead of Plan & Execute?

Use ReAct when the right next step genuinely depends on what a previous tool call returns — investigative or "it depends" tasks. Use Plan & Execute when you can name the exact tools and order in advance and need every run to follow the identical, auditable sequence, such as a regulated 3-way match process.

Why choose the OCI GenAI variant of a pattern instead of a third-party LLM?

Three enterprise reasons: data residency (reasoning data never leaves the OCI region), unified billing through the same Universal Credits pool as the rest of OIC, and governance parity, since the same IAM policies and dynamic groups that cover other OCI services also cover the AI Agent.

Can the Planner and Executor use different models in Plan for OCI GenAI?

Yes — since they are two separate agents, a larger, more capable model can be assigned to the Planner (which only runs once per plan) while a smaller, cheaper model runs the Executor (which handles the bulk of repeated tool calls), meaningfully reducing cost at high transaction volume.

Can I use an OCI GenAI model in a different region from my OIC instance?

No — cross-region calls are not supported. The OCI Generative AI model must live in the same OCI region as your OIC instance, so always check regional model availability before designing an agent around a specific model.

📝 Summary

• ReAct → adapts step-by-step; best when the next action depends on what was just learned
• ReAct for OCI GenAI → same loop, hosted inside your OCI tenancy for residency/governance
• Plan & Execute → fixed, pre-written plan run exactly as written; best for structured, audit-heavy processes
• Plan for OCI GenAI → same split, OCI-hosted, with the option to size Planner and Executor models differently for cost control

Happy building! ✨