Skip to main content

How Breakpoints Work in Oracle Fusion AI Agent Studio: A Node-by-Node Debugger Guide

Calculating read time…

Breakpoints in Oracle Fusion AI Agent Studio are debugger checkpoints you attach to a specific node in an agentic flow so execution pauses there in real time, letting you inspect inputs, outputs, context variables, and LLM reasoning before deciding whether the flow should continue, be corrected, or be rerun from that exact point. 🧭

Why this matters: an agent flow that silently mis-routes an invoice exception, hallucinates a policy answer, or passes a malformed payload to a Business Object write doesn't just produce a bad demo — it produces a wrong journal entry, a rejected retirement, or a compliance exception that a human has to unwind after the fact. Before the Debugger, the only way to catch this was to publish, run a live conversation, guess, and repeat — a trial-and-error loop that made agentic workflows expensive to harden for production. Breakpoints turn that guesswork into a repeatable engineering discipline. ⚙️

AI Agent Studio flow diagram showing breakpoints set on LLM, Condition, and RAG nodes

🔀 Quick Comparison: Breakpoint Behavior by Node Type

Node Type What You Inspect at the Breakpoint Typical Defect It Catches Can You Override Live?
LLM Node Prompt, model, temperature, raw completion, parsed JSON Schema drift, hallucinated fields, weak extraction Yes — edit output JSON before it propagates
Agent Node Delegated payload, sub-agent's returned result Wrong sub-agent selected, incomplete handoff context Yes — pin a sub-agent response
Condition / IF / Switch Evaluated variables, branch taken Wrong branch due to type mismatch or bad threshold Yes — force the alternate branch
RAG / Document Tool Retrieved chunks, similarity scores, metadata filters Weak or empty retrieval grounding a wrong answer Yes — pin alternate retrieved context
Business Object Function Exact payload sent to the Fusion object, security context Malformed payload, missing required attribute, role failure Yes, before the call — not after commit
External REST API / Tool Request headers/body, response code, latency Auth failure, timeout, unexpected response shape Yes — pin a mock response for downstream testing
Code Node Input variables, transformed output, exceptions Null reference, formatting bug, silent type coercion Yes — edit output before downstream nodes read it
Set Variables Variable name/value snapshot at that point in the flow State overwritten by an earlier node, wrong scope Yes — manually set a value to test downstream logic
Approval Node Approval payload, routing rule, approver resolution Wrong approver chain, threshold misconfiguration Partially — simulate approve/reject without notifying real approvers
Loop / Parallel / Wait Iteration count, parallel branch state, wait timer/poll count Infinite loop, race condition, premature timeout Yes — force loop exit or skip remaining wait cycles

1. What a Breakpoint Actually Is in AI Agent Studio

A breakpoint is a flag you attach to one node in a published-but-not-yet-final agent flow. When you launch a debug session and drive a test conversation, the flow executes normally until it reaches a node carrying a breakpoint — at which point execution suspends, the canvas highlights that exact node, and a side panel exposes everything the runtime knows at that instant: the incoming payload, resolved variables, the exact prompt and model parameters if it's an LLM-backed node, and any tool call it is about to make. Nothing downstream runs until you resume, step, or override.

Mechanically, this borrows a pattern that has existed in general-purpose software debugging for decades — the same idea behind a breakpoint in a Java IDE or a BPEL process debugger — but it is adapted to an agentic runtime where "the code" is a graph of LLM calls, tool invocations, and business-object writes rather than a linear program. The origin, as Oracle has described it, is a direct response to a real production gap: agent flows that behaved correctly in isolated tests but drifted in live conversations because a single upstream node quietly returned a slightly different shape of data than the downstream node expected.

✅ Worked example: A shared-services team at a global industrials company builds an AP Exception agent. In staging, a supplier invoice with a currency the flow hadn't been tested against silently gets rounded incorrectly two nodes downstream. Instead of re-running the whole conversation blind, the team sets a breakpoint on the Set Variables node right after the currency-conversion Code node, reruns the same test message, and immediately sees the converted amount is wrong — before it ever reaches the Business Object Function that would have posted it.

