Làm Cùng Long.
← Quay lại Bắt Nhịp
AI & Automation · 21 phút đọc · · Google Developer Program

Google đang ghép đủ các mảnh của một “agentic stack”: 8 tín hiệu đáng chú ý tháng 10/2026

Điểm đáng chú ý không chỉ nằm ở model mới. Google đang đồng thời chuẩn hóa cách agent nhận kỹ năng, kết nối IDE, truy cập dữ liệu, chạy code, giao tiếp bằng giọng nói, được kiểm soát và được vận hành ở quy mô production.

Minh họa Google Agentic Stack 2026 với model trung tâm kết nối coding agents, voice, data analytics, cloud runtime và governance trong hệ thống kính ấm

Một email cập nhật developer có thể rất dễ bị đọc theo kiểu: có tính năng mới thì xem, chưa dùng thì bỏ qua.

Nhưng bản The Monthly Build tháng 10/2026 của Google Developer Program đáng đọc theo một cách khác.

Trong cùng một bản tin, Google đặt cạnh nhau nhiều mảnh tưởng như không liên quan:

  • một plugin mới để coding agent hiểu và thao tác Google Cloud tốt hơn;
  • Android Studio cho phép mang Claude, Codex hoặc Antigravity vào IDE qua Agent Client Protocol;
  • BigQuery thêm các hàm phân tích nguyên nhân, tương quan, xu hướng, mùa vụ và causal effect;
  • Gemini 3.8 Live tiến thêm một bước về voice agent thời gian thực;
  • Firebase đưa khả năng text-to-speech của Gemini gần hơn tới ứng dụng;
  • Cloud Run Sandboxes mở một đường chạy Python/Bash bị cô lập cho các workflow;
  • Google ra chứng chỉ Professional Agentic Architect;
  • DevFest 2026 lấy chủ đề “Build, Secure, Scale” trong kỷ nguyên agentic.

Nhìn từng tin riêng lẻ, đây là một loạt cập nhật sản phẩm.

Nhìn như một hệ thống, tôi thấy một câu chuyện khác:

AI agent đang dần được tách khỏi khái niệm “một model biết làm nhiều việc” để trở thành một stack gồm model, context, protocol, skills, tools, data, runtime an toàn, governance và khả năng vận hành.

Điểm đáng chú ý nhất vì vậy không phải Google vừa có thêm một model hay một tính năng.

Điểm đáng chú ý là những phần còn thiếu quanh model đang được lấp dần.

Mục lục

1. Từ model-centric sang agentic stack

Trong giai đoạn đầu của AI tạo sinh, câu hỏi phổ biến nhất là:

Model nào thông minh hơn?

Sau đó câu hỏi chuyển dần sang:

Model nào code tốt hơn? Model nào rẻ hơn? Model nào có context window lớn hơn?

Đến giai đoạn agent, những câu hỏi đó vẫn quan trọng nhưng không còn đủ.

Một agent làm việc thật phải giải quyết thêm hàng loạt vấn đề:

  1. Nó lấy instruction và kiến thức chuyên môn từ đâu?
  2. Làm sao nó biết trạng thái thật của môi trường hiện tại?
  3. Nó được phép gọi công cụ nào?
  4. Nó có thể chuyển từ IDE này sang IDE khác không?
  5. Khi cần phân tích dữ liệu, nó nhận được kết quả dạng nào?
  6. Khi phải chạy code do AI tạo ra, code đó chạy ở đâu?
  7. Hành động nào được tự làm, hành động nào phải xin duyệt?
  8. Ai chịu trách nhiệm về chi phí, quyền truy cập, audit và sự cố?
  9. Người xây hệ thống cần bộ kỹ năng gì?

Nếu một trong các lớp này yếu, model mạnh hơn chưa chắc giúp hệ thống đáng tin hơn.

Đây là lý do tôi thấy cụm cập nhật lần này thú vị: Google đang chạm gần như tất cả các lớp đó cùng lúc.

