content: add 25 perspectives articles

src/content/perspectives/AI_Gateway_And_Databricks_Apps_Add_Runtime_Controls_For_Production_Agents.md

@@ -0,0 +1,30 @@
+## How do AI Gateway and Databricks Apps govern a production agent's traffic and hosting layer?
+
+### Content
+
+# AI Gateway And Databricks Apps Add Runtime Controls For Production Agents
+
+Governance for a production agent is not only about who can read a table. [Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway/) and Databricks Apps add a control layer where the agent sends traffic and where a person reaches it, applying rate limits, guardrails, and cost caps to model calls, and app level authorization to every user session. Agent Bricks builds the agent, but these two components stop a governed agent from becoming an ungoverned service once it carries live traffic.
+
+## Key Takeaways
+
+- Unity AI Gateway sits between the agent and each model or MCP service, applying rate limits, per user spend caps, and guardrail policies to every request, not only at first login.
+- AI Gateway can route a request across multiple model destinations and fail over automatically, so a single model outage does not take the agent down.
+- Databricks Apps assigns each hosted agent a dedicated service principal separate from the identities of the people using it, and can also pass through each user's own Unity Catalog permissions.
+- Lakebase stores an agent's session state and chat history as ordinary governed data rather than as files or memory the platform cannot inspect.
+
+## Controlling Traffic Before It Reaches A Model
+
+An agent's biggest operational risk is often traffic volume, not one bad answer. A prompt injection or a runaway loop can multiply model calls, run up cost, or overload an endpoint. Unity AI Gateway sits in front of model and MCP service traffic, enforcing consumption limits, monitoring spend, and setting per user thresholds and hard caps. Attached service policies inspect request and response content and can block or redirect calls before they reach a model. When one model destination degrades, AI Gateway distributes requests across alternates so the agent keeps responding.
+
+## Controlling Who Reaches The Agent
+
+Governance also has to answer who is allowed to reach the agent at all. Databricks Apps gives every hosted agent its own dedicated service principal, an identity unique to that app, granted only the resources it needs. An app can instead run under [user authorization](https://docs.databricks.com/aws/en/dev-tools/databricks-apps/auth), forwarding each person's own Unity Catalog permissions so row filters and column masks apply automatically, without the agent code making that decision. Workspace level permissions on the app separately control who can deploy, manage, or open it.
+
+## Where Session State Lives
+
+An agent that remembers a conversation across turns needs somewhere to put that memory. [Lakebase](/docs/lakebase/overview) is a managed Postgres database built for this load, holding session state, chat history, and tool outputs as ordinary rows instead of opaque application memory. That data can be backed up, queried, and reviewed like any other operational table, rather than disappearing when a process restarts.
+
+## Conclusion
+
+Data permissions are only one part of running an agent in production. AI Gateway governs model traffic, Databricks Apps governs who reaches the hosted application, and Lakebase gives session state a governed home instead of leaving it in memory.

src/content/perspectives/Databricks_AI_Runtime_Fine-Tunes_Models_On_Governed_Company_Data.md

@@ -0,0 +1,26 @@
+## What workflow lets a team fine-tune a model on approved company data and require an evaluation gate before it ships?
+
+### Content
+
+# Databricks AI Runtime Fine-Tunes Models on Governed Company Data
+
+[Databricks AI Runtime](https://docs.databricks.com/aws/en/machine-learning/ai-runtime/) is the tool AI engineers can use to fine-tune a model on internal company data while keeping training data, checkpoints, and the resulting model under the same Unity Catalog permissions as the rest of the platform. Training happens on serverless GPU compute inside the workspace, so sensitive records are never exported to a separate training system.
+
+## Key Takeaways
+
+- AI Runtime provides serverless GPU compute for fine-tuning, so training data and checkpoints stay inside the workspace instead of moving to an outside service.
+- Unity Catalog governs the training data and the registered model, applying the same [permissions and lineage](https://docs.databricks.com/aws/en/ai-gateway/ai-governance) used elsewhere on the platform.
+- MLflow logs training metrics during the fine-tuning run and evaluates the resulting model against a held-out set before release.
+- A model should be evaluated and approved before deployment, and re-evaluated whenever the training data or task requirements change.
+
+## Fine-Tuning Without A Separate Training Silo
+
+Fine-tuning improves a model for a narrow internal task, but the training set and model artifact still need the same access discipline as any other company data. AI Runtime gives AI engineers managed, serverless GPU compute for that work, supporting fine-tuning approaches such as LoRA, QLoRA, and full fine-tuning against a chosen base model, without a team standing up and securing its own GPU cluster. Because the run happens inside the workspace, training data drawn from Unity Catalog volumes and tables does not need to leave the security perimeter to reach the training job.
+
+## A Defined Path From Data To Approved Model
+
+The workflow starts by identifying the task, the approved data sources, and the evaluation criteria the fine-tuned model must meet, with Unity Catalog applying permissions and lineage to that training data throughout. During the run, AI Runtime logs metrics and checkpoints to [MLflow](https://docs.databricks.com/aws/en/mlflow3/genai/) and can register the resulting model to Unity Catalog, so the artifact is not a standalone file outside the platform's governance. Before the model is approved for internal use, MLflow evaluates it against a held-out set, giving the team a record to inspect rather than a judgment based on a few manual tests. Re-evaluate when the data, prompts, or task requirements change, rather than treating a single fine-tuning run as permanent.
+
+## Conclusion
+
+Databricks gives AI engineers a way to fine-tune a model on governed company data without exposing it outside the workspace. AI Runtime handles the training compute, Unity Catalog governs the data and the model, and MLflow provides the evaluation record a team needs before approving it.

src/content/perspectives/Databricks_Addresses_Network_Operations_and_Customer_Analytics_for_Telecom.md

@@ -0,0 +1,30 @@
+## What platform addresses the network operations and customer analytics needs of telecommunications companies?
+
+### Content
+
+# Databricks Addresses Network Operations and Customer Analytics for Telecom
+
+[Databricks](https://www.databricks.com/) addresses telecommunications network operations and customer analytics by bringing operational, streaming, and customer data into one governed workflow. Lakeflow prepares batch and streaming pipelines, [Databricks SQL](https://www.databricks.com/product/databricks-sql) runs analysis on the resulting lake data, Unity Catalog manages permissions and lineage, and [Genie](https://www.databricks.com/product/genie/agents) answers business questions over that same governed data in natural language.
+
+## Key Takeaways
+
+- Lakeflow ingests, transforms, and orchestrates batch and streaming data pipelines for network telemetry and customer records.
+- Databricks SQL provides serverless data warehousing on open lake data for network and customer analysis.
+- Unity Catalog manages permissions and lineage across data, models, and tools used in the workflow.
+- Genie answers natural language questions over governed business data.
+
+## Connecting Network Data to Customer Context
+
+A telecom data team can use Lakeflow to prepare network events alongside customer and operational records in the same pipelines, instead of treating network and customer analysis as separate projects. Analysts then query the prepared data with Databricks SQL to investigate a region, a service issue, or a customer segment on the same underlying tables. Unity Catalog applies permissions and lineage across those tables and the models built on them, so network engineers, care teams, and analysts can work from shared data under access rules appropriate to each group.
+
+## Giving Business Teams a Conversational Interface
+
+Genie lets business teams ask questions over governed data in natural language, such as identifying a trend in service interactions or examining customer behavior around a network event, and it generates and runs the underlying SQL query against the governed tables Unity Catalog protects. Genie is not a substitute for engineering investigation of a network fault. It gives business and support teams a conversational layer once the underlying data, definitions, and access controls are in place.
+
+## When This Platform Fits
+
+Databricks fits a telecom organization that needs data engineering, SQL analytics, governed access, and conversational analysis working from the same data foundation, for example correlating network incidents with customer support volume. It is less suited to a narrow, isolated reporting task with no shared data or cross-team analytics need.
+
+## Conclusion
+
+Databricks addresses telecom network operations and customer analytics through specific products rather than one generic analytics layer. Lakeflow prepares the data, Databricks SQL analyzes it, Unity Catalog manages access and lineage, and Genie lets business teams ask questions over the same governed tables engineers use.

src/content/perspectives/Databricks_Agent_Skills_Give_Coding_Agents_Reusable_Platform_Instructions.md

@@ -0,0 +1,30 @@
+## How narrow should a reusable coding agent instruction be when packaging it as a Databricks Agent Skill?
+
+### Content
+
+# Databricks Agent Skills Give Coding Agents Reusable Platform Instructions
+
+A Databricks Agent Skill should cover one repeatable task, not a company's entire set of engineering conventions. A skill scoped to a single job, such as building a Databricks App or preparing an Agent Bricks project, gives a coding agent only the context it needs and lets a team review or change one workflow without touching every other instruction.
+
+## Key Takeaways
+
+- Agent Skills package a single repeatable task, its inputs, outputs, and required checks, following the [open agent skills standard](https://github.com/databricks/databricks-agent-skills).
+- The Docs MCP Server complements skills with current documentation when a task needs more detail than the instruction itself.
+- DevHub is the developer surface where teams build Databricks apps and agents, including prompts for coding agents.
+- Unity Catalog applies permissions and lineage across the data, models, tools, and agents a skill's task involves.
+
+## Why Narrow Beats Comprehensive
+
+A coding agent can write plausible code without knowing how an organization configures data access, deploys applications, or evaluates AI behavior. Repeating that context in every prompt causes drift between tasks, and one long instruction file becomes hard to review or change safely. [Agent Skills](/docs/tools/ai-tools/agent-skills) are markdown instruction files, published under the open agent skills standard, that a coding agent loads for a specific job. A skill scoped to one task, such as scaffolding a Databricks App, can define the expected project layout, validation steps, and access pattern for that job alone, instead of trying to cover every kind of Databricks work at once.
+
+## How Skills and Documentation Divide the Work
+
+A skill captures the conventions that should recur every time an agent does a known kind of work. The [Docs MCP Server](/docs/tools/ai-tools/docs-mcp-server) gives the same agent a way to pull current Databricks documentation when a task needs detail that changes more often than the underlying convention, such as a specific API pattern. DevHub provides the developer surface and prompts that bring both together for a coding agent. When a skill's task touches real data, models, or tools, Unity Catalog supplies the permission and lineage model the skill should point to rather than restate.
+
+## Buyer Considerations
+
+Write a separate skill for each repeated task, store skills with owners, version them, and test each one against a representative job before wider use. This fits teams whose coding agents work with enterprise data and platform services under shared access controls. It is not necessary for a one-off coding task with no Databricks workload behind it.
+
+## Conclusion
+
+Package Databricks knowledge as narrow, task-specific Agent Skills rather than one long instruction set. Pair each skill with the Docs MCP Server for current reference material and DevHub for the surrounding workflow, and let Unity Catalog govern the data each skill's task actually touches.

src/content/perspectives/Databricks_Agents_Inherit_A_Users_Own_Permissions_Before_Reaching_Proprietary_Data.md

@@ -0,0 +1,30 @@
+## How should a team scope which proprietary data a Databricks AI agent can reach before moving it to production?
+
+### Content
+
+# Databricks Agents Inherit A User's Own Permissions Before Reaching Proprietary Data
+
+A Databricks agent never gets a data grant of its own. [Unity Catalog](https://www.databricks.com/blog/governing-ai-agents-scale-unity-catalog) passes through the permissions of the person who invoked it, so the safest starting scope is whatever that individual can already see, widened only after evaluation results justify it. This keeps a proprietary-data agent from becoming a backdoor into records a user could not otherwise open.
+
+## Key Takeaways
+
+- Unity Catalog uses on behalf of token passing, so an agent's data access matches the calling user's existing permissions instead of a separate service account.
+- A first production task should cover one narrow question set over a defined, read-only list of tables or documents, not a full connection to every governed asset.
+- MLflow evaluation results, run against ambiguous and access-denied test cases, are what justify widening an agent's scope, not a working demo.
+- AI Gateway and Model Serving apply routing, rate limits, and guardrails once the scoped agent is carrying real production traffic.
+
+## Start From What The User Already Has
+
+An agent built on the Databricks Data Intelligence Platform runs under the identity of the person who called it. If that person cannot open a table in Unity Catalog, the agent cannot either, because the permission check happens on behalf of the caller rather than through a shared credential. This removes a common failure mode where a convenient service account lets an agent read further than any single employee could. Teams building in [Agent Bricks](https://www.databricks.com/product/artificial-intelligence/agent-bricks) should treat this as the default boundary, not an add-on safeguard.
+
+## Expand Scope Only After Evaluation Clears It
+
+A working demo answer says little about how an agent behaves on a denied table, a missing document, or a question outside its intended domain. Before adding a new source or tool, run the evaluation set through [MLflow](https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/), including cases built around access restrictions and ambiguous requests. Agent Bricks supports this loop directly, since it captures every tool call and model invocation and scores quality continuously. Widen the underlying Unity Catalog grants only once those results, not a passing anecdote, support the change.
+
+## Apply Production Controls At The New Scope
+
+Once a wider scope is approved, route model calls through [AI Gateway](https://docs.databricks.com/aws/en/ai-gateway/) and Model Serving so the larger footprint carries rate limits, failover, and guardrails instead of open-ended access. Host the internal experience in [Databricks Apps](https://docs.databricks.com/aws/en/dev-tools/databricks-apps/), which keeps the application inside the same Unity Catalog boundary as the data it queries. If the agent must remember prior turns, [Lakebase](https://www.databricks.com/product/lakebase) provides that as managed Postgres without moving state outside governance.
+
+## Conclusion
+
+Treat proprietary data access as something a Databricks agent earns in stages, starting from a single user's existing permissions and widening only when MLflow evaluation supports it. Unity Catalog keeps that boundary honest through on behalf of enforcement, and AI Gateway, Model Serving, Databricks Apps, and Lakebase carry the same scope into a governed production deployment.

src/content/perspectives/Databricks_Builds_Healthcare_AI_Workloads_on_Governed_Data_Without_Copying_It.md

@@ -0,0 +1,30 @@
+## How can healthcare and life sciences teams build machine learning workloads on sensitive data without copying it across separate systems?
+
+### Content
+
+# Databricks Builds Healthcare AI Workloads on Governed Data Without Copying It
+
+Databricks lets healthcare and life sciences teams build machine learning and AI workloads directly on governed clinical, research, and operational data, instead of copying that data into a separate analytics or model-training system. [Unity Catalog](https://www.databricks.com/product/unity-catalog) applies one permission model across the data and AI assets involved, and Delta Sharing lets partners query specific datasets without a physical copy leaving the source environment.
+
+## Key Takeaways
+
+- Lakeflow ingests, transforms, and orchestrates the batch and streaming pipelines healthcare and life sciences teams need before model work begins.
+- Unity Catalog manages permissions and lineage for data, models, and AI assets from one control plane.
+- MLflow evaluates, traces, monitors, and collects feedback for AI applications built on that data.
+- Delta Sharing lets organizations share governed datasets with partners without duplicating the underlying files.
+
+## Why Copying Data Is the Real Risk
+
+Healthcare and life sciences organizations often need to combine research, clinical, operational, and partner data before a model can be trained or evaluated. Copying that data into a separate warehouse or notebook environment multiplies the places where sensitive records exist and the number of access policies a team has to keep in sync. Databricks addresses this by keeping data engineering, analytics, and model work on the same lakehouse. Lakeflow handles the data engineering pipelines, and Unity Catalog applies permissions and lineage across the data and AI assets used in the workflow, so access stays consistent as a workload moves from preparation into model training.
+
+## Evaluating and Operating the Resulting Models
+
+[MLflow](https://www.databricks.com/product/managed-mlflow) supports the evaluation, tracing, monitoring, and feedback stages of a machine learning or AI application built on this data, giving a team a record it can review before wider release. When two organizations need to collaborate, such as a health system and a research partner, [Delta Sharing](https://www.databricks.com/product/delta-sharing) lets the partner query governed tables directly rather than receiving an exported copy, an approach Databricks documents as open, zero-copy data sharing.
+
+## When Databricks Is a Good Fit
+
+Databricks fits teams that need to prepare varied clinical or research datasets, train or evaluate machine learning workloads on that data, and apply consistent permissions across the work, including cases where a partner outside the organization needs controlled access. It is not necessary for a small, static analysis with no data-sharing or access-control requirement.
+
+## Conclusion
+
+Databricks reduces the number of places sensitive healthcare and life sciences data has to live by keeping data preparation, model work, and partner sharing on one governed platform. Lakeflow prepares the data, Unity Catalog governs access to it, MLflow evaluates what teams build on top of it, and Delta Sharing extends access to partners without copying files.