Meet the app you will build.

Try this

Select TRAIN-101, Payments slow after a release. Request: Analyze this synthetic incident using read-only evidence.

1. Create a synthetic ticket; search and filter it.
2. Select TRAIN-101 and sign in to the app, separately from the builder workspace.
3. Choose Analyze safely once and inspect the returned answer.

What it should look like

A ticket inbox on the left; selected ticket, analysis request and readable answer on the right. Loading, sign-in and failure states are visible.

What a good result says

An actual model answer separates observations, uncertainties and safe next checks. Payments p95 is 1,800 ms and errors are 1.2% in the synthetic fixture. Release r42 is a correlation, not a confirmed cause.

Try this

Repeat the selected synthetic incident, then test an unknown tool and an argument outside the selected service scope in isolated tests.

1. Keep the same inbox and Analyze safely action.
2. Inspect the server tool registry and strict argument validation.
3. Open the actual run inspector after one successful investigation.

What it should look like

An expandable inspector below the answer shows actual model/tool events. A teaching animation explains these events but is not a live trace.

What a good result says

Only service_health and release_diff can execute in the Lovable example. The observed successful run used both tools and two model calls, below its three-call limit. Rejected tool cases must be checked in code tests.

Try this

Use the same synthetic task for each explicitly selected, available model. Keep tool inputs and limits fixed.

1. Read provider-reported input and output usage from the real run.
2. Add matching sourced token rates only when available; otherwise show unknown.
3. If a second model is available, compare answer quality, tool behavior, latency and usage on the same task.

What it should look like

A compact measurement panel beside the answer. Comparison rows distinguish reported tokens, illustrative arithmetic, estimated model cost and actual provider charges.

What a good result says

The reviewed Lovable run reported 761 input + 191 output = 952 total tokens and 5,218 ms. Estimated cost remained unknown. These are one run's observations, not a benchmark or a bill.

Try this

Provide LANGFUSE_BASE_URL, LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY only through the app's server-side settings.

1. Use the three-value instrumentation prompt with your current builder and existing LLM.
2. Run one synthetic investigation and retain its actual trace/session identifiers privately.
3. Find that exact trace in your own Langfuse project and check the root, authorization, actual generations and tools.

What it should look like

Your real Langfuse project shows a trace tree and reported usage. Until configured, the app explicitly displays Langfuse not configured; no imitation dashboard is presented as evidence.

What a good result says

Expected structure: agent root → authorization; generation 1 → tools; generation 2 → answer. Export acknowledgment and independent readback are separate results. OCI APM spans and Log Analytics events require their own configured destinations and readback.

Try this

Choose Test a change request in the authenticated app. Exercise malformed tools and controlled dependency failures in isolated tests.

1. Keep the working investigation path.
2. Trigger the explicit change-request control and inspect its response.
3. Verify zero model calls, then examine local tests for unknown tools, malformed arguments and safe failures.

What it should look like

A clear refusal beside the original ticket, with a zero-call inspector. Failures stay visible instead of being replaced with a fake answer.

What a good result says

approval_required; model not called; model calls 0 / 3. The actual app inspector reports an explicit server block. There is no automatic approval-resume or system-changing tool.

Try this

Use your own reviewed OCI scope and supported agent-hosting option; preserve the existing app and runtime compatibility.

1. Review OCI AI Platform options and the Private Agent Factory walkthrough; confirm the selected runtime supports your app.
2. Prepare a deployment plan and exact resource/cost inventory before requesting deployment authority.
3. After an approved deployment, repeat create → select → analyze → change stop, then independently read back telemetry and test rollback.

What it should look like

A deployment checklist showing source, artifact, runtime, canary, telemetry and rollback separately. Missing cloud access remains visibly pending.

What a good result says

A reviewed release packet with immutable artifact identity, permissions, secret references, health and canary results, exact telemetry readback and rollback procedure. A rendered plan alone never satisfies this gate.