Agent Databricks vừa suy luận vừa hành động: Genie, MCP và Unity Catalog function

1. Agent cần vừa suy luận trên dữ liệu lịch sử, vừa hành động trên hệ thống live

Thomas Hass mở đầu bằng một nhận định (video đăng ngày 30/10/2026): ngày nay agent được kỳ vọng hành động tự chủ hơn, và phải làm việc với nhiều hệ thống khác nhau. Vì thế, theo anh, có thể bạn đang tự hỏi đâu là cách tốt nhất để vừa cho agent truy cập toàn bộ dữ liệu lịch sử của mình, vừa cho nó đúng những tool để thực thi việc trên các hệ thống khác, có thể qua một MCP integration. Ví dụ anh đưa ra: agent cập nhật một ticket trong Salesforce, hoặc lấy dữ liệu tồn kho live từ hệ thống ERP.

Anh nói (video đăng ngày 30/10/2026) có nhiều khả năng khác nhau để làm việc này: MCP connection, tool, các agent do Databricks cung cấp, và còn nữa. Vì vậy, trong video này, dựa trên một use case thực tế, anh xem xét đúng câu hỏi đó: làm sao cho agent khả năng suy luận (reason) trên dữ liệu lịch sử, đồng thời thực hiện hành động (action) trên các hệ thống live, và làm sao gói tất cả lại trong một agent đạt chuẩn production (production-grade agent).

2. Use case: agent cho kỹ thuật viên bảo trì thang máy

Trước khi vào Databricks, Thomas nhắc lại use case (video đăng ngày 30/10/2026). Thứ anh đang xây là một field service technician agent cho một công ty thang máy: các kỹ thuật viên bảo trì có sẵn một agent trong tay để troubleshoot, tạo ticket, có thêm insight, và nhận hướng dẫn dựa trên các manual, vân vân.

Tính đến video đăng ngày 30/10/2026, agent đã có sẵn knowledge base dựa trên dữ liệu PDF nằm trong SharePoint. Ở đó có tất cả hướng dẫn, mã lỗi (error code) và những thứ tương tự. Nhưng công ty hư cấu này còn có rất nhiều nguồn dữ liệu khác. Trong use case, anh dùng Microsoft Dynamics Business Central làm hệ thống ERP, nơi có toàn bộ thông tin tồn kho chẳng hạn. Salesforce đóng vai hệ thống CRM và hệ thống ticket, nơi lấy được thông tin khách hàng cũng như các ticket đang mở. Thêm vào đó, đây rõ ràng là một công ty "smart future", nên có dữ liệu cảm biến gửi thẳng từ các thang máy về. Đó là nguồn dữ liệu thứ tư.

Tóm lại, trong use case của video đăng ngày 30/10/2026 có bốn nguồn: manual trong SharePoint, dữ liệu cảm biến live từ thang máy, Business Central làm ERP và Salesforce làm CRM.

Vậy agent cần làm được gì? Theo Thomas (video đăng ngày 30/10/2026), agent phải suy luận được trên dữ liệu lịch sử đến từ ERP và CRM. Đồng thời, nó cũng phải với tới được các hệ thống live, ví dụ hỏi ERP xem ngay lúc này còn bao nhiêu hàng trong kho. Như vậy, nếu một kỹ thuật viên phát hiện có thứ cần thay, anh hoặc chị ấy có thể hỏi agent ngay xem linh kiện đó còn hay không. Ở phía Salesforce, nơi có hệ thống ticket, anh muốn agent tạo được ticket ngay, hoặc lấy được dữ liệu ticket và dữ liệu khách hàng live từ đó.

3. Ba yêu cầu, bốn con đường dữ liệu

Từ đó, Thomas liệt kê các năng lực agent cần có (video đăng ngày 30/10/2026). Thứ nhất, agent phải truy xuất và đọc được manual để hướng dẫn kỹ thuật viên dựa trên tài liệu thật. Đó là lý do anh đã dựng vector search index, hay AI Search index, cho phần manual.

