Harness Engineering in Practice: A Guide to Enterprise-Grade Multi-Agent System Architecture

What Is Harness Engineering?

The job market for AI and LLMs is quietly shifting. Whether in algorithm research or LLM application development, interviewers are raising the bar for technical depth. Against this backdrop, a new architectural concept is entering the spotlight for both enterprises and hiring managers — Harness Engineering.

According to content shared by Bilibili creator Mashibing (Mashi Group), the Harness architecture is a new framework proposed by Anthropic after January 2026, translated into Chinese as "驾驭工程" (literally "taming engineering"), designed specifically for intelligent agent systems that handle complex tasks. It's worth noting that Anthropic, the company behind the Claude series of LLMs, has long focused on AI safety and reliability. The Harness architecture emerged as their engineering answer to a fundamental question: how do you keep multiple agents working together without losing control? While a single agent's capabilities can be clearly bounded and managed, multi-agent collaboration easily devolves into runaway call chains, cascading errors, and privilege escalation. The core value of Harness architecture lies in providing a complete "harnessing" mechanism — when a single agent can no longer handle enterprise-grade complexity, this framework enables you to orchestrate multiple models, tools, and services in an orderly way, building a multi-agent system that can genuinely operate in production.

This concept resonates with interviewers because it touches on the hardest part of deploying LLMs in practice — not just getting an agent running, but running it safely, stably, and in an isolated manner within an enterprise production environment.

Called LLM Algorithm Engineer

Two Career Paths in AI and LLMs

Before diving into Harness engineering projects, it's worth clarifying the two main career tracks in the LLM field today.

Algorithm Research

This track focuses on creating or updating new versions of foundation models. For example, DeepSeek hiring algorithm engineers to participate in the next version's pre-training work. These roles typically demand strong academic credentials and published research — usually a master's degree or higher from a top-tier university. Pre-training work involves large-scale distributed training, data cleaning and mixing, model architecture innovation, and other highly specialized tasks that typically rely on clusters of hundreds to thousands of GPUs. This is the domain of a small number of elite research teams.

Engineering and Deployment

The other track involves customized development based on existing foundation models, tailored to specific business needs. This covers a broad range — model fine-tuning, traditional algorithm integration (e.g., YOLO for object detection), inference optimization, and so on. The focus is on "using models" and "fine-tuning models" rather than pre-training from scratch. Practitioners in this space need to be fluent in prompt engineering, RAG (Retrieval-Augmented Generation), agent orchestration frameworks (like LangChain or LlamaIndex), and model deployment and serving. Market demand in this track far exceeds that for algorithm research roles, and it's the realistic path for most job seekers.

One nuance worth mentioning: job titles aren't standardized. Two companies doing the same fine-tuning work might call the role "LLM Algorithm Engineer" at one place and "LLM Application Engineer" at another. For job seekers, understanding what the role actually involves matters far more than the title.

Hands-On Project: An AI-Powered Procurement Assistant Built on ERP

To address the evolving job market, this article presents a complete Harness architecture project — an intelligent procurement assistant built on top of an existing ERP system. The defining feature of this project is that it closely mirrors real-world enterprise scenarios.

Why Emphasize "Built on an Existing ERP System"?

Long before LLMs became popular, most enterprises had already built their own business platforms — CRM systems, ERP systems, or other internal tools. When a company introduces an AI agent, it almost never operates in isolation; it inevitably needs to integrate with existing systems.

In this project, the automated procurement assistant needs to read data from the company's existing ERP system. The project deliberately uses an MCP protocol combined with a gateway to access the complete ERP project data. MCP (Model Context Protocol) is a standardized protocol open-sourced by Anthropic in late 2024, designed to solve the problem of standardizing connections between LLMs and external data sources and tools. Before MCP, every AI application had to write custom integration code for each different data source, making maintenance extremely costly. MCP is essentially the "USB port" of the AI world — it defines a unified communication standard between models and tools/data sources, allowing agents to connect to databases, file systems, third-party APIs, and even enterprise ERP systems using the same protocol, dramatically reducing integration complexity. This design approach is the canonical pattern for deploying enterprise-grade agents in production.

Does it need to read from the existing ERP project in your company

A Frontend/Backend Separated Architecture

The overall project is divided into two parts:

Frontend: Built with Vue, running on port 3000
Backend: Built with FastAPI, running on port 8090

