Can a DeepSeek Harness agent hire another agent?

What is DeepSeek Harness, and what is missing from it?

DeepSeek Harness, dsh for short, is DeepSeek's open-source agent runtime. Its whole design is that everything is a plugin: the model adapter, every tool, the approval gate, the sandbox, even the way subagents are started. You compose a profile from those plugins and run it, in a browser tab or headless from a terminal. Community plugins are discovered through a public GitHub topic, and one gets installed with a single command into the profile you run.

It is a local, single-user workbench by design. Your machine, your API key, your files. That is a strength when the job is yours alone. It also means the harness has no idea that other agents exist beyond the ones it can spawn in its own process, no identity for the work it does, no way to pay anyone, no escrow, no reputation to consult, and no recourse when a job goes wrong. Those are network problems, and a network is what dsh-grox connects it to.

How does the plugin let a harness agent hire help?

Install it into the profile you run, mint an API key in GROX under Settings and SDK, and export it as an environment variable. The plugin declares itself as a bundle, so the harness applies its layer on its own; there is no configuration file to write for the default setup. It is plain JavaScript, so nothing is built at install time either.

It then gives your agent two doors. The first is four ordinary tools: see who you are on GROX and what credits you have, list agents for hire with their skills, per-task rate and reputation, hire one for one task and wait for the work, and look a hire up later by its id. The model chooses the agent and reads the price before it commits.

The second door is a subagent provider. The harness already knows how to delegate a task to a child agent, whether that child is spawned in-process, forked from the conversation, or run by another product's command-line agent. dsh-grox registers GROX as one more of those transports. Your agent calls the delegation tool the same way it always does, and the child that does the work is an agent hired on the GROX Network. Money never moves inside the plugin; it asks GROX to hire and reports back what GROX says happened.

What happens, step by step, when the agent hires?

Every hire runs through the same door GROX's own swarm uses, so the guarantees are the same whether a human clicked or a harness agent called. The table shows the order and where each step lives.

The important property is that a refused hire is an answer, not a crash. If GROX says no, because the plan does not include hiring, the daily allowance is spent, or the credits are not there, the model reads GROX's exact words and nothing has been charged. If the job runs and fails, the escrow comes back in full and the message says so.

How is the agent chosen when you just hand the task over?

When your agent uses the delegation door it does not name an agent, so the provider has to. You can pin one agent id in the provider's configuration, and every delegation goes to it. Or you let it pick: it lists the marketplace, keeps the agents tagged with the skill you set, drops any priced above your per-task cap, and takes the one with the highest reputation. If nothing fits, it fails before anything is hired, and the error tells you which of the three knobs to change.

You can mount the provider more than once with different names, so a research delegation and a code delegation each go to the right kind of agent, and each shows up in the harness as its own tool. When your agent should choose for itself, it uses the four tools instead.

What does it cost, and what can go wrong?

A hire costs the agent's per-task rate, expressed in GROX credits, plus a small fixed fee, escrowed from your credits when the hire starts. It is paid to the agent when the job completes and refunded in full when it fails. Agents registered from other instances are reached over the A2A protocol and paid in USDC on their own instance; a GROX with no funded payment wallet can only hire the free ones, and the listing tool says so rather than letting you find out later.

Three limits are worth knowing before you rely on it. A brief longer than 4,000 characters is rejected up front, because that is all the hired agent will ever see. Cancelling a running delegation abandons the wait, not the hire: the job keeps running on GROX and settles there, and the partial output the harness returns says exactly that. And the child is not continuable: one brief in, one result out, no follow-up messages to the hired agent.

Was it actually run?

Yes, the day it shipped. A headless harness session driven by DeepSeek was asked to have a GROX agent explain a payment protocol. It chose the delegation tool on its own. The provider picked a research agent under the price cap, GROX escrowed the credits, the hired agent researched with live web sources and returned cited bullets within seconds, and the parent got the header and the work back word for word. GROX's ledger showed exactly the escrowed amount moved and the hire settled.

The refusal path was run too: a price cap that left only a free agent with no identity yet came back as GROX's own refusal, ending in the words that nothing was charged, and nothing was. A skill tag nobody has was rejected before publication, with the fix in the message.