Từ Language Model đến AI Agent: Hệ thống Agentic thực sự hoạt động như thế nào

Hãy làm quen với Ari.

Ari phản hồi nhanh, diễn đạt rõ và xử lý được nhiều loại yêu cầu. Bạn hỏi một khái niệm khó, Ari có thể giải thích. Bạn cần một đoạn code, Ari có thể viết. Bạn đưa một tài liệu dài, Ari có thể đọc và tóm tắt.

Nghe khá thông minh. Nhưng Ari ở phiên bản đầu tiên vẫn có một giới hạn rất lớn.

Ari chỉ tạo ra câu trả lời.

Ari chưa thể mở repository của bạn để xem code thật đang nằm ở đâu. Ari không thể tự chạy test, mở trình duyệt, kiểm tra một dịch vụ production, cập nhật database hay xác nhận giải pháp vừa đề xuất có hoạt động hay không.

Nói một cách dễ hình dung, Ari có một bộ não nhưng chưa có tay, chưa có mắt, chưa có nơi làm việc và cũng chưa có cách làm việc ổn định.

Đó là khoảng cách giữa một generative model và một AI agent.

Trong bài này, chúng ta sẽ hoàn thiện Ari từng lớp một. Ari bắt đầu với Model. Sau đó Ari nhận Prompt và Context, được kết nối với Tools, học cách làm việc theo Agent Loop, duy trì Memory và State, sử dụng Skills và Workflows, tuân theo Persistent Guidance, rồi hoạt động bên trong một môi trường có Runtime Configuration và Guardrails rõ ràng.

Phần cuối bài sẽ nối mental model này với OpenAI Codex. Codex không phải định nghĩa duy nhất của AI agent. Tuy nhiên, đây là ví dụ dễ quan sát vì nhiều lớp trong hệ thống được thể hiện qua những thành phần cụ thể như config.toml, AGENTS.md, SKILL.md và các Tools mà agent có thể sử dụng.

Ari là một nhân vật dùng để giải thích kiến trúc. Câu chuyện này không có ý nói phần mềm suy nghĩ hay trải nghiệm thế giới như con người. Bên dưới hình tượng Ari vẫn là một hệ thống nhận Context, tạo đầu ra, chọn hành động, đọc kết quả và tiếp tục cho đến khi đạt điều kiện dừng.

Lược sử: từ trí thông minh đến khả năng hành động

Ý tưởng về máy móc thông minh đã có từ rất lâu trước khi Large Language Model xuất hiện.

Vào mùa hè năm 1956, một nhóm nhà nghiên cứu tập trung tại Dartmouth Summer Research Project on Artificial Intelligence. Hội thảo này góp phần đưa trí tuệ nhân tạo trở thành một lĩnh vực nghiên cứu có tên gọi rõ ràng. Nhiều công trình thời kỳ đầu đi theo hướng suy luận ký hiệu: con người mô tả sự kiện và quy tắc, còn phần mềm thực hiện phép suy luận trên những biểu diễn đó.

Từ thập niên 1960 đến thập niên 1980, các hệ chuyên gia cho thấy máy tính có thể giải quyết những bài toán hữu ích trong một phạm vi hẹp nếu được cung cấp cơ sở tri thức đủ tốt. Vấn đề là mỗi quy tắc đều phải được dự liệu và viết ra. Hệ thống càng lớn thì chi phí xây dựng, cập nhật và bảo trì càng cao.

Đến thập niên 1990, các nghiên cứu về agent thông minh bắt đầu nhấn mạnh hai việc: nhận biết và hành động. Một agent không chỉ tính toán để đưa ra câu trả lời. Nó tồn tại trong một môi trường, quan sát một phần của môi trường đó và hành động để tiến gần hơn đến mục tiêu.

Các agent tạo sinh hiện đại lại đi lên từ một nhánh kỹ thuật khác:

