DeepSeek Harness (DSH) is usually discussed as a coding harness. But its MCP client also creates a useful boundary for enterprise automation: DSH can plan and select a tool, while an RPA runtime performs the visible desktop work.
We tested that boundary with Astron RPA. The result was a real local execution chain, not a conceptual architecture diagram:
user goal
→ DSH planning
→ MCP tool call
→ Astron RPA
→ Excel workbook
→ local ERP sandbox
→ human approval gate
What actually ran
The prompt asked DSH to process three synthetic purchase orders. It also imposed a hard constraint: any high-risk action had to stop for human approval, and no final submission was allowed.
DSH produced a short plan and made one MCP call to Astron's excel_to_erp_human_approval capability. Astron then performed the desktop-side work:
- opened the local demonstration workbook;
- read the purchase-order range
A5:H7; - carried the three rows into a local ERP sandbox as drafts;
- evaluated the demo risk rule;
- stopped the high-value order before the final business action.
The three draft values were ¥1,700, ¥1,600, and ¥58,800, for a total of ¥62,100. The first two remained ordinary drafts. The ¥58,800 order crossed the demonstration threshold and entered a human-approval state.
The important interface is responsibility, not branding
DSH and Astron RPA do different jobs.
- DSH plans. It interprets the goal, keeps the constraints in context, and selects the MCP capability.
- Astron RPA executes. It interacts with desktop software, browsers, Excel, and the ERP interface.
- A human owns the irreversible decision. The risky order is surfaced for review instead of being silently submitted.
That separation matters in enterprise environments. APIs are useful when every system has a clean integration surface. Many real processes still cross spreadsheets, desktop clients, browser forms, and older line-of-business systems. An agent plugin that only returns text or calls a modern REST endpoint does not cover that gap.
Why start with an install preset instead of a native plugin
Astron RPA already exposes API and MCP service boundaries, and DSH already includes an MCP client. That means the first useful release does not need a bespoke native plugin.
A smaller first package can contain:
- an install preset that registers the Astron MCP service;
- a bounded demonstration capability;
- a sample workbook and local ERP sandbox;
- an explicit human-approval rule for high-risk actions.
This validates the full operating loop before adding a deeper product-specific extension. A native plugin can come later if it improves discovery, configuration, or observability. It is not required to prove that the execution path works.
What is hard for ordinary plugins to copy
The moat is not another prompt template. It is the controlled bridge from planning to physical software operation:
- desktop application control;
- browser interaction;
- structured Excel reading;
- ERP-style draft creation;
- risk classification;
- a visible handoff to a human before an irreversible step.
Each part is observable. The DSH session shows the tool call and result. The Astron application shows the available automation. Excel shows the source rows. The ERP sandbox shows the created drafts and the approval dialog.
Scope and safety
This demonstration used only synthetic purchase-order data and a local ERP sandbox. It did not touch a live ERP, create a real purchase order, authorize a payment, or perform a final submission. The approval button was intentionally disabled for automation.
That boundary is the point: enterprise agents should be able to automate routine work without inheriting authority for every consequential action.
Evidence
The short version is simple: DSH decides what should happen, Astron RPA makes it happen on the desktop, and a human keeps the final say when the risk is high.
Top comments (0)