Các tác nhân (agent) có giá trị vì nhiều lý do, nhưng đến giờ tôi nghĩ chúng ta đều có thể đồng ý một điều: ngày càng có khoảng cách giữa việc xây dựng tác nhân trở nên dễ dàng như thế nào và số lượng tác nhân sản xuất có ROI cao mà doanh nghiệp thực sự triển khai lại ít ỏi ra sao.
Các công cụ ngày càng tốt hơn, và chúng ta liên tục nghe nói rằng việc xây dựng đang trở nên phổ biến hóa, nhưng tốc độ các công ty đạt được giá trị kinh doanh bền vững từ tác nhân hầu như không cải thiện với cùng một nhịp độ.
Tôi đã nói điều gì đó liên quan tại Snowflake Dev Day tuần trước, khi chúng tôi công bố tích hợp sâu hơn giữa CrewAI và Snowflake:
Đó là cách rõ ràng nhất tôi biết để mô tả một trong những phần khó khăn về tác nhân doanh nghiệp.
Các công ty cần năng suất xây dựng tác nhân không vi phạm các quy tắc mà doanh nghiệp vận hành, và công việc thực tế nằm trong các quyền truy cập, ranh giới dữ liệu, lộ trình phê duyệt, quy tắc mua sắm, nhật ký kiểm toán và các hệ thống kinh doanh chưa bao giờ được thiết kế cho các hệ thống tác nhân. Nút thắt của tác nhân doanh nghiệp đã chuyển từ các trường hợp sử dụng và mô hình sang năng suất xây dựng dưới sự quản trị.
DocuSign là một trong những ví dụ mạnh mẽ nhất về việc một công ty làm đúng điều này. Họ đã xây dựng một vòng lặp vận hành xuyên suốt CrewAI, Snowflake, Salesforce và các hệ thống nội bộ, nơi công việc của tác nhân nằm trong quy trình kinh doanh thay vì giả vờ rằng quy trình đó không tồn tại. Hôm nay, chúng tôi hợp tác với DocuSign trong các trường hợp sử dụng trên toàn thế giới, hỗ trợ các chức năng vượt xa GTM, đây chính xác là mô hình mở rộng mà các công ty nên mong muốn từ hạ tầng tác nhân.
Các công ty đã xác định được 20, 100, đôi khi 800 trường hợp sử dụng tác nhân (tôi nghe con số 800 đó tuần trước từ một khách hàng tiềm năng, hiện đã là khách hàng trả phí). Nhóm AI của họ thực tế có thể triển khai khoảng 10 trường hợp trong năm nay, và chỉ một số ít người có thể duy trì các hệ thống này; mọi người khác trong công ty phải chờ đợi.
Nút thắt không phải là ý tưởng, cũng không phải là trí thông minh của mô hình. Nút thắt là năng suất: làm thế nào để xây dựng, triển khai và mở rộng quy mô các tác nhân trong các hoạt động phức tạp mà không biến mười kỹ sư thành chủ sở hữu vĩnh viễn của mọi quy trình làm việc.
Một thành phần lớn của các tác nhân hữu ích thực ra là dữ liệu, và dữ liệu có rất nhiều sức hút. Dữ liệu doanh nghiệp không muốn di chuyển. Nó nằm trong các hồ dữ liệu, ứng dụng SaaS, Snowflake, Salesforce và các hệ thống nội bộ với các chính sách truy cập tồn tại vì những lý do chính đáng. Khi quy trình làm việc của tác nhân kéo bối cảnh đó qua quá nhiều ranh giới, quản trị bị phá vỡ, và khi các tác nhân bị mắc kẹt trong một hệ thống, chúng thường không thể tiếp cận đủ xa để thực hiện công việc hữu ích.
Vì vậy, các nhóm bị mắc kẹt giữa hai lựa chọn tồi: hoặc duy trì sự quản trị và hẹp, hoặc mở rộng và tạo ra một mớ hỗn độn về quản trị. Cả hai đều không mang lại cho bạn các tác nhân sản xuất có tác động cao ở quy mô lớn.
Các công ty cần các tác nhân có thể hoạt động xuyên suốt doanh nghiệp mà không vượt ra khỏi các ranh giới mà doanh nghiệp đã tin tưởng, và họ cũng cần nhiều người hơn xây dựng các tác nhân đó, không chỉ riêng nhóm AI.
Tôi đã sử dụng cụm từ "orchestration có quản trị" (governed orchestration) để mô tả mô hình mà tôi thấy đang hoạt động trong sản xuất. Nó có nghĩa là các tác nhân phối hợp
CrewAI và Snowflake hợp tác để giải quyết bài toán quản trị (governance) trong xây dựng agent AI. Nền tảng Snowflake cung cấp lớp dữ liệu có quản trị (dữ liệu đáng tin cậy, quyền truy cập được kiểm soát, mô hình phân quyền), trong khi CrewAI cung cấp lớp xây dựng và runtime (tạo workflow agent, chạy, quan sát, tái sử dụng pattern). Mục tiêu không chỉ là "kết nối agent với database" mà là xây dựng hệ thống multi-agent có thể được nhiều người trong doanh nghiệp xây dựng, hoạt động ở quy mô lớn mà không phá vỡ quản trị.
AI trở nên thực tế cho doanh nghiệp khi nó hoạt động trong các ràng buộc của doanh nghiệp: dữ liệu đáng tin cậy, quyền truy cập được thực thi, mô hình được phê duyệt, và audit trail mà lãnh đạo có thể bảo vệ. Snowflake đã sở hữu quyền, lineage và mô hình truy cập dữ liệu mà nhiều doanh nghiệp tin tưởng. Cortex Agents phối hợp truy cập dữ liệu có cấu trúc và phi cấu trúc qua Cortex Analyst và Cortex Search, và CrewAI hiện tích hợp với cả hai.
Vấn đề không phải là giữ mọi thứ trong Snowflake (doanh nghiệp không hoạt động như vậy), nhưng dữ liệu nhạy cảm của doanh nghiệp không nên bị sao chép vào hạ tầng không được quản lý chỉ vì agent cần nó, và quyền truy cập mô hình không nên biến thành mỗi team quản lý key riêng, vendor riêng, và quy trình phê duyệt riêng.
Dữ liệu có quản trị là yếu tố chịu tải trong AI sản xuất, nhưng dữ liệu và mô hình không tự tạo ra kết quả kinh doanh. Chúng phải đi vào workflow vượt qua các hệ thống, gọi công cụ, xử lý lỗi và biết khi nào dừng. CrewAI biến dữ liệu và mô hình thành workflow agent có kiểm soát. Framework mã nguồn mở CrewAI (Flows) và Harness (Crews) đã được hơn 65% Fortune 500 sử dụng, và nhiều công ty trong số đó đang tham gia CrewAI AMP để doanh nghiệp phân quyền xây dựng agent trong khi vẫn giữ kiểm soát runtime tập trung.
CrewAI xem xét vấn đề xây dựng và runtime theo từng lớp vì mỗi lớp thất bại khác nhau trong sản xuất. Lớp nền tảng thiết lập các kiểm soát: quyền, truy cập mô hình, ranh giới dữ liệu, secrets, telemetry, FinOps. Các team cắm Snowflake, kết nối MCP servers, và để engineering định nghĩa các quy tắc. Lớp runtime giữ workflow sống sau demo: scale, human review, giới hạn thực thi, observability.
Khả năng quan sát, cơ chế thử lại và những trường hợp ngoại lệ khó chịu xuất hiện lúc 2 giờ sáng. Tầng xây dựng là nơi nhiều người tạo ra các agent hơn. Tôi quan tâm đến điều này vì mọi doanh nghiệp đều có nhu cầu về agent vượt quá khả năng đáp ứng của đội ngũ AI.
Chúng tôi đã có hơn hai tỷ lượt thực thi quy trình agent chạy qua CrewAI. Một bài học từ khối lượng đó tuy nhàm chán nhưng quan trọng: khoảng cách giữa một bản demo hoạt động và một quy trình sản xuất hầu như không bao giờ nằm ở mô hình. Nó nằm ở quản lý trạng thái, phục hồi, xác thực, bàn giao và biết phần nào của quy trình nên mang tính xác định.
Đây là lý do chúng tôi xây dựng CrewAI vừa là bề mặt xây dựng vừa là mặt phẳng điều khiển runtime. Studio là bề mặt xây dựng, một chuyên gia miền có thể bắt đầu với các agent, nhiệm vụ, tích hợp và các khối xây dựng tái sử dụng, trong khi một kỹ sư có thể đi sâu với Flows, Crews, công cụ, bộ nhớ và các mẫu thực thi trong cùng một môi trường. AMP là mặt phẳng điều khiển: chính sách, triển khai, khả năng quan sát, truy cập mô hình, quyền và các kiểm soát vận hành.
Sai lầm trong nhiều kiến trúc agent là coi agency là trung tâm của hệ thống. Trong sản xuất, agency là thứ bạn đặt một cách cẩn thận bên trong một quy trình xác định.
Flows quan trọng ở đây vì chúng cung cấp xương sống xác định: trình tự, trạng thái, phân nhánh, thử lại, leo thang và ranh giới giữa những gì agent quyết định và những gì quy trình kiểm soát. Các kho lưu trữ agent tái sử dụng, kho lưu trữ công cụ và kho lưu trữ kỹ năng giúp các đội không phải xây dựng lại cùng một thứ ở mười nơi. Kỹ thuật xác định các kiểm soát, và các chuyên gia miền xây dựng bên trong chúng.
Đây là sự thay đổi mà tôi liên tục quay lại: biến những người xây dựng của bạn thành những người hỗ trợ. Thay vì yêu cầu kỹ sư xây dựng mọi quy trình, hãy để họ xây dựng các bánh đà, như tích hợp, kiểm soát nền tảng, thành phần tái sử dụng, lan can bảo vệ, và sau đó những người gần nhất với quy trình kinh doanh có thể xây dựng các agent bên trong những ranh giới đó.
Đó là cách bạn đi từ 10 quy trình agent mỗi năm đến các agent chạy khắp công ty. Theo thời gian, agent
Agents are valuable for many reasons, but by now I think we can all agree on one thing: there is a growing disconnect between how easy it has become to build agents and how few high-ROI production agents enterprises are actually shipping.
The tools keep getting better and we keep hearing about building getting commoditize, but the rate at which companies are getting durable business value from agents has not improved at nearly the same pace.
I said something related at Snowflake Dev Day last week, as we announced a deeper integration between CrewAI and Snowflake:
It is the cleanest way I know to describe one of the hard parts about enterprise agents.
Companies need agent building throughput that does not break the rules the business runs on, and real work lives inside permissions, data boundaries, review paths, procurement rules, audit logs, and business systems that were never designed for agentic systems. The enterprise agent bottleneck has moved from use cases and models to building throughput under governance.
DocuSign is one of the strongest examples of what it looks like when a company gets this right, they built an operating loop across CrewAI, Snowflake, Salesforce, and internal systems, where the agent work sat inside the business process instead of pretending the process did not exist. Today we work with DocuSign on use cases across the world, supporting functions well beyond GTM, which is exactly the expansion pattern companies should want from agent infrastructure.
Companies have 20, 100, sometimes 800 agent use cases identified (I heard that 800 number last week from a potential customer who is now a paying customer). Their AI team can realistically deliver maybe 10 this year and only a handful of people can maintain these systems, everyone else in the company waits.
The bottleneck is not ideas, and it is not model intelligence either. The bottleneck is throughput: getting agents built, deployed, and scaled inside complex operations without making ten engineers the permanent owners of every workflow.
A big component of useful agents is actually data, anddata has a lot of gravity.Enterprise data does not want to move. It sits in data lakes, SaaS applications, Snowflake, Salesforce, and internal systems with access policies that exist for good reasons. When agent workflows pull that context across too many boundaries, governance breaks, and when agents stay trapped inside one system, they usually cannot reach far enough to do useful work.
So teams get stuck between two bad options: stay somewhat governed and narrow, or go broad and create a governance mess.Neither gets you high-impact production agents at scale.
Companies need agents that can act across the business without escaping the boundaries the business already trusts, they also need more people building those agents and not just the AI team.
I have been using the phrase governed orchestration to describe the pattern I see working in production. It means agents coordinate work across systems while the platform carries governance from the first design decision.
That, and a bunch more, has to move left.
Agent builders need to know which data they can touch, which models they can use, which tools they can call, what needs human review, and what happens when something fails. The builder experience needs to guide people toward governed choices, and the runtime needs to enforce those choices when nobody is watching. When both of those work together, you get a path where more of the enterprise can actually build agents without the platform losing control.
Snowflake has become a great governed data foundation in this stack.It is where a lot of enterprise context already lives, and it has the permission model those companies trust.
CrewAI is the build and runtime layer.It is where teams create the agent workflows, run them, observe them, and turn reusable patterns into something more people inside the company can use.
Together, the goal is not"agents connected to a database"That framing is too small. The goal is multi-agent systems that can be built by many and act at scale without breaking governance.
Snowflake's Summit theme was "Making AI Real for Business." That is the same fight we are in at CrewAI.
AI becomes real for business when it can operate inside the constraints of the business: trusted data, enforced permissions, approved model access, and audit trails leaders can defend.
Snowflake matters here because it already owns the permissions, lineage, and access model around data many enterprises trust. Cortex Agents coordinate access to structured and unstructured data through Cortex Analyst and Cortex Search, andCrewAI now integrates with both.
The point is not to keep everything inside Snowflake, enterprises do not work that way, but we do all know that sensitive enterprise context should not be copied into unmanaged infrastructure just because an agent needs it, and model access should not turn into every team managing separate keys, separate vendors, and separate approval paths.
Governed data is load-bearing in production AI, but data and models do not produce business outcomes on their own. They have to enter a workflow that crosses systems, calls tools, handles failures, and knows when to stop.
CrewAI turns data and models into controlled agent workflows. CrewAI Open Source framework (Flows) and Harness (Crews) has been the go to for over 65% of Fortune 500 company and now many of them are joining CrewAI AMP as how enterprises federate agent building while keeping central runtime control.
We think about the build and runtime problem in layers because each layer fails differently in production.
The platform layer sets the controls: permissions, model access, data boundaries, secrets, telemetry, FinOps. Teams plug in Snowflake, connect MCP servers, and let engineering define the rules of the road. The runtime layer keeps workflows alive after the demo: scale, human review, execution limits, observability, retries, and the ugly edge cases that show up at 2 a.m. The build layer is where more people create agents. I care about this because every enterprise has more agent demand than its AI team can satisfy.
We have had over two billion agentic workflow executions run through CrewAI. One lesson from that volume is boring but important: the gap between a working demo and a production workflow is almost never the model. It is state management, recovery, validation, handoffs, and knowing which parts of the process should be deterministic.
This is why we built CrewAI as both a builder surface and a runtime control plane. Studio is the builder surface, a domain expert can start with agents, tasks, integrations, and reusable building blocks, while an engineer can go deep with Flows, Crews, tools, memory, and execution patterns in the same environment. AMP is the control plane: policy, deployment, observability, model access, permissions, and operational controls.
The mistake in a lot of agent architecture is treating agency as the center of the system. In production, agency is something you place carefully inside a deterministic process.
Flows matter here because they provide the deterministic backbone: sequencing, state, branching, retries, escalation, and the boundary between what the agent decides and what the process controls. Reusable agent repositories, tool repositories, and skills repositories keep teams from rebuilding the same thing in ten places. Engineering defines the controls, and domain experts build inside them.
This is the shift I keep coming back to: turn your builders into enablers. Instead of asking engineers to build every workflow, have them build the flywheels, things like integrations, platform controls, reusable components, guardrails, and then the people closest to the business process can build agents inside those boundaries.
That is how you go from 10 agent workflows a year to agents running across the company. Over time, the agent