FACT: Bản tin Monthly Build tháng 10/2026 của Google Developer Program gom các cập nhật về Developer Plugin, BYOA trong Android Studio, BigQuery augmented analytics, Gemini 3.8 Live, Agentic Architect, Firebase AI Logic và Cloud Run Sandboxes vào cùng một nhịp cập nhật.

INTERPRETATION: Tôi không coi đây là bằng chứng Google đã hoàn thiện một “agent operating system” thống nhất. Google cũng không dùng cụm từ đó cho toàn bộ các sản phẩm này. Nhưng hướng phát triển cho thấy giá trị đang dịch chuyển từ một model đơn lẻ sang khả năng kết nối các lớp quanh model thành một hệ thống có thể hành động.

2. Tín hiệu 1: Agent Plugin biến skills và MCP thành gói năng lực

Google Cloud Developer Plugin là mảnh dễ bị đánh giá thấp nhất.

Nếu chỉ nhìn bề ngoài, nó giống một gói cài thêm cho coding agent.

Nhưng trong thông báo chính thức, Google nhấn mạnh ba thứ được đặt cạnh nhau:

  • Agent Skills;
  • tài liệu chính thức;
  • MCP server.

Vấn đề mà plugin cố giải quyết là tool coupling.

Một agent làm việc với Google Cloud hiếm khi chỉ cần “biết lệnh gcloud”. Nó cần hiểu authentication, project, IAM, guardrail, tài liệu cập nhật và cách tương tác với môi trường thật.

Nếu từng phần được cài riêng, người dùng phải tự lắp ghép:

Skills riêng.

MCP riêng.

Instruction riêng.

Biến môi trường riêng.

Cách cài riêng cho từng client.

Agent Plugins cố đưa các phần liên quan vào một package có cấu trúc thống nhất. Google cho biết plugin của họ tuân theo Agent Plugins specification — một chuẩn mở, trung lập nhà cung cấp, đóng gói Agent Skills và MCP server thành các đơn vị có thể mang sang nhiều client.

Google Cloud Developer Plugin hiện tập trung vào các việc nền tảng như:

  • authentication và authorization;
  • project management;
  • guardrail cho gcloud CLI;
  • truy cập Developer Knowledge MCP để grounding bằng tài liệu developer chính thức mới hơn.

Điểm này nối rất sát với một nguyên tắc của Context Engineering:

Agent không nhất thiết phải “nhớ” mọi thứ. Nó cần biết cách tìm đúng context, đúng lúc và trong phạm vi đúng.

Nếu cách này trưởng thành, plugin có thể trở thành một lớp phân phối năng lực cho agent, tương tự cách package/library từng phân phối năng lực cho ứng dụng.

Nhưng có một khác biệt quan trọng.

Một library thường đưa code cho chương trình gọi.

Một agent plugin có thể đưa cả:

tri thức + workflow + tools + connection tới dữ liệu bên ngoài.

Điều đó làm tăng năng lực, đồng thời tăng bề mặt rủi ro.

Vì vậy, câu hỏi khi cài plugin không nên chỉ là “plugin này làm được gì?”, mà còn là:

  • Nó thêm skill nào?
  • Nó kết nối MCP nào?
  • Nó cần secret nào?
  • Nó có thể thực hiện hành động gì?
  • Hành động nào có guardrail?
  • Tôi có audit được không?

Bài Knowledge đi sâu hơn: Agent Plugins là gì? Google Cloud đang đóng gói Skills + MCP thành lớp năng lực cho coding agent.

3. Tín hiệu 2: Android Studio tách IDE khỏi nhà cung cấp agent

Cập nhật Bring Your Own Agent trong Android Studio đưa ra một hướng khác nhưng bổ sung rất tốt cho plugin.

Google cho phép kết nối các coding agent như Claude Agent, Codex và Antigravity vào Android Studio.