• Ngày 12 tháng 6 năm 2017, bài báo Attention Is All You Need giới thiệu kiến trúc Transformer, nền tảng quan trọng của các Large Language Model hiện đại.
• Ngày 28 tháng 5 năm 2020, Language Models are Few-Shot Learners mô tả GPT-3 và cho thấy một Model lớn có thể thực hiện nhiều nhiệm vụ dựa trên hướng dẫn và ví dụ bằng ngôn ngữ tự nhiên mà không cần huấn luyện lại riêng cho từng nhiệm vụ.
• Ngày 6 tháng 10 năm 2022, bài báo ReAct trình bày cách đan xen suy luận với hành động. Cách tiếp cận này giúp Language Model tương tác với môi trường thay vì chỉ đưa ra một câu trả lời cuối cùng.
• Ngày 9 tháng 2 năm 2023, Toolformer nghiên cứu cách Language Model có thể học khi nào cần gọi Tool và gọi như thế nào.
• Trong năm 2023 và 2024, function calling, agent framework, retrieval system, multimodal model và các dạng tích hợp Tool đã đưa hệ thống agentic đến gần hơn với công việc thực tế.

Không có một cột mốc nào tạo ra kiến trúc agent duy nhất mà tất cả mọi người đều dùng. Tuy nhiên, các hướng phát triển này gặp nhau ở một ý tưởng chung:

Một Model trở nên hữu ích hơn nhiều khi nó có thể làm việc trong Agent Loop, duy trì State và tác động lên môi trường thông qua những hành động được kiểm soát.

Giai đoạn 1 - Ari có bộ não (Model)

Từ khóa kiến trúc: Model - Thành phần tạo sinh và suy luận, có nhiệm vụ đọc Context rồi đề xuất đầu ra hoặc hành động tiếp theo.

Model là phần cốt lõi trong một AI agent.

Model nhận đầu vào dưới dạng Context và dự đoán phần tiếp theo phù hợp. Nhờ được huấn luyện trên lượng dữ liệu lớn, Model hiện đại có thể làm theo hướng dẫn, chuyển đổi thông tin, phân loại, lập kế hoạch, giải thích và tạo code.

Những khả năng đó dễ tạo cảm giác rằng Model có thể làm mọi thứ. Thực tế không phải vậy.

Khi đứng một mình, Model thường không thể:

• Biết repository riêng tư của bạn hiện có những tệp nào.
• Kiểm tra một dịch vụ production còn hoạt động tốt hay không.
• Thực thi đoạn code mà nó vừa tạo ra.
• Truy cập calendar, database hoặc CMS nếu chưa được kết nối.
• Xác nhận một thông tin bên ngoài có còn mới hay không.
• Tự lưu mọi thông tin qua những phiên làm việc độc lập.
• Thay đổi bất cứ thứ gì bên ngoài nội dung phản hồi.

Vì thế, Model là bộ máy ra quyết định của agent. Nó chưa phải một agent hoàn chỉnh.

Có thể ghi nhớ điểm khác biệt đầu tiên như sau:

Model tạo đầu ra dựa trên Context. Agent dùng Model như một phần của hệ thống có khả năng theo đuổi mục tiêu bằng hành động.

Giai đoạn 2 - Ari nhận nhiệm vụ (Prompt và Context)

Từ khóa kiến trúc: Prompt và Context - Prompt mô tả điều cần làm. Context cung cấp những thông tin mà Model cần để hiểu tình huống hiện tại.

Có bộ não nhưng không có mục tiêu thì Ari vẫn chưa có việc để làm.

Ari cần một yêu cầu rõ ràng. Chẳng hạn:

Tìm nguyên nhân khiến checkout bị lỗi, sửa lỗi, chạy những test liên quan và giải thích phần đã thay đổi.

Đó là Prompt. Prompt cho Ari biết kết quả nào đang được mong đợi.

Nhưng chỉ một câu yêu cầu thường chưa đủ. Ari còn cần Context: lịch sử trao đổi, cấu trúc repository, nội dung tệp, chỉ dẫn hệ thống, tài liệu được truy xuất, ảnh chụp màn hình, mô tả Tool và kết quả của các hành động trước đó.

Ở đây có ba khái niệm dễ bị trộn lẫn:

• Prompt: chỉ dẫn hoặc câu hỏi hiện tại.
• Context: thông tin đang được cung cấp cho Model.
• State: tình trạng tích lũy của công việc, gồm những gì đã quan sát, quyết định nào đã được đưa ra, tệp nào đã sửa và Tool trả về kết quả gì.

Ba thứ này liên quan với nhau nhưng không thay thế nhau.

Prompt nói Ari cần làm gì. Context giúp Ari hiểu vấn đề. State nối các bước rời rạc thành một quá trình liên tục.

Dù vậy, Ari ở giai đoạn này vẫn chỉ có thể mô tả một cách sửa hợp lý. Muốn kiểm tra và thực hiện cách sửa đó, Ari cần tiếp xúc với môi trường bên ngoài Model.

