Punit S Baviskar - Oracle AI Agent Studio and Oracle Fusion AI ERP consultant in Pune, India. Builds production-grade RAG workflow agents, agentic AI, and Oracle inbound and outbound integrations. Oracle AI Agent Developer and Oracle Agentic AI Foundations Associate certified. Experience at Infosys, OPL Innovate and Tecnotree. Open to consulting, AI product and Forward Deployed Engineer (FDE) roles.

Article · 8 min read

Building workflow-type RAG agents in Oracle AI Agent Studio

A workflow agent is not a chatbot with a database attached. It is an ERP process with a language model somewhere inside it, and the difference shows up the moment you try to ship one.

Start from the process, not the prompt

The temptation with Agent Studio is to open the canvas and start wiring nodes. The engagements that went well started somewhere duller: a written description of the process as it runs today, including who approves what and where the exceptions live. An agent that automates a step nobody could describe tends to automate the wrong step.

Only once that is written down does the node graph become obvious. Understand the intent, set the variables the rest of the flow depends on, retrieve grounding data, act, then verify the result before it is returned.

Grounding is a data problem before it is a model problem

Retrieval quality decides the ceiling of the whole agent. Two things mattered more than any prompt tuning:

• Chunking that follows the document's own structure rather than a fixed character count.
• Filtering retrieval by the business context already in scope — ledger, business unit, period — so the model never has to disambiguate what the process already knows.

When an answer is wrong, check what was retrieved before you touch the prompt. Most of the time the model reasoned correctly over the wrong passages.

The full lifecycle is build, test, document, promote. Skipping the documentation step is how an agent becomes unmaintainable three sprints later.

The testing loop

Agents fail differently from code. A regression is not a stack trace; it is a subtly worse answer. What worked was a fixed set of representative questions with expected characteristics — not exact strings — run before every promotion, plus a guardrail check that the agent refuses cleanly when it lacks grounding.

What I would tell someone starting

Build the smallest agent that completes one real process end to end, including the unhappy path. A narrow agent that finishes is worth more than a broad one that demos well and stalls in UAT.

Article · 6 min read

Beyond the canvas: Business Objects, Deeplinks and code nodes

The out-of-the-box nodes cover more than people expect, right up until they don't. Knowing where that line sits saves a lot of rework.

Business Objects are the contract

A business object is the agreement between the agent and Fusion about what a thing is. Defining them carefully early pays off repeatedly: every downstream node, every prompt and every piece of documentation refers back to the same shape, and changes stay in one place.

Deeplinks are what make an answer useful

An agent that tells a user something is helpful. An agent that hands them the exact Fusion page to act on it is useful. Deeplinks turn a response into the start of a task rather than the end of a query, and they are the single cheapest improvement to perceived quality.

Code nodes: use sparingly, document heavily

Custom code nodes are the escape hatch for transformations the canvas cannot express — reshaping a payload, deriving a value, enforcing a rule the model should not be trusted with. Two rules held up in review:

• Deterministic logic belongs in code, never in the prompt. If the answer must be exact, do not ask a model for it.
• Every code node needs a comment explaining why it exists, because the next person will otherwise assume a node could have done it.

Article · 7 min read

Writing FDD and BR100 for AI-driven ERP modules

Functional documentation assumes deterministic behaviour. Agents are not deterministic, and the templates need adjusting rather than abandoning.

What changes

A classic FDD documents inputs, processing and outputs. For an agent, processing is probabilistic, so the document has to describe the boundaries instead: what the agent is grounded on, what it is permitted to do, what it must refuse, and what happens when it is unsure.

What stays the same

Everything about setup. BR100 remains a configuration record, and agents have plenty to record — the business objects, the deeplinks, the policies attached, the connections and scopes. Keeping to Oracle Modern Best Practices here matters, because it is the part an auditor or a future implementer will actually read.

The section worth adding

Add an evaluation section: the representative questions, what a good answer looks like, and the guardrails checked before release. It converts "we tested it" into something a reviewer can repeat.

Article · 5 min read

Guardrailing LLM responses in finance workflows

In a finance process, a confident wrong answer is worse than no answer. Guardrails are what make that trade explicit.

Refusal is a feature

The most valuable behaviour to engineer is a clean refusal: when grounding is missing, the agent should say so and point to where the answer would come from, rather than filling the gap. This is far easier to build in from the start than to retrofit after a stakeholder demo.

Evaluate before you monitor

Evaluation is a pre-release gate; monitoring is what runs afterwards. Both are needed, and they answer different questions. Evaluation asks whether this version is good enough to promote. Monitoring asks whether it is still behaving in production.

Cost belongs in the design review

Tokenisation and API pricing are design constraints, not a finance surprise. Retrieval size, context length and how often an agent is invoked all decide run cost, and all are decided at design time. Raising it in the design review is a much easier conversation than raising it in the retrospective.