Phần quan trọng nằm ở Agent Client Protocol — ACP.

Android Studio dùng ACP để đưa cho agent context giàu hơn từ IDE, gồm project graph, build setup và thông tin nền tảng. Agent cũng có thể được nối với các công cụ native như build diagnostics, Jetpack Compose Preview, Android SDK tools và emulator control.

Nếu plugin trả lời câu hỏi:

“Agent có năng lực gì?”

thì ACP ở đây gần hơn với câu hỏi:

“Agent giao tiếp với môi trường làm việc của developer bằng cách nào?”

Hai bài toán này khác nhau.

Một agent có model rất tốt nhưng nếu phải đọc toàn bộ codebase bằng cách dò file thô, không hiểu build graph và không truy cập được tool native, nó vẫn lãng phí token và dễ làm sai.

Android Studio còn nhấn mạnh một điểm rất thực dụng: agent flexibility.

Nếu một agent hết quota hoặc không đáp ứng kỳ vọng, người dùng có thể chuyển sang agent khác miễn là agent đó tương thích ACP.

Đây là một thay đổi đáng theo dõi.

Trước đây, AI coding dễ bị gắn chặt theo chuỗi:

IDE A → assistant A → model A.

Nếu protocol layer thực sự mở ra, kiến trúc có thể chuyển dần thành:

IDE → protocol → nhiều agent → nhiều model/provider.

INFERENCE: Điều này chưa đồng nghĩa “agent hoàn toàn interchangeable”. Mỗi agent vẫn có harness, memory, permission model và hành vi khác nhau. Nhưng protocol chung làm giảm một lớp lock-in và khiến IDE trở thành một control surface có giá trị riêng, thay vì chỉ là nơi gõ code.

Bài Knowledge: Agent Client Protocol và BYOA: IDE đang trở thành môi trường làm việc chung của nhiều AI agent.

4. Tín hiệu 3: BigQuery biến phân tích thành primitive cho agent

Cập nhật BigQuery ban đầu nghe giống tin dành cho Data Analyst.

Google bổ sung sáu Table-Valued Functions cho augmented analytics:

  • AI.KEY_DRIVERS;
  • AI.CAUSAL_EFFECT;
  • ML.CORRELATION;
  • ML.DETECT_CHANGE_POINTS;
  • ML.TREND;
  • ML.SEASONALITY.

Mỗi hàm giải quyết một loại câu hỏi khác nhau.

Ví dụ:

“Vì sao doanh thu tăng so với quý trước?” khác với “đợt tăng đó có thật sự do thay đổi giá không?”.

Câu đầu là bài toán tìm driver.

Câu sau là bài toán causal effect.

“Metric A và B đi cùng nhau” lại chỉ mới là correlation.

Google nhấn mạnh các hàm này chạy nơi dữ liệu đang nằm và trả về structured SQL output. Chính dạng output có cấu trúc khiến chúng phù hợp để tích hợp thành skills cho AI agents và có thể chain nhiều bước phân tích.

Đây là một thay đổi quan trọng cho Data + AI.

Rất nhiều agent phân tích dữ liệu hiện nay làm theo cách:

User hỏi → model tự sinh SQL → lấy bảng → model tự diễn giải → trả lời.

Điểm yếu là model vừa phải quyết định phương pháp phân tích, vừa phải thao tác dữ liệu, vừa phải diễn giải.

Khi những khối phân tích chuẩn được đưa thành function có contract rõ, agent có thể làm việc giống một orchestrator hơn:

  1. xác định câu hỏi;
  2. chọn primitive phù hợp;
  3. chạy trên dữ liệu;
  4. nhận structured output;
  5. quyết định bước phân tích kế tiếp;
  6. giải thích kết quả và độ chắc chắn.

Đây là một ví dụ khá rõ về xu hướng:

Đừng bắt LLM tự làm mọi thứ bằng reasoning tự do. Hãy biến những phần có thể chuẩn hóa thành tool/function có output kiểm soát được.