Với hai nguồn còn lại là CRM và ERP, theo Thomas (video đăng ngày 30/10/2026), một mặt agent phải với tới các hệ thống này một cách live, và đây là chỗ anh dùng MCP integration tới hai hệ thống. Mặt khác, agent cũng phải chạy được những câu truy vấn mang tính phân tích hơn trên dữ liệu lịch sử, dựa trên dữ liệu lakehouse thật, nơi các nguồn đã được chuẩn bị, biến đổi (transform) và có thể đã được kết hợp với nhau. Đây là kiểu truy vấn phân tích trên dữ liệu đang nằm trong Databricks, ví dụ: trong 12 tháng qua, thang máy cụ thể này đã từng gặp sự cố nào chưa?

Theo Thomas (video đăng ngày 30/10/2026), với những trường hợp như vậy, nhiều khả năng bạn sẽ muốn đưa dữ liệu vào Databricks trước, chuẩn bị nó theo một cách phân tích đúng nghĩa, rồi sau đó chạy các phép aggregation và phân tích sẽ dễ hơn, thay vì để agent lúc nào cũng phải với ra từng hệ thống, cố gom hết thông tin lại, rồi tự chuẩn bị, vân vân.

Như vậy, theo Thomas (video đăng ngày 30/10/2026), với hai hệ thống này có hai con đường. Một bên là live access. Bên kia là những câu hỏi mang tính lịch sử hơn, và cả những câu hỏi liên quan tới nhiều nguồn dữ liệu cùng lúc: ở đây dữ liệu được chuẩn bị trước, rồi agent được cấp quyền truy cập vào dữ liệu đã chuẩn bị và tổng hợp đó.

Yêu cầu thứ ba (video đăng ngày 30/10/2026) là truy cập dữ liệu cảm biến. Thomas lấy ví dụ: kỹ thuật viên đang tự hỏi trong 12 giờ qua, những mã lỗi thực tế nào đã được gửi về từ chiếc thang máy này. Đó là những gì anh tập trung trong video, và từ đây anh quay lại Databricks để xem cần những bước nào để mọi thứ chạy được end to end.

4. Hiện trạng trong Databricks: catalog elevator_pitch

Vào Databricks, Thomas cho xem setup hiện tại (demo trong video đăng ngày 30/10/2026). Catalog có các schema Bronze, Silver và Gold, cùng một schema AI Services. Trên màn hình, catalog tên elevator_pitch có các schema 01_bronze, 02_silver, 03_gold, ai_services, và vài schema khác. Manual đã được ingest từ SharePoint, và từ đó có các bảng documents chunked và indexed. Theo anh, đó về cơ bản là knowledge corpus của agent.

Bây giờ anh muốn đi tiếp từ đó và mở rộng thêm các năng lực khác (demo trong video đăng ngày 30/10/2026). Trước hết, anh kể thêm việc đã làm trong thời gian qua: trong Bronze, anh đã ingest toàn bộ dữ liệu từ hệ thống ERP Business Central, cùng dữ liệu Salesforce, mỗi nguồn mang prefix tương ứng. Anh không đi vào chi tiết đã làm thế nào, vì đó không phải trọng tâm của phần về agent này. Điều cần nắm là ngoài manual, giờ trong catalog còn có cả dữ liệu Salesforce lẫn Business Central.

Anh tự hỏi lại (video đăng ngày 30/10/2026): vì sao làm vậy? Sao không cho agent truy cập thẳng vào các hệ thống này? Câu trả lời của anh: anh cũng sẽ làm việc đó, bằng MCP integration. Nhưng thứ anh muốn thêm là cho người dùng hỏi được những câu phân tích trên dữ liệu từ các hệ thống này, dữ liệu đã được chuẩn bị và có thể đã được đặt vào một data model đúng nghĩa, để những câu hỏi phân tích đó chạy nhanh.

Vậy làm sao cho agent truy cập vào dữ liệu này? Theo Thomas (video đăng ngày 30/10/2026), một trong những cách anh khuyên dùng là tạo một Genie agent bên trên. Đó là việc anh làm trước tiên.

5. Tạo Genie agent trên các bảng gold