Giai đoạn 3 - Ari có tay và mắt (Tools)

Từ khóa kiến trúc: Tools - Những năng lực được kiểm soát, cho phép agent quan sát hoặc thay đổi hệ thống bên ngoài Model.

Tools đưa Ari ra khỏi phạm vi tạo văn bản.

Mỗi Tool là một thao tác có tên, mục đích và giao diện rõ ràng. Tùy vào hệ thống, Tools có thể cho phép Ari:

• Đọc, tìm kiếm, tạo và chỉnh sửa tệp.
• Chạy lệnh terminal và test.
• Truy vấn database hoặc API.
• Mở website và kiểm tra giao diện đã render.
• Tìm kiếm trong kho tri thức.
• Gửi tin nhắn hoặc tạo ticket.
• Cập nhật CMS.
• Tạo hoặc phân tích hình ảnh.
• Kết nối với dịch vụ bên ngoài thông qua Model Context Protocol (MCP).

Tool tìm tệp giống như mắt của Ari trong repository. Terminal cho Ari khả năng vận hành các công cụ phát triển. Trình duyệt giúp Ari nhìn thấy kết quả cuối cùng. API mở đường để Ari trao đổi dữ liệu với hệ thống khác.

Nhưng Tool chỉ cung cấp năng lực. Tool không tự biết khi nào nên được gọi và cũng không biết toàn bộ quy trình an toàn xung quanh nó.

Ví dụ, một Tool tên updatePost có thể nhận document ID và payload. Tool đó không tự hiểu rằng Ari cần kiểm tra bài viết đã tồn tại chưa, xác nhận đúng locale, giữ nguyên tác giả, liên kết media, tránh tạo bản trùng và đọc lại kết quả sau khi cập nhật.

Đây là điểm phân biệt thứ hai:

Tools quyết định agent có thể làm gì. Tools không tự quyết định agent nên làm việc đó như thế nào cho đúng.

Giai đoạn 4 - Ari có nhịp làm việc (Agent Loop)

Từ khóa kiến trúc: Agent Loop - Chu trình lặp gồm hiểu mục tiêu, quan sát, hành động, đọc kết quả, điều chỉnh và xác minh.

Khi Ari đã có thể quan sát và hành động, hệ thống cần một nhịp làm việc để nối các bước lại với nhau.

Một Agent Loop đơn giản có thể được hình dung như sau:

Hiểu mục tiêu
        |
Kiểm tra môi trường
        |
Chọn hành động tiếp theo
        |
Gọi Tool
        |
Đọc kết quả
        |
Cập nhật State
        |
Xác minh tiến độ hoặc điều chỉnh cách làm
        |
Dừng khi mục tiêu đã đạt hoặc công việc thực sự bị chặn

Agent Loop biến những lần gọi Tool riêng lẻ thành một quá trình hướng đến mục tiêu.

Giả sử Ari được giao sửa một form website đang lỗi. Cách làm có thể diễn ra như sau:

1. Tìm phần code triển khai form.
2. Đọc logic validation và submission.
3. Tái hiện lỗi bằng trình duyệt hoặc test.
4. Đưa ra giả thuyết về nguyên nhân.
5. Sửa tệp liên quan.
6. Chạy nhóm test phù hợp.
7. Đọc lỗi mới xuất hiện.
8. Điều chỉnh phần triển khai.
9. Chạy test lần nữa.
10. Kiểm tra hành vi cuối cùng và báo cáo kết quả.

Giá trị không nằm ở một hành động riêng lẻ. Giá trị đến từ việc kết quả của bước trước trở thành dữ liệu cho bước sau.

Nếu agent không quan sát được kết quả do mình tạo ra, nó gần với một công cụ sinh macro hơn là một hệ thống tự chủ đáng tin cậy.

Giai đoạn 5 - Ari có sổ ghi chép (Memory và State)

Từ khóa kiến trúc: Memory và State - Thông tin giúp agent giữ được mạch công việc trong một nhiệm vụ và duy trì những hiểu biết cần thiết qua nhiều nhiệm vụ.

Nhiệm vụ càng dài, Ari càng cần nhớ mình đang ở đâu.

Trong hệ thống agentic, Memory không chỉ có một dạng.

Working Context