Why does an agent need a backend service? Because in an enterprise production environment, a finished agent ultimately needs to be deployed in an ASGI service. ASGI (Asynchronous Server Gateway Interface) is the standard interface specification for asynchronous Python web services — the async evolution of the traditional synchronous WSGI. Traditional WSGI dedicates one thread per request, which quickly exhausts thread pool resources under high concurrency. ASGI, based on an event loop mechanism, can handle thousands of concurrent connections in a single process, making it a natural fit for the streaming output and persistent connection requirements of agent workloads. This project uses uvicorn as the ASGI server — built on the high-performance uvloop and httptools, it is one of the best-performing ASGI implementations in the Python ecosystem. It addresses two critical challenges:

High-concurrency async handling — reliably processing high-frequency asynchronous requests
Agent streaming output — enabling true streaming responses from agents (using SSE or WebSocket protocols to push the model's token-by-token output to the frontend in real time, rather than waiting for the complete response before returning)

This is the fundamental difference between personal projects and enterprise production: a personal project can run however you like, but enterprise deployments require the agent to be properly deployed in an ASGI backend, exposed to users via a frontend (Vue, a mobile app, or a WeChat Mini Program).

Sandboxing: The Core Mechanism for Enterprise-Grade Security

If the architectural design is the skeleton of a Harness engineering project, the sandbox mechanism is the part that best reflects enterprise-grade engineering thinking. This project includes a dedicated Linux server running an OpenSandbox Server service to implement this capability.

Two Core Problems Sandboxing Solves

The agents in this project support SQL generation — SQL that may be downloaded from the internet or generated by the LLM itself, which introduces two problems that must be addressed:

First, SQL security. LLM-generated SQL carries significant security risks in an enterprise environment and cannot be executed directly without safeguards. When generating SQL, a model might produce destructive statements like DROP TABLE or full-table DELETE, or even generate SQL injection payloads under adversarial prompts. Executing these directly on a production database without isolation could cause irreversible damage.

Second, data isolation between users. The agent frontend is open to multiple users, and files generated by different users during their sessions must be strictly isolated to prevent data leakage or unauthorized access.

Achieving Natural Isolation Through Sandboxing

The sandbox approach is elegant in its simplicity: assign each user their own dedicated sandbox.

Take user Zhang San (ZS) as an example. When they use the agent, the system allocates a dedicated sandbox for them. All intermediate files generated during their complex tasks — analytical reports, PowerPoint files, and so on — are stored exclusively in their sandbox. Li Si has their own separate sandbox in the same way, with the two naturally isolated and completely independent.

Zhang San, I'll use the English abbreviation ZS

Technically speaking, a sandbox is essentially a set of containers. Container technology (Docker being the prime example) uses Linux kernel namespace mechanisms to achieve multi-dimensional isolation of processes, networks, and file systems, then leverages cgroups to limit maximum CPU and memory usage, enabling multiple mutually isolated execution environments to run safely on the same physical machine. This is a mature solution with over a decade of history, already deployed at scale across cloud-native infrastructure. Since containers require images, the project also includes an image registry: different users may need different container environments, and by preparing multiple images in advance, you can allocate containers with slightly different configurations to different users.

External Integration Capabilities of the Agent

As a procurement assistant, the agent also needs data connections to suppliers. The project uses web crawlers to access supplier websites and scrape pricing pages and key quote information. The crawler here serves the role of structured data collection — combined with the LLM's information extraction capabilities, it transforms unstructured web content into standardized quote data that can be referenced for procurement decisions.

Taken together, the entire multi-agent system connects to a rich set of external resources:

Reasoning model: DeepSeek
Fallback model: Zhipu AI
Summarization model: Separately configured
ERP data: Read via MCP protocol and gateway
Supplier data: Scraped via web crawler
Sandbox service: Ensures secure isolation
Image registry: Supports multi-container environments

Sandbox solves two core problems

Why Harness Engineering Is the Key to Enterprise AI Deployment

This ERP-based intelligent procurement assistant demonstrates that the value of Harness engineering isn't about showing off — it's about systematically "harnessing" disparate models, tools, and services into a complete, stable loop that can run reliably in an enterprise production environment. This philosophy aligns closely with software engineering's core principles of observability, maintainability, and scalability. Enterprises don't just need AI that "runs" — they need AI that can be debugged when it fails, scaled horizontally when demand grows, and safely isolated in multi-tenant scenarios.

For job seekers pursuing the engineering and deployment track, mastering the complete skill set of Harness architecture, MCP protocol integration, ASGI deployment, and sandbox isolation is the core competitive advantage for tackling increasingly demanding LLM engineering interviews. A truly enterprise-grade multi-agent system never tests just a single capability — it tests your comprehensive engineering ability to run complex tasks safely, reliably, and at scale.