Trước khi tạo, Thomas cho xem dữ liệu đang có trong từng schema (demo trong video đăng ngày 30/10/2026). Ở Bronze có toàn bộ dữ liệu thô của Business Central và Salesforce, cùng manual và dữ liệu cảm biến. Ở Silver, tất cả đã được làm sạch.

Còn ở Gold (demo trong video đăng ngày 30/10/2026), ngoài các document đã index, giờ còn có thêm vài bảng join một phần dữ liệu ERP và CRM với nhau. Đây chính là thứ anh muốn đưa vào Genie agent. Anh vào mục Genie agents, bấm New. Việc đầu tiên là chọn các bảng sẽ nằm trong Genie agent này.

Anh chọn năm bảng. Đây là những bảng anh đã làm vài phép join và aggregation giữa dữ liệu ERP và CRM. Rồi anh giải thích vì sao làm vậy. Theo Thomas (video đăng ngày 30/10/2026), có một lỗi anh thấy khá thường xuyên: nếu bạn đang xây một agent và dữ liệu của bạn đã nằm sẵn trong Databricks, bạn không nên mất thời gian xây một agent truy cập dữ liệu (data access agent) chuyên biến câu hỏi bằng ngôn ngữ tự nhiên thành câu lệnh SQL bên dưới để truy vấn dữ liệu.

Lý do anh đưa ra: đó là việc Genie agent đã làm rất thạo. Lời khuyên của anh trong video đăng ngày 30/10/2026: mỗi khi cần cho agent truy cập dữ liệu trong Databricks, cứ dùng Genie. Tạo một Genie agent như anh vừa làm, đưa các bảng vào đó. Theo anh, việc thêm mô tả (description) và các thông tin bổ sung khác chắc chắn cũng hợp lý.

6. Câu hỏi phân tích đầu tiên và Genie làm gì bên dưới

Với Genie agent vừa tạo (demo trong video đăng ngày 30/10/2026), Thomas hỏi được những câu phân tích như: "Have there been any tickets in the last 30 days mentioning door problems?" (trong 30 ngày qua có ticket nào nhắc tới lỗi cửa không). Anh nói một kỹ thuật viên bảo trì hoàn toàn có thể thắc mắc đúng câu này khi đang ở hiện trường sửa một chiếc thang máy.

Theo Thomas (video đăng ngày 30/10/2026), một lần nữa, anh không muốn agent phải với ra hệ thống live, lấy hết dữ liệu về, rồi cố tự hiểu nên chuẩn bị nó ra sao. Việc đó đã được làm sẵn ở phía lakehouse: dữ liệu được ingest, được chuẩn bị, rồi đưa vào một Genie agent.

Kết quả trong demo (video đăng ngày 30/10/2026): câu trả lời có ngay, đã có một ticket liên quan tới cửa trong 30 ngày qua. Thomas nhận xét lần này "super fast", nhanh hơn rất nhiều so với việc để agent tự làm hết phần chuẩn bị ngay lúc đó. Theo anh, đó chính xác là mục đích của Genie agent.

Anh cũng giải thích Genie làm gì bên dưới (video đăng ngày 30/10/2026): nó nhìn vào các bảng bên dưới, nhìn vào metadata như description, comment và những thứ tương tự. Rồi Genie agent tự đưa ra code SQL, thứ bạn cũng xem được ngay trong giao diện, để truy vấn dữ liệu và trả về câu trả lời đúng.

7. Live access qua MCP, và khi hệ thống không có MCP server

Đến đây, theo Thomas (video đăng ngày 30/10/2026), anh đã có một tool qua Genie agent MCP, trả lời được mọi câu hỏi phân tích trên phần dữ liệu liên quan. Bước tiếp theo: còn live access tới các hệ thống thì sao?

Cách làm, theo anh, là dùng MCP integration. Anh nhắc lại MCP là viết tắt của Model Context Protocol. Theo Thomas (video đăng ngày 30/10/2026), phần lớn các hệ thống bạn muốn nối agent vào đều tự cung cấp một MCP server. Bạn có thể hình dung nó như một cách cho agent khả năng lấy thông tin live từ hệ thống, và có thể cả thực thi việc trên hệ thống đó, như tạo một ticket. Trong trường hợp này, bạn không phải tự bảo trì gì, cũng không phải tìm hiểu các API cấp thấp để tích hợp với từng hệ thống.