Working Context là phần thông tin có sẵn trong lần gọi Model hiện tại. Nó có thể gồm yêu cầu của người dùng, chỉ dẫn liên quan, tệp đang được đọc, kết quả Tool gần nhất và lịch sử trao đổi.

Context luôn có giới hạn. Hệ thống phải chọn nội dung nào cần đưa vào, nội dung nào nên tóm tắt, khi nào cần truy xuất lại và phần nào có thể bỏ đi.

Task State

Task State ghi lại diễn biến của công việc hiện tại.

State có thể chứa kế hoạch, các bước đã hoàn thành, ID do API trả về, tệp đã thay đổi, lỗi đã gặp hoặc phê duyệt đang chờ. Nhờ State, agent biết mình đã làm gì và không phải bắt đầu lại sau mỗi hành động.

State cũng là nền tảng để phục hồi sau khi phiên làm việc bị gián đoạn.

Durable Memory

Durable Memory tồn tại lâu hơn một nhiệm vụ.

Nó có thể lưu những lựa chọn ổn định của người dùng, thông tin quan trọng về dự án, quyết định thường xuyên được lặp lại hoặc bài học từ những lần làm việc trước.

Durable Memory hữu ích nhưng không nên được xem là sự thật tuyệt đối. Thông tin có thể cũ, xung đột với chỉ dẫn mới hoặc vô tình chứa dữ liệu nhạy cảm. Một hệ thống tốt cần quy định rõ điều gì được phép ghi nhớ, ghi ở đâu, khi nào cần đọc lại và bằng chứng hiện tại có quyền thay thế Memory cũ như thế nào.

Vì vậy, Memory không đơn giản là "thêm nhiều Context hơn".

Memory là cả một vòng đời: chọn thông tin, lưu thông tin, truy xuất, kiểm tra rồi cập nhật.

Giai đoạn 6 - Tools tạo ra hỗn loạn (Reliability Gap)

Từ khóa kiến trúc: Reliability Gap - Khoảng cách giữa việc agent có đủ năng lực và việc agent sử dụng những năng lực đó một cách ổn định, an toàn.

Đến đây, Ari đã có Model, Tools, Agent Loop và State. Nhìn qua, hệ thống dường như đã đủ mạnh để làm việc thật.

Nhưng khi năng lực tăng lên, một vấn đề khác xuất hiện: Ari có thể làm đúng ở lần này và làm khác ở lần sau.

Hãy lấy việc tạo tài khoản quản trị CMS làm ví dụ. Ari có đầy đủ API Tool cần thiết. Nếu không có quy trình đáng tin cậy, Ari có thể:

• Dùng endpoint dành cho public user thay vì admin endpoint.
• Tạo tài khoản trước khi kiểm tra password.
• Gán nhầm role.
• Quên kích hoạt tài khoản.
• Không thử đăng nhập sau khi tạo.
• Để lại một invitation record chưa hoàn chỉnh khi gặp lỗi.
• In password hoặc token trong phần trả lời cuối cùng.

Một Prompt dài có thể giảm bớt sai sót. Tuy nhiên, việc lặp lại toàn bộ quy trình trong mọi yêu cầu vừa tốn Context vừa dễ thiếu bước.

Ari cần một cách làm đã được đóng gói và kiểm chứng.

Giai đoạn 7 - Ari có cẩm nang (Skills và Workflows)

Từ khóa kiến trúc: Skills và Workflows - Kiến thức quy trình có thể tái sử dụng cho những loại công việc quen thuộc.

Workflow đóng gói cách hoàn thành một loại công việc.

Tùy nền tảng, cùng ý tưởng này có thể được gọi là workflow, capability, recipe, procedure, plugin hoặc skill. Điểm chung là agent không phải tự nghĩ lại cách làm từ đầu mỗi lần nhận yêu cầu.

Một Skill tốt có thể quy định:

• Ý định nào của người dùng sẽ kích hoạt Skill.
• Điều kiện cần kiểm tra trước khi bắt đầu.
• Tools nào được phép sử dụng.
• Thứ tự thực hiện.
• Những bước kiểm tra an toàn bắt buộc.
• Cách xử lý lỗi và rollback.
• Tiêu chí xác minh và nghiệm thu.
• Cấu trúc của phần trả lời cuối cùng.
• Tài liệu tham khảo, template hoặc script đi kèm.