Với marketing analytics, tư duy này đặc biệt hữu ích vì nó giúp tách những khái niệm rất hay bị trộn lẫn: tương quan, driver, xu hướng, mùa vụ, change point và causal effect.

Bài Knowledge: BigQuery Augmented Analytics TVFs: khi phân tích trở thành primitive cho AI agent.

5. Tín hiệu 4: Voice agent bắt đầu có đủ context và tool execution

Gemini 3.8 Live và Gemini 3.8 Live Extended Thinking không chỉ là cập nhật speech model.

Google mô tả 3.8 Live theo hướng scale và cost efficiency, còn Extended Thinking dành cho task phức tạp hơn và multi-step reasoning.

Điểm tôi quan tâm hơn benchmark là các capability quanh hội thoại:

  • visual input gần thời gian thực;
  • tự chuyển giữa nhiều ngôn ngữ trong cuộc hội thoại;
  • tool và API call chạy nền trong khi cuộc trò chuyện tiếp tục;
  • Extended Thinking có thể reasoning sâu hơn mà vẫn giữ luồng hội thoại;
  • asynchronous function calling cho các tác vụ nhiều bước.

Tại sao điều này quan trọng?

Một voice assistant kiểu cũ chủ yếu làm:

nói → speech-to-text → trả lời → text-to-speech.

Một voice agent để làm việc thật cần nhiều hơn:

nói → hiểu intent → nhìn context → gọi tool → chờ kết quả → xử lý exception → tiếp tục nói → cập nhật trạng thái.

Nếu cứ dừng hội thoại mỗi lần tool chạy, trải nghiệm rất dễ “gãy”.

Google đang nhấn mạnh việc model có thể tiếp tục hội thoại trong khi tool hoặc API call xử lý nền.

INTERPRETATION: Đây là dấu hiệu voice interface đang tiến gần hơn tới một “operating surface” cho workflow, thay vì chỉ là phương thức nhập câu hỏi bằng giọng nói.

Nhưng điều này cũng làm governance khó hơn.

Khi người dùng nói tự nhiên và agent có thể hành động, hệ thống phải phân biệt:

  • câu nói nào là ý định;
  • câu nói nào chỉ là thảo luận;
  • hành động nào reversible;
  • hành động nào cần xác nhận;
  • tool nào được phép chạy nền;
  • khi nào phải báo tiến độ hoặc lỗi.

Voice làm UI tự nhiên hơn.

Nó không làm bài toán quyền hạn đơn giản hơn.

6. Tín hiệu 5: TTS và Live API đang tách thành hai kiến trúc khác nhau

Video Firebase AI Logic trong Monthly Build bổ sung một mảnh dễ nhầm với Gemini Live: text-to-speech.

Tài liệu Firebase phân biệt khá rõ:

TTS là luồng một chiều, request-response: text in → audio out.

Nó phù hợp khi nội dung cần được đọc gần như chính xác theo văn bản đã xác định, nhưng vẫn muốn điều khiển style, accent, pace hoặc tone.

Ví dụ:

  • đọc bài viết;
  • narration;
  • audiobook;
  • tạo audio từ script;
  • hội thoại hai nhân vật đã có nội dung.

Trong khi đó Live API là bidirectional streaming, phù hợp với hội thoại thời gian thực mà model tự quyết định nội dung cần trả lời theo context đang diễn ra.

Đây không phải chuyện “model nào xịn hơn”.

Đây là bài toán kiến trúc.

Nếu nhu cầu là biến một bài Knowledge thành audio:

TTS hợp lý hơn.

Nếu nhu cầu là một trợ lý voice có thể hỏi lại, nhìn màn hình, gọi tool và tiếp tục làm việc:

Live API phù hợp hơn.

Một lỗi rất phổ biến khi xây AI product là dùng thành phần phức tạp nhất vì nó hấp dẫn hơn, trong khi use case chỉ cần một primitive đơn giản.

