Harness Architecture in Practice: A Full Breakdown of Enterprise-Grade Agents from Deployment to Production

Title

Harness Architecture in Practice: A Full Breakdown of Enterprise-Grade Agents from Deployment to Production

Meta Description

A deep dive into a hands-on enterprise agent project built on the Harness engineering architecture: Vue + FastAPI front and back ends, ASGI streaming deployment, MCP gateway integration with ERP, sandbox isolation for Skill security and user data, covering the full deployment workflow and interview talking points for LLM engineering in production.

Article Content

The bar for LLM job interviews is rising. In a video, an instructor who has long provided career coaching noted that interviewers now clearly lean toward two specific questions when evaluating LLM application developers: Is the agent you built a multi-agent architecture? Does it use the Harness (harness engineering) architecture? Behind these two questions is really the same point: what enterprises want is not an agent that can run a demo, but a production-grade agent that can plug into existing business systems, isolate user data, and run securely.

Two Directions in LLM Careers Determine What You Need to Learn

The instructor subjectively divides LLM-related roles into two categories. One is the algorithm research direction, responsible for pretraining and version iteration, with high requirements for academic credentials and papers, typically requiring a 985 master's degree or above. The other is the engineering implementation direction, taking an existing base model and combining it with enterprise business needs for custom development, fine-tuning, and inference optimization. Job titles vary widely—application engineer, agent engineer, LLM application algorithm engineer may all point to the same kind of work.

This classification is not an industry standard, but it explains a reality: for the same title "LLM algorithm engineer," Company A might be hiring someone for fine-tuning, while Company B might genuinely be hiring for pretraining. For job seekers, figuring out which direction the role they are applying for falls into is far more useful than memorizing job titles. And an agent project built on the Harness architecture is precisely the most impressive work sample in the engineering implementation direction.

What the Harness Architecture Is and Why Interviewers Care

According to the video, Harness is a new architecture proposed after January 2026, called "harness engineering" (驾驭工程) in Chinese. It deals with the orchestration of complex tasks—when an agent needs to call multiple external models, read and write to existing enterprise systems, and generate and manipulate files, how these capabilities are organized and constrained is what Harness addresses.

The project demonstrated by the instructor connects the reasoning model to DeepSeek^Ad, uses Zhipu as a backup model, and also configures a summarization model. Multiple models each play their role under unified scheduling by the agent—this is an intuitive manifestation of the Harness architecture in multi-model collaboration. Interviewers care about it because it corresponds to real enterprise development scenarios, not a teaching demo.

Harness (驾驭工程, harness engineering) has not yet formed a unified industry standard; it is closer to a summary of a class of engineering practices: when an agent is no longer just single-turn Q&A but must schedule multiple models, call external tools, and read and write files and business systems, a dedicated layer responsible for orchestration and constraints is needed. This layer typically includes responsibilities such as task decomposition, tool routing, context management, failure retry, and permission boundaries, so that the reasoning model focuses only on "thinking," while "how to do it safely" is handed to the outer framework. Therefore, it is fundamentally different from simply writing prompts and connecting to a model API; the assessment point is whether the candidate understands the control flow and exception handling of agents in production environments.

Project Overview: An Intelligent Procurement Assistant Based on ERP

This hands-on project is an intelligent procurement assistant built on an existing ERP system. In reality, many companies already had systems like CRM and ERP running before adopting LLMs; a newly built agent cannot exist independently and must integrate with these legacy systems, read data, and deliver results. The project chooses ERP as an example to simulate exactly this scenario of "an agent embedded in existing systems."

The overall framework is front end plus back end. The front end uses Vue on port 3000; the back end is FastAPI on port 8090. The agent reads data from the ERP through the MCP protocol and a gateway. This design brings the question of "how an agent securely accesses enterprise data" to the forefront and is also an engineering detail in the project worth mentioning.

MCP (Model Context Protocol) is a protocol that lets models or agents access external data sources and tools in a standardized way. Its value lies in abstracting "what an agent can call and how it calls it" into a unified interface description, so the agent does not need to write separate adapter code for each internal enterprise system. Instead, capabilities are exposed through an MCP Server and calls are managed uniformly by a gateway. The gateway here assumes the roles of authentication, auditing, and traffic consolidation, allowing enterprises to control that the agent can only read authorized ERP fields and preventing the model from directly holding database credentials. This is also the technical point behind the article's emphasis on "how an agent securely accesses enterprise data."

Why Agents Should Run in an ASGI Service

After the agent is developed, it must be deployed to a back-end service. In the project, this back end is an ASGI service carried by the UV framework.