Khi đó, Ari không chỉ biết admin API tồn tại. Ari biết cách dùng API này trong một quy trình tạo tài khoản đầy đủ: kiểm tra dữ liệu, tạo hoặc đối chiếu tài khoản, gán đúng role, kích hoạt, thử đăng nhập và dọn dẹp nếu quá trình thất bại.

Ranh giới giữa Tool và Skill rất quan trọng:

Tool cung cấp một hành động. Skill cung cấp cách dùng các hành động để hoàn thành công việc đáng tin cậy.

Skill cũng không tự cấp quyền truy cập.

Nếu Ari có Skill xuất bản bài viết nhưng không có CMS Tool đã được xác thực, Ari biết quy trình nhưng không thể thực hiện. Ngược lại, nếu Ari có CMS Tool rất mạnh nhưng không có Skill xuất bản, Ari có năng lực nhưng thiếu cách làm ổn định.

Giai đoạn 8 - Ari bước vào nơi làm việc (Persistent Guidance)

Từ khóa kiến trúc: Persistent Guidance - Những quy tắc và kỳ vọng lâu dài, giúp agent hiểu cách làm việc trong phạm vi người dùng, tổ chức, repository hoặc subsystem.

Skill nói cho Ari biết cách hoàn thành một loại nhiệm vụ. Nhưng Ari còn phải hiểu nơi mình đang làm việc.

Mỗi môi trường có những quy ước riêng:

• Dự án dùng package manager nào?
• Sau khi sửa code cần chạy test gì?
• Tệp mới phải được đặt ở đâu?
• Thư mục nào chỉ được đọc?
• Secret phải được xử lý như thế nào?
• Website tổ chức nội dung theo cấu trúc nào?
• Hành động nào cần con người phê duyệt?
• Workflow chuyên biệt nào áp dụng cho repository này?

Đây không phải chỉ dẫn cho một yêu cầu duy nhất. Chúng là những kỳ vọng tồn tại qua nhiều công việc.

Persistent Guidance nên có phạm vi.

Quy ước cá nhân có thể áp dụng trên nhiều dự án. Quy tắc của repository chỉ nên áp dụng trong repository đó. Một thư mục con hoặc subsystem có thể cần Guidance cụ thể hơn phần còn lại của hệ thống code.

Có thể hình dung chuỗi Guidance như sau:

Thiết lập cá nhân
      |
Chính sách tổ chức hoặc máy
      |
Repository Guidance
      |
Directory hoặc Subsystem Guidance
      |
Yêu cầu hiện tại của người dùng

Guidance ở phạm vi hẹp bổ sung hoặc chuyên biệt hóa Guidance rộng hơn. Tuy nhiên, các quy tắc an toàn có thẩm quyền cao hơn vẫn tiếp tục được áp dụng.

Điểm khác nhau giữa Persistent Guidance và Skill là:

Persistent Guidance giải thích Ari nên hành xử thế nào trong môi trường này. Skill giải thích Ari nên hoàn thành một loại công việc như thế nào.

Giai đoạn 9 - Ari gặp cửa khóa (Guardrails và Permissions)

Từ khóa kiến trúc: Guardrails và Permissions - Những giới hạn về hành vi và khả năng thực thi, dùng để kiểm soát quyền truy cập, rủi ro, approval và hành động phá hủy.

Agent có thể làm việc thật thì cũng có thể gây ra hậu quả thật.

Vì thế, hệ thống đáng tin cậy cần Guardrails quanh mỗi nhóm hành động quan trọng:

• Authentication: Ari đang hành động dưới danh tính nào?
• Authorization: Danh tính đó được truy cập hoặc thay đổi những gì?
• Sandboxing: Tệp, lệnh, network và tài nguyên nào đang được cô lập?
• Approvals: Hành động nào cần con người xác nhận?
• Least privilege: Agent có nhiều quyền hơn mức cần thiết không?
• Validation: Mục tiêu đã được xác định chính xác trước khi thực hiện hành động nguy hiểm chưa?
• Rollback: Có thể phục hồi nếu thay đổi mới chỉ hoàn thành một phần không?
• Auditability: Người vận hành có biết agent đã thử làm gì và đã thay đổi gì không?

Guardrails không nên chỉ tồn tại trong Prompt.

Một Skill có thể nhắc Ari không xóa dữ liệu production khi chưa được đồng ý. Nhưng hệ thống sẽ an toàn hơn nếu token mà Ari sử dụng vốn không có quyền xóa. Instruction giúp định hướng hành vi. Permission tại Tool và dịch vụ bên ngoài giới hạn năng lực thực tế.

