AI Is Already Good Enough—the Hard Part Is Choosing the Right Harness
Not long ago, I was breaking down a HubSpot query request. The goal fit into one sentence: employees should be able to use natural language to query the data they are authorized to see.
It sounded like a simple matter of connecting a model to an API. The model could understand the question, and HubSpot had an API. But turning a natural-language question into a real request still required a system in between to call tools, pass parameters, and organize the results.
I started by exploring the Dify route. Dify can connect models, processes, and external tools. When the query path is fixed, a Workflow app can define the steps in advance: an LLM interprets the question, then a HubSpot tool node queries the CRM. For more open-ended questions, a Classic Agent node can be added to the Workflow so the model chooses a tool at runtime.
Both approaches can call only tools configured in advance on the platform. Neither provides an environment where software can be installed, files saved, and commands executed.
Dify Has Two Agent Systems
Dify still supports the Legacy Agent app. It is a standalone application type, whereas the Classic Agent node sits inside a Workflow. But both let the model call preconfigured tools, and neither has a general-purpose Shell that can run the HubSpot CLI directly.
Dify 1.16 also introduced Dify Agent (Beta), which the official documentation also calls New Agent. It is an Agent entity that can be managed and reused across a workspace. It has its own Agent Runtime and Linux Sandbox, allowing it to execute commands, install programs, and read and write files.
A Dify Agent can be published on its own or called through the New Agent node in a Workflow. The node is only an entry point. The Dify Agent is what actually carries the capabilities and runs with the Sandbox.
As of August 25, 2026, Dify Agent with a Linux Sandbox is not publicly supported as a Dify Cloud SaaS feature; it appears only in the Self-host documentation. Therefore, if a solution depends on the HubSpot CLI, the option with explicit support is a self-hosted Community Edition deployment, not Dify Cloud.
This is where the Harness truly enters the picture. It is not a particular application type, but the combination of model, tools, identity, permissions, credentials, and Runtime. The model determines whether the AI knows how to do the job. The Harness determines whether it can do the job in a real business environment.
Runtime Changes the Identity and Permission Model
One option is to use a Private App Access Token. It represents the application, not the employee asking the question. Every query uses the same application permissions by default. Restricting what each employee can see requires a separate way to identify that employee and filter the data.
Another option is to give each employee their own HubSpot Personal Access Key. This Key is used by the HubSpot CLI and local development tools, and the Scopes available to it are limited by that employee’s HubSpot user permissions.
The personal Key approach requires an isolated execution environment. The Sandbox must be able to install the HubSpot CLI, store the employee’s ~/.hscli/config, and execute commands. Only then can the employee’s identity, CLI, and credentials be bound together.
Dify Agent’s Linux Sandbox makes this route possible, but it does not automatically give every employee a securely isolated account environment. The Community Edition Agent Runtime is not a hardened security boundary designed to isolate mutually untrusted users, and Dify does not automatically switch HubSpot credentials for each end user. The team still has to design credential distribution and environment isolation.
The official role of a Personal Access Key is to support the CLI and local development. Using it for an internal enterprise assistant also introduces costs for key storage, rotation, revocation when employees leave, and auditing. Whether it fully reproduces the record-level visibility of the HubSpot interface also needs to be verified separately.
What Is Good Judgment Worth Before a Prototype?
Without a clear understanding of these differences, a team can easily get halfway through implementation before discovering that the chosen solution has no CLI Runtime. Switching to Community Edition then introduces new operational and security costs. Whether credentials represent an application or an employee also leads to entirely different permission models.
A prototype can reveal these issues, but prototypes require engineers, environments, and time. Some solutions are technically possible yet not worth that investment.
This case also made me more certain of the value of AIBPs and FDEs. An internal AIBP (AI Business Partner) translates requirements, permissions, costs, and business metrics into an AI solution. A vendor-side FDE (Forward Deployed Engineer) validates product boundaries and delivers the solution.
They begin by turning the goal into constraints: Are the queries fixed? Must tools be selected dynamically? Does the identity belong to an individual or an application? Is the CLI required? How granular must permissions be? How much deployment and operational cost is the company willing to bear? They then eliminate the routes that cannot work and reserve the smallest possible technical validation for the uncertainties that remain.
The AIBP is closer to the business decision; the FDE is closer to technical delivery. Their value comes from the same place: shortening the distance between a business problem and the right system.
Decide First, Then Build the Demo
For this HubSpot request, my conclusion is straightforward. If application-level credentials are acceptable and the process is stable, use a Workflow app. If user intent is open-ended, add a Classic Agent node and restrict the tools available to it. Only if employees must use their own CLI identity should the team evaluate Dify Agent with a Linux Sandbox—and accept the accompanying costs of key management, isolation, and operations.
The demo now needs to answer only two questions: whether a Personal Access Key fully inherits an employee’s record visibility, and whether the isolation design can contain the credential risk. Until those are clear, expanding the prototype has no value.