Write the Job Description First: What DeepSeek Harness Presets Teach About Enterprise Agent Design

Last month I sat down with a freight operations team that wanted to pilot an AI agent. Their opening line: “We want to use DeepSeek’s model — we heard it’s cheap.” I asked a different question: when this agent goes live, who is it? A quoting assistant for sales? A tool that checks space and routing for the operations desk? Or a general helper that does a bit of everything? They paused. They hadn’t thought about it.

That pause is more dangerous than a wrong model choice. A wrong model can be swapped out. An undefined role means the agent starts its first day of work not knowing who it is.

An agent preset splits the role into four layers

DeepSeek Harness, released in August 2026, is DeepSeek’s first agent product. Its central concept is the agent preset — a configuration that decides which tools, prompts, skills, and sub-agents a session’s agent can see. It is also the cleanest decomposition of an agent I have seen:

• Model = the brain. It sets the baseline for reasoning and comprehension.
• Skill = the playbook. It tells the model how to handle a specific class of task.
• Tool / plugin = software and permissions. It decides whether the agent can search, edit files, run commands, or send email.
• Preset = the job plus the working environment. Identity, standing rules, available tools, and working style are all defined here.

Translated into enterprise language: an agent preset is a job description, tools are office permissions, skills are the operating manual, and the model is the brain. When you hire a person, you do not start by buying a laptop. You write down what the role does, where its boundaries are, and which permissions it needs. Enterprise agent adoption should follow the same order.

Most companies run the order backwards

The sequence I see on the ground is: compare models (which is smarter, which is cheaper) → assemble a framework → only then ask what the agent is actually responsible for. The result is a beautiful demo that falls apart in real work, because it has no identity, no boundaries, and no one to accept its output.

This is not a model problem. The same model produces visibly different results under different tool organization, context management, and execution strategy. Run the same DeepSeek-V4-Flash model inside three different agent execution environments on the same task, and the outputs are clearly different. Same model. What changed was the execution layer around it.

So “pick the best model first” is the wrong question. The first question is: what is this agent’s job? What are its standing rules? What is it allowed to touch, and what must it never touch?

A one-page job description, four items

When I design an agent for a client, I write a one-page “agent job description” first. Four items:

1. Identity. Who is it? A “freight quoting assistant” and a “general customer service bot” are two completely different jobs. Identity decides which tasks it accepts, in whose voice it responds, and what outcome it is accountable for.

2. Standing rules. What must it always do, what must it never do, which rules can never be broken. For a quoting agent, a standing rule might be: confirm origin port and destination port before quoting; if schedule data is missing, say so explicitly — never invent it. The rules live in the preset, which is the same as putting them in the job description, instead of reminding the model every conversation.

3. Tools and permissions. Can it touch the system? Write back to the database? Send email? This is the tool/plugin layer. The permission boundary sets the ceiling on the cost of its mistakes. Give it too much access and the company will never let it near real work; give it too little and it cannot do anything.

4. Working style. Does it work alone, or does it need sub-agents, multi-step flows, and periodic review? How does it organize context and handle long-running tasks? This layer decides whether it can actually finish an end-to-end piece of work, instead of answering a single question.

Only after these four items do you choose a model, configure skills, and open permissions. The model determines how smart the agent is. The job description determines what it does, where its boundaries are, and how it gets accepted.

What an agent without a job description looks like

Here is a pattern I keep meeting on site: a company gives its agent huge permissions — “it can read every spreadsheet, every chat log, and reply to customers.” It sounds powerful. But when it is time to go live, the business owner refuses to use it, because nobody can say what it will do, when, and who to blame when it goes wrong.

That is the price of “doing everything”: an agent without boundaries is a process without an owner. I wrote earlier about why AI projects stall when no one owns the process outcome; an agent without a job description is the other side of the same coin. The process has an owner, but the person doing the work does not know their own role boundary, so acceptance is impossible.

Once the job description exists, several problems disappear by themselves. Acceptance metrics become clear (judge the agent by its role’s results, not by whether “AI ran”). Permission approvals get a basis (grant exactly what the role needs). Exception handoff becomes concrete (anything outside the role’s boundary goes to the corresponding human owner).

Scope and what I cannot yet prove

This framework comes from DeepSeek Harness’s product design and from failure patterns I have repeatedly hit in real business. It fits teams that have already decided to build an agent but have not yet decided who the agent is.

I am not claiming a one-page document guarantees success. It is a necessary condition, not a sufficient one. Three things I still do not have complete answers for, and I want to be honest about that:

• Real business exceptions are always more numerous than what gets written down. Who maintains the rules, and how often? I currently rely on a process owner as the backstop; I do not yet have a scalable answer.
• The DSH preset system itself is still in beta, and features may differ from the final release. It proves a preset is a viable design; it does not prove every agent product should work this way.
• Could “agent job design” harden into a new kind of organizational rigidity — the role is so fixed that the agent loses flexibility? My instinct is to define first and loosen later, but I do not have enough samples to validate that yet.

A judgment you can carry away

Treat enterprise agent adoption like hiring a person, not buying a computer. Write the job description first: identity, standing rules, tool permissions, working style. Then choose the model, configure skills, and open permissions. The model sets the floor; job design sets the ceiling.

The most useful thing to copy from DeepSeek Harness is not a feature — it is the order of operations. It separates “the role” from “the model.” Enterprises should do the same: answer who this AI is, what it does, and where its boundaries are, before answering which model to use. If the first question is unresolved, the second does not matter.

Continue reading: find the process owner before you scale an AI workflow; how agents move from tasks to a formal work unit; how SOP defines an agent’s boundary. Full path: Organization & Service Growth.