Hệ thống trưởng thành cần cả hai.

Giai đoạn 10 - Ari có phòng điều khiển (Runtime Configuration)

Từ khóa kiến trúc: Runtime Configuration - Thiết lập vận hành dùng để chọn Model, Tools, tích hợp, policy và giới hạn thực thi.

Lớp cuối cùng là môi trường vận hành nơi các thành phần được nối với nhau.

Runtime Configuration có thể quyết định:

• Model và mức reasoning được sử dụng.
• Tools và integration nào đang khả dụng.
• MCP server nào được kết nối.
• Chế độ sandbox và approval.
• Agent có được truy cập network hay không.
• Hook nào chạy quanh command hoặc lifecycle event.
• Cách logging và observability hoạt động.
• Skills nào được phép dùng.
• Project override nào đang có hiệu lực.
• Authentication provider và credential source nào được chọn.

Runtime Configuration không giống Guidance.

Nếu một quy tắc nói "hãy hỏi trước khi chạy destructive database migration", đó là Guidance về hành vi. Nếu runtime chặn command cho đến khi con người phê duyệt, đó là enforcement.

Nếu Skill nói "khi xử lý incident, hãy tạo ticket trong hệ thống của công ty", Runtime Configuration là phần kết nối ticket Tool và cung cấp phương thức xác thực phù hợp.

Có thể gói gọn mối quan hệ này như sau:

Runtime Configuration chuẩn bị môi trường. Guidance định hình hành vi. Skills cung cấp quy trình. Tools cung cấp năng lực. Agent Loop điều phối toàn bộ công việc.

Mental model cô đọng nhất

Nếu chỉ muốn nhớ một phần của bài viết, hãy nhớ sơ đồ này:

Model
  Đọc Context và đề xuất đầu ra hoặc hành động

Prompt và Context
  Xác định mục tiêu hiện tại và thông tin đang có

Tools
  Cho phép agent quan sát hoặc thay đổi hệ thống bên ngoài

Agent Loop
  Nối hành động, kết quả, điều chỉnh và xác minh

Memory và State
  Giữ mạch công việc trong và giữa các nhiệm vụ

Skills và Workflows
  Cung cấp quy trình ổn định cho công việc lặp lại

Persistent Guidance
  Giải thích agent nên hành xử thế nào trong một phạm vi

Runtime Configuration và Guardrails
  Xác định thứ gì được kết nối, cho phép, chặn hoặc cần approval

Tìm hiểu tiếp với Codex

Codex là một cách triển khai cụ thể cho nhiều lớp trong mental model này. Phần tùy chỉnh Codex nên được giải thích trong một bài riêng để tránh biến bài nhập môn thành tài liệu cấu hình quá dài.

Đọc tiếp Codex hoạt động như thế nào: MCP Tools, Skills và AGENTS.md.

Bài tiếp theo đi sâu vào ba lớp:

• MCP Tools kết nối Codex với dịch vụ bên ngoài và các hành động được kiểm soát.
• Skills toàn cục và Skills trong repository đóng gói những Workflow có thể tái sử dụng.
• Các tệp AGENTS.md ở cấp cá nhân, repository và thư mục con tạo ra Guidance theo phạm vi.
• Ba lớp này phối hợp ra sao khi Codex xử lý một nhiệm vụ thật.

Lời kết

AI agent không chỉ là chatbot được gắn thêm vài API call.

Đó là một hệ thống trong đó Model hoạt động bên trong môi trường, nhận mục tiêu và Context, chọn hành động được kiểm soát, đọc kết quả, duy trì State, làm theo Workflow, tôn trọng Persistent Guidance và tiếp tục cho đến khi công việc hoàn thành hoặc bị chặn một cách an toàn.

Ari bắt đầu với một bộ não. Tools cho Ari tay và mắt. Agent Loop tạo ra nhịp làm việc. Memory và State giữ mạch công việc. Skills cung cấp cách làm đã được rèn luyện. Persistent Guidance giúp Ari hiểu nơi mình đang làm việc. Runtime Configuration và Guardrails tạo ra môi trường vận hành an toàn.

Chính kiến trúc nhiều lớp này biến một câu trả lời được tạo ra thành công việc có thể kiểm tra, sửa chữa và chịu trách nhiệm.