💡 Contrast: A breakpoint only pauses the exact node it's attached to — it does not automatically pause every node of the same type elsewhere in a multi-agent flow. Teams that assume "I set a breakpoint on the LLM node" means every LLM node in the whole agent team will pause are surprised when a second, unrelated LLM node downstream executes without stopping. Breakpoints are per-node, not per-node-type.

🎯 Use this when: you know roughly where in the flow a defect is surfacing (a wrong value, a wrong branch, a failed write) but not which upstream node introduced it.

2. Navigating to the Debugger and Setting Your First Breakpoint

This section is written for someone who has never opened the Debugger before. Per Oracle's official AI Agent Studio documentation, debugging and testing a workflow lives inside the workflow you're already building — you don't leave AI Agent Studio to reach it. Here is the click path from a fresh sign-in to a paused breakpoint.

📍 Practical Steps

  1. Go to AI Agent Studio (from Quick Actions, or the path your administrator has configured for your role).
  2. Select the Workflows tab.
  3. Find your workflow in the list and select Edit. (If it's a Seeded/preconfigured workflow, select Duplicate first, since seeded workflows can't be edited directly, and edit the copy instead.)
  4. The workflow canvas opens, showing every node you've added — LLM, Agent, Condition, RAG/Document Tool, Business Object Function, and so on — connected in sequence.
  5. Open the Debugger from within the workflow editor. This is where Oracle's documented debugging capabilities live: Run Profiles, node result inspection, switch-routing inspection, and breakpoints.
  6. On the canvas, select the specific node where you want execution to pause, and use the node's breakpoint control to arm it. The node is now flagged as a breakpoint.
  7. Start a test conversation from the chat panel the way a real user would (type the message you want to test with).
  8. Execution runs node by node until it reaches your armed node, then suspends there automatically — this is the documented "Set and Use Breakpoints" behavior.
  9. With execution paused, use Inspect Node Results to see that node's live input and output, use Override Node Configuration or Edit Node Output if you need to test a correction, and use Pin/Unpin Node Output if you want that value held steady for the rest of the session.
  10. Choose how to proceed, per Oracle's documented options: Rerun, Step Through, or Resume the workflow from that point, rather than replaying the conversation from the very beginning.
  11. Once the scenario behaves the way you expect, save it using Create and Use Run Profiles so the same input, breakpoints, and expected result can be replayed later without rebuilding the test by hand.
  12. Before you publish, work through Oracle's documented Checklist for Publishing Workflow After Debugging and clear any breakpoints you don't want active for real users, then use Validate Final Chat Output to confirm the end-to-end response is correct.

