An agent sees a successful deployment and reports that the customer's problem is fixed. Another sees a configured data job and reports that the data is current. Neither has answered its assigned question.

Operational agents need to keep configuration, execution, and the result someone cares about as separate facts, whether investigating a site on Vercel or a data workflow in Databricks.

Use this method with your existing agent. Start with read access and add a separately authorized change when the diagnosis calls for one.

Start with the user-visible symptom#

"Check the deployment" is a tool-oriented task. "Determine whether the affected user can save their settings on the production site" gives the investigation an outcome to establish. Likewise, "inspect the job" leaves the agent to decide what success means, while "determine whether the report contains the expected data for the requested period" names the result.

Write the expected observation before the agent starts browsing status pages, with the environment, account, or dataset scope. Otherwise the investigation drifts toward the easiest green indicator.

Pin the object and its environment#

Suppose a preview deployment contains the fix and the production domain still serves an earlier version. A successful preview is evidence about that preview and says nothing about production.

Vercel documents Local, Preview, and Production environments, including distinct deployment paths and environment configuration. Keep the project, deployment identifier, intended environment, and user-facing URL in the task brief, since a mutable alias or project name alone does not identify the version.

For a data workflow, keep the workspace and job identifier, then identify the execution for the reported period. Databricks exposes a separate job-run retrieval API, because a job definition and an execution are different objects.

Build an evidence ladder the agent can follow#

Each observation has a job:

Observation	What it establishes	What remains to check
Project or job configuration	The intended object and setup	Whether the relevant execution happened
Deployment or execution result	What happened to that attempt	Whether the intended destination uses its result
Destination state	Which output or version is present	Whether the reported user behavior is correct
A targeted behavioral check	The outcome for that scenario	Whether the conclusion applies beyond that scope

If the connection cannot retrieve the next missing observation, hand the question to a tool or person that can.

A deployment marked successful still needs a check at the production URL, and a completed data execution still needs a check that its output covers the requested period. The agent names the next missing observation.

Use read access to narrow the investigation#

The Vercel connection reads projects and deployments. The Databricks connection reads clusters, warehouses, pipelines, jobs, and instance pools. These reads locate the objects involved and prepare a handoff. They do not deploy, roll back, launch a job, or query every output dataset. When another authorized tool is needed, pass it the exact object and the unanswered question. Broader credentials do not create a missing operation.

A diagnostic prompt:

Identify the project or job relevant to the reported symptom.
Record the environment and the exact objects inspected.
Separate configuration, execution status, and observed output.
For each conclusion, state which observation establishes it.
If a required check is unavailable, name that check and the tool or owner needed.
Do not repeat a recovery action whose earlier outcome is unresolved.

Recovery attempts need an identity#

An uncertain response after a recovery action is dangerous. Starting another deployment or data execution creates competing outputs and obscures the original failure.

If your execution tool exposes an operation identifier, keep it. Inspect that attempt and the destination before deciding on another, and keep the reason for retrying with the task so a later agent can tell a deliberate recovery from an accidental loop.

For changes routed through Deixic, review the proposed target and apply the relevant approval policy. Keep approval, execution result, and observed behavior as separate facts in the handoff.

Make the completion statement as specific as the check#

Two useful conclusions:

The named production URL served the intended version and the settings-save scenario passed.
Job configuration was inspected, and output freshness still needs a dataset check.

Both beat "everything looks good."

Test the workflow with four cases: a successful preview with stale production, a job definition without the relevant execution, an execution whose output is incomplete, and an interrupted recovery response. Save the method as a reviewed skill and refresh deployment and execution facts on each task.

The agent finishes by closing the actual question or naming the exact observation still needed. A green status is a clue; the customer's working result is the point.