The instructor gives two reasons: handling high-concurrency requests and true streaming output. These two points are critical for enterprise production environments—users interact with the agent through the front-end interface, and the response cannot wait until the entire task is finished to be emitted; streaming output is the foundation of the experience. So he emphasizes that while it is fine to casually run agents for personal use, deploying agents into an ASGI service is standard practice in enterprise environments.

ASGI (Asynchronous Server Gateway Interface) is an asynchronous-oriented web service interface standard in the Python ecosystem. WSGI, commonly used in the Flask era, is synchronous: one request occupies one worker thread, and with long-running tasks like agents, it is easy to saturate the thread pool. ASGI is based on async/await, so a single process can concurrently handle a large number of waiting-type requests and natively supports streaming response methods such as Server-Sent Events. The UV framework mentioned in the article is an ASGI-based Python runtime and package management tool; using it to host services provides both asynchronous concurrency and a faster dependency installation experience.

Sandbox: Solving Both Skill Security and User Isolation

The other key design in the project is the sandbox service. In the video demonstration, the instructor starts OpenSandbox-Server on a Linux server and enters the corresponding Python virtual environment.

The sandbox addresses two problems. The first is the security risk of Skills—Skills may be downloaded from the internet or generated by the LLM itself; the project itself can help users generate Skills, and an uncontrollable source means risk. The second is isolation between users: after the front end is connected, both Zhang San and Li Si can use this agent, and the files they operate on and generate must be invisible to each other.

The approach is to allocate an independent sandbox container to each user. Zhang San's sandbox belongs only to Zhang San; the intermediate files and analysis reports he generates cannot be accessed by others, and isolation is inherent. The instructor also explains that a sandbox is essentially multiple containers—a concept that has existed in programming for over a decade and should not be mystified. Container environments may differ by user, so the project also prepares an image repository with multiple different images ready in advance for allocation.

A Skill refers to a packaged capability unit that an agent can invoke, usually in the form of executable code or a tool description, which the agent loads and executes on demand. Because a Skill may be dynamically generated by the model or obtained externally, its code content is untrusted; executing it directly in the main service process is equivalent to giving uncontrolled code server privileges. Container sandboxes use mechanisms such as namespaces and cgroups to limit the file system, network, and resource usage. Even if a Skill behaves maliciously, the impact is confined to a single container, and the cost of destroying and rebuilding is low—this is exactly why it has become the default security foundation for enterprise-grade agents.

External Integration: Suppliers and Existing Systems

As a procurement assistant, the agent needs to be associated with suppliers. In the project design, it accesses supplier websites through crawlers or APIs, for example scraping information from quotation pages. Combined with the aforementioned ERP data reading, the entire chain is: the agent runs in a sandbox → reads ERP through the MCP gateway → retrieves supplier quotations through crawlers → completes reasoning and summarization through multi-model collaboration → returns to the front end in streaming mode via the ASGI service. This chain basically covers the common external dependencies of enterprise-grade agents.

It should be noted that this episode of the video only covers the overall framework; the specific functional details of the agent are left to the next episode. But even looking only at the framework, the positioning of this project is clear: it is not meant to show off some flashy agent capability, but to lay out the dirty work that cannot be avoided in enterprise implementation—deployment, security, isolation, and system integration—and provide an engineering solution for each. For those preparing for interviews, being able to clearly explain these design trade-offs is far more persuasive than memorizing concepts.

(This article is compiled based on a project explanation video by a Bilibili creator; the views and project design all come from this single source.)

One-line Summary

Enterprise agent interviews value the Harness architecture and multi-agent systems, with the core being deployment, security, and system integration.

Paragraph Summary

The article is compiled from a career coaching instructor's video and points out that LLM job interviews are shifting from "can run a demo" to assessing production-grade capabilities, with frequent questions focused on whether a multi-agent architecture is used and whether the Harness (harness engineering) architecture is adopted. The author divides LLM roles into algorithm research and engineering implementation, with the latter better suited to proving ability through hands-on projects. It then uses an ERP-based intelligent procurement assistant as an example to break down the key designs of enterprise-grade agents: a Vue front end and FastAPI back end with an ASGI service providing high concurrency and streaming output; secure reading of existing ERP data through the MCP protocol and a gateway; sandboxes allocating independent containers per user while solving both the security risk of uncontrollable Skill sources and data isolation between users; and DeepSeek for reasoning, Zhipu as backup, and a separate summarization model reflecting the multi-model collaboration form of the Harness architecture.