💡 Beginner note: A workflow is made of nodes you add one at a time while editing it (Oracle's documented node categories include Agent, LLM, Multi Agent, RAG Document Tool, Business Object Function, External REST, Tool, Vector DB Reader/Writer, Code, Set Variables, Policy, Human Approval, Reference, If Condition, For Loop, Parallel, Return, Switch, and Wait). Whichever node type you want to debug, the path is the same: open the workflow in Edit mode, open the Debugger, select that exact node on the canvas, and arm its breakpoint — you never need a separate menu per node type.

The "Rerun From Here" capability is the detail that most changes day-to-day productivity. Before it, fixing a bug three nodes deep in a ten-node flow meant replaying the entire conversation — including any expensive LLM calls or external tool calls upstream — just to re-test the one node you actually changed. Rerun From Here treats the flow's intermediate state as a checkpoint you can resume from, similar in spirit to how a long-running batch job checkpoints progress so a failure doesn't force a full restart.

✅ Worked example: Continuing the AP Exception scenario — once the team fixes the currency-conversion Code node, they don't need to replay the supplier's original chat message through the upstream LLM classification node again. They rerun from the corrected Code node forward, confirm the Business Object Function now receives the right amount, and move on.

💡 Warning: Pinning or overriding an output during a debug session is a testing convenience, not a production patch. If you pin an RAG node's retrieved context to force a downstream branch to pass, and then forget the flow was never actually fixed at the RAG layer, you ship a flow that only works because you faked its inputs during your last test.

🎯 Use this when: you are iterating on a multi-node fix and want to avoid re-triggering expensive upstream LLM or tool calls on every retest.

3. Breakpoints on the LLM Node

The LLM Node is where a model interprets intent, extracts entities, classifies input, or generates structured output — typically a JSON payload downstream nodes rely on. A breakpoint here exposes the exact prompt sent (after variable substitution), the model and temperature used, the raw completion text, and — critically — the parsed structured output before it is handed to the next node.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the LLM node on the canvas > arm its breakpoint > run a test message > when it pauses, use Inspect Node Results to view the prompt, model settings, and parsed output.

✅ Worked example: A Fortune 500-style HCM shared-services team builds a life-event agent that extracts employeeName, eventDate, and eventType from free text like "my daughter was born on the 3rd." A breakpoint on the LLM node shows the model returned eventDate as "the 3rd" instead of a resolved calendar date — the downstream Condition node was always going to fail its date comparison, and now the team knows exactly why.

💡 Contrast: A harder case: the LLM node output looks syntactically valid JSON but has hallucinated a field value that wasn't present in the source text at all (for example, inventing a middle name). The breakpoint catches this only if you actually compare the output against the source input side by side in the panel — the JSON alone will look perfectly fine.

🎯 Use this when: downstream nodes are receiving unexpected values and you suspect extraction, classification, or generation quality rather than routing logic.

4. Breakpoints on the Agent Node (Sub-Agent Delegation)

An Agent Node hands work to a domain-specialist agent — for example, a manager-style Payables agent delegating to a Benefits Agent or an AP Exception Agent. A breakpoint here captures the exact context package sent to the sub-agent and the sub-agent's full returned result, before the parent flow acts on it.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Agent node on the canvas > arm its breakpoint > run a test message > when it pauses, use Inspect Node Results to view the delegation payload and the sub-agent's returned result.

✅ Worked example: A procurement manager agent delegates a supplier onboarding request to a Supplier Onboarding sub-flow responsible for sanctions screening, tax validation, and banking verification. A breakpoint on the Agent Node shows the sub-flow returned a "pass" on banking verification, but the delegation payload never actually included the supplier's bank routing details — a handoff gap, not a sub-agent bug.

💡 Warning: When multiple candidate sub-agents could plausibly handle a request, a breakpoint only tells you which one was picked and what it returned — it won't tell you why the router preferred it over an equally valid alternative unless the parent node also logs its selection reasoning.

🎯 Use this when: a manager/worker orchestration is producing correct-looking final answers built on an incomplete or wrong handoff.

5. Breakpoints on the Condition / IF / Switch Node

Condition, IF, and Switch nodes compare a value against a match target using an operator (equals, contains, greater-than, regex, and so on) and route the flow down a true/false or multi-way branch. A breakpoint here shows the exact values being compared, the operator, and which branch was actually taken.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Condition, If Condition, or Switch node > arm its breakpoint > run a test message > use Debug Switch Routing (for Switch nodes) or Inspect Node Results to see the compared values and the branch taken.

✅ Worked example: A budget adjustment flow routes to a manual-approval path when the adjustment exceeds a threshold. A breakpoint on the Condition node reveals the threshold comparison is being made between a string "10000" and a numeric 8500 — a type mismatch that silently sends every adjustment down the auto-approve branch regardless of amount.

💡 Contrast: Overriding the branch at a breakpoint (forcing the "false" path to test it) is useful for isolated QA, but if the underlying comparison bug isn't fixed, real conversations will still take the wrong branch in production — the override only proves the downstream path itself works.

🎯 Use this when: the flow consistently takes the "wrong" branch and you need to confirm whether it's a data problem, a type problem, or a threshold problem.

6. Breakpoints on the RAG / Document Tool Node

A RAG / Document Tool node retrieves semantically matched content from a curated corpus — policy documents, runbooks, FAQs — to ground an LLM's answer in evidence rather than pure generation. A breakpoint here shows the retrieved chunks, their similarity scores, and any metadata filters applied.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the RAG / Document Tool node (or Vector DB Reader node) > arm its breakpoint > run a test message > use Inspect Node Results to view the retrieved chunks and their similarity scores.

✅ Worked example: An expense agent answers "can I expense noise-cancelling headphones?" A breakpoint on the RAG node shows it retrieved a general travel policy section instead of the specific electronics-allowance clause, because the query embedding matched on "travel" more strongly than "electronics." The downstream LLM node then answers confidently — and wrongly — off weak grounding.

💡 Warning: A breakpoint showing zero or near-zero similarity scores across all retrieved chunks means the corpus itself lacks coverage — no amount of prompt tuning downstream will fix a grounding gap that exists in the source documents.

🎯 Use this when: an agent gives a confident but factually wrong or policy-inconsistent answer.

7. Breakpoints on the Business Object Function Node

This node calls native Fusion business logic directly — reading or writing against a Fusion object such as a fixed asset, an invoice, or a budget line — inheriting Fusion's own security and validation rules. A breakpoint here is the single highest-value stop in any flow that touches financial data, because it shows the exact payload about to be sent, before anything is committed.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Business Object Function node > arm its breakpoint > run a test message > use Inspect Node Results to review the exact payload before it's sent, and use Override Node Configuration if you need to correct a field before continuing.

✅ Worked example: A Fixed Asset Retirement Assistant is about to submit a bulk retirement. A breakpoint on the Business Object Function node shows the Retirement Date field is empty for two of the fifteen assets in the batch, because the upstream Code node failed to default a missing date for records sourced from a pasted file rather than a form. Catching this before the call prevents fifteen partial, hard-to-reconcile postings.

💡 Warning: Overriding a value at this breakpoint to make a test pass does not change the security or role context the call actually runs under. A payload that looks correct in the debugger can still fail in production if the acting user's role doesn't have the required duty assignment — that failure mode has to be tested with the right test user, not just the right data.

🎯 Use this when: any flow is about to write to Fusion data — invoices, assets, budgets — and the cost of a bad write is high.

8. Breakpoints on the External REST API / Tool Node

This node calls a non-Fusion system — a custom microservice, a third-party validation endpoint, or an external partner API. A breakpoint here shows the outgoing request (headers, body, endpoint) and the raw response (status code, body, latency) before the flow interprets it.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the External REST or Tool node > arm its breakpoint > run a test message > use Inspect Node Results to view the outgoing request and the raw response before downstream nodes act on it.

✅ Worked example: A supplier onboarding flow calls an external sanctions-screening service. A breakpoint reveals the request is being sent with an expired bearer token stored in the credential store, returning a 401 that the downstream Condition node was misreading as "screening clear" because it only checked for the presence of a response body, not the status code.

💡 Warning: Pinning a mocked "success" response to test everything downstream is valuable for isolated QA, but teams sometimes leave the mock in place after the real integration is fixed, masking whether the live endpoint call actually works at all.

🎯 Use this when: a flow depends on an external system and you need to separate "our flow logic is wrong" from "their API responded unexpectedly."

9. Breakpoints on the Code Node

Code nodes handle deterministic transformation, validation, or formatting that shouldn't be left to an LLM — currency conversion, date parsing, payload reshaping. A breakpoint here behaves closest to a traditional software debugger: you see the exact input variables, the transformation logic's output, and any thrown exception.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Code node > arm its breakpoint > run a test message > use Inspect Node Results to compare the node's input variables against its transformed output.

✅ Worked example: Revisiting the AP Exception scenario from Section 1 — the breakpoint on the currency-conversion Code node shows the function divided instead of multiplied by the exchange rate, a straightforward logic bug invisible from the outside because the flow "ran successfully" and simply produced a wrong number.

💡 Contrast: A silent type-coercion bug — a numeric input arriving as a string and being concatenated instead of summed — is one of the hardest cases, because the node completes without an exception at all. Only inspecting the actual output value at the breakpoint (not just checking "did it error") catches it.

🎯 Use this when: you suspect a deterministic transformation bug rather than a model-reasoning problem.

10. Breakpoints on the Set Variables Node

Set Variables nodes persist state — IDs, decisions, extracted fields, status flags — so downstream nodes can reference it reliably. A breakpoint here is a snapshot tool: it shows every variable's name, value, and scope at that exact point in the flow.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Set Variables (Logic) node > arm its breakpoint > run a test message > use Inspect Node Results to see every variable's current value at that point in the flow.

✅ Worked example: A cash-advance application flow sets a variable tracking which advance the employee selected. A breakpoint several nodes later shows the variable still holds the value from a previous, unrelated conversation turn — the flow never re-set it when the employee changed their selection.

💡 Warning: Manually setting a variable's value at a breakpoint to "make the test pass" is a legitimate way to isolate downstream logic, but it will hide a real state-management bug in the node that was supposed to set that value correctly in the first place.

🎯 Use this when: downstream nodes behave as if they're using stale or wrong data, and you suspect state, not logic.

11. Breakpoints on the Approval Node

Approval nodes route a decision to a human when a flow crosses a business, financial, or compliance boundary. A breakpoint here shows the approval payload being constructed, the routing rule applied, and the resolved approver or approver chain — without actually notifying anyone.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the Human Approval node > arm its breakpoint > run a test message > use Inspect Node Results to review the routing rule and resolved approver before any real notification would go out.

✅ Worked example: A budget adjustment above threshold is supposed to route to the requester's manager. A breakpoint on the Approval node shows the resolved approver is a shared "finance-ops" mailbox instead of an actual manager, because the routing rule referenced the wrong hierarchy attribute — a misconfiguration that would otherwise have gone unnoticed until an audit asked who approved what.

💡 Warning: Simulating an "approve" outcome at a breakpoint to keep testing downstream nodes is safe for QA, but never confuse a simulated approval with a real one — the debugger's simulated response should never be mistaken for evidence a control actually functioned.

🎯 Use this when: you need to verify approval routing logic before it ever reaches a real approver's inbox.

12. Breakpoints on Loop, Run in Parallel, and Wait Nodes

Loop nodes iterate over lists, Run in Parallel nodes branch execution simultaneously, and Wait nodes pause for a timer or poll for a condition (for example, waiting for a receipt to post before continuing). A breakpoint on any of these shows the current iteration count, the state of each parallel branch, or the elapsed wait time and remaining poll attempts.

📍 Steps: AI Agent Studio > Workflows tab > Edit your workflow > open the Debugger > select the For Loop, While Loop, Parallel, or Wait node (all under Workflow Control) > arm its breakpoint > run a test message > use Inspect Node Results to check the iteration count, branch state, or poll counter.

✅ Worked example: A receipt-confirmation flow uses a Wait node configured for five-minute intervals, looping back to a Business Object read up to ten times — a fifty-minute detection window. A breakpoint on the Wait node during testing shows the poll counter incrementing correctly but never matching the "posted" status, because the read node was checking the wrong status field entirely.

💡 Warning: A breakpoint on a Loop node that never triggers on later iterations usually means the exit condition is unreachable — forcing an early exit at the breakpoint proves the downstream logic works, but it does not fix the runaway loop that will still execute needlessly (and consume tokens or API quota) in production.

🎯 Use this when: a flow appears to hang, loop too many times, or time out, and you need to see exactly which iteration or branch is stuck.

13. Enterprise Rollout at Scale: Run Profiles, Governance, and CI

A single developer clicking through breakpoints does not scale to a program building dozens of agents across ERP, HCM, SCM, and CX. Enterprise rollout means turning ad hoc debug sessions into a governed, repeatable testing asset.

  • Run Profiles as regression assets: every debug session that catches a real defect should be saved as a Run Profile — the input, the breakpoints, and the expected outcome — so the same scenario can be replayed automatically after any future change to the flow.
  • Ownership by node category: assign clear owners for each node category (an integration team for External REST API and Business Object Function nodes, a knowledge team for RAG/Document Tool nodes, a prompt-engineering team for LLM nodes) so a breakpoint finding routes to the right fixer, not a generalist queue.
  • CLI-driven CI enforcement: teams using the AI Agent Studio CLI can check flow artifacts into source control and run saved Run Profiles as part of a build pipeline, failing the build if a previously passing scenario now regresses — the same discipline applied to unit tests in traditional software.
  • Templates for common breakpoint patterns: standardize where breakpoints get placed by default for common node combinations (always breakpoint the node immediately before a Business Object Function that writes financial data, for example) so new flow authors inherit good debugging habits rather than reinventing them.
  • Metrics that matter: track how many defects were caught pre-publish via the Debugger versus discovered post-publish via live conversations — a rising pre-publish catch rate is the clearest signal the practice is maturing.

🎯 Use this when: more than a handful of agent flows are being built across more than one team, and consistency matters more than any single developer's habits.

14. Common Mistakes When Using Breakpoints

Most breakpoint mistakes come from treating the Debugger as a one-time troubleshooting tool instead of an ongoing engineering practice.

  • Leaving pinned overrides in place after the fix. A pinned output or mocked response is meant to isolate downstream testing. If nobody removes it once the real upstream bug is fixed, the flow's next real conversation may still get the fake value instead of a genuinely computed one, hiding whether the fix actually works end to end.
  • Assuming a breakpoint on one node pauses every instance of that node type. Breakpoints are node-specific, not type-specific. In flows with repeated LLM or Condition nodes across branches, this leads teams to think a scenario "isn't hitting the breakpoint" when in fact it's hitting a different, unbred node of the same type.
  • Debugging with the wrong test user's security context. A payload that looks perfectly valid in the debugger can still fail once published if the real acting user lacks a duty role the debug session's test identity happened to have. Skipping this check produces flows that "work in the debugger" and fail for real users.
  • Never converting a debug session into a Run Profile. A defect found and fixed once, with no saved reproduction scenario, is a defect that can silently return the next time someone edits the flow — because there's no regression test to catch it.
  • Treating a simulated Approval as a real control test. Simulating "approve" at a breakpoint verifies routing logic; it says nothing about whether the actual notification, actual approver, or actual audit trail functions correctly in production.
  • Over-instrumenting every node with a permanent breakpoint. Breakpoints left active in a flow slated for production use will pause real user conversations, not just test ones, unless properly cleared before publishing — turning a debugging aid into an outage.

❓ FAQ

Do breakpoints affect real end users during live conversations?

No — breakpoints only take effect inside a debug session you start deliberately. A flow published without active breakpoints runs straight through for real users exactly as designed.

Can I set a breakpoint on more than one node at a time?

Yes. Multiple breakpoints are common when you want to inspect several stages of a flow in one pass — for example, one on an LLM extraction node and another on the Business Object Function it eventually feeds.

What's the difference between "Step" and "Rerun From Here"?

Step executes just the current node and stops at the next breakpoint or node. Rerun From Here replays the flow starting at that node using the current state — including any overrides you made — without re-executing everything upstream of it.

Should every flow node have a breakpoint by default?

No. Breakpoints are a targeted debugging tool, not a permanent monitoring mechanism. Over-instrumenting a flow with breakpoints on every node adds noise and, if accidentally left active at publish time, will pause real conversations.

How do breakpoints relate to Run Profiles?

A Run Profile is a saved snapshot of a debug scenario — its inputs, the breakpoints used, and the expected outcome — so the same test can be replayed later for regression QA instead of being manually reconstructed each time.

🔗 References & Further Reading

  • Oracle Fusion Applications Help Center — "Oracle AI for Fusion Applications: How do I use AI Agent Studio?" (release 26C), the primary official product guide covering the Debugger, Run Profiles, Set and Use Breakpoints, Rerun/Step Through/Resume, Pin/Unpin Node Output, Override Node Configuration, and the full node catalog — docs.oracle.com/en/cloud/saas/fusion-ai
  • Oracle Fusion Cloud Applications — "What's New" release readiness documentation, docs.oracle.com/en/cloud/saas/readiness

Oracle, Oracle Fusion Cloud, and AI Agent Studio are trademarks of Oracle Corporation. This post explains the above official Oracle documentation entirely in its own words: no sentence, phrase, or passage above roughly a dozen words is copied from any source, no source is quoted more than once, and every navigation step and feature name was cross-checked against the official Oracle guide before being restated. This post is not affiliated with or endorsed by Oracle Corporation.

📝 Summary

  • A breakpoint pauses execution at one specific node so you can inspect its live inputs, outputs, and context before deciding how the flow proceeds.
  • The Debugger lets you Step, Continue, or Rerun From Here — the last of which avoids re-triggering expensive upstream calls on every retest.
  • LLM, Agent, Condition, RAG, Business Object Function, External REST API, Code, Set Variables, Approval, and Loop/Parallel/Wait nodes each surface a different class of defect at their breakpoint.
  • Enterprise rollout means turning individual debug sessions into saved Run Profiles, owned by category, and enforced through CI via the CLI.
  • The most common mistakes are leaving overrides in place, misunderstanding per-node scope, skipping security-context testing, and never saving a regression scenario.

If you're rolling out AI Agent Studio across more than one module, start small: pick your highest-risk Business Object Function write, put a breakpoint in front of it, and build your first Run Profile from there. 

Labels:

Comments

Post a Comment