Put business rules in profiles before data agents reach dashboards

A useful data-agent rollout does not begin with a chat box. It begins by deciding where business meaning, data access and agent behavior live—and keeping those responsibilities separate.

Oracle’s reusable business-context guide makes that separation concrete. It puts SQL-specific definitions—such as how to interpret “last week,” what counts as a delayed flight and whether cancelled flights are excluded—in an NL2SQL profile. Retrieval constraints belong in a separate RAG profile. Agent persona and orchestration duties normally belong in the agent role and task definitions.

Put durable rules at the layer that enforces them

This is more than prompt organization. Oracle says profile-level role and additional_instructions are added to each augmented prompt that uses the profile. The same SQL definitions can therefore apply across RUNSQL, SHOWSQL, EXPLAINSQL and related actions without every application repeating them.

Oracle also documents a call-level override through DBMS_CLOUD_AI.GENERATE. An application can temporarily change date handling, output shape or role for one request without mutating the shared profile. That yields a useful operating distinction: persistent business definitions go in the profile; request-specific presentation and scope stay with the call.

The same boundary should survive deployment. Oracle’s portable agent-team guide says team definitions can move as Open Agent Specification JSON or canonical PL/SQL. AI profile definitions, custom tool code, manifests and test assets can travel with them. Credential values, network ACLs, privileges, endpoints and target data-access policy remain responsibilities of the destination environment.

That means portability is not permission inheritance. A production promotion should rebind and validate local controls rather than assume that a working development agent carries authority with it. Oracle recommends recreating prerequisites first, then testing team objects, tool functions and representative requests after deployment.

Expand the conversational surface last

Looker’s release notes show the user-facing layer widening while configuration boundaries remain visible. Conversational Analytics verified queries are generally available, dashboard data agents remain in preview, copied dashboards preserve agent instructions, configurations and sources, and self-service models are limited to their assigned user database connections.

Taken together, the two vendors suggest a defensible rollout checklist:

1. Encode durable business definitions and approved objects in the relevant SQL or retrieval profile.
2. Keep SQL, RAG and orchestration instructions separate instead of relying on one oversized prompt.
3. Treat agent definitions as versioned release artifacts, but recreate credentials and privileges in each target environment.
4. Validate tool behavior and representative questions before promotion.
5. Only then expose the agent through dashboards or wider user groups.

This sequence cannot guarantee correct answers. It does make meaning, portability and access boundaries inspectable before the interface reaches more users—a stronger production gate than a polished demo response.