Nguyên tắc: dùng deterministic pipeline khi đã biết đầu vào/đầu ra; chỉ đưa agentic reasoning vào chỗ thực sự cần phán đoán.

Bài Knowledge về voice: Gemini Live hay TTS? Cách chọn kiến trúc cho ứng dụng voice AI.

7. Tín hiệu 6: Sandboxed execution trở thành lớp bắt buộc

AI có thể sinh code rất nhanh.

Nhưng sinh code và cho phép code đó chạy là hai bài toán khác nhau.

Bài viết trên Google Cloud Community về Cloud Run Sandboxes kết hợp Apps Script minh họa khá rõ điều này.

Workflow mẫu:

Google Sheets / Apps Script
→ gửi dữ liệu và Python/Bash
→ Cloud Run Sandbox
→ chạy trong môi trường cô lập
→ trả structured output hoặc ảnh Base64
→ Apps Script đưa kết quả về Workspace.

Tác giả minh họa việc tạo correlation heatmap bằng Python từ dữ liệu Google Sheets. Tác giả cũng thử nhiều lớp isolation như metadata server, environment variables, filesystem và outbound egress.

Có một chi tiết cần đọc cẩn trọng: các số latency trong bài là đo trên demo của tác giả, không phải SLA chung của Cloud Run Sandboxes. Trong test đó, cold start mất vài giây, còn nhiều lần chạy warm ở mức vài trăm mili-giây. Không nên biến con số demo thành lời hứa cho mọi workload.

Tài liệu Cloud Run chính thức hiện vẫn đánh dấu Sandboxes là Preview.

Điểm có giá trị lâu dài hơn latency là mẫu kiến trúc:

LLM sinh hoặc chọn code
→ sandbox thực thi code bị giới hạn
→ output có cấu trúc
→ ứng dụng tiếp tục workflow.

Tách reasoning khỏi execution giúp chúng ta áp quyền hạn khác nhau cho hai lớp.

Model có thể được phép đề xuất code rộng hơn.

Runtime chỉ cho code thực thi trong phạm vi nhỏ hơn.

Đây là logic tương tự “AI boundaries”:

Năng lực suy luận có thể rộng. Quyền hành động phải hẹp hơn và quan sát được.

Bài Knowledge: Cloud Run Sandboxes + Apps Script: tách “AI suy luận” khỏi “code chạy thật”.

8. Tín hiệu 7: nghề “Agentic Architect” bắt đầu được định hình

Google Cloud đã có Professional Agentic Architect.

Tôi không nghĩ phần đáng quan tâm nhất là cái chứng chỉ.

Đáng quan tâm hơn là Google chọn kiểm tra những gì.

Trang chứng chỉ liệt kê các nhóm năng lực:

  • build agent bằng low-code;
  • dùng coding agent để phát triển ứng dụng;
  • xây custom agent;
  • evaluate và deploy agentic workflow;
  • secure và govern agentic workflow.

Bài thi còn được chia hai phần: kiến thức/kiến trúc qua bài thi proctored và hands-on labs để kiểm tra khả năng thực thi.

Đây là tín hiệu khá rõ rằng công việc agentic không được định nghĩa chỉ bằng:

“biết prompt”.

Hay:

“biết dùng Gemini”.

Nó gần hơn với một vai trò tích hợp:

model + software + data + tool + evaluation + deployment + security + governance + cost.

Nếu nhìn dưới góc nghề nghiệp, đây là điểm đáng chú ý cho cả marketer/data/automation practitioner.

Không nhất thiết ai cũng phải trở thành Cloud Architect.

Nhưng một người xây workflow AI ngày càng cần hiểu đủ các lớp để biết:

  • lúc nào model không phải bottleneck;
  • lúc nào nên dùng API/function thay vì agent;
  • dữ liệu đi đâu;
  • secret nằm ở đâu;
  • hành động nào cần approval;
  • output được đánh giá thế nào;
  • failure được quan sát ra sao;
  • chi phí bị chặn ở đâu.