Anh nói thêm (video đăng ngày 30/10/2026) rằng các LLM làm việc khá tốt với MCP, vì MCP có một cấu trúc định sẵn về cách mọi thứ trông ra sao. Vì vậy, với live access tới các hệ thống, anh dùng MCP integration, và cả hai hệ thống của anh, Salesforce và Dynamics, đều cung cấp MCP server.

Anh cũng nói nhanh về trường hợp hệ thống không có MCP server (video đăng ngày 30/10/2026). Khi đó anh có các lựa chọn khác: hoặc tạo các tool gọi thẳng API để tương tác, hoặc tự tạo MCP server của riêng mình, host trong Databricks. Theo anh, việc này làm được trên một Databricks App, và có sẵn template cho nó: trong mục Apps có một "MCP server starter". Nhưng với use case này, anh dùng các MCP được cung cấp sẵn.

8. Tạo MCP service cho Salesforce và Business Central

Để nối MCP, Thomas nói anh vào AI Gateway, vì anh muốn quản lý và govern các MCP integration ở một chỗ tập trung. Trên màn hình, trang này mang tên Unity Gateway, với các tab Models, Providers, MCPs, Skills và Agents (demo trong video đăng ngày 30/10/2026). Anh bấm tạo MCP server, và ở đó có thể nối tới một MCP server sẵn có. Theo anh, đó đúng là thứ cần trong trường hợp này, vì cả Salesforce lẫn Business Central đều cung cấp MCP server.

Tiếp theo, anh phải chọn nơi đặt MCP service này. Trong use case, việc đó khá đơn giản: catalog Elevator Pitch và schema AI services đã tạo từ trước (trên màn hình là elevator_pitch và ai_services). Theo Thomas (video đăng ngày 30/10/2026), những thứ bạn cần lo ở bước này về cơ bản là server, kiểu xác thực (authentication type), và vài thứ khác.

Anh đã làm sẵn hết phần đó (demo trong video đăng ngày 30/10/2026) và tạo connection từ trước, nên chỉ việc chọn connection Salesforce, nơi anh đã khai báo mọi thứ dựa theo tài liệu của Salesforce. Lúc này anh thấy danh sách các tool mà MCP server này expose, và có thể tạo MCP service. Anh chọn tất cả các tuỳ chọn, tạo MCP service cho Salesforce, rồi làm y như vậy cho Business Central.

Làm xong, anh refresh catalog và thấy dưới mục Services giờ có MCP của Business Central và của Salesforce (trên màn hình là bc_mcp và sf_mcp, demo trong video đăng ngày 30/10/2026). Điểm hay theo anh: tất cả đều được govern tập trung.

9. Chọn những tool agent được phép dùng

Trong trang của MCP service, Thomas cho xem các tool có thể expose cho agent (demo trong video đăng ngày 30/10/2026). Anh có thể sửa danh sách này và bỏ chọn một vài tool, ví dụ nếu không muốn cho agent quyền cập nhật một record trong Salesforce.

Nhưng trong trường hợp của anh (video đăng ngày 30/10/2026), đó chính là thứ anh muốn: agent có quyền một mặt đọc dữ liệu từ các hệ thống live, mặt khác thực thi một số hành động nhất định.

10. Thử Business Central MCP trong Playground: kit có còn hàng không?

Theo Thomas (video đăng ngày 30/10/2026), cách dễ nhất để test các integration này lại là Playground. Anh vào Playground để test cả hai MCP server integration. Trước hết, anh thêm cả hai vào: Salesforce và Business Central. Anh lưu lại và thấy hai tool đã được gắn vào (trên màn hình, model đang chọn là Grok 4.7, mục Tools ghi "Tools (2)").

Rồi (demo trong video đăng ngày 30/10/2026) anh nghĩ tới một câu hỏi mà kỹ thuật viên sẽ hỏi agent, cần live access vào hệ thống. Với Business Central, vì đây là ERP, câu đó có thể là: hiện đang có một bộ kit nào đó trong kho ở đâu. Câu anh gõ trên màn hình:

Where do we have belt tensioner kit STG-DO4-TK2 in stock right now?

Ở đây anh hy vọng LLM sẽ tự quyết định dùng Business Central MCP. Chờ vài giây, agent bắt đầu dùng các tool của Business Central MCP, trước hết để nắm xem có những company nào, vân vân (demo trong video đăng ngày 30/10/2026). Trên màn hình, nó gọi list_environments rồi list_companies trước khi tìm tồn kho.

Thomas nhận xét (video đăng ngày 30/10/2026) rằng agent đã thực hiện khá nhiều lượt gọi khác nhau trước khi thực sự tìm kiếm. Vì vậy, theo anh, về sau có thể làm hai việc. Một là tuỳ biến MCP server và thêm tool của riêng mình, expose thẳng đúng những tool cho đúng loại câu hỏi. Hai là mở rộng agent bằng các skill, cho agent sẵn chỉ dẫn về cách tìm kiếm trong MCP cho đúng để ra được insight cần thiết.

Sau một hồi qua lại, Thomas nói thật là anh phải cho agent thêm một gợi ý rằng đang nói về Elevator Pitch, vì nó đang nhìn vào sai company. Nhưng anh coi đây là một phát hiện ban đầu tốt. Sau khi kiểm tra dữ liệu thật từ Business Central, agent trả lời rằng món hàng này còn trong kho (demo trong video đăng ngày 30/10/2026).

11. Agent tự tạo một case trong Salesforce

Tiếp theo là một câu hỏi về phía Salesforce (demo trong video đăng ngày 30/10/2026). Ở đây Thomas muốn kiểm tra xem MCP integration có cho phép thực thi việc hay không. Anh yêu cầu agent tạo một case Salesforce cho chiếc thang máy này để thay một linh kiện, và đặt độ ưu tiên là high.

Lúc này, theo anh (demo trong video đăng ngày 30/10/2026), sẽ thấy agent hành động qua MCP integration và thật sự tạo ticket. Anh mở Salesforce ra xem: hiện chưa có case nào đang mở. Anh dự đoán chỉ vài giây nữa, khi agent làm xong, sẽ thấy case mới do agent tạo.

Agent báo rằng case đã được tạo thành công (demo trong video đăng ngày 30/10/2026). Anh gọi đây là "moment of truth", và trong Salesforce đúng là có một case được agent tạo hoàn toàn tự động. Anh lưu ý thêm rằng agent đang hành động thay mặt (on behalf of) chính anh.

12. Dữ liệu cảm biến: vì sao không dùng MCP, cũng không dùng Genie

Thomas tóm lại những gì đã làm (video đăng ngày 30/10/2026): Genie cho agent khả năng tự chạy truy vấn phân tích, và MCP cho các hệ thống live. Rồi anh giới thiệu lựa chọn thứ ba, thứ anh muốn dùng cho dữ liệu cảm biến.

Nếu nhìn vào catalog Bronze, dữ liệu cảm biến cũng nằm ở đó (demo trong video đăng ngày 30/10/2026). Anh giải thích: chạy ngầm là một script sinh dữ liệu cảm biến và gửi sang Databricks bằng Zerobus ingest. Anh không đi vào chi tiết Zerobus ở đây. Điều cần hiểu lúc này là có một bảng sensors, nơi nhận các event cho từng unit, từng toà nhà, với các số đo cảm biến khác nhau. Trên màn hình, câu SQL đầu tiên trong SQL editor có comment "The raw telemetry that ep-sensor-sim streams in through Zerobus".

Theo Thomas (video đăng ngày 30/10/2026), với trường hợp này MCP không phải lựa chọn phù hợp, vì đây là nguồn dữ liệu thật, tự xây của riêng anh, và không có MCP server nào trả về dữ liệu đó.

Anh nói anh cũng có thể đưa bảng này vào một Genie agent, rồi để agent hỏi bất kỳ câu phân tích nào trên Genie agent đó. Nhưng với dữ liệu cảm biến, anh có kế hoạch khác: định nghĩa trước chính xác loại truy vấn nào được chạy trên bảng này. Anh không muốn cho agent quyền chạy bất cứ thứ gì trên bảng sensor, điều sẽ xảy ra nếu anh chỉ tạo một Genie agent bên trên (theo Thomas, video đăng ngày 30/10/2026).

Thay vào đó (demo trong video đăng ngày 30/10/2026), và cũng để cho thấy lựa chọn này, anh đã tạo một Unity Catalog function tên là query elevator sensors (trên màn hình là query_elevator_sensors, nằm dưới Functions của ai_services). Anh cho xem cách tạo nó và cách nó hoạt động.

13. Viết Unity Catalog function query_elevator_sensors

Thomas chuyển sang SQL editor (demo trong video đăng ngày 30/10/2026). Trước hết anh cho xem lại dữ liệu: anh có thể query thẳng bảng dữ liệu cảm biến thang máy và chạy những câu SQL bình thường trên đó.

Để có function vừa thấy, anh tạo một Unity Catalog function và đặt nó vào catalog. Theo Thomas (video đăng ngày 30/10/2026), phần quan trọng nhất là anh thêm hai parameter, mỗi parameter kèm một comment. Comment này cũng cực kỳ quan trọng, vì sau đó anh sẽ cho agent truy cập function này, và vai trò của agent là điền vào hai parameter những giá trị phù hợp để trả lời câu hỏi của kỹ thuật viên.

Hai parameter đó (demo trong video đăng ngày 30/10/2026) là: unit ID, là ID của unit thang máy, có kèm một ví dụ; và cửa sổ nhìn lại (look back window) tính bằng phút. Đoạn đầu của function trên màn hình:

-- 2 · Create the function. The comments are the tool and parameter descriptions the agent reads.
CREATE OR REPLACE FUNCTION elevator_pitch.ai_services.query_elevator_sensors(
  unit_id_input STRING COMMENT 'Elevator unit ID, e.g. ASC-4412',
  lookback_minutes INT COMMENT 'Lookback window in minutes, e.g. 60'
)
RETURNS TABLE (
  event_id STRING,
  event_ts TIMESTAMP,
  unit_id STRING,
  mode STRING,
  direction STRING,
  floor INT,
  target_floor INT,
  speed_mps DOUBLE,
  load_kg DOUBLE,
  door_state STRING,
  door_close_time_s DOUBLE,
  door_cycle_count BIGINT,

Phần còn lại, theo anh, giống một function bình thường: khai báo thứ muốn trả về và theo định dạng nào, rồi viết mô tả cho cả function. Theo Thomas (video đăng ngày 30/10/2026), mô tả này cũng quan trọng với agent, vì nó dựa vào đó để quyết định khi nào gọi function. Anh viết: gọi khi được hỏi cảm biến cho thấy gì về một unit trong một khoảng thời gian. Cuối cùng là câu lệnh SELECT để lấy thông tin. Một đoạn ở phần sau của function trên màn hình:

COMMENT 'Agent tool. Sensor telemetry for one elevator over the last N minutes, newest first. Call when asked what the sensors show for a unit in a time window.'
RETURN
  SELECT
    event_id, event_ts, unit_id, mode, direction, floor, target_floor,
    speed_mps, load_kg, door_state, door_close_time_s, door_cycle_count,
    belt_tension_n, motor_current_a, motor_temp_c, oil_temp_c, levelling_mm,
    pit_water_mm, fault_code, fault_class, severity
  FROM elevator_pitch.01_bronze.elevator_sensors
  WHERE unit_id = unit_id_input
    AND event_ts >= current_timestamp() - MAKE_INTERVAL(0, 0, 0, 0, 0, lookback_minutes, 0)
  ORDER BY event_ts DESC
  LIMIT 200;

14. Gọi function và lý do scope down: kiểm soát và tốc độ

Giờ Thomas gọi được function này y như vậy, truyền vào các input parameter là tên unit và cửa sổ nhìn lại (demo trong video đăng ngày 30/10/2026). Lần chạy đầu, anh không thấy kết quả nào, vì trong 15 phút qua anh chưa ingest dữ liệu nào. Nhưng khi tăng cửa sổ lên, dữ liệu của cảm biến này trong khoảng thời gian đó hiện ra: trong trường hợp này là 20.000 phút gần nhất. Anh nói về sau sẽ có một luồng dữ liệu cảm biến live, để anh hỏi được kiểu: trong năm giây vừa qua, dữ liệu nào đã được gửi về.

Theo Thomas (video đăng ngày 30/10/2026), cách hình dung là thế này: agent giờ query được dữ liệu, nhưng chính anh định nghĩa cụ thể agent được query nó ra sao. Agent không chạy được truy vấn tuỳ ý, mà chỉ chạy được đúng câu SQL định sẵn này, và chỉ được điền hai parameter: unit nào, và cửa sổ nhìn lại là bao lâu. Anh nói đây là một cách khác anh muốn cho thấy để expose dữ liệu cho agent.

Anh so hai lựa chọn (video đăng ngày 30/10/2026). Lựa chọn một: thêm bảng vào Genie và cho agent truy cập Genie; khi đó, về lý thuyết, bất kỳ câu SQL nào cũng có thể chạy. Còn nếu bạn thật sự muốn scope down, lý do có thể là bạn không muốn expose toàn bộ dữ liệu cho agent, hoặc, theo anh là trường hợp phổ biến hơn, bạn chỉ muốn agent nhanh hơn và định nghĩa sẵn một số thứ.

Lý do về tốc độ, theo Thomas (video đăng ngày 30/10/2026): nếu dùng Genie agent, về lý thuyết nó có thể hỏi bất kỳ câu nào, và vì thế có khi mất nhiều thời gian hơn, bởi trước hết Genie phải dựng câu SQL, vân vân. Còn ở đây, anh đã nói sẵn với agent: đây là một loại truy vấn bạn được chạy, chỉ cần điền parameter. Vì vậy nó cũng sẽ chạy nhanh hơn.

15. Thử function trong Playground

Giống như trước, Thomas test trực tiếp trong Playground (demo trong video đăng ngày 30/10/2026). Anh chọn một model bất kỳ, rồi thêm tool. Anh chỉ ra rằng các tool này cũng được expose qua một MCP server: trên màn hình, khung "Add tools" có tab MCP Servers với các mục UC MCP Service, Unity Catalog Function, AI Search và Genie Agent. Anh chọn function của mình, xác nhận và lưu lại.

Rồi anh hỏi (demo trong video đăng ngày 30/10/2026), chẳng hạn: cảm biến trên unit này đã báo về những gì trong hai tuần qua, lần đọc gần nhất là khi nào. Anh cũng đổi sang một model khác (trên màn hình là Grok 4.7). Câu hỏi đầy đủ trên màn hình:

What did the sensors on ASC-4412 report over the last two weeks? When was the latest reading, and what did it show for door close time, belt tension, pit water and fault codes?

Theo Thomas (video đăng ngày 30/10/2026), đây đúng là loại câu hỏi anh muốn agent trả lời bằng tool này. Agent không phải đi tìm đúng Genie space rồi tự nghĩ ra câu truy vấn. Thay vào đó, nó biết ngay loại câu hỏi này trả lời được bằng tool, một tool mà anh cũng govern trong Unity Catalog.

Kết quả trong demo (video đăng ngày 30/10/2026): agent điền ngay đúng unit ID lấy từ câu hỏi, cùng số phút nhìn lại tương ứng với hai tuần, rồi trả lời câu hỏi của anh. Đến đây, theo anh, tất cả các tool, MCP server và Genie agent đều đã chạy được riêng lẻ.

16. Tổng kết: ba cách đưa dữ liệu và hành động cho agent

Thomas tóm tắt lại các cách đã xem (video đăng ngày 30/10/2026): cho agent khả năng chạy câu hỏi phân tích trên dữ liệu lakehouse bằng Genie; với tới các hệ thống live bằng MCP server; và cung cấp các truy vấn đã scope down bằng Unity Catalog function, như anh làm với dữ liệu cảm biến.

Theo anh (video đăng ngày 30/10/2026), giờ đã có đủ mọi thứ cần thiết, nhưng vẫn phải ghép tất cả lại với nhau và đặt vào một agent orchestration framework.