Bài Knowledge: Professional Agentic Architect: Google đang định nghĩa bộ năng lực nào cho thời đại AI agent?.

9. Tín hiệu 8: Build nhanh hơn kéo theo yêu cầu secure và scale

DevFest 2026 dùng chủ đề:

Build, Secure, Scale: Developers and Builders in the Agentic Era.

Google dự kiến hơn 800 sự kiện tại 115 quốc gia trong mùa DevFest từ 1/10 đến 31/12/2026, với gần một triệu developer và builder tham gia.

Nếu bỏ phần sự kiện sang một bên, ba động từ Build – Secure – Scale phản ánh đúng bài toán agent hiện tại.

Build dễ hơn trước rất nhiều.

Coding agent, AI Studio, low-code, Firebase và các model mới giảm ma sát tạo prototype.

Nhưng càng dễ build, hai lớp còn lại càng quan trọng.

Secure: agent có tool access, secret, dữ liệu và khả năng hành động.

Scale: agent cần observability, budget, failure handling, policy, evaluation và infrastructure đủ ổn định.

Đây là một nghịch lý thú vị:

Khi chi phí tạo phần mềm giảm, chi phí của judgement và governance có thể tăng về tầm quan trọng.

Vì tạo ra một workflow chạy được không còn là phần khó nhất.

Phần khó hơn là biết workflow đó:

  • có nên chạy không;
  • được chạy tới đâu;
  • tin được bao nhiêu;
  • thất bại thế nào;
  • ai chịu trách nhiệm;
  • có sống được khi volume tăng không.

10. Ghép lại: một agentic stack có thể trông như thế nào?

Nếu ghép các cập nhật ở trên thành một sơ đồ khái niệm, tôi sẽ nhìn nó theo bảy lớp.

Lớp 1 — Model

Gemini Live, Extended Thinking hoặc model khác.

Model cung cấp khả năng hiểu, suy luận và tạo output.

Lớp 2 — Context & Knowledge

Tài liệu chính thức, knowledge base, memory, project context.

Google Cloud Developer Plugin dùng Developer Knowledge MCP để đưa tài liệu developer chính thức vào luồng làm việc.

Lớp 3 — Skills & Capability Packaging

Agent Skills + MCP được đóng thành plugin.

Mục tiêu là giúp một năng lực có thể được cài, quản lý và mang qua nhiều agent client dễ hơn.

Lớp 4 — Client / Work Surface

IDE, app, voice interface, Workspace.

ACP giúp nối agent vào Android Studio và nhận context/tool native từ IDE.

Lớp 5 — Data & Analytical Primitives

BigQuery và các hàm phân tích có output structured.

Agent không cần “tự nghĩ mọi phép phân tích” nếu đã có primitive đáng tin cậy.

Lớp 6 — Execution Runtime

Cloud Run Sandbox hoặc môi trường thực thi bị cô lập.

Agent có thể đề xuất code, nhưng code chạy trong boundary khác.

Lớp 7 — Governance & Operations

Permissions, guardrails, evaluation, deployment, security, cost, audit.

Đây cũng chính là nhóm kỹ năng xuất hiện trong Professional Agentic Architect.

Điều đáng chú ý là không lớp nào tự nó tạo thành agent production.

Model không đủ.

MCP không đủ.

Skills không đủ.

Sandbox không đủ.

Data không đủ.

Giá trị đến từ cách chúng được ghép với nhau.

11. Điều này có ý nghĩa gì với người không phải software engineer?

Nếu làm Marketing, Data hoặc Automation, rất dễ nhìn các tin này rồi nghĩ “đây là chuyện của developer”.

Một phần đúng.

Nhưng logic bên dưới lại áp dụng khá trực tiếp.

Ví dụ một marketing agent có thể được thiết kế như sau:

Context: campaign taxonomy, conversion definitions, budget rules, landing pages.

Skills: audit Search, kiểm tra tracking, phân loại issue, tạo report.

Tools: Google Ads API, GA4, BigQuery, Sheets, Gmail.

Data primitives: trend, seasonality, anomaly, correlation, causal analysis.

Execution boundary: chỉ đọc mặc định; thay đổi budget cần approval; script chạy trong sandbox.

Interface: ChatGPT, IDE, Slack, Google Workspace hoặc voice.

Governance: log mọi action, budget cap, secret isolation, rollback.

Điểm mấu chốt:

Agent tốt không phải agent được trao mọi quyền. Agent tốt là agent có đúng context, đúng tool và đúng quyền cho từng loại quyết định.

Đây cũng là cách tôi nghĩ về automation nói chung.

Không bắt đầu từ:

“AI có thể làm gì?”

Mà từ:

“Quy trình nào đáng giao, dữ liệu nào đủ tin, hành động nào được phép và failure sẽ được xử lý ra sao?”

12. Tôi sẽ theo dõi gì tiếp theo?

Tôi chưa nghĩ chúng ta đã có một chuẩn agentic stack ổn định.

Rất nhiều thành phần vẫn đang Preview, đang thay đổi nhanh hoặc có nhiều chuẩn cạnh tranh.

Nhưng có bốn câu hỏi đáng theo dõi trong vài tháng tới.

Một: portability có thật sự xảy ra không?

Agent Plugins và ACP đều nói tới interoperability ở những lớp khác nhau. Giá trị thật chỉ xuất hiện khi một capability có thể chuyển client mà không cần viết lại phần lớn hệ thống.

Hai: security model có bắt kịp tool access không?

Agent càng hành động được nhiều, permission, sandbox, secret management và audit càng trở thành phần lõi.

Ba: data primitive có thay reasoning tự do ở các bước quan trọng không?

BigQuery augmented analytics là một ví dụ. Tôi kỳ vọng nhiều hệ thống sẽ chuyển từ “hãy để LLM phân tích tất cả” sang “LLM chọn và phối hợp các hàm phân tích chuẩn”.

Bốn: con người sẽ đứng ở đâu trong vòng lặp?

Các cập nhật tốt nhất hiện nay không loại bỏ con người hoàn toàn. Chúng đang làm rõ hơn nơi con người cần đặt policy, approval, evaluation và judgement.

Đó có lẽ cũng là tín hiệu lớn nhất tôi rút ra từ The Monthly Build tháng này.

Model tiếp tục mạnh lên.

Nhưng hệ thống tốt hơn không đến từ việc cứ thay model mới.

Nó đến từ việc thiết kế môi trường để model có thể làm việc đúng, an toàn và có thể kiểm soát.

Series Knowledge: Agentic Stack 2026

Bài Bắt Nhịp này là bản đồ tổng quan. Tôi tách các lớp quan trọng thành một series Knowledge để đi sâu hơn:

  1. Agent Plugins là gì? Google Cloud đang đóng gói Skills + MCP thành lớp năng lực cho coding agent
  2. Agent Client Protocol và BYOA: IDE đang trở thành môi trường làm việc chung của nhiều AI agent
  3. BigQuery Augmented Analytics TVFs: khi phân tích trở thành primitive cho AI agent
  4. Gemini Live hay TTS? Cách chọn kiến trúc cho ứng dụng voice AI
  5. Cloud Run Sandboxes + Apps Script: tách “AI suy luận” khỏi “code chạy thật”
  6. Professional Agentic Architect: Google đang định nghĩa bộ năng lực nào cho thời đại AI agent?

Nguồn tham khảo

Ghi chú nguồn: các số latency và kết quả test trong bài Cloud Run Sandboxes là số liệu từ demo của tác giả bài viết trên Google Cloud Community, không phải SLA chung